Arborescence des pages

Vous regardez une version antérieure (v. /wiki/display/SGC/FAQ) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 53) afficher la version suivante »

Projet / plateforme ESUP-SGC

A quoi correspond ESUP-SGC, que fait-il, quelle est sa couverture fonctionnelle ?

En parcourant les différentes documentations, vous devriez vous faire une idée de la couverture fonctionnelle assez large d'ESUP-SGC.

Celui-ci est et a été présenté à divers occasions et des vidéos, articles et présentations sont disponibles en ligne  : ESUP-SGC#SGC-Documents,sp%C3%A9cifications,pr%C3%A9sentations,...

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 2019 à Dijon → Vidéo  / Diaporama / Article.

Nous hésitons à passer sur ESUP-SGC ...

Si vous mettez en œuvre un projet de carte étudiante / professionnel multi-services sur technologie Desfire dans votre établissement de l'ESR, la question du passage à ESUP-SGC peut effectivement se poser.

Les raisons qui peuvent vous pousser à mettre en place ESUP-SGC au lieu d'un autre SGC, notamment un SGC propriétaire fourni par un prestataire sont en effet nombreuses : 

  • Une non satisfaction du produit actuellement utilisé, mal ou peu intégré dans votre Système d'Information (c'est ce qui nous a amené à développer ESUP-SG, voir à ce propos sgc-v3.pdf).
  • Une meilleure maîtrise du SGC, de votre projet, de votre carte.
  • Une indépendance vis à vis d'un prestataire et d'un logiciel propriétaire, dont la pérennité ne peut être garantie (ESUP-SGC est un logiciel libre qui vous appartient sans restriction).
  • Une meilleure intégration du SGC dans votre Système d'Information, avec des interactions fortes et synchrones 
    • avec vos briques du SI, source de données : 
      • authentification/identification shibboleth
      • annuaire supann/ldap
      • bases de données sql
    • avec les services  de votre SI, consommateurs de la carte : 
      • CROUS/IZLY : via l' API CROUS - grâce à l'usage de cette API (en lieu et place de InfoCarteCROUS) ESUP-SGC vous y apporte une maitrise des échanges, une compréhension et possibilité de résoudre les problèmes de synchronisation/activation de comptes et carte Izly, ce en temps réel ; les avantages sont nombreux et qualitatifs pour l'usager final qui utilise les services CROUS/IZLY (étudiant, personnel, ...).
      • Contrôle d'accès : la synchronisation temps réel de vos cartes avec les contrôles d'accès que peut vous permettre de mettre en place ESUP-SGC renforce indéniablement la sécurité de vos accès.
      • Bibliothèques
      • Impression
      • Initiative de la Carte Etudiante Européenne (ESC)
      • Outils institutionnels divers
  • Une interface web dédiée à chacun, dont les utilisateurs finaux
  • Une possibilité d'utiliser le matériel que vous souhaitez, en terme d'impression notamment ; toute la chaine d'édition pouvant utiliser uniquement des protocoles standards (et pas les API/SDK des imprimantes), cela vous évite les problèmes récurrents de compatibilité des imprimantes vis à vis des version d'OS, de fin de vie de modèles d'imprimantes, d’instabilité matériel ... notamment au cours du temps.
  • ...

Un certain nombre de raisons peuvent a contrario vous pousser à faire un autre choix :

  • Le logiciel que vous utilisez actuellement vous convient et vous en êtes satisfait.
  • Vous utilisez un logiciel qui n'est pas juste un SGC mais un gestionnaire d'identités dont les fonctionnalités spécifiques vous sont précieuses (ESUP-SGC n'est pas un gestionnaire d'identités, c'est un SGC qui a vocation à s'intégrer dans un Système d'Information déjà établi).
  • Vous n'avez pas les compétences et les moyens humains disponibles et motivés pour mettre en place un tel logiciel
  • Vous ressentez le besoin d'avoir un prestataire qui vous accompagne de bout en bout pour assurer la mise en œuvre de votre projet, ce avec un logiciel maitrisé par le prestataire.
  • Vous pensiez passer sur ESUP-SGC en lieu et place de votre solution actuelle pour réaliser des économies de prestation et de licence : vous n'envisagiez pas cependant de changer/modifier/améliorer votre organisation, les fonctionnalités proposées, etc.
  • Le fait qu'ESUP-SGC impose une édition en 2 temps (impression puis encodage) vous parait rédhibitoire.
  • ...

Bref, le choix n'est pas évident, et en tant que simple 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 ; au contraire même, 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 !

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

La vue "Manager" est disponible en lecture seule.

Il est possible de noter une carte comme livrée :

  • via l'interface web
  • 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

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

ROLE_CONSULT

La vue "Manager" est disponible en lecture seule. Il n'est pas possible d'imprimer la carte ni de l'encoder, mais les liens vers les applications permettant d'utiliser le lecteur NFC sont présents, ils permettent de rechercher une carte via badgeage de la carte sur smartphone ou ordinateur.

Après badgeage d'une carte dans la 'salle recherche' de l'application cliente, à la validation la fiche de la carte est automatiquement affichée dans le navigateur de l'utilisateur connecté (dernière session en date) avec le même identifiant que sur l'application cliente (si connecté == si session en cours).

ROLE_CONSULT_XYZ

Même principe que pour ROLE_MANAGER_XYZ, permet de donner des droits de consultation restreints à certains userType uniquement (XYZ étant à remplacer par un userType configuré par ailleurs dans applicationContext-services.xml au travers des "userInfo").

ROLE_VERSO

Les utilisateurs ayant ce rôle peuvent voir le 'verso dématérialisé' d'une carte au travers d'un badgeage depuis esup-nfc-tag-droid ou esup-nfc-tag-desktop.

Notez que cette possibilité est offerte également aux utilisateurs ayant le rôle ROLE_CONSULT (ou/et ROLE_MANAGER, ROLE_SUPER_MANAGER, ROLE_ADMIN)

ROLE_USER

Pour pouvoir faire une demande de carte, l'utilisateur doit avoir ce rôle.

ROLE_USER_NO_EDITABLE

Si un utilisateur dispose de ce rôle, alors sa carte ne peut pas être éditée (par ex: problème sur dossier), même si celui-ci a pu effectuer la demande.

Plutôt que d'utiliser ce rôle, vous pouvez utiliser le champ 'userInfo' editable de l'utilisateur cf le tableau donné dans Configurations ESUP-SGC et ESUP-NFC-TAG-SERVER#SGCetESUP-NFC-TAG-SERVER-applicationContext-services.xml.

ROLE_USER_RENEWAL_PAYED

Si un utilisateur dispose de ce rôle, celui-ci doit payer avant de pouvoir demander un renouvellement de carte.

Plutôt que d'utiliser ce rôle, vous pouvez utiliser le champ 'userInfo' requestFree de l'utilisateur cf le tableau donné dans Configurations ESUP-SGC et ESUP-NFC-TAG-SERVER#SGCetESUP-NFC-TAG-SERVER-applicationContext-services.xml.

Dans l'application ESUP-SGC, peut-on utiliser une base de données externe Oracle pour récupérer des données utilisateurs ?

Oui.

Le driver oracle n'étant pas dans le maven central, une modification du pom.xml ne suffit pas. Il faudra en plus l'ajouter dans votre 'repository local' ainsi (après l'avoir téléchargé depuis https://www.oracle.com/technetwork/database/features/jdbc/default-2280470.html )  : 

mvn install:install-file -Dfile=/tmp/ojdbc7.jar -DgroupId=com.oracle -DartifactId=ojdbc7 -Dversion=12.1.0.2 -Dpackaging=jar -DgeneratePom=true

puis ajout dans le pom.xml de la dépendance :

<dependency>
  <groupId>com.oracle</groupId>
  <artifactId>ojdbc7</artifactId>
  <version>12.1.0.2</version>
</dependency>

La configuration se fait ensuite dans applicationContext-services.xml avec un dataSource adéquat ...

    <bean id="dataSourceOracle" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>
        <property name="url" value="jdbc:oracle:thin:@oracle.devcake.co.uk:1521:INTL"/>
        <property name="username" value="sa"/>
        <property name="password" value=""/>
    </bean>

 

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

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-services.xml on modifiera 

	<bean id="groupService" class="org.esupportail.sgc.services.ldap.LdapGroupService">
		<property name="ldapTemplate" ref="ldapTemplate"/>
		<property name="groupSearchBase" value="ou=groups" />
		<property name="groupSearchFilter" value="member={0}"/>
		<property name="memberSearchBase" value="ou=people"/>
		<property name="memberSearchFilter" value="memberOf={0}"/>
	</bean>

par quelque chose du type : 

	<bean id="groupService" class="org.esupportail.sgc.services.ldap.LdapFilterGroupService">
		<property name="ldapTemplate" ref="ldapTemplate"/>
		<property name="ldapFiltersGroups">
			<map>
				<entry key="(|(eduPersonAffiliation=student)(eduPersonAffiliation=employee))" value="esup-sgc-users"/>
				<entry key="eduPersonPrincipalName=joe@univ-ville.fr" value="esup-sgc-admins"/>
				<entry key="eduPersonPrincipalName=jack@univ-ville.fr" value="esup-sgc-managers"/>
			</map>
		</property>
	</bean>

C'est ensuite ces noms de groupes ainsi déifinis ('esup-sgc-users', esup-sgc-admins', ...) qui peuvent être utilisés dans applicationContext-security.xml au niveau du bean sgcMappingGroupesRoles pour définir les rôles de chacun : 

	<util:map id="sgcMappingGroupesRoles">
		<beans:entry key="esup-sgc-admins" value="ROLE_ADMIN" />
		<beans:entry key="esup-sgc-managers" value="ROLE_MANAGER" />
		<beans:entry key="esup-sgc-users" value="ROLE_USER" />
	</util:map>

 

Est-ce que ldap est obligatoire ?

L'identification par shibboleth est obligatoire. Ldap était aussi obligatoire au début du projet.

  • L'idée est de s'appuyer au mieux sur supann (et schémas ldap associés) pour les attributs utilisateurs et donc de privilégier la récupération de ces attributs utilisateurs via LDAP.
  • Ldap est aussi proposé pour gérer les rôles des utilisateurs via les groupes ldap.

Il est possible de fonctionner sans ldap, le premier cas d'usage ici a été le montage de site de démo esup-sgc-demo.univ-rouen.fr (voir la page wiki à propos de celle-ci, et notez notamment les limitations d'une telle intégration) :

  • on récupère les attributs utilisateurs de shibboleth, et éventuellement d'une BD sql
  • les groupes/rôles sont construits via des règles sur les attributs utilisateurs directement

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 ?

Non, rien n'oblige à déclarer vos serveurs ESUP-SGC et ESUP-NFC-TAG en tant que service provider dans la fédération d'identités (de production comme de test) Renater - https://services.renater.fr/federation/

Pour des raisons de tests, de développements ... si vous souhaitez notamment restreindre l'accès à ces serveurs, celà peut être plus simple/pratique/rapide de ne pas le faire en se contentant d'une approbation interne entre votre SP ESUP-SGC / ESUP-NFC-TAG et votre IdP (qui peut tout à fait être votre Idp de production).

Techniquement c'est par exemple ce qui est fait dans la VM de démonstration, VM embarquant un IdP shibboleth ; vous y retrouverez donc un exemple de telles configurations : VM ESUP-SGC

Si vous souhaitez par contre proposer un SGC multi-établissements de l'ESR, en permettant à des extérieurs issus d'autres établissements de demander des cartes avec leurs propres comptes d'établissements ; ou encore si vous voulez permettre l'intégration / importation de cartes d'SGC d'autres établissements dans votre propre SGC, déclarer votre SGC dans la fédération d'identités Renater est une bonne option.

Qu'est-ce qu'un thème dans ESUP-SGC ?

Un thème correspond notamment à une CSS ainsi qu'au logo de l'établissement tous deux utilisés lors de l'impression de la carte.
Ce même CSS permet la prévisualisation (pour l'usager et pour le manager) de la carte, aussi dans ce contexte un css spécifique à la vue mobile est présent ainsi qu'un masque (de carte) et un qrcode.

On peut avoir plusieurs thèmes et une même 'clef' de thème peut également être utilisée plusieurs fois avec des versions différentes.

L'idée est ainsi de permettre d'avoir des thèmes différents suivant les individus et éventuellement des versions de thèmes différentes si le thème évolue dans le temps (changement de look de la carte d'un établissement).

L'affectation d'un thème à un utilisateur se fait au travers du peuplement d'un nouveau 'userInfo' nommé 'template'. La dernière version du thème correspondant à cette clef étant utilisée lors de l'impression de la carte.

Enfin notez que les thèmes sont gérés depuis l'interface web d'esup-sgc et l'outil permettant de les créer ou les modifier permet ainsi au passage d'éditer la CSS avec rendu immédiat synchronisé dans le navigateur (~ live edit du css) !

 

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

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

curl -F "eppn=username@univ-ville.fr" -F "difPhotoTransient=true" -F "crousTransient=true" -F "europeanTransient=true" -F "PhotoFile.file=@/path/to/image.png"  https://esup-sgc.univ-ville.fr/wsrest/api

La liste des clients autorisés à utiliser ce webservice est définie dans la variable accessRestrictionWSRestAPI du fichier security.properties. Par exemple, pour autoriser certaines adresses IP (notez que la valeur de cette variable n'est pas entourée de guillemets):

accessRestrictionWSRestApi=hasIpAddress('127.0.0.1') or hasIpAddress('192.168.1.39') or hasIpAddress('192.168.22.0/24')

 

Comment sont synchronisés 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 synhconrisation 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.

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

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

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 :

Encodeur

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.

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

Application Android

Lien esup-nfc-tag-server de esupnfctagdroid.apk
Le code source est sur https://github.com/EsupPortail/esup-nfc-tag-droid
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.


Application 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 "create" au lieu de "update" au niveau du fichier persistence.xml ?

Oui, en mettant create en place de update au niveau du fichier persistence.xml la base est alors écrasée et recréée au prochain redémarrage du SGC.

Pour être complet, il faut noter ici que le trigger appelé lors de la suppression d'un 'fichier' (d'une photo ici surtout) n'est pas appelé en supprimant/recréant la base aussi directement. De fait les blobs (lo postgresql pour large object) correspondants aux fichiers/photos stockés en base ne sont en fait pas supprimés de la base postgresql et se retrouvent 'orphelins' car plus référencés dans la base esup-sgc qui a été réinitialisée.
Ils "trainent" donc dans la base postgresql et ne dérangent pas le moins du monde, à part qu'ils utilisent de la place ...
Aussi ici pour 'nettoyer' la base et supprimer effectivement ces blobs, on peut alors utiliser l'utilitaire vacuumlo sur la base (juste après avoir relancé esup-sgc avec create donc) :
postgres@debian-i7:~$ vacuumlo esupsgc

Plus d'info ici :
https://www.postgresql.org/docs/9.3/static/vacuumlo.html

Comment récupérer les photos par script ?

Esup-sgc propose une API permettant de récupérer les photos.

Pour pouvoir l'utiliser, l'IP du client doit être référencé dans accessRestrictionWSRestPhoto, fichier security.properties

  • Récupérer la dernière photo en date non rejetée  d'un utilisateur :
    wget 'http://localhost:8080/wsrest/photo/joe@univ-ville.fr/photo'
  • Récupérer la dernière photo en date dans un état donné d'un utilisateur : 
    wget 'http://localhost:8080/wsrest/photo/joe@univ-ville.fr/photo?cardEtat=ENABLED'
    (état activé ici)
  • Récupérer la dernière photo en date dans un état donné d'un utilisateur après une date précisée (renvoie un code http 304 si la photo en question n'a pas été modifiée depuis cette date) : 
    wget 'http://localhost:8080/wsrest/photo/joe@univ-ville.fr/photo?cardEtat=ENABLED&dateEtatAfter=2018-06-19'

Pour prendre en compte le choix de l'utilisateur de diffuser ou non sa photo, on peut faire les mêmes requêtes avec /restrictedPhoto en lieu et place de /photo :

  • wget 'http://localhost:8080/wsrest/photo/joe@univ-ville.fr/restrictedPhoto?cardEtat=ENABLED'

Comment récupérer par script 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, l'IP du client doit être référencé dans accessRestrictionWSRestApi, fichier security.properties

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 8 (fourni par votre distribution) ; à noter que la version 8 est requise : les versions 11 ne sont pas supportées par exemple.
  • 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.

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 

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

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

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

Est-ce que ldap est obligatoire ?

L'identification par shibboleth est obligatoire. Ldap était aussi obligatoire au début du projet.

  • Ldap est utilis pour gérer les rôles des utilisateurs via les groupes ldap.

Il est possible de fonctionner sans ldap, le premier cas d'usage ici a été le montage de site de démo esup-sgc-demo.univ-rouen.fr (voir la page wiki à propos de celle-ci, et notez notamment les limitations d'une telle intégration) :

  • les groupes/rôles sont construits via des règles sur l'eppn uniquement ...

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'encdoder 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)

<bean id="desfireChangeMasterKeyTagEsupSgc" class="org.esupportail.nfctag.beans.DesfireTag" p:formatBeforeWrite="true" 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)

<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

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 : 

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.

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.




 

  • Aucune étiquette