ESUPSGC

Arborescence des pages

Comparaison des versions

Ancienne version 137

changes.mady.by.user Vincent Bonamy

Sauvegardée le

comparé à

Nouvelle version Actuel

changes.mady.by.user Vincent Bonamy

Sauvegardée le

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

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 (clin d'œil) ) qu'ESUP-SGC vous donne moins de satisfaction que votre ancienne solution !

Est-ce qu'ESUP-SGC est configurable pour s'adapter à mon établissement ? Combien et quels établissements l'utilisent actuellement ?

ESUP-SGC 

De quel matériel ai-je besoin ?

...

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.

...

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 ).

...

Si on propose dans nos documentations de monter un mod_shib avec Apache pour proposer une authentification fédérée via la fédération d'identités ESR, vous pouvez en réalité utiliser d'autres mécansimes/briques (et même d'autres frontaux) du moment que vous renvoyez en tant que REMOTE_USER le 'username' de l'utilisateur - qui doit être l'eduPersonPrincipalName (eppn) .ou l'équivalent, c'est à dire un identifiant unique et pérenne inter-établissements (eppn correspondant à uid_local@le_domaine).

Aussi, plutôt que d'utiliser sous Apache, mod_shib, Aussi, plutôt que d'utiliser sous Apache, mod_shib, vous pouvez par exemple utiliser mod_auth_openidc pour faire de l'openId connect, ou mod_auth_cas pour utiliser le protocole CAS, mod_authnz_ldap pour ldap, etc.

...

Bloc de code
languagejs
themeRDark
{
  "@class" : "org.apereo.cas.services.OidcRegisteredService",
  "clientId": "esupsgc",
  "clientSecret": "esupsgcOidcSecret",
  "serviceId" : "https://esup-sgc.univ-ville.fr/secureoidc/redirect_uri",
  "name": "ESUP-SGC - authentification via OpenId Connect",
    "id": 32,
    "scopes" : [ "java.util.HashSet", [ "openid", "profile", "email" ] ],
    "attributeReleasePolicy": {
    "@class": "org.apereo.cas.oidc.claims.OidcProfileScopeAttributeReleasePolicy",
    "claimMappings" : {
      "@class" : "java.util.TreeMap",
      "preferred_username" : "eduPersonPrincipalName"
    }
  }
}

Pour une installation rapide et en première approche, comment court-circuiter l'authentification ?

En configurant une propriété (ou variable d'environnement) devRemoteUser valué à l'eppn d'un utilisateur, unbe authentification transparente est effectuée pour tous les utilisateurs accédant aux pages esup-sgc et esup-nfc-tag sous le nom de cet utilisateur.

C'est une facilité qui est proposée dans le cadre du développement d'esup-sgc notamment.

Comment puis-je voir les entêtes HTTP transmises par mon frontal à esup-sgc ?

...

Pour la partie SQL, le paramétrage de la requpête SQL complète rend la chose plus souple, on peut par exemple faire un  where uid = replace(?, '@univ-ville.fr', '') ; la aussi, il faut indexer la colonne sql sur laquelle le where est effectué.

Note supplémentaire : esup-sgc permet à un utilisateur existant dans le SI de disposer d'une carte dans le SGC. Un utilisateur existant correspond à une entrée dans un des "UserInfoService" que vous aurez configuré avec donc a minima un eduPersonPrincipalName (ou équivalent uid_local@domaine). ESUP-SGC garantit ainsi une cohérence du SI en ne déstructurant pas votre SI, puisque chaque carte est relié à une entité compte utilisateur renseignée dans le SI. En utilisant eduPersonPrincipalName cependant ici comme identifiant des comptes détenant les cartes, on tend ici cependant à généraliser l'usage d'eduPerson (dont est issu eduPersonPrincipalName) à l'ensemble des comptes du SI, et pas seulements aux seuls "personnes humaines" comme recommandé.

Les serveurs ESUP-SGC et ESUP-NFC-Les serveurs ESUP-SGC et ESUP-NFC-TAG sont shibbolethisés, leur déclaration en tant que Service Provider dans la fédération d'identités Renater est donc obligatoire ?

...

Bloc de code
languagexml
themeRDark
<p class="card-birthday">Née le 17/12/1999</p><p class="card-ine">N° INE : 18100XXXXX</p>

...

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 carte.

Comment faire une demande de carte en utilisant le webservice proposé par ESUP-SGC ?

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

...

Bloc de code
languagetext
themeRDark
accessRestrictionWSRestApi=hasIpAddress('127.0.0.1') or hasIpAddress('192.168.1.39') or hasIpAddress('192.168.22.0/24')

Comment passer la carte d'un état à un autre via web-service ?

Lors de cet appel au WebService, les paramètres possibles correspondent en réalité à l'ensemble des attributs d'une Carte au sens Java. On peut déduire ces paramètres du code Java lui-même donné ici : https://github.com/EsupPortail/esup-sgc/blob/master/src/main/java/org/esupportail/sgc/domain/Card.java

 Exemple d'appel WEB-Service spécifiant le CSN et le numéro de contrôle d'accès dans le cadre où on souhaiterait 'importer' des cartes éditées par une autre solution Le passage d'un état à un autre d'une carte peut se faire via l'appel à un webservice. Cet appel ressemble à ceci :

Bloc de code
languagebash
themeRDark
curl -F -d"desfireIds[access-control]=12340000000125" -F "etatcsn=REQUEST_CHECKED0479CDE56F1490" https://esup-sgc.univ-ville.fr/wsrest/api/setCardEtat/1818864

Où 1818864 est l'id de la carte. Cet appel retourne true ou false suivant que la commande a réussi ou échoué.

Ainsi, si on veut par exemple demander une carte par web-service et valider aussitôt cette demande, il faudra appeler le web service de la question précédente suivie de celui-ci.

 -F "eppn=toto@univ-ville.fr" -F "difPhotoTransient=true" -F "crousTransient=true" -F "europeanTransient=true" -F "PhotoFile.file=@/tmp/toto.jpeg" https://esup-sgc.univ-ville.fr/wsrest/api

Notez qu'on peut donc ici spécifier l'etat dans lequel on souhaiterait voir la carte éditée (-F "etat=ENCODED" par exemple) mais suivre le cycle de vie de la carte peut cependant être préférable pour pouvoir
bénéficier des appels de fonctions entre les transitions de la carte (positionnement des rectos imprimés, envoi d'email, activation de la carte) : d'autant qu'une fois la demande créee, on peut aussi passer les changements d'états par WS également.

Comment passer la carte d'un état à un autre via web-service ?

Le passage d'un état à un autre d'une carte peut se faire via l'appel à un webservice. Cet appel ressemble à ceci Exemple en python :

Bloc de code
languagepybash
themeRDark
curl -d "etat=REQUEST_CHECKED" https://esup-sgc.univ-ville.fr/wsrest/api/setCardEtat/1818864

Où 1818864 est l'id de la carte. Cet appel retourne true ou false suivant que la commande a réussi ou échoué.

Ainsi, si on veut par exemple demander une carte par web-service et valider aussitôt cette demande, il faudra appeler le web service de la question précédente suivie de celui-ci.

Exemple en python :


Bloc de code
languagepy
themeRDark
#!/usr/bin/env python3          #!/usr/bin/env python3                                                                                                                                                                              
# -*- coding: utf-8 -*-                                                                                                                                                                       

import requests

api_url = "https://esup-sgc.univ-ville.fr/wsrest/api"
response = requests.post(api_url, data={"eppn":"toto@univ-ville.fr"}, files={"PhotoFile.file":("photo-toto.png", open("/tmp/photo-toto.png","rb"), "image/png")})
card_id = response.text
response = requests.post("%s/setCardEtat/%s" % (api_url, card_id), data={"etat":"REQUEST_CHECKED"})
print(response.text)

...

  • on peut passer de l'état NEW à REJECTED par exemple ;
  • mais on ne peut pas passer de DESTROYED à NEW ;
  • les changements d'état par web service ont le même comportement que via l'interface web, des mails sont envoyés si des messages (sans dans admin/messages) ont été configurés en ce sens ;
  • la validation des services s'opèrent si on passe la carte à ENABLED ;
  • le services sont invalidés si on passe sur l'état DISABLED
  • ainsi l'impression d'une carte (via l'édition en 1 passe) peut être déclenchée également par ce même web service, cf q/r plus bas ;
  • NEW ne peut pas être utilisé par exemple concrètement ici, pour demander une nouvelle carte il faut utiliser le web-service de demande de carte décrit ci-avant ;
  • de même, RENEWED ne peut pas être utilisé également dans ce web-service, il faut utiliser le web-service décrit ci-après ;
  • ...

...

Bloc de code
languagepy
themeRDark
#!/usr/bin/env python3                                                                                                                                                                        
# -*- coding: utf-8 -*-                                                                                                                                                                       

import requests


api_url = "https://esup-sgc.univ-ville.fr/wsrest/api"
response = requests.post(api_url, data={"eppn":"toto@univ-ville.fr"}, files={"PhotoFile.file":("photo-toto.png", open("/tmp/photo-toto.png","rb"), "image/png")})
card_id = response.text
requests.post("%s/setCardEtat/%s" % (api_url, card_id), data={"etat":"REQUEST_CHECKED"})
requests.post("%s/setCardEtat/%s" % (api_url, card_id), data={"etat":"IN_PRINT", "printerEppn":"dsiprint@univ-ville.fr"})

De quelles données utilisateur issues du SI esup-sgc a besoin  ?

ESUP-SGC a besoin de récupérer un certain nombre de champs/donnnées utilisateurs depuis le SI, il lui faut par exemple le nom et prénom pour l'imprimer sur la carte.

L'ensemble de ces champs sont listés dans le tableau de cette page wiki. On privilégie l'usage de champs utilisateurs 'standardisés'. En ce sens on privilégie notamment l'usage de champs supann.

Suivant votre usage, certains champs sont +/- obligatoires.

Comment sont synchronisées les données utilisateur  ?

La synchronisation des données/champs utilisateurs depuis le Système d'Information vers ESUP-SGC se fait en fonction des "userInfoServices" que vous aurez configuré dans applicationContext-services.xml

En fonction des données synchronisées, cette synchronisation peut ensuite engendrer une synchronisation des services de contrôles d'accès, ldap, crous, esc-r (si la date de fin est dépassée et que la carte devient caduque, par exemple).

La synchronisation si-> esup-sgc est déclenchée par plusieurs moyens, en fonction de vos configurations et des actions des utilisateurs, c'est à dire : 

...


Peut-on envoyer le CSN de la carte par Web Service ?

L'usage standard d'esup-sgc est de l'utiliser conjointement avec esup-nfc-tag pour éditer la carte, c'est à dire imprimer et encoder la carte. 

"Encoder la carte" correspond :

  • à 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.

Cependant, ce mécanisme peut être intéressant à réaliser dans un contexte d'établissement qui externaliserait l'encodage (et impression) de la carte à un prestataire mais qui souhaiterait utiliser esup-sgc pour ses possibilités de workflow / gestion du cycle de ve de la carte.

Le Web Service d'esup-sgc permet donc de marquer comme encodée une carte en passant le CSN en paramètre. Exemple (avec curl ici ) :

Bloc de code
languagebash
themeRDark
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  ?

ESUP-SGC a besoin de récupérer un certain nombre de champs/donnnées utilisateurs depuis le SI, il lui faut par exemple le nom et prénom pour l'imprimer sur la carte.

L'ensemble de ces champs sont listés dans le tableau de cette page wiki. On privilégie l'usage de champs utilisateurs 'standardisés'. En ce sens on privilégie notamment l'usage de champs supann.

Suivant votre usage, certains champs sont +/- obligatoires.

Comment sont synchronisées les données utilisateur  ?

La synchronisation des données/champs utilisateurs depuis le Système d'Information vers ESUP-SGC se fait en fonction des "userInfoServices" que vous aurez configuré dans applicationContext-services.xml

En fonction des données synchronisées, cette synchronisation peut ensuite engendrer une synchronisation des services de contrôles d'accès, ldap, crous, esc-r (si la date de fin est dépassée et que la carte devient caduque, par exemple).

La synchronisation si-> esup-sgc est déclenchée par plusieurs moyens, en fonction de vos configurations et des actions des utilisateurs, c'est à dire : 

  • à 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.

La page Synchronisations sur ce même wiki donne des informations techniques supplémentaires.

Comment obtenir des identifiants pour utiliser l'API CNOUS lescrous ou encore l'API ESC (Eropean Student Card) ?

Pour synchroniser les données utilisateurs et cartes avec l'API CNOUS ou encore l'API ESC vous avez besoin d'identifiants sur les plateformes de pré-production puis de production de l'api CNOUS et l'api ESC - cf Configurations API CROUS / ESCR.

Pour les obtenir, et en tant que membre de la DSI (ou référent technique dans votre établissement) vous pouvez contacter departement-vem@cnous.fr en mettant également en copie 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.

Peut-on encoder l'application CROUS quand on utilise des cartes vierges ?

Dans le cadre d'Esup-SGC il est conseillé d'utiliser des cartes pré-encodées avec l'application CROUS/IZLY. Il est tout de même possible d'activer l'encodage CROUS lors de l'encodage de cartes vierges avec Esup-Sgc-Client. Pour cela il faut:

  • Utiliser un PC sous un windows 64 bits et se procurer l'application cnousApi auprès de la liste esup-sgc-devel@esup-portail.org
  • Obtenir une plage d'identifiants auprès du CNOUS ainsi qu'une DLL, un fichier clé CNOUS ZDC et une clé matérielle SAM.

  • Installer l'application sous c:\cnousApi, le dossier devra contenir les fichier suivants:
    - cnous_fournisseur_carte.dll (fourni sur demande par le cnous)
    - CreationCarteCrous.exe (correspond à https://github.com/EsupPortail/esup-crous-client)
    - CreationCarteCrous.exe.config (correspond à https://github.com/EsupPortail/esup-crous-client)
    - key.txt (Clé CNOUS ZDC fourni sur demande par le cnous)
    - libeay32.dll (openSSL)
    - libssl32.dll (openSSL)
    - pcsc_desfire.dll (springcard)

  • Brancher la clé USB SAM (fourni sur demande par le cnous)

  • Lancer CreationCarteCrous.exe permet de s'assurer que l'application fonctionne correctement

- "CreationCarteCrous.exe -t" doit afficher true
- "CreationCarteCrous.exe -l" permet de lire l'application CROUS d'une carte

  • Modifier la configuration du sgc dans applicationContext-services.xml
Bloc de code
languagexml
themeRDark
<bean class="org.esupportail.sgc.services.cardid.CnousCardIdService">
	<property name="appName" value="crous"/>
	<property name="idCounterBegin" value="<numero de debut de plage CNOUS>"/>
	<property name="postgresqlSequence" value="crous_smart_card_sequence"/>
	<property name="crousEncodeEnabled" value="true"/>
</bean>

  • Insérer le premier identifiant de votre plage au niveau du idCounterBegin et mettre crousEncodeEnabled à true.

Lors du lancement de l'application Esup-Sgc-Client depuis le SGC, un contrôle de l'application cnousApi sera effectué. 

La première ligne de log doit indiquer "dll cnous : OK"

Utilisation de cartes pré-encodées

En utilisant des cartes pré-encodées CROUS, vous n'aurez pas besoin de mettre en œuvre l'encodage CROUS (avec pc windows, dll crous, clef sam, génération d'identifiants izly ...).

Il vous suffira en effet simplement d'importer le fichier CSV reçu avec les cartes pré-encodées dans le SGC : onglet Admin > Cartes Crous.

Cela fonctionnera de fait si vous demandez à votre fournisseur de cartes un CSV reprenant le formattage proposé nativement par la DLL CROUS/CNOUS !

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 ?")

Utilisation de cartes pré-encodées - ajout du fichier CSV par Web Service

Dans des usages très particuliers, vous pouvez utilsier l'API REST pour importer le CSV issu de la DLL CROUS, et fourni par votre prestataire lors de la livraison de vos cartes (pré)encodées ainsi par exemple : 

Bloc de code
languagebash
themeRDark
curl --form "file=@/tmp/le-csv.txt" https://esup-sgc.univ-ville.fr/wsrest/api/addCrousCsvFile

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 :

Image AddedEncodeur

Lien esup-sgc de esup-sgc-client.jnlp qui lance le jar esupsgcclient-XXXX.jar

La page Synchronisations sur ce même wiki donne des informations techniques supplémentaires.

Comment obtenir des identifiants pour utiliser l'API CNOUS lescrous ou encore l'API ESC (Eropean Student Card) ?

Pour synchroniser les données utilisateurs et cartes avec l'API CNOUS ou encore l'API ESC vous avez besoin d'identifiants sur les plateformes de pré-production puis de production de l'api CNOUS et l'api ESC - cf Configurations API CROUS / ESCR.

Pour les obtenir, et en tant que membre de la DSI (ou référent technique dans votre établissement) vous pouvez contacter departement-vem@cnous.fr en mettant également en copie 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.

Peut-on encoder l'application CROUS quand on utilise des cartes vierges ?

Dans le cadre d'Esup-SGC il est conseillé d'utiliser des cartes pré-encodées avec l'application CROUS/IZLY. Il est tout de même possible d'activer l'encodage CROUS lors de l'encodage de cartes vierges avec Esup-Sgc-Client. Pour cela il faut:

  • Utiliser un PC sous un windows 64 bits et se procurer l'application cnousApi auprès de la liste esup-sgc-devel@esup-portail.org
  • Obtenir une plage d'identifiants auprès du CNOUS ainsi qu'une DLL, un fichier clé CNOUS ZDC et une clé matérielle SAM.

  • Installer l'application sous c:\cnousApi, le dossier devra contenir les fichier suivants:
    - cnous_fournisseur_carte.dll (fourni sur demande par le cnous)
    - CreationCarteCrous.exe (correspond à https://github.com/EsupPortail/esup-crous-client)
    - CreationCarteCrous.exe.config (correspond à https://github.com/EsupPortail/esup-crous-client)
    - key.txt (Clé CNOUS ZDC fourni sur demande par le cnous)
    - libeay32.dll (openSSL)
    - libssl32.dll (openSSL)
    - pcsc_desfire.dll (springcard)

  • Brancher la clé USB SAM (fourni sur demande par le cnous)

  • Lancer CreationCarteCrous.exe permet de s'assurer que l'application fonctionne correctement

- "CreationCarteCrous.exe -t" doit afficher true
- "CreationCarteCrous.exe -l" permet de lire l'application CROUS d'une carte

  • Modifier la configuration du sgc dans applicationContext-services.xml
Bloc de code
languagexml
themeRDark
<bean class="org.esupportail.sgc.services.cardid.CnousCardIdService">
	<property name="appName" value="crous"/>
	<property name="idCounterBegin" value="<numero de debut de plage CNOUS>"/>
	<property name="postgresqlSequence" value="crous_smart_card_sequence"/>
	<property name="crousEncodeEnabled" value="true"/>
</bean>

  • Insérer le premier identifiant de votre plage au niveau du idCounterBegin et mettre crousEncodeEnabled à true.

Lors du lancement de l'application Esup-Sgc-Client depuis le SGC, un contrôle de l'application cnousApi sera effectué. 

La première ligne de log doit indiquer "dll cnous : OK"

Utilisation de cartes pré-encodées

En utilisant des cartes pré-encodées CROUS, vous n'aurez pas besoin de mettre en œuvre l'encodage CROUS (avec pc windows, dll crous, clef sam, génération d'identifiants izly ...).

Il vous suffira en effet simplement d'importer le fichier CSV reçu avec les cartes pré-encodées dans le SGC : onglet Admin > Cartes Crous.

Cela fonctionnera de fait si vous demandez à votre fournisseur de cartes un CSV reprenant le formattage proposé nativement par la DLL CROUS/CNOUS !

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 ?")

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 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 :

Image RemovedEncodeur

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.

Image RemovedEncodeur - robot ZXP3

Lien esup-sgc de esup-sgc-client-r2d2.jnlp qui lance le jar esupsgcclient-r2d2.jar
Le code source est sur https://github.com/EsupPortail/esup-sgc-client - branche univ-rouen-robot-zxp3
C'est un encodeur compatible esup-sgc, il requiert une webcam et une imprimante Zebra ZXP3 sous Windows. Cela permet l'encodage de plusieurs cartes via le chargeur de la ZXP3.
Le jar n'est par fourni par défaut dans esup-sgc, il faut le compiler soi-même et le signer (contrainte java web start).

Image RemovedApplication Android

Lien esup-nfc-tag-server de esupnfctagdroid.apk
Le code source est sur https://github.com/EsupPortail/esup-nfcsgc-tagclient - droidbranche master
C'est l'application cliente esup-nfc sous Android. Elle permet d'intégrer de manière générique le badgeage dans des applications institutionnelles. Pour ce faire elle propose le badgeage dans les 'salles' esup-nfc, salles elles-mêmes récupérées depuis d'autres applications. Esup-SGC fait partie de ces applications et propose des salles de recherche, livraison, verso dématérialisé, mise à jour.
L'apk n'est par fourni par défaut dans esup-nfc-tag-server, il faut configurer les sources (lien sur le serveur esup-nfc-tag-server) et le compiler soi-même.

...

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.

Image AddedEncodeur - robot ZXP3

Lien esup-sgc de esup-sgc-client-r2d2.jnlp qui lance le jar esupsgcclient-r2d2Lien esup-nfc-tag-server de esupnfctagdesktop.jar
Le code source est sur https://github.com/EsupPortail/esup-sgc-client - branche univ-rouen-robot-zxp3
C'est un encodeur compatible esup-sgc, il requiert une webcam et une imprimante Zebra ZXP3 sous Windows. Cela permet l'encodage de plusieurs cartes via le chargeur de la ZXP3.
Le jar n'est par fourni par défaut dans esup-sgc, il faut le compiler soi-même et le signer (contrainte java web start).

Image AddedApplication Android

Lien esup-nfc-tag-server de esupnfctagdroid.apk
Le code source est sur https://github.com/EsupPortail/esup-nfc-tag-desktopdroid
C'est l'application cliente esup-nfc pour PC (Desktop : client java).
sous Android. Elle permet d'intégrer de manière générique le badgeage dans des applications institutionnelles. Pour ce faire elle propose le badgeage dans les 'salles' esup-nfc, salles elles-mêmes récupérées depuis d'autres applications. Esup-SGC fait partie de ces applications et propose des salles de recherche, livraison, verso dématérialisé, mise à jour.
Le jar L'apk n'est par fourni par défaut dans esup-nfc-tag-server, il faut configurer les sources (lien sur le serveur esup-nfc-tag-server) et le compiler soi-même.

Dans le cadre d'une migration sur ESUP-SGC, comment réimporter les cartes éditées/encodées par l'ancien SGC ?

Voir Importation de 'cartes' dans ESUP-SGC / Migration des données.


Image AddedApplication Java

Lien esup-nfc-tag-server de esupnfctagdesktop.jar
Le code source est sur https://github.com/EsupPortail/esup-nfc-tag-desktop
C'est l'application cliente esup-nfc pour PC (Desktop : client java).
Elle permet d'intégrer de manière générique le badgeage dans des applications institutionnelles. Pour ce faire elle propose le badgeage dans les 'salles' esup-nfc, salles elles-mêmes récupérées depuis d'autres applications. Esup-SGC fait partie de ces applications et propose des salles de recherche, livraison, verso dématérialisé, mise à jour.
Le jar n'est par fourni par défaut dans esup-nfc-tag-server, il faut configurer les sources (lien sur le serveur esup-nfc-tag-server) et le compiler soi-même.

Dans le cadre d'une migration sur ESUP-SGC, comment réimporter les cartes éditées/encodées par l'ancien SGC ?

Voir Importation de 'cartes' dans ESUP-SGC / Migration des données.

Comment repartir sur une base propre et vide dans esup-sgc, suffit-il de mettre Comment repartir sur une base propre et vide dans esup-sgc, suffit-il de mettre "create" au lieu de "update" au niveau du fichier persistence.xml ?

...

Bloc de code
languagebash
themeRDark
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
languagebash
themeRDark
wget 'http://localhost:8080/wsrest/api/get?eppn=toto@univ-ville.fr&eppn=titi@univ-ville.fr'

Quelle version de Java puis-je utiliser ?

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.

Désormais on propose

La récupération du CSN de la carte active peut se faire ainsi par exemple :

Bloc de code
languagebash
themeRDark
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
languagesql
themeRDark
select csn from card where eppn='toto@univ-ville.fr' and etat='ENABLED';

Quelle version de Java puis-je utiliser ?

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.

Désormais on propose

  • côté serveur, pour esup-sgc et esup-nfc-tag, vous pouvez utiliser openjdk 17 ou 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
  • côté serveur, pour esup-sgc et esup-nfc-tag, vous pouvez utiliser openjdk 17 ou 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.

Mis à part Java,

...

quelles sont les autres technologies requises côté serveur ?

esup-sgc et esup-nfc-tag-server sont les 2 appliations web à installer côté serveur.

Elles sont codées en utilisant le framework Spring 5 et Java Servlet 4.0 et utilisent des spécificités de PostgreSQL, l'authentification repose pour sa part sur les entêtes HTTP fournis par un proxy web (cf la Q/R "ESUP-SGC supporte donc une authentification autre que shibboleth ? CAS ? OpenID ? LDAP ?").

Ainsi, PostgreSQL est requis, le minimum doit être la version8, on vous conseille d'utiliser la version proposée par votre distribution linus ; postgresql 15.5 sous debian bookworm par exemple.

...

Quelles optimisations serveur sont possibles ?

Octobre 2021Mars 2024,  le le esup-sgc de l'Université de Rouen Normandie gère 100.000 cartes pour plus de 5080.000 utilisateurs (étudiants de l'année n et , n-1, ... personnels, invités ...).

L'ensemble des briques serveur esup-sgc (esup-sgc, esup-nfc-tag, apache en frontal et base de données Postgresql) tourne sur  une seule VM qui dispose de 2 4 CPUS et 8 12 GB de RAM.
La base de données prend un peu moins de 40GB sur disque25GB sur disque.
Le serveur est une debian bookworm avec openjdk 17, postgresql 15 et apache 2.4 (avec mpm_event) de cette distribution.

Le service est stable et peu gourmand ; complexifier l'architecture en installant des mécansimes mécanismes logiciels de failover ou load-balancing n'est pas conseillé.

1 2 GB de RAM alloué au tomcat d'esup-sgc (-Xms1024M -Xmx1024MXmx2048M) est suffisant.

L'AJP est utilisé entre le tomcat et le apache avec un proxypass ainsi fait :
ProxyPass / ajp://localhost:8009/ ttl=10 timeout=3600 retry=1

...

Un munin avec les plugins suivants peut également être utile par exemple :
cpu  df_inode http_loadtime irqstats  memory open_files postgres_autovacuum  postgres_connections_ALL processes swap uptime df diskstats interrupts load netstat open_inodes postgres_checkpoints postgres_size_ALL proc_pri threads  usersOn conseille de paramétrer du cache http/apache et la compression côté des frontaux. 

Côté PostgreSQL, on conseille de procéder à quelques paramétrages élémentaires permettant de mettre à profit les capacités matérielles du serveur.

Une mesure de performance de l'instance d'esup-sgc est de regarder le temps de récupération(et rendu) de la page "manager" lors d'une recherche ou non affichant 10 cartes simplement.
Sous chrome, via l'outil d'inspection / réseau, la page en elle-même est rendue en moins de 200ms quelque soit la recherche effectuée, chaque photo de carte (non mise en cache) moins de 15ms ; l'ensemble s'affiche en moins de 800ms. 

Les synchronisations des utilisateurs s'opèrent grâce à de très nombreuses Les synchronisations des utilisateurs s'opèrent grâce à de très nombreuses requêtes ldap/sql sur les LDAP et bases de données SQL du SI.
Ces requêtes sont issues des configurations données dans applicationContext-services.xml.
Aussi les ldap et bases de données doivent présenter des index permettant de répondre au mieux à ces requêtes (l'eppn est généralement utilisé comme clef).

ESUP-NFC-TAG

Je n'ai pas de groupes dans ldap, est-ce que je peux plutôt utiliser des filtres pour affecter les rôles dans l'application ESUP-NFC-TAG ?

Même si l'usage de groupes ldap, notamment via l'usage de Grouper, est conseillé (c'est ce que propose la configuration par défaut et c'est ce qui est utilisé dans la VM de démonstration), il est effectivement possible d'utiliser en lieu et place des filtres ldap.

Pour ce faire, dans applicationContext-security.xml on modifiera 

Bloc de code
languagexml
themeRDark
	<beans:bean id="groupService" class="org.esupportail.nfctag.security.LdapGroupService">
		<beans:property name="ldapTemplate" ref="ldapTemplate"/>
		<beans:property name="groupSearchBase" value="ou=groups" />
		<beans:property name="groupSearchFilter" value="member={0}"/>
		<beans:property name="memberSearchBase" value="ou=people"/>
		<beans:property name="memberSearchFilter" value="memberOf={0}"/>
	</beans:bean>

par quelque chose du type : 

Bloc de code
languagexml
themeRDark
	<beans:bean id="groupService" class="org.esupportail.nfctag.security.LdapFilterGroupService">
		<beans:property name="ldapTemplate" ref="ldapTemplate"/>
		<beans:property name="ldapFiltersGroups">
			<util:map>
				<beans:entry key="eduPersonPrincipalName=joe@univ-ville.fr" value="esup-nfc-admins"/>
				<beans:entry key="eduPersonPrincipalName=jack@univ-ville.fr" value="esup-nfc-supervisors"/>
			</util:map>
		</beans:property>
	</beans:bean>

C'est ensuite ces noms de groupes ainsi déifinis ('esup-sgc-admins', 'esup-nfc-supervisors') qui peuvent être utilisés au niveau du bean nfcMappingGroupesRoles pour définir les rôles de chacun : 

Bloc de code
languagexml
themeRDark
	<util:map id="nfcMappingGroupesRoles">
			<beans:entry key="esup-nfc-admins" value="ROLE_ADMIN" />
			<beans:entry key="esup-nfc-supervisors" value="ROLE_SUPERVISOR" />
	</util:map>

Nous souhaitons mettre en place l'encodage des cartes pour du contrôle d'accès basé sur Desfire

ESUP-SGC et ESUP-NFC-TAG permettent cette mise en oeuvre de l'encodage Desfire pour des usages très sécurisés comme le contrôle d'accès.

C'est la partie la plus délicate de l'installation d'une telle plateforme dans un établissement ou un groupement d'établissements : Desfire est assez éloignée de nos coeurs de métiers dans nos SI !

Pour une telle mise en oeuvre, nous vous conseilleurs de prendre connaissance et lire attentivement les documentations suivantes sur les espaces ESUP-SGC / ESUP-NFC-TAG : 

Avant toute chose cependant, assurez-vous d'être en possession de la "master key" de vos cartes !

Sans cette clef, vous n'aurez pas  la possibilité d'ajouter des "applications Mifare Desfire" sur vos cartes.

J'ai besoin de connaître la master key de ma carte ?

La "master key" de la carte Mifare Desfire est une clef (DES ou AES) qui permet d'ajouter des "applications Desfire" pour du contrôle d'accès ou tout autre type d'usage.

Ces applications Desfire peuvent être positionnées par esup-nfc-tag si vous avez en votre possession la master key de la carte.

Pour plus d'information sur NFC et Mifare Desfire, vous pouvez consulter la page wiki Tags NFC - getting started.

Vous avez donc besoin de connaitre effectivement la master key de votre carte uniquement si vous souhaitez ajouter des applications Mifare Desfire dans vos cartes.

Cependant nous vous conseillons fortement d'avoir la main sur vos propres cartes, c'est à dire de faire en sorte d'avoir en votre possession la master key de vos cartes.

Quelle est la master key de ma carte ?

Les cartes Mifare Desfire vierges ont une master key en DES à 0, sa représentation en hexa est 0000000000000000.

Dès qu'on encode une carte, il est d'usage de prendre la main sur la carte et de modifier cette master-key par défaut par une clef différente, usuellement en AES (car plus sécurisé).

Si vos cartes sont pré-encodées ou ont été encodées par un sous-traitant, demandez leur de positionner une master-key unique pour l'ensemble de vos cartes (et d'en avoir connaissance).

Comment avoir la master-key sur des cartes pré-encodées CROUS ?

On conseille de faire pré-encoder vos cartes avec l'application CROUS/IZLY, cela vous évite de manipuler des clefs sam, dll windows, etc.

Au moment du pré-encodage, pour des questions de sécurité, une master-key est positionnée par l'entreprise qui encode vos cartes.

Par défaut cette master-key est diversifiée, non unique pour l'ensemble de vos cartes, et fonction de la clef SAM crous ; en d'autres termes cette master key vous est inconnue et vous ne pouvez pas alors ajouter de nouvelles applications avec votre esup-sgc / esup-nfc-tag.

Aussi, on vous recommande fortement de demander à positionner une master-key sur vos cartes.  Pour ce faire, vous devez transmettre cette clef en suivant la procédure "MasterKeyGenerator : Génération & communication de clés" mise au point par le CROUS : téléchargement ici.

Cette procédure, accompagnée d'un programme java (jar) vous permet d'obtenir votre master-key à positionner et 3 fichiers supplémentaires, qui assemblés, permettent au prestataire de positionner la master-key sur vos cartes (sans pour autant en avoir connaissance).

Ces 3 fichiers doivent être envoyés par mail chiffrés (c'est le prestataire qui vous donne les 3 mails et 3 clefs de chiffrement respectives à utiliser pour ce faire).

Quels types de cartes ESUP-NFC-TAG est-il capable d'encoder ?

ESUP-NFC-TAG propose l'encodage (et décodage/lecture sécurisée) des cartes Mifare Desfire ; c'est à dire les cartes actuellement les plus utilisées dans nos établissements car considérées comme les plus sécurisées et permettant ainsi de proposer en confiance un moyen de paiement et de contrôle d'accès.

De fait ESUP-NFC-TAG supporte à la fois les cartes Mifare Desfire EV1 et Mifare Desfire EV2.

Peut-on utiliser esup-nfc-tag pour modifier la master key d'une carte

Dans certains cas (par exemple l'utilisation de carte vièrge dans le cadre du SGC) il peut être nécessaire de positionner une cle master sur une carte avant de pouvoir l'encoder normalament (ceci sans passer par les différents contrôles proposés par esup-nfc-tag). En effet esup-nfc-tag propose, dans son fonctionnement le plus courant, de contrôler l'existence de la carte puis de vérifier sa validité dans le système d'information (tagIdCheck et validateTag).

L'idée ici est de shunter ces deux étapes en utilisant les implémentations Dummy proposées dans esup-nfc-tag-server. Ces implémentations valident systématiquement les tags en retournant "true" quelle que soit la carte badgée.

Il est donc possible de créer un bean AppliExtApi reprenant l'implémantation AppliExtDummy en précisant un nom de salle (location) personnalisé.

De plus il faut déclarer un DesfireWriteConfig et un DesfireTag qui décrivent les actions à opérer sur la carte.

Dans ce cas il faut donc ajouter la configuration suivante:

applicationContext-desfire.xml (pour modifier la master key par defaut par une clé AES)

Bloc de code
languagexml
themeRDark
<bean id="desfireChangeMasterKeyTagEsupSgc" class="org.esupportail.nfctag.beans.DesfireTag" p:formatBeforeWrite="false" p:keyStart="0000000000000000" p:keyTypeStart="DES" p:keyFinish="12345678901234567890123456789012" p:keyTypeFinish="AES" p:keyVersionFinish="01">   
</bean>
 
<bean id="desfireAuthConfigChangeKeyMasterEsupSgc" class="org.esupportail.nfctag.service.api.impl.DesfireWriteConfig">
    <property name="desfireTag" ref="desfireChangeMasterKeyTagEsupSgc" />
    <property name="description" value="Changement de la Master Key"/>
</bean>

La récupération et le calcul des UserInfoServices d'un utilisateur depuis le SI prend environ 3ms : ce temps de calcul est consultable dans l'IHM via le menu Admin < UserInfos.
Concernant le calcul des groupes et rôles, l'IHM via le menu Admin < GroupsRoles donne 122ms pour la récupération des groupes d'un user ou encore 326ms pour lé décompte des membres des différents groupes.
La synchronisation totale régulière des 80.000 utilisateurs (cf ResynchronisationService en level info dans les logs) se fait en 33min, avec seuls 300 environs notés comme ayant "du" être mis à jour.
Notez que cette synchronisation n'est pas parallélisée : nous avons préféré ici la faire fonctionner sur un seul thread ce qui permet de garantir une non sur-sollicitation des ressources système du esup-sgc mais aussi du reste du SI (ldap, bd sql, ...) en estimant ici qu'il n'y avait pas lieu de minimiser le temps d'exécution de la synchronisation totale.
La synchronsisation totale régulière des groupes en base (LdapGroup2UserRoleService en level debug dans les logs) prend 0.5sec.

L'usage CPU du esup-sgc est finalement très modéré, des pics d'usage sont simplement présents lors des synchronisations totales et du backup (pg_dump) de la base : 

Image Added

Côté apache, les requêtes en long polling utilisées par esup-sgc et esup-nfc-tag sont bien présentes :

Image Added 

Accélération temporaire pour optimiser des procédures de modifications en masse.

Les modifications en base de données esup-sgc des données sur les cartes et les utilisateurs sont sujet à une indexation plein texte continue qui sont consommateurs de ressources.

Sur un usage courant et quotidien d'esup-sgc, même avec des centaines de milliers de cartes et utilisateurs, cette (ré)indexation à chaque modification d'une entrée de carte et/ou utilisateur n'est pas pénalisante, mais elle peut le devenir si vous intervenez en masse sur l'ensemble de la base de données.

Ainsi par exemple, la procédure d'upgrade de la base de données esup-sgc lors de montée de version majeure intègre de facto la désactivation des triggers permettant l'indexation plein texte continue des cartes/utilisateurs, la réindexation totale plein texte et la réactivation des triggers.

Si vous devez intervenir sur la base de données en masse et que vous avez des dizaines de milliers d'entrées de cartes et utilisateurs, nous vous conseillons d'en faire de même ainsi.

Dans psql pour désactiver les triggers :


Bloc de code
languagesql
themeRDark
esupsgc=# alter table user_account disable trigger tsvectorupdateuser;
esupsgc=# alter table card disable trigger tsvectorupdate;


Vous pouvez alors effectuer vos modifications.

Ensuite, vous pouvez réindexer l'ensemble et réactiver les triggers, dans psql toujours : 


Bloc de code
languagesql
themeRDark
esupsgc=# UPDATE card SET textsearchable_index_col = setweight(to_tsvector('simple', coalesce(card.eppn,'')), 'B')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.name,''),'-',' ')), 'A')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.firstname,''),'-',' ')), 'B')
 || setweight(to_tsvector('simple', coalesce(user_account.email,'')), 'B')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.supann_emp_id,''),'-',' ')), 'B')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.supann_etu_id,''),'-',' ')), 'B')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.supann_entite_affectation_principale,''),'-',' ')), 'C')
 || setweight(to_tsvector('simple', replace(coalesce(card.csn,''),'-',' ')), 'C')
 || setweight(to_tsvector('simple', replace(coalesce(card.full_text,''),'-',' ')), 'D')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.full_text,''),'-',' ')), 'D')
 FROM user_account where card.eppn=user_account.eppn;

esupsgc=# alter table user_account enable trigger tsvectorupdateuser;
esupsgc=# alter table card enable trigger tsvectorupdate;


ESUP-NFC-TAG

Je n'ai pas de groupes dans ldap, est-ce que je peux plutôt utiliser des filtres pour affecter les rôles dans l'application ESUP-NFC-TAG ?

Même si l'usage de groupes ldap, notamment via l'usage de Grouper, est conseillé (c'est ce que propose la configuration par défaut et c'est ce qui est utilisé dans la VM de démonstration), il est effectivement possible d'utiliser en lieu et place des filtres ldap.

Pour ce faire, dans applicationContext-security.xml on modifiera 

Bloc de code
languagexml
themeRDark
	<beans:bean id="groupService" class="org.esupportail.nfctag.security.LdapGroupService">
		<beans:property name="ldapTemplate" ref="ldapTemplate"/>
		<beans:property name="groupSearchBase" value="ou=groups" />
		<beans:property name="groupSearchFilter" value="member={0}"/>
		<beans:property name="memberSearchBase" value="ou=people"/>
		<beans:property name="memberSearchFilter" value="memberOf={0}"/>
	</beans:bean>

par quelque chose du type : applicationContext-custom.xml (ajout d'une application dummy dediée)

Bloc de code
languagexml
themeRDark
<bean	<beans:bean id="dummyChangeMasterKeyExtApigroupService" class="org.esupportail.nfctag.service.api.impl.AppliExtDummysecurity.LdapFilterGroupService">
   	<property		<beans:property name="descriptionldapTemplate" valueref="Changement Master KeyldapTemplate"/>
   	<property		<beans:property name="locationsNamesldapFiltersGroups">
   			<util:list>
   			<value>Change Master Key</value>
   map>
				<beans:entry key="eduPersonPrincipalName=joe@univ-ville.fr" value="esup-nfc-admins"/>
				<beans:entry key="eduPersonPrincipalName=jack@univ-ville.fr" value="esup-nfc-supervisors"/>
			</util:list>
   	</property>
</bean>

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 et Mifare Desfire EV2 ?

Mifare Desfire EV2 est la dernière génération de Mifare Desfire, elle 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.

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.

map>
		</beans:property>
	</beans:bean>

C'est ensuite ces noms de groupes ainsi déifinis ('esup-sgc-admins', 'esup-nfc-supervisors') qui peuvent être utilisés au niveau du bean nfcMappingGroupesRoles pour définir les rôles de chacun : 

Bloc de code
languagexml
themeRDark
	<util:map id="nfcMappingGroupesRoles">
			<beans:entry key="esup-nfc-admins" value="ROLE_ADMIN" />
			<beans:entry key="esup-nfc-supervisors" value="ROLE_SUPERVISOR" />
	</util:map>

Nous souhaitons mettre en place l'encodage des cartes pour du contrôle d'accès basé sur Desfire

ESUP-SGC et ESUP-NFC-TAG permettent cette mise en oeuvre de l'encodage Desfire pour des usages très sécurisés comme le contrôle d'accès.

C'est la partie la plus délicate de l'installation d'une telle plateforme dans un établissement ou un groupement d'établissements : Desfire est assez éloignée de nos coeurs de métiers dans nos SI !

Pour une telle mise en oeuvre, nous vous conseilleurs de prendre connaissance et lire attentivement les documentations suivantes sur les espaces ESUP-SGC / ESUP-NFC-TAG : 

Avant toute chose cependant, assurez-vous d'être en possession de la "master key" de vos cartes !

Sans cette clef, vous n'aurez pas  la possibilité d'ajouter des "applications Mifare Desfire" sur vos cartes.

J'ai besoin de connaître la master key de ma carte ?

La "master key" de la carte Mifare Desfire est une clef (DES ou AES) qui permet d'ajouter des "applications Desfire" pour du contrôle d'accès ou tout autre type d'usage.

Ces applications Desfire peuvent être positionnées par esup-nfc-tag si vous avez en votre possession la master key de la carte.

Pour plus d'information sur NFC et Mifare Desfire, vous pouvez consulter la page wiki Tags NFC - getting started.

Vous avez donc besoin de connaitre effectivement la master key de votre carte uniquement si vous souhaitez ajouter des applications Mifare Desfire dans vos cartes.

Cependant nous vous conseillons fortement d'avoir la main sur vos propres cartes, c'est à dire de faire en sorte d'avoir en votre possession la master key de vos cartes.

Quelle est la master key de ma carte ?

Les cartes Mifare Desfire vierges ont une master key en DES à 0, sa représentation en hexa est 0000000000000000.

Dès qu'on encode une carte, il est d'usage de prendre la main sur la carte et de modifier cette master-key par défaut par une clef différente, usuellement en AES (car plus sécurisé).

Si vos cartes sont pré-encodées ou ont été encodées par un sous-traitant, demandez leur de positionner une master-key unique pour l'ensemble de vos cartes (et d'en avoir connaissance).

Comment avoir la master-key sur des cartes pré-encodées CROUS ?

On conseille de faire pré-encoder vos cartes avec l'application CROUS/IZLY, cela vous évite de manipuler des clefs sam, dll windows, etc.

Au moment du pré-encodage, pour des questions de sécurité, une master-key est positionnée par l'entreprise qui encode vos cartes.

Par défaut cette master-key est diversifiée, non unique pour l'ensemble de vos cartes, et fonction de la clef SAM crous ; en d'autres termes cette master key vous est inconnue et vous ne pouvez pas alors ajouter de nouvelles applications avec votre esup-sgc / esup-nfc-tag.

Aussi, on vous recommande fortement de demander à positionner une master-key sur vos cartes.  Pour ce faire, vous devez transmettre cette clef en suivant la procédure "MasterKeyGenerator : Génération & communication de clés" mise au point par le CROUS : téléchargement ici.

Cette procédure, accompagnée d'un programme java (jar) vous permet d'obtenir votre master-key à positionner et 3 fichiers supplémentaires, qui assemblés, permettent au prestataire de positionner la master-key sur vos cartes (sans pour autant en avoir connaissance).

Ces 3 fichiers doivent être envoyés par mail chiffrés (c'est le prestataire qui vous donne les 3 mails et 3 clefs de chiffrement respectives à utiliser pour ce faire).

Quels types de cartes ESUP-NFC-TAG est-il capable d'encoder ?

ESUP-NFC-TAG propose l'encodage (et décodage/lecture sécurisée) des cartes Mifare Desfire ; c'est à dire les cartes actuellement les plus utilisées dans nos établissements car considérées comme les plus sécurisées et permettant ainsi de proposer en confiance un moyen de paiement et de contrôle d'accès.

De fait ESUP-NFC-TAG supporte à la fois les cartes Mifare Desfire EV1, Mifare Desfire EV2, Mifare Desfilre EV3.

Mifare Desfire EV3 étant la dernière en date actuellement (NDR : au 11/03/2022), ce sont ces cartes qui sont achetées et utilisées par les établissements actuellement (via notamment le marché cartes multiservices porté par le CNOUS et le CNCEU).

Peut-on utiliser esup-nfc-tag pour modifier la master key d'une carte

Dans certains cas (par exemple l'utilisation de carte vièrge dans le cadre du SGC) il peut être nécessaire de positionner une cle master sur une carte avant de pouvoir l'encoder normalament (ceci sans passer par les différents contrôles proposés par esup-nfc-tag). En effet esup-nfc-tag propose, dans son fonctionnement le plus courant, de contrôler l'existence de la carte puis de vérifier sa validité dans le système d'information (tagIdCheck et validateTag).

L'idée ici est de shunter ces deux étapes en utilisant les implémentations Dummy proposées dans esup-nfc-tag-server. Ces implémentations valident systématiquement les tags en retournant "true" quelle que soit la carte badgée.

Il est donc possible de créer un bean AppliExtApi reprenant l'implémantation AppliExtDummy en précisant un nom de salle (location) personnalisé.

De plus il faut déclarer un DesfireWriteConfig et un DesfireTag qui décrivent les actions à opérer sur la carte.

Dans ce cas il faut donc ajouter la configuration suivante:

applicationContext-desfire.xml (pour modifier la master key par defaut par une clé AES)

Bloc de code
languagexml
themeRDark
<bean id="desfireChangeMasterKeyTagEsupSgc" class="org.esupportail.nfctag.beans.DesfireTag" p:formatBeforeWrite="false" p:keyStart="0000000000000000" p:keyTypeStart="DES" p:keyFinish="12345678901234567890123456789012" p:keyTypeFinish="AES" p:keyVersionFinish="01">   
</bean>
 
<bean id="desfireAuthConfigChangeKeyMasterEsupSgc" class="org.esupportail.nfctag.service.api.impl.DesfireWriteConfig">
    <property name="desfireTag" ref="desfireChangeMasterKeyTagEsupSgc" />
    <property name="description" value="Changement de la Master Key"/>
</bean>

applicationContext-custom.xml (ajout d'une application dummy dediée)

Bloc de code
languagexml
themeRDark
<bean id="dummyChangeMasterKeyExtApi" class="org.esupportail.nfctag.service.api.impl.AppliExtDummy">
   	<property name="description" value="Changement Master Key"/>
   	<property name="locationsNames">
   		<util:list>
   			<value>Change Master Key</value>
   		</util:list>
   	</property>
</bean>

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.

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 ?

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.

Avec 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 ?

Techniquement, il est possible de choisir soi-même un AID quelconque qui sera l'identificant de votre application de contrôle d'accès. Vous positionnerez alors les fichiers et clefs dans cette application.

Cependant, il est d'usage de s'adresser à NXP pour obtenir un AID qui vous soit propre. Cette procédure est gratuite et la société NXP s'assure ainsi de distribuer un AID unique et réservé pour l'usage de chacun. Pour ce faire, il faut remplir l'annexe A du document AN10787.pdf et l'envoyer à NXP via support.docstore@nxp.com.

Plus d'information à ce propos sur le document AN11909.pdf : How to create an Installation IDentifier (IID)

Le retour Contrôle d'accès à l'Université de Rouen Normandie dans ce même wiki vous donnera aussi des explications et cas d'usage sur l'encodage d'une application Desfire de contrôle d'accès dans le contexte d'esup-sgc/esup-nfc-tagAvec l'édition en 1 temps disponible dans esup-sgc 2, cette limitation est cependant théoriquement levée.

Est-ce qu'esup-sgc peut positionner des DAM keys sur les cartes supportant Mifare DesFire EV2 ?

...