Historique de la page

...

La première partie du fichier comporte les « UserInfoService » ainsi que les « SpelUserInfoService » . Ces deux entités ont pour but de peupler les informations des demandeurs de carte à l’aide des différentes sources de données présentent dans le SI de l'établissement (ou dans les SI des établissements partneaires - cas d'une authentification shibboleth extérieure, ou encore de l'usage d'un 'meta-annuaire' multi-établissements).

Trois methodes Quatre méthodes sont implémentées dans le SGC SGC :

• ShibUserInfoService (recupération des données via le context Shibboleth)

• LdapUserInfoService

• SqlUserInfoService

• RestUserInfoService

Les spelUserInfoService sont des règles qui s’appliquent ensuite pour calculer certains attributs de l’utilisateur.

...

On note que l'usage de shibboleth permet de récupérer des informations sur un individu extérieur au SI sans connexion directe d'Esup-SGC au SI de cet individu. Le fonctionnement de shibboleth fait cependant que ces informations ne pourront pas être mises à jour régulièrement sans connexion régulière de l'individu au SGC. Aussi la récupération des informations également depuis le LDAP au moins pour les utilisateurs internes au SI est à implémenter (en place ou même en plus de shibboleth).

Les requêtes se font par défaut en utilisant l'eppn (eduPersonPrincipalName) en clef ; depuis la version 3.2.0, il est possible également de faire une requête en utilisant un champ préalablement récupéré depuis une autre source.

On peut par exemple récupérer via ldap la majorité des champs en utilisant le searchFilter par défaut (eduPersonPrincipalName={eppn}), dont supannEtuId par exemple - puis utiliser ce supannEtuId dans un "userinfoservice" de type RestUserInfoService implémentant l'appel à l'API Pegase par exemple, comme illustré dans les commentaires du fichier applicationContext-services.xml
https://github.com/EsupPortail/esup-sgc/commit/383b95e3feb894814c46ddeedb5515d79f0b89b8

→ Merci de consulter https://github.com/EsupPortail/esup-sgc/blob/master/src/main/resources/META-INF/spring/applicationContext-services.xml qui donne quelques exemples des possibilités de récupération de champs utilisateur via ces différents "UserInfoService".

Note supplémentaire sur le editable (et requestFree qui se comporte de la même manière) : après avoir utilisé un temps le userInfo editable (ou requestFree) et que vous voulez finalement revenir à l'usage de ROLE_USER_NO_EDITABLE (ou ROLE_USER_RENEWAL_PAYED),
il vous faut également supprimer les références au groupe ROLE_USER_NO_EDITABLE (ou ROLE_USER_RENEWAL_PAYED) et remettre les editable à true (ou request_free à true) dans la base esupsgc pour réinitialiser les caculs : 
delete from roles where role='ROLE_USER_NO_EDITABLE';
update user_account set editable = true;
ou
delete from roles where role='ROLE_USER_RENEWAL_PAYED';

update user_account set request_free = true;

caducIfEmpty

Si vous souhaitez rendre caduques les cartes des utilisateurs qui ne sont plus remontés par le SI (ou qui n'ont plus le droit d'avoir de carte selon des règles internes, comme l'appartenance à un groupe ldap) alors même que la date de fin (schacExpiryDate dans esup-sgc) qui a été récupérée lorsque celle-ci était encore disponible reste postérieure à la date du jour, l'utilisation de caducIfEmpty peut être utile.

Dans applicationContext-services.xml vous pouvez mettre :

Note supplémentaire sur le editable (et requestFree qui se comporte de la même manière) : après avoir utilisé un temps le userInfo editable (ou requestFree) et que vous voulez finalement revenir à l'usage de ROLE_USER_NO_EDITABLE (ou ROLE_USER_RENEWAL_PAYED),
il vous faut également supprimer les références au groupe ROLE_USER_NO_EDITABLE (ou ROLE_USER_RENEWAL_PAYED) et remettre les editable à true (ou request_free à true) dans la base esupsgc pour réinitialiser les caculs : 
delete from roles where role='ROLE_USER_NO_EDITABLE';
update user_account set editable = true;
ou
delete from roles where role='ROLE_USER_RENEWAL_PAYED';

update user_account set request_free = true;

caducIfEmpty

Si vous souhaitez rendre caduques les cartes des utilisateurs qui ne sont plus remontés par le SI (ou qui n'ont plus le droit d'avoir de carte selon des règles internes, comme l'appartenance à un groupe ldap) alors même que la date de fin (schacExpiryDate dans esup-sgc) qui a été récupérée lorsque celle-ci était encore disponible reste postérieure à la date du jour, l'utilisation de caducIfEmpty peut être utile.

Dans applicationContext-services.xml vous pouvez mettre :

<bean id="userInfoService" class="org.esupportail.sgc.services.userinfos.UserInfoService">
  <property name="caducIfEmpty" value="caducIfEmpty"/>
</bean>

...

• %csn% (en hexadécimal)
• %reverse_csn% (le csn retourné par paires, en hexadécimal)
• %csn_dec% (en décimal)
• %reverse_csn_dec% (le csn retourné par paires, en décimal)
• %eppn%
• %escn%
• %esi%
• %secondary_id%
• %csn_dec% 
• décimal)
• %reverse_csn_dec% (le csn retourné par paires, en décimal)
• %eppn%
• %escn%
• %esi%
• %secondary_id%
• %enabled_date% (la date d'activation de la carte - au format generalizedTime - yyyyMMddHHmmss'Z' )
• %due_date% (la date de fin de validité de la carte - au format generalizedTime - yyyyMMddHHmmss'Z'  - peut permettre d'informer supanncmsdatefin)
• %etat_date% (la date de dernier changement d'état de la carte - au format generalizedTime - yyyyMMddHHmmss'Z' - correspondra logiquement dans le ldap à %enabled_date% )
• %etat% (l'état de la carte - correspondra logiquement à ENABLED )
• %photo%
• ... et enfin les identifiants de cartes générés par esup-sgc, via des 'CardIdService' (cf CardIdsService)
  • dont %access-control% pour l'identifiant de contrôle d'accès

...

<bean id="apiCrousService" class="org.esupportail.sgc.services.crous.ApiCrousService">
 <property name="enable" value="false"/>
 <property name="webUrl" value="https://api-pp.nuonet.fr" />
 <property name="appIdclientId" value="xxxxxxxxxxxxx" />
 <property name="appSecretclientSecret" value="yyyyyyyyyyyy" />
 <property name="accessUrl" value="https://acces.lescrous.fr"/>
 <property name="restTemplate" ref="restTemplate" />
</bean>

 Pour récupérer appId et appSecret la procédure est la suivante : 

...

/>
</bean>

 Pour récupérer appId et appSecret la procédure est la suivante : 

1. se rendre sur https://dev-pp.lescrous.fr afin de vous créer une application et demander la souscription à l'API Beforeizly.
2. une fois vos tests validés, vous pouvez vous connecter avec le même utilisateur sur https://dev.lescrous.fr et faire la même démarche pour obtenir vos identifiants de production.

3. clientId et clientSecret doivent être informés en fonction.

4. accessUrl doit rester https://acces.lescrous.fr pour la pre-production comme la production
5.  webUrl doit être renseigné à https://api-pp.nuonet.fr pour la préproduction et https://api.lescrous.fr pour la production.

Attention : les opérations sur les API de la pré-production comme de la production de l'API Crous/Izly peuvent provoquer l'envoi de mails auw ayants-droits manipulés.

...

EsistCrousService :

Fait référence au fichier XML de calcul des tarifs CROUS

...

• Nom : « Ecriture SGC »

• Configuration NFC : « Ecriture ESUP SGC » (spécifié dans applicationContext-desfire.xml)

• Application externe : « Web Service Write Esup SGC »

• Contrôle du tagId : « via Esup SGC »

• Valeur par défaut pour la validation sans confirmation : true → cela permet de valider le bon encodage de la carte, si cette valeur est laissée à false [non cochée], sans la validation manuelle, la carte reste à l'état "en cours d'impression", et dans le cadre de l'édition en 1 temps/passe, la carte est réimprimée/réencodée en continue !

• Visible : true
• Application d'écriture pour esup-sgc-client: true

Voir aussi la configuration des applications optionnelles : Applications ESUP-SGC / ESUP-NFC-TAG optionnelles