...

• des cartes Mifare DesfireEV1 ou EV2
• un PC sous linux ou windows (l'encodeur ne fonctionne actuellement pas sous MAC OS)
• une imprimante à carte plastique ps/pcl (exemples : evolis primacy, zebra zxp7, ...)
• une webcam
• un lecteur de carte pc/sc (exemple : Identiv UTrust 3700 F)

...

Pour les établissements qui éditent une quantité conséquente de cartes à imprimer/encoder tous les ans (l'Université de Rouen Normandie qui a développé ESUP-SGC accueille 35.000 étudiants), en plus d'utiliser des imprimantes à cartes performantes pour l'impression (le fait de n'être pas lié à une API propriétaire spécifique permet de choisir l'imprimante que vous souhaitez), on propose d'utiliser une imprimante (avec lecteur nfc permettant l'encodage) pour procéder à l'encodage dans un second temps en utilisant les possibilités de chargement et d'encodage de l'imprimante par lot.
Actuellement on propose un tel "robot d'encodage" via un code spécifique à l'imprimante zxp3 de zebra. Dans le cadre de l'utilisation d'un autre type d'imprimante pour mettre en place cet encodage par lot, il faudra(it) porter le code sur l'API propriétaire spécifique à l'image que ce qui a été fait pour la zxp3 : https://github.com/EsupPortail/esup-sgc-client/tree/univ-rouen-robot-zxp3

Est-ce qu'ESUP-SGC est pensé pour être "multi-établissements" ?

Oui, une page dédiée à cette question est proposée sur ce WIKI.

Est-ce qu'ESUP-SGC a été pensé pour respecter le RGPD ?

Oui, une page dédiée à cette question est proposée sur ce WIKI.

ESUP-SGC

A quoi correspondent les rôles dans ESUP-SGC ?

...

La demande de carte peut être faite par l'appel d'un webservice (API). Cet appel ressemble à ceci:

...

Lorsque vous commanderez votre pré-encodées avec l'application Desfire, pensez à demander de positionner une master-key spécifique sur l'ensemble de vos cartes pour avoir la maîtrise de celle-ci !
(voir à ce propos la q/r "Comment avoir la master-key sur des cartes pré-encodées CROUS ?")

A quoi correspondent les Apps disponibles depuis le menu de l'interface web ESUP-SGC ?

Image Removed

Ces applications sont des applications clientes permettant de badger la carte en lecture ou/et écriture.

Ces liens se configurent par un administrateur depuis le menu Admin > NavBarApp.

Pour une mise en oeuvre simplifiée, cf les documentations sur ce wiki, vous pouvez :

• vous appuyer sur l'application Android officielle sur le playstore Google d'EsupPortail
• et générer les clients pour PC  depuis https://esup-sgc-client-web-installer.univ-rouen.fr/

Image RemovedEncodeur

Quelles informations sont échangées entre ESUP-SGC et l'API CROUS ?

ESUP-SGC échange avec l'API CROUS

• des données sur l'ayant droit (right holder) - cf RightHolder.java :
  identifier, firstName, lastName, email, dueDate, idCompanyRate, idRate, birthDate, ine, rneOrgCode, accountStatus, blockingStatus
• des données sur les cartes (smart card) - cf CrousSmartCard.java ; ces données correspondent aux données de sortie de la DLL CNOUS utilisée pour (pré)encoder les cartes avec l'application desfire crous/izly :
  idTransmitter, idMapping, idZdc, zdcCreationDate, pixSs, pixNn, appl, uid, rid
  (uid et rid sont tous deux valués avec le CSN)

A quoi correspondent les Apps disponibles depuis le menu de l'interface web ESUP-SGC ?

Image Added

Ces applications sont des applications clientes permettant de badger la carte en lecture ou/et écriture.

Ces liens se configurent par un administrateur depuis le menu Admin > NavBarApp.

Pour une mise en oeuvre simplifiée, cf les documentations sur ce wiki, vous pouvez :

• vous appuyer sur l'application Android officielle sur le playstore Google d'EsupPortail
• et générer les clients pour PC  depuis https://esup-sgc-client-web-installer.univ-rouen.fr/

Image AddedEncodeur

Lien esup-sgc de esup-sgc-client.jnlp qui lance le jar esupsgcclient-XXXX.jar
Lien esup-sgc de esup-sgc-client.jnlp qui lance le jar esupsgcclient-XXXX.jar
Le code source est sur https://github.com/EsupPortail/esup-sgc-client - branche master
C'est l'encodeur par défaut à utiliser avec esup-sgc, il requiert une webcam et un lecteur usb nfc. Cela permet l'encodage de carte une à une.
Le jar est fourni par défaut compilé dans esup-sgc, il est signé par l'Université de Rouen.

...

• côté serveur, pour esup-sgc et esup-nfc-tag, vous pouvez utiliser openjdk 11 (fourni par votre distribution) ; la version 8 est encore également supportée.
• côté client, 
  • pour esup-sgc-client, esup-nfc-tag-desktop, esup-nfc-keyboard, vous pouvez utiliser openjdk11 avec openjfx11, c'est ce que vous propose et embarque l'installateur windows que vous pouvez générer depuis https://esup-sgc-client-web-installer.univ-rouen.fr/
  • si vous utilisez la version 'robot' d'esup-sgc-client utilisant une zxp3 pour encoder en série les cartes,  cf la documentation à ce sujet vous devez rester sur une version 8 du JDK disposant de JFX (JavaFX) sur windows (le sdk zebra ne supportant pas les versions java ultérieurs), vous pouvez alors vous tourner sur la version de la communauté zulu du jdk+jfx en version 8 ; cf la documentation à ce sujet donc à nouveau.

Quelles optimisations serveur sont possibles ?

...

L'usage du protocole Mifare Desfire (et en excluant l'usage conjoint d'un CSN fixe ... ça exclue d'ailleurs de fait l'application Desfire de la Carte Etudiante Européenne qui propose la diversification de clef via le CSN ainsi que la signature via le CSN).
Théoriquement* on peut estimer pouvoir émuler une carte Mifare Desfire avec un Android. ESUP-NFC-TAG lui-même propose avec esup-nfc-tag-droid de jouer des APDU NFC Mifare Desfire au travers d'un téléphone pour interagir avec une carte Mifare Desfire. Jouer les APDU de la carte plutôt que ceux du lecteur n'est donc théoriquement* qu'une affaire d'implémentation des calculs des APDU, en se basant en plus sur les mêmes algorithmes de chiffrement déjà en place dans esup-nfc-tag-server. Si l'on souhaite ne pas donner les clefs des applications Mifare Desfire au téléphone (à proscrire pour des raisons de sécurité : les clefs manipulées directement par un logiciel dans un téléphone ne pouvant pas être considérées comme sécurisées - une personne malveillante étant susceptible de pouvoir les récupérer via différents scénarios), on peut en effet imaginer reprendre/étendre esup-nfc-tag : les apdu desfire sont calculés par le serveur esup-nfc-tag-server et esup-nfc-tag-droid ne fait que relais (proxy) avec le lecteur NFC de contrôle d'accès (sans jamais avoir connaissance des clefs notamment).
Cela présuppose que le téléphone ait une connexion internet pour dialoguer avec le serveur esup-nfc-tag-server au moment du badgeage de la carte. Le problème que cela pose également est qu'on se place alors dans un scénario qui ressemble à une attaque de type Man-in-the-Middle pour du contrôle d'accès sans contact : on se retrouve en effet à utiliser un téléphone pour faire proxy avec un mécanisme sécurisé (dans notre cas le serveur et non la carte d'une victime) permettant d'ouvrir une porte. C'est ce type de scénario et donc d'usage que NXP tente d'endiguer avec les évolutions de Mifare Desfire (EV1, EV2 puis maintenant EV3). En plus du problème technique que cela pourrait poser (avec des systèmes sophistiqués visant justement à empêcher ce type de pratique pour raisons de sécurité), on peut ainsi se demander si l'émulation d'une carte NXP Mifare Desfire est accepté/toléré par NXP, les solutions de contrôles d'accès, voire l'ANSSI ... jusqu'à preuve du contraire, la réponse semble plutôt non ; et à notre connaissance aucune solution du marché ne propose actuellement cette fonctionnalité.

* Notez bien que dans le parapgraphe ci-dessus, nous disons qu'on peut éventuellement émuler une carte Desfire depuis un Android en théorie : les possibilités de host-based card emulation (HCE) fourni nativement et officiellement par Google sur Android seraient si contraintes qu'elles ne permettraient en fait pas de proposer une émulation complète (cf par exemple cette question/réponse stackoverflow) et donc par exemple compatible avec les systèmes de controle d'accès du marché. 

En conclusion, implémenter l'émulation Desfire (sur Android comme sur iOS) fait face à plusieurs problèmes : impossibilités (?) d'implémentation (contraintes Apple/Google), problèmes de conformité (les cartes Mifare Desfire sont certifiées par l'ANSSI), de sécurité, de légalité (vis-à-vis de NXP). L'émulation Desfire (complète ; sur Android comme sur iOS) ne parait pas être à ce jour une piste exploitable.

L'usage du protocole ISO/IEC 7816-4
Si l'émulation complète de Mifare Desfire parait délicate, l'implémentation de commandes ISO/IEC 7816-4 semble plus à portée et plus en cohérence avec les possibilités d'HCE proposé par Android.
Aussi on peut imaginer proposer des services accessibles à l'utilisateur au travers d'une application Android émulant une "carte", notamment si on opère à la fois l'application cliente (Android) et serveur (lecteur NFC rattaché au service).
En ce sens l'émulation de la mise à disposition du fichier ESCN de la DEUInfo en ISO/IEC 7816-4 pourrait par exemple être envisagé (non étudié ni implémenté).

Au vu de ces considérations techniques, il parait donc préférable de recentrer le problème sur le besoin (fonctionnel) de départ et donc de reformuler par exemple la question en : comment peut-on se passer de la carte ?

Suivant les services considérés, on trouve des solutions déjà en place.

...

le lecteur NFC de contrôle d'accès (sans jamais avoir connaissance des clefs notamment).
Cela présuppose que le téléphone ait une connexion internet pour dialoguer avec le serveur esup-nfc-tag-server au moment du badgeage de la carte. Le problème que cela pose également est qu'on se place alors dans un scénario qui ressemble à une attaque de type Man-in-the-Middle pour du contrôle d'accès sans contact : on se retrouve en effet à utiliser un téléphone pour faire proxy avec un mécanisme sécurisé (dans notre cas le serveur et non la carte d'une victime) permettant d'ouvrir une porte. C'est ce type de scénario et donc d'usage que NXP tente d'endiguer avec les évolutions de Mifare Desfire (EV1, EV2 puis maintenant EV3). En plus du problème technique que cela pourrait poser (avec des systèmes sophistiqués visant justement à empêcher ce type de pratique pour raisons de sécurité), on peut ainsi se demander si l'émulation d'une carte NXP Mifare Desfire est accepté/toléré par NXP, les solutions de contrôles d'accès, voire l'ANSSI.

* Notez bien que dans le parapgraphe ci-dessus, nous disons qu'on peut éventuellement émuler une carte Desfire depuis un Android en théorie : les possibilités de host-based card emulation (HCE) fourni nativement et officiellement par Google sur Android seraient si contraintes qu'elles ne permettraient en fait pas de proposer une émulation complète (cf par exemple cette question/réponse stackoverflow) et donc par exemple compatible avec les systèmes de controle d'accès du marché. 

Implémenter l'émulation Desfire (sur Android comme sur iOS) fait donc face à plusieurs problèmes : contraintes imposées par Apple/Google, problèmes de conformité (les cartes Mifare Desfire sont certifiées par l'ANSSI), de sécurité, de légalité (vis-à-vis de NXP).
En lien direct avec Google, NXP proposerait une émulation Desfire  sur Android (via Google Pay) au travers de la solution MIFARE 2GO ; cette solution permet déjà d'utiliser son Android pour utiliser les transports public dans quelques villes (San Francisco, Whashington, Melbourne ...).

L'usage du protocole ISO/IEC 7816-4
Si l'émulation complète de Mifare Desfire est délicate, l'implémentation de commandes ISO/IEC 7816-4 semble plus à portée et plus en cohérence avec les possibilités d'HCE proposé par Android.
Aussi on peut imaginer proposer des services accessibles à l'utilisateur au travers d'une application Android émulant une "carte", notamment si on opère à la fois l'application cliente (Android) et serveur (lecteur NFC rattaché au service).
En ce sens l'émulation de la mise à disposition du fichier ESCN de la DEUInfo en ISO/IEC 7816-4 pourrait par exemple être envisagé (non étudié ni implémenté).

Au vu de ces considérations techniques, il parait donc préférable de recentrer le problème sur le besoin (fonctionnel) de départ et donc de reformuler par exemple la question en : comment peut-on se passer de la carte ?

Suivant les services considérés, on trouve des solutions déjà en place.

• Le CROUS propose une application Android spécifique permettant de régler un repas via QR-Code. 
• esup-emargement propose la possibilité d'émarger avec un QR-Code (proposée par l'interface web d'esup-emargement, sans application telephone supplémentaire à installer) ; l'interface web permet aussi au gestionnaire de cocher une simple case pour palier l'oubli d'une carte par exemple.
• Les copieurs permettent une authentification par login/password (en plus de l'authentification/identification par badgeage).
• Dans les BUs, les documentalistes peuvent retrouver une personne via le nom/prénom.
• Pour le contrôle d'accès, on note que les portes peuvent être déverrouillées par clef via une serrure classique (en plus du badgeage donc) ; des contrôles d'accès permettent de déverrouiller des portes à distance également (via l'interface web, et donc sans carte).
• ...

Est-ce qu'esup-nfc-tag peut mettre à jour électroniquement une carte Mifare Desfire ?

Oui,  ESUP-NFC-TAG est prévu pour ajouter une application Desfire sur des cartes déjà en circulation.

La configuration dans esup-nfc-tag-server correspondra quasiment à l'identifique à la configuration d'une édition de carte (structure Desfoire de la carte).

Cette configuration sera à utiliser au travers non plus d'esup-sgc-client mais d'esup-nfc-tag-droid ou esup-nfc-tag-desktop ; l'enrôlement via reconnaissance du qr-code n'étant ici pas nécessaire.

Aussi, pratiquement, dans ESUP-SGC, l'ajout d'une application de contrôle d'accès peut revenir alors à un simple badgeage de la carte avec un téléphone Android.

Est-ce qu'esup-nfc-tag peut ré-encoder complètement une carte Mifare Desfire ?

Techniquement, esup-sgc peut "réencoder" une carte en la formattant avant, c'est une option à spécifier dans la configuration de la structure de la carte dans esup-nfc-tag.

Si vous achetez des cartes pré-encodées avec crous/izly (cf Q/R "Utilisation de cartes pré-encodées" dans cette même FAQ) cependant, cela veut dire que l'application crous/izly n'est pas encodée par esup-sgc et que donc si esup-sgc formatte et réencode la carte, l'application crous/izly ne sera plus présente sur la carte.

Encoder soit-même la partie crous/izly via esup-sgc présente donc cet intérêt de pouvoir relancer un encodage en cas de problème. Si vous utilisez actuellement un SGC qui présente une instabilité lors de l'édition des cartes et notamment lors de leur encodage, pouvoir ré-encoder complètement une carte semble séduisant. L'encodage dans ESUP-SGC est cependant fiable (cf question ci-dessous sur le taux de perte lors de l'édition des cartes) ; aussi, les avantages qu'on peut retirer d'acheter des cartes pré-encodées crous/izly l'emportent (malgré le surcoût d'achât des cartes pour cette option de pré-encodage) sur cette possibilité : maintenance simplifiée, pas d'adhérence à la dll crous (et donc à windows), distribution logicielle facilitée, pas de gestion des clefs sam, ...

... ajoutons que la mise en oeuvre d'un pré-encodage crous/izly par un seul prestataire offre un niveau de sécurité plus élevé pour l'ensemble des établissements, c'est ainsi la recommandation du CNOUS.

Quel est le taux de perte de cartes lors de l'édition dans ESUP-SGC ?

Les SGC du marché proposent usuellement une édition comprenant l'impression et l'encodage de la carte en 1 seul passage dans une imprimante (faisant office également d'encodeur).

Cf la Q/R "L'impression des cartes nécessite de faire deux passages de carte ?", cela est possible en utilisant les APIs d'un modèle d'imprimante à carte spécifique (avec encodeur intégré). Dans les faits, outre les problèmes de maintenance (logiciel testé/validé uniquement pour une version/type d'OS, ... parfois plus maintenu, ...), les établissements utilisant ce type de Système de Gestion de Cartes constatent des taux d'échec/perte de cartes importants lors de l'édition (jusqu'à 30% de perte pour certains).

Avec esup-sgc / esup-nfc-tag (qui ne fait que du standard / basique lors de l'édition des cartes : impression ps/pcsl et encodage nfc/pcsc) le taux de perte attendu est proche de 0, tant sur l'impression que sur l'encodage.
(Notons que l'usage d'une ZXP3 pour encoder en masse les cartes, malgré l'usage de l'API propriétaire Zebra [usage la plus modérée possible cependant], se révèle également très fiable via ESUP-SGC).

Si, avec esup-sgc, vous constatez un taux de perte de l'ordre de 5% par exemple, ce n'est pas normal.

Problème d'impression

Si le problème se pose au niveau de l'impression, l'imprimante ou les rubans sont sans doute en cause (ou/et drivers et configurations associées).

Problème d'encodage

Si le problème se pose lors de l'encodage, ça peut être un problème humain (encodage avorté en 'arrachant' la carte du lecteur NFC alors qu'elle est en train d'être encodée ; on retrouve alors l'erreur 0x4d3).

Si le problème n'est pas humain mais technique, il est intéressant de retrouver l'erreur 'source'.

Une erreur 91DE DUPLICATE_ERROR correspond à une tentative d'encodage d'un élément déjà encodé : lorsque vous avez cette erreur c'est que l'encodage de la carte avait déjà été effectuée partiellement (partiellement car sinon le SGC ne détecterait plus la carte comme carte à encoder puisque marquée comme 'encodé' dans le SGC), et cet encodage n'avait pas abouti et l'erreur source (à prendre en compte) est donc donnée lors de cette première tentative d'encodage.

Si le problème technique n'est pas aléatoire mais systématique pour une carte/personne donnée, ça peut être un problème de configuration de la structure de la carte (erreur type 'boundary error' car on tente d'encoder plus de données que la taille du fichier par exemple ...)

Si le problème technique est "aléatoire", la piste la plus probable est un encodeur (ou/et driver associé) pas très stable. Certains modèles sont en effet plus fiables que d'autres (avec des drivers bien supportés sur windows comme sur linux également) ; ça peut également être lié à un poste et système d'exploitation à bout de souffle, ports USB HS, etc

...

.