...
Nous vous invitons par exemple à visionner la dernière présentation actuellement en date : la présentation "ESUP-SGC, Système de Gestion de Cartes sur-mesure pour l'ESR" proposée aux JRES proposée aux JRES 2019 à Dijon → → Vidéo / Diaporama / Article.
Nous hésitons à passer sur ESUP-SGC ...
...
En conclusion, gardez à l'esprit qu'en tant que communauté et développeurs d'ESUP-SGC, nous n'avons aucun intérêt à vous convaincre de passer à ESUP-SGC si vous n'avez tout simplement pas l'envie, la motivation, la volonté d'adhérer à ce projet ; on serait très embêtés (en plus d'être étonnés tout de même ) qu'ESUP-SGC vous donne moins de satisfaction que votre ancienne solution !
De quel matériel ai-je besoin ?
En plus des applications web à installer sur un serveur, il vous faut pour éditer des cartes :
- 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, fargo, ...)
- une webcam
- un lecteur de carte pc/sc (exemple : Identiv UTrust 3700 F)
L'impression des cartes nécessite de faire deux passages de carte ?
Avant la version 2 d'esup-sgc, et contrairement aux autres Systèmes de Gestion de Cartes, ESUP-SGC ne permettait effectivement pas d'imprimer et encoder la carte en 1 seul passage dans une imprimante à cartes disposant d'un lecteur/encodeur NFC.
Dans ESUP-SGC, et avec le fonctionnement historique issu de sa version 1, une carte est d'abord imprimée par une imprimante à carte, puis celle-ci est encodée dans un second temps (voir à ce propos la vidéo ESUP-SGC - demande de carte, impression, encodage et activation).
C'est un choix qui avait été fait dès l'étude préliminaire, en toute conscience, avant même la conception du SGC.
A ce sujet, voir le document "ESUP-SGC : UN SGC LIBRE", Juin 2017.
Pour les établissements utilisant des SGC propriétaires, la mise en oeuvre des API propriétaires des imprimantes à cartes peut en effet poser quelques problèmes : instabilité des drivers, imprimante spécifique imposée, code/librairie non évolutif lié à un environnement logiciel donné, nombre de pannes/erreurs potentielles élevée, nombre de rejets élevé, code fermé, coûts plus élevés, maintenance plus compliquée, temps de mise en oeuvre et de manutention plus important à l'usage. Pour les SGC propriétaires du marché, ces difficultés de mise en oeuvre peuvent en partie être traitées par les prestataires/éditeurs au travers de différentes prestations : achat d'imprimantes spécifiques au travers du prestataire (vente liée), contrat de maintenance matérielle, contrat de maintenance logicielle, formation d'installation, dépannage ponctuelle, montée de version logicielle, migration de codes sur une nouvelle version d'imprimantes, etc. Ces prestations font partie intégrante du modèle économique et ne posent de fait pas de problème aux éditeurs. Pour un SGC libre, la situation est toute autre ; pour que le modèle de développement et de mutualisation autour du logiciel libre tienne, on minimise au maximum les problèmes côté des établissements pour faire en sorte que leurs installations fonctionnent avec un minimum de support (stabilité, autonomie, indépendance notamment matérielle), il en découle un certain nombre de choix très pragmatiques, notamment celui de fonctionner au maximum sur des standards. Ainsi pour l'impression des cartes on proposait par défaut de se baser uniquement sur ps/pcl et pour l'encodage on utilise pc/sc ; ce qui impliquait d'imprimer et d'encoder la carte en 2 actions bien distinctes.
Sur le papier, cette spécificité peut paraître moins intéressante que l'impression+encodage en 1 passe.
Aussi, 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 peut proposer 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
Cependant, et depuis la version 2.0 d'esup-sgc financée en partie via l'Appel À Projets Services Numériques Aux Étudiants ESUP-SGC 2022/2023, esup-sgc est également capable d'éditer une carte en un seul passage !
La réponse à cettequestion est donc maintenant non : à l'instar des SGC du marché, esup-sgc vous permet aujourd'hui d'éditer les cartes en imprimant et encodant dans le même temps chaque carte et c'est maintenant cette possibilité que l'on met en avant, notre implémentation sur les métériels evolis comme zebra étant parfaitement stable et efficace.
esup-sgc garde néanmoins la possibilité d'éditer les cartes en 2 temps et conserve cette spécificité de pouvoir être indépendant de tout matériel car utilisable avec n'importe quelle imprimante du marché (matériel passé ou à venir).
Voir à ce propos ESUP-SGC-Client et édition des cartes
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.
Dans le cadre de l'usage de plusieurs SGC pour un même projet de cartes (multi-instances pour du multi-établissements), est il possible de paramétrer un générateur d'identifiants de carte pour le contrôle d'accès pour que chaque instance ait une plage (range) dédiée ?
Oui, cette possibilité est à configurer via cardIdService comme décrit sur ce même wiki ici.
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.
Est-ce qu'un usager doit forcément faire une demande via l'interface web d'ESUP-SGC pour que l'on puisse lui imprimer sa carte ?
Contrairement aux SGC du marché, ESUP-SGC propose en effet une interface web aux utilisateurs pour qu'ils puissent demander leur carte (en utilisant leur navigateur d'ordinateur ou même un téléphone permettant de se prendre en photo au travers d'esup-sgc), désactiver leur carte en cas de perte ou de vol, payer éventuellement un renouvellement, etc.
Cependant, ESUP-SGC permet aussi aux gestionnaires de demander une carte pour un utilisateur donné, avec prise de vue par webcam interposée.
Enfin ESUP-SGC propose aussi une api simple pour initialiser les demandes de cartes par script ; voir a Q/R "Comment faire une demande de carte en utilisant le webservice proposé par ESUP-SGC ?"
Des établissements ont ainsi par exemple fait le choix d'initier les demandes de carte des étudiants dès que le SI-Scol a connaissance de l'inscription de l'étudiant, en reprenant la photo demandée lors de l'inscription.
Dans tous les cas, notez simplement que l'utilisateur doit être 'connu' de votre SI pour qu'esup-sgc récupère les données depuis votre SI ; et il doit avoir ainsi un eppn (eduPersonPrincipalName) utilisé comme identifiant métier d'un utilisateur dans esup-sgc.
Nous devons/voulons migrer d'un SGC vers un autre, quels sont les points d'attention à observer ?
Suivant la solution que vous utilisez, vous pouvez avoir un niveau de maîtrise plus ou moins élevé de votre système de gestion de cartes et donc finalement de vos cartes et de leur fonctionnement.
Suivant l'éventuel prestataire qui vous fournit (ou fournissait) la solution, celui-ci a pu vous conduire à des choix propres à sa (ou même ses) solution(s) en matière d'édition de cartes (SGC, imprimantes) mais aussi d'usage de la carte (contrôle d'accès, émargement, retrait en bibliohtèque, ...).
Les points d'attention à considérer peuvent de fait être nombreux, en voici quelques uns : :
...
Est-ce qu'ESUP-SGC est configurable pour s'adapter à mon établissement ? Combien et quels établissements l'utilisent actuellement ?
ESUP-SGC a été développé et imaginé dès le départ pour être déployé dans les différents établissements de la COMUE Normandie Université.
Ainsi, depuis 2018, des instances d'esup-sgc sont en production dans des écoles privées, publiques, des universités de petite et grande taille, une COMUE : la Normandie compte ainsi plusieurs instances d'ESUP-SGC en production depuis 2018 pour des établissements gérant leur SI avec les produits de l'AMUE, de Cocktail ou autre. L'instance de la COMUE est multi-tenants, et l'ensemble correspond à un projet multi-établissements ; voir la page wiki esup-sgc Multi Etablissements.
Depuis 2018, d'autres établissements ont adopté esup-sgc, notamment grâce à l'Appel À Projets Services Numériques Aux Étudiants ESUP-SGC 2022/2023.
En 2024, on compte ainsi près de 20 établissements qui utilisent ESUP-SGC en production.
De quel matériel ai-je besoin ?
En plus des applications web à installer sur un serveur, il vous faut pour éditer des cartes :
- des cartes Mifare Desfire (EV1, EV2, EV3, ... actuellement les établissements utilisent tous des EV3)
- un PC sous linux ou windows ou un MAC OS
- une imprimante à carte plastique ps/pcl (exemples : evolis primacy, zebra zxp7, fargo, ...)
- une webcam
- un lecteur de carte pc/sc (exemple : Identiv UTrust 3700 F)
L'impression des cartes nécessite de faire deux passages de carte ?
Avant la version 2 d'esup-sgc, et contrairement aux autres Systèmes de Gestion de Cartes, ESUP-SGC ne permettait effectivement pas d'imprimer et encoder la carte en 1 seul passage dans une imprimante à cartes disposant d'un lecteur/encodeur NFC.
Dans ESUP-SGC, et avec le fonctionnement historique issu de sa version 1, une carte est d'abord imprimée par une imprimante à carte, puis celle-ci est encodée dans un second temps (voir à ce propos la vidéo ESUP-SGC - demande de carte, impression, encodage et activation).
C'est un choix qui avait été fait dès l'étude préliminaire, en toute conscience, avant même la conception du SGC.
A ce sujet, voir le document "ESUP-SGC : UN SGC LIBRE", Juin 2017.
Pour les établissements utilisant des SGC propriétaires, la mise en oeuvre des API propriétaires des imprimantes à cartes peut en effet poser quelques problèmes : instabilité des drivers, imprimante spécifique imposée, code/librairie non évolutif lié à un environnement logiciel donné, nombre de pannes/erreurs potentielles élevée, nombre de rejets élevé, code fermé, coûts plus élevés, maintenance plus compliquée, temps de mise en oeuvre et de manutention plus important à l'usage. Pour les SGC propriétaires du marché, ces difficultés de mise en oeuvre peuvent en partie être traitées par les prestataires/éditeurs au travers de différentes prestations : achat d'imprimantes spécifiques au travers du prestataire (vente liée), contrat de maintenance matérielle, contrat de maintenance logicielle, formation d'installation, dépannage ponctuelle, montée de version logicielle, migration de codes sur une nouvelle version d'imprimantes, etc. Ces prestations font partie intégrante du modèle économique et ne posent de fait pas de problème aux éditeurs. Pour un SGC libre, la situation est toute autre ; pour que le modèle de développement et de mutualisation autour du logiciel libre tienne, on minimise au maximum les problèmes côté des établissements pour faire en sorte que leurs installations fonctionnent avec un minimum de support (stabilité, autonomie, indépendance notamment matérielle), il en découle un certain nombre de choix très pragmatiques, notamment celui de fonctionner au maximum sur des standards. Ainsi pour l'impression des cartes on proposait par défaut de se baser uniquement sur ps/pcl et pour l'encodage on utilise pc/sc ; ce qui impliquait d'imprimer et d'encoder la carte en 2 actions bien distinctes.
Sur le papier, cette spécificité peut paraître moins intéressante que l'impression+encodage en 1 passe.
Aussi, 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 peut proposer 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
Cependant, et depuis la version 2.0 d'esup-sgc financée en partie via l'Appel À Projets Services Numériques Aux Étudiants ESUP-SGC 2022/2023, esup-sgc est également capable d'éditer une carte en un seul passage !
La réponse à cettequestion est donc maintenant non : à l'instar des SGC du marché, esup-sgc vous permet aujourd'hui d'éditer les cartes en imprimant et encodant dans le même temps chaque carte et c'est maintenant cette possibilité que l'on met en avant, notre implémentation sur les métériels evolis comme zebra étant parfaitement stable et efficace.
esup-sgc garde néanmoins la possibilité d'éditer les cartes en 2 temps et conserve cette spécificité de pouvoir être indépendant de tout matériel car utilisable avec n'importe quelle imprimante du marché (matériel passé ou à venir).
Voir à ce propos ESUP-SGC-Client et édition des cartes
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.
Dans le cadre de l'usage de plusieurs SGC pour un même projet de cartes (multi-instances pour du multi-établissements), est il possible de paramétrer un générateur d'identifiants de carte pour le contrôle d'accès pour que chaque instance ait une plage (range) dédiée ?
Oui, cette possibilité est à configurer via cardIdService comme décrit sur ce même wiki ici.
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.
Est-ce qu'un usager doit forcément faire une demande via l'interface web d'ESUP-SGC pour que l'on puisse lui imprimer sa carte ?
Contrairement aux SGC du marché, ESUP-SGC propose en effet une interface web aux utilisateurs pour qu'ils puissent demander leur carte (en utilisant leur navigateur d'ordinateur ou même un téléphone permettant de se prendre en photo au travers d'esup-sgc), désactiver leur carte en cas de perte ou de vol, payer éventuellement un renouvellement, etc.
Cependant, ESUP-SGC permet aussi aux gestionnaires de demander une carte pour un utilisateur donné, avec prise de vue par webcam interposée.
Enfin ESUP-SGC propose aussi une api simple pour initialiser les demandes de cartes par script ; voir a Q/R "Comment faire une demande de carte en utilisant le webservice proposé par ESUP-SGC ?"
Des établissements ont ainsi par exemple fait le choix d'initier les demandes de carte des étudiants dès que le SI-Scol a connaissance de l'inscription de l'étudiant, en reprenant la photo demandée lors de l'inscription.
Dans tous les cas, notez simplement que l'utilisateur doit être 'connu' de votre SI pour qu'esup-sgc récupère les données depuis votre SI ; et il doit avoir ainsi un eppn (eduPersonPrincipalName) utilisé comme identifiant métier d'un utilisateur dans esup-sgc.
Nous devons/voulons migrer d'un SGC vers un autre, quels sont les points d'attention à observer ?
Suivant la solution que vous utilisez, vous pouvez avoir un niveau de maîtrise plus ou moins élevé de votre système de gestion de cartes et donc finalement de vos cartes et de leur fonctionnement.
Suivant l'éventuel prestataire qui vous fournit (ou fournissait) la solution, celui-ci a pu vous conduire à des choix propres à sa (ou même ses) solution(s) en matière d'édition de cartes (SGC, imprimantes) mais aussi d'usage de la carte (contrôle d'accès, émargement, retrait en bibliohtèque, ...).
Les points d'attention à considérer peuvent de fait être nombreux, en voici quelques uns : :
- Est-ce que le SGC utilisée jusque là correspond uniquement à un Système de Gestion de Cartes ou des fonctionnalités de gestionnaire d'identités ont également été utilisées ?
Présentées comme SGC, certaines solutions vous offrent en fait la possibilité de créer des comptes locaux non liés au reste de votre Système d'Information souvent dans le but de créer des cartes dites génériques (invités, ou autres) : ce type de fonctionnalités de gestionnaire d'identités tend à faire de votre SGC le coeur de votre SI et donc à le déstructurer.
ESUP-SGC ne propose pas de création de carte non liée à un compte utilisateur ; même si celui-ci peut correspondre à une simple entrée dans une table SQL, l'utilisateur doit pré-exister. - Est-ce que les cartes éditées proposent des applications DESFIRE sécurisées de contrôle d'accès propriétaires au prestataire ou est-ce que l'application DESFIRE est bien la propriété de l'établissement et peut être recodée par un nouveau SGC (et utilisée par différents contrôles d'accès) ?
Le principe des cartes DESFIRE est d'héberger plusieurs applications desfire permettant d'y associer différents services/usages (quand on dit application desfire ; comme on dit application xml ; il faut le comprendre comme "une manière d'utiliser quelque chose dans un but particulier"). Si il est normal que l'application Desfire crous/izly soit à usage (et la propriété) de crous/izly même si elle est sur votre (vous, établissement) carte qui vous (établissement toujours) appartient, il ne semble pas normal que l'application Desfire dédiée à votre contrôle d'accès ne vous appartienne pas (état de fait constaté dans un certain nombre d'établissements). - Est-ce que votre SGC actuel vous permet de récupérer les données permettant de réimporter vos cartes dans un nouveau SGC ?
Voyez si/comment vous pouvez récupérer les données telles que mentionnées dans la page Importation de 'cartes' dans ESUP-SGC / Migration des données
ESUP-SGC
A quoi correspondent les rôles dans ESUP-SGC ?
ROLE_ADMIN
Permet d'avoir la vue "Admin" de l'interface, et donc accès aux paramètres de configuration, aux imports CSV, aux logs, etc.
Le rôle Admin permet également de disposer de la fonction SU (Switch User).
ROLE_SWITCH_USER
Permet de disposer de la fonction SU (Switch User) ; à donner éventuellement à un gestionnaire.
Attention avec ce rôle on peut faire un Switch User sur un administrateur, donc ce rôle peut finalement permettre de devenir administrateur simplement.
ROLE_SUPER_MANAGER
Permet d'avoir la vue "Manager" de l'interface. Un manager peut valider/refuser une demande, imprimer les cartes (suivant restriction, cf ROLE_PRINTER) et les activer.
Le lien pour l'application java d'encodage (disponible depuis le menu Apps) est présent, cette application java étant à la fois cliente d'ESUP-SGC et ESUP-NFC-TAG.
ROLE_MANAGER_XYZ
Rôle particulier et dynamique, XYZ étant à changer par un userType, comme P par exemple (dans les configurations données par défaut, P est un userType qui désigne les personnels) : MANAGER_P.
Si l'utilisateur a le rôle MANAGER_P il ne pourra rechercher (et éditer, etc.) que les cartes dont les utilisateurs sont de userType P.
ROLE_PRINTER
Pris en compte uniquement si PRINTER_ROLE_CONFIG (dans admin < configurations) est cochée :
- seuls les managers (ROLE_SUPER_MANAGER ou ROLE_MANAGER_XYZ) ayant en plus le ROLE_PRINTER (édition en 2 passes) peuvent imprimer une carte.
A noter que pour l'édition en 1 passe, l'affectation des managers à une imprimante via eppn ou groupe suffit.
ROLE_LIVREUR
La vue "Manager" est disponible en lecture seule mais ne donne accès à aucune fiche en consultation (si il n'y a pas en plus ).
Avec ce rôle, il est possible de noter une carte comme livrée :
- via l'interface web (si l'utilisateur peut afficher la fiche de l'utilisateur, avec un ROLE_CONSULT en plus par exemple a manima)
- en
...
ESUP-SGC
A quoi correspondent les rôles dans ESUP-SGC ?
ROLE_ADMIN
Permet d'avoir la vue "Admin" de l'interface, et donc accès aux paramètres de configuration, aux imports CSV, aux logs, etc.
Le rôle Admin permet également de disposer de la fonction SU (Switch User).
ROLE_SWITCH_USER
Permet de disposer de la fonction SU (Switch User) ; à donner éventuellement à un gestionnaire.
Attention avec ce rôle on peut faire un Switch User sur un administrateur, donc ce rôle peut finalement permettre de devenir administrateur simplement.
ROLE_SUPER_MANAGER
Permet d'avoir la vue "Manager" de l'interface. Un manager peut valider/refuser une demande, imprimer les cartes (suivant restriction, cf ROLE_PRINTER) et les activer.
Le lien pour l'application java d'encodage (disponible depuis le menu Apps) est présent, cette application java étant à la fois cliente d'ESUP-SGC et ESUP-NFC-TAG.
ROLE_MANAGER_XYZ
Rôle particulier et dynamique, XYZ étant à changer par un userType, comme P par exemple (dans les configurations données par défaut, P est un userType qui désigne les personnels) : MANAGER_P.
Si l'utilisateur a le rôle MANAGER_P il ne pourra rechercher (et éditer, etc.) que les cartes dont les utilisateurs sont de userType P.
ROLE_PRINTER
Pris en compte uniquement si PRINTER_ROLE_CONFIG (dans admin < configurations) est cochée :
- seuls les managers (ROLE_SUPER_MANAGER ou ROLE_MANAGER_XYZ) ayant en plus le ROLE_PRINTER (édition en 2 passes) peuvent imprimer une carte.
A noter que pour l'édition en 1 passe, l'affectation des managers à une imprimante via eppn ou groupe suffit.
ROLE_LIVREUR
La vue "Manager" est disponible en lecture seule mais ne donne accès à aucune fiche en consultation (si il n'y a pas en plus ).
Avec ce rôle, il est possible de noter une carte comme livrée :
- via l'interface web (si l'utilisateur peut afficher la fiche de l'utilisateur, avec un ROLE_CONSULT en plus par exemple a manima)
- en utilisant une application cliente esup-nfc-tag (disponible depuis le menu Apps) pour smartphone (android) ou de bureau (java) et en badgeant la carte qu'on livre
ROLE_UPDATER
...
- utilisant une application cliente esup-nfc-tag (disponible depuis le menu Apps) pour smartphone (android) ou de bureau (java) et en badgeant la carte qu'on livre
ROLE_UPDATER
ll est possible de mettre à jour électroniquement une carte en utilisant une application cliente esup-nfc-tag (disponible depuis le menu Apps) pour smartphone (android) ou de bureau (java) et en badgeant la carte.
Cette mise à jour électronique est configurée dans esup-nfc-tag (ajout d'applications, de fichiers et clefs ...)
...
Est-ce que ESUP-SGC support l'impression du verso en plus du recto de la carte ?
Nous n'avons pas travaillé sur ce sujet actuellement, aussi l'édition en 2 passes n'a pas été testé en ce sens, et encore moins l'édition en 1 passe qui demanderait pour un tel support une adaptation des développements.
En l'état, la réponse est donc qe non, ESUP-SGC ne supporte pas l'impression recto/verso des cartes, il ne propose d'imprimer que le recto de la carteOui, à partir de la version 2.3.0 (en cours de finalisation pour été 2024) esup-sgc supporte l'édition de cartes en recto-verso, ce à la fois lors de l'édition en 1 temps (recommandé) que l'édition en 2 temps.
Comment faire une demande de carte en utilisant le webservice proposé par ESUP-SGC ?
...
- à enrôler la carte, c'est à dire à enregistrer en base de données d'esup-sgc le CSN de la carte physique qu'on lie donc à la carte en base de données (qui n'était au départ qu'une demande de carte).
- et éventuellement à personnaliser la carte électronique en spécifiant des clefs, des applications et fichiers Desfire, pour
Dans un usage standard, il n'y a donc pas lieu de positionner le CSN de la carte par Web Service : c'est le rôle d'esup-sgc, esup-sgc-client et esup-nfc-tag lors de l'édition de la carte.
...
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
curl -d "etat=ENCODED" -d "csn=061D72BB3E7280" https://esup-sgc.univ-ville.fr/wsrest/api/setCardEtat/205 |
Notez qu'on peut également positionner ce CSN et tout autre attribut de la carte dès la création de la carte par Web-Service - voir à ce propos la question ci-avant "Comment faire une demande de carte en utilisant le webservice proposé par ESUP-SGC ?".
De quelles données utilisateur issues du SI esup-sgc a besoin ?
...
- à chaque authentification de l'utilisateur et lors de la demande d'une carte
- lorsqu'un un gestionnaire clique sur le bouton "synchroniser" sur la fiche de l'utilisateur
- régulièrement en fonction de la configuration de votre fichier applicationTasksContext.xml
- si un appel web service ( type curl https://esup-sgc.univ-ville.fr/wsrest/api/sync?eppn=toto@univ-ville.fr ) est lancé - ce dernier moyen avancé peut vous permettre d'obtenir quelque chose de quasi synchrone en plaçant par exemple cette commande dans un trigger de votre base métier SI.
...
Pour les obtenir, et en tant que membre de la DSI (ou référent technique dans votre établissement) vous pouvez contacter departementcontacter sdn-vem@cnousventes@cnous.fr en fr en mettant également en copie Vincentcopie Vincent.Bonamy@univ-rouen.fr
Si vous êtes dans cette démarche, abonnez-vous également en premier lieu à la liste privée esup-sgc-devel.
...
L'URL en restrictedPhoto permet côté esup-sgc de prendre en compte l'acceptation par l'étudiant de la diffusion de sa photo, suivant l'usage et les spécificités rgpd, l'établissement peut aussi ne pas prendre en compte cela en mettant simplement en url
https://esup-sgc.mon-univ.fr/wsrest/photo/%s/photo
A noter que %s est remplacé par l'eppn de l'étudiant récupéré du ldap (le ldap doit donc proposer cet attribut).
Côté esup-sgc, le contrôle d'accès au web-service des photos se fait via la propriété de accessRestrictionWSRestPhoto de security.properties où on propose par défaut de lister les IPs via des expressions type hasIpAddress('127.0.0.1') or hasIpAddress('0:0:0:0:0:0:0:1') or ...
Il faut donc y ajouter ici l'IP du serveur où est installé esup-mdw ; notez qu'esup-mdw récupère véritablement les photos pour les présenter à l'utilisateur, la sécurité d'accès des photos est donc vis-à-vis de l'utilisateur opéré directement par esup-mdw.
Comment récupérer les photos par script ?
...
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
wget 'http://localhost:8080/wsrest/photo/joe@univ-ville.fr/restrictedPhoto?cardEtat=ENABLED' |
Comment récupérer par script / API / SQL les données et cartes d'un ou plusieurs utilisateurs ?
Esup-sgc propose une API permettant de récupérer les données et carte d'un ou plusieurs utilisateurs.
Pour pouvoir l' utiliser ce web service, l'IP du client doit être référencé dans accessRestrictionWSRestApi, fichier security.properties
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
wget 'http://localhost:8080/wsrest/api/get?eppn=toto@univ-ville.fr&eppn=titi@univ-ville.fr' |
Quelle version de Java puis-je utiliser ?
La récupération du CSN de la carte active peut se faire ainsi par exemple :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
curl -s 'http://localhost:8080/wsrest/api/get?eppn=toto@univ-ville.fr' | jq '.[] | select(.eppn == "toto@univ-ville.fr") | .cards[] | select(.etat == "ENABLED") | .csn' |
Notez qu'on peut aussi facilement récupérer ces mêmes données via une simple requête SQL dont la base de données est simple et stable :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
select csn from card where eppn='toto@univ-ville.fr' and etat='ENABLED'; |
Quelle version de Java puis-je utiliser ?
Initialement, Initialement, le projet fonctionnait de part et d'autre avec le JDK 8 d'Oracle.
Puis, suite au changement de license d'Oracle, à l'abandon prochain de Java Web Start, on a fait évoluer esup-sgc et esup-nfc-tag.
...
Puis il faut créer une application esup-nfc-tag au niveau de l'IHM en utilisant les paramètres suivants :
- Nom : Change Master Key
- Configuration NFC : Changement de la Master Key
- Application externe : Changement Master Key
Quelle est la différence entre Mifare Desfire EV1, Mifare Desfire EV2 ou encore Mifare Desfire EV3 ?
Ces 3 technologies correspondent à des évolutions de Mifare Desfire. En prime abord, il faut retenir que NXP assure une compatibilité descendante de ses cartes vis-à-vis des applicatifs compatibles Mifare Desfire : en bref et rapidement, un contrôle d'accès compatible et codé au départ pour prendre en charge le protocole Mifare Desfire EV1 pourra utiliser des cartes Mifare Desfire EV3.
Pus précisément, parlons par exemple de la différence entre EV1 et EV2 : Mifare Desfire EV2 fait suite à Mifare Desfire EV1.
EV2 est présentée comme plus sécurisée que EV1.
Il faut cependant distinguer la carte du protocole utilisé.
Aussi retenons que :
- EV2 est donc à la fois des cartes EV2 et un nouveau protocole EV2.
- Les cartes Desfire EV2 supportent le protocole EV1 et le protocole EV2.
- Les cartes Desfire EV1 ne supportent que le protocole EV1
- Le protocole EV2 est plus sécurisé (et plus complexe du coup) que le protocole EV1.
- Les nouvelles possibilités offertes par les cartes EV2 (application déléguée et libération de la mémoire)
- ne sont pas supportées par les cartes EV1
- mais peuvent être codées avec le protocole EV1.
- ESUP-SGC au travers d'ESUP-NFC-TAG utilise le protocole EV1 (et est donc compatible avec les cartes EV1 et EV2).
Codées avec ESUP-SGC / ESUP-NFC-TAG (via le protocole EV1), l'usage des cartes EV2 avec le protocole EV2 (par exemple au travers du contrôle d'accès) apporteraient de fait une plus grande sécurité que son usage au travers du protocole EV1.
Cf la documentation NXP https://www.nxp.com/docs/en/fact-sheet/MIFARE-DESFIRE-EV2-FS.pdf : "Proximity Check protects against relay attacks".
ESUP-SGC / ESUP-NFC-TAG, dans le cadre du projet de Carte Etudiante Européenne devrait également prochainement (en cours d'implémentation) supporter au niveau de l'encodage les nouvelles possibilités offertes par EV2, à savoir le support des applications déléguées et de la libération de la mémoire.
Concernant EV3 (et toutes autres versions qui pourraient suivre), la logique de rétrocompatibilité est la même.
Est-ce que ESUP-SGC peut coder la DEUInfo de la care étudiante européenne ?
Oui, esup-sgc peut être configuré pour coder l'application DEUInfo dans un carte Mifare Desfire.
La documentation pour ce faire est donnée ici : Carte étudiante européenne
Est-ce qu'on peut demander à un prestataire de se charger de coder la DEUInfo ?
Avant la version 2.0, l'implémentation d'esup-sgc faisait qu'on ne poiuvait pas déléguer cette partie à un prestataire.
La DEUInfo (Data European University Info) consiste notamment à coder l'ESCN (European Student Card Number) dans la carte.
Le QRCode utilisé par esup-sgc correspond à l'ESCN inclu dans une url en esc.gg
Le fonctionnement d'esup-sgc (lorsqu'il imprime et encode en 2 temps) rattache ce qui est imprimé à la partie électronique en utilisant le QR Code d'une part et le CSN d'autre part.
De fait l'association escn/csn ne peut pas se faire en dehors d'esup-sgc, et donc les établissements utilisant esup-sgc avec l'édition en 2 temps ne peuvent pas demander à un prestataire de pré-encoder la DEUInfo pour eux.
- Change Master Key
- Configuration NFC : Changement de la Master Key
- Application externe : Changement Master Key
Quelle est la différence entre Mifare Desfire EV1, Mifare Desfire EV2 ou encore Mifare Desfire EV3 ?
Ces 3 technologies correspondent à des évolutions de Mifare Desfire. En prime abord, il faut retenir que NXP assure une compatibilité descendante de ses cartes vis-à-vis des applicatifs compatibles Mifare Desfire : en bref et rapidement, un contrôle d'accès compatible et codé au départ pour prendre en charge le protocole Mifare Desfire EV1 pourra utiliser des cartes Mifare Desfire EV3.
Pus précisément, parlons par exemple de la différence entre EV1 et EV2 : Mifare Desfire EV2 fait suite à Mifare Desfire EV1.
EV2 est présentée comme plus sécurisée que EV1.
Il faut cependant distinguer la carte du protocole utilisé.
Aussi retenons que :
- EV2 est donc à la fois des cartes EV2 et un nouveau protocole EV2.
- Les cartes Desfire EV2 supportent le protocole EV1 et le protocole EV2.
- Les cartes Desfire EV1 ne supportent que le protocole EV1
- Le protocole EV2 est plus sécurisé (et plus complexe du coup) que le protocole EV1.
- Les nouvelles possibilités offertes par les cartes EV2 (application déléguée et libération de la mémoire)
- ne sont pas supportées par les cartes EV1
- mais peuvent être codées avec le protocole EV1.
- ESUP-SGC au travers d'ESUP-NFC-TAG utilise le protocole EV1 (et est donc compatible avec les cartes EV1 et EV2).
Codées avec ESUP-SGC / ESUP-NFC-TAG (via le protocole EV1), l'usage des cartes EV2 avec le protocole EV2 (par exemple au travers du contrôle d'accès) apporteraient de fait une plus grande sécurité que son usage au travers du protocole EV1.
Cf la documentation NXP https://www.nxp.com/docs/en/fact-sheet/MIFARE-DESFIRE-EV2-FS.pdf : "Proximity Check protects against relay attacks".
ESUP-SGC / ESUP-NFC-TAG, dans le cadre du projet de Carte Etudiante Européenne devrait également prochainement (en cours d'implémentation) supporter au niveau de l'encodage les nouvelles possibilités offertes par EV2, à savoir le support des applications déléguées et de la libération de la mémoire.
Concernant EV3 (et toutes autres versions qui pourraient suivre), la logique de rétrocompatibilité est la même.
Peut-on utiliser l'application Desfire Crous/Izly via esup-nfc-tag et plus généralement dans nos services institutionnels comme le servie d'impression ou le contrôle d'accès ?
Si esup-nfc-tag (allié à esup-sgc) sait lancer la DLL CROUS/Izly pour écrire l'application crous/izly (on recommande cependant l'achat de cartes pré-encodées), esup-nfc-tag ne propose pas de lire l'application Desfire CROUS/Izly.
Il faut en fait considérer que l'application Desfire CROUS/Izly, même si elle est écrite sur vos cartes (et éventuellement par vous-même), ne vous appartient pas et ne devrait pas être utilisée en dehors du contexte précis pour lequel elle a été conçue (services du CROUS).
Cela exclut donc de fait l'usage de l'application Desfire CROUS/Izly au travers d'esup-nfc-tag, mais aussi au travers de votre service d'impression, de votre contrôle d'accès, etc.
Si vous souhaitez utiliser une application Desfire sur vos cartes pour le contrôle d'accès ou tout autre service, vous devez en écrire une (ou plusieurs) vous-même, qui vous appartient ; on vous y encourage, cela constitue en partie la raison d'être d'esup-nfc-tag allié à esup-sgc !
Est-ce que ESUP-SGC peut coder la DEUInfo de la care étudiante européenne ?
L'application DEUInfo dans une carte Mifare Desfire était une fonctionnalité proposée par la Carte Étudiante Européenne jusqu'en Novembre 2024 et esup-sgc pouvait effectivement l'encoder (cf la page wiki archivée à ce sujet : Carte étudiante européenne - Archivé).
Elle a depuis été abandonnée - voir la documentation à jour à propose de la Carte étudiante européenneAvec l'édition en 1 temps disponible dans esup-sgc 2, cette limitation est cependant théoriquement levée.
Comment renseigner l'application Desfire ID AID pour la mise en place d'une application Desfire de contrôle d'accès ?
...
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éservice).
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 ?
...
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).
...
Si le problème se pose au niveau de l'impression, l'imprimante ou les rubans sont sans doute en cause (ou/et les drivers et configurations associées).
Suivant les modèles d'imprimantes, les utilitaires associés peuvent être à l’origine d’interférences avec ESUP-SGC-CLIENT s’ils génèrent de nombreuses notifications ou prennent temporairement le contrôle de l’imprimante en pleine session d'impression des cartes.
On notera notamment, que pour le modèle Evolis Primacy2, il est fortement recommandé d’installer le logiciel Evolis Print Center 2 en mode « minimal » :
ce mode permet de bénéficier des fonctionnalités utiles de l’outil, comme le processus de nettoyage automatique de l’imprimante, la gestion des consommables et la mise à jour du firmware, tout en réduisant considérablement les interactions et notifications intempestives susceptibles de perturber ou bloquer les impressions déclenchées par le client ESUP-SGC. Pour cela, lors de l’installation du Print Center 2, sélectionner le mode de fonctionnement « minimal » dans les options de configuration.
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).
...