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 5 méthodes sont implémentées dans le SGC ESUP-SGC :

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

• LdapUserInfoService

• SqlUserInfoService

• RestUserInfoService
• SpelUserInfoService

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

→ Merci également de consulter la page Exemples de UserInfoServices

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>

Par défaut la propriété caducIfEmpty étant valuée à ""

Vous pouvez alors manipuler un champ caducIfEmpty ainsi par exemple : 

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>

Par défaut la propriété caducIfEmpty étant valuée à ""

Vous pouvez alors manipuler un champ caducIfEmpty ainsi par exemple : 

<bean id="NoCaduc4All" class="org.esupportail.sgc.services.userinfos.SpelUserInfoService" p:order="5">
  <property name="sgcParam2spelExp">
    <map>
      <entry key="caducIfEmpty" value="'Carte-OK'"/>
    </map>
  </property>
</bean>

<bean id="caducIfNoResourceLeocarte" class="org.esupportail.sgc.services.userinfos.SpelUserInfoService" p:order="6">
  <property name="eppnFilter" value=".*@univ-ville\.fr"/>
  <property name="sgcParam2spelExp">
    <map>
      <entry key="caducIfEmpty" value="#userInfosInComputing['memberOf']!=null and #userInfosInComputing['memberOf'].contains('cn=from.si.ressources.carte,ou=groups,dc=univ-ville,dc=fr'))) ? 'Carte-OK' : ''"/>
    </map>
  </property>
</bean>

Avec une telle configuration, les utilisateurs univ-ville verront leurs cartes devenir caduques si le  memberOf (groupes de l'utilisateur) récupéré depuis le SI ne contient pas cn=from.si.ressources.carte,ou=groups,dc=univ-ville,dc=fr

memberOf étant lui-même récupéré via ldap en l'ajoutant dans les attributs ldap à récupérer

<bean id="ldapUserInfoService" class="org.esupportail.sgc.services.userinfos.LdapUserInfoService" p:order="2">
  <property name="eppnFilter" value=".*@univ-ville\.fr"/>
  <property name="ldapTemplate" ref="ldapTemplate"/>
  <property name="sgcParam2ldapAttr">
    <map>
      ....
      <entry key="memberOf" value="memberOf"/>
    </map>
  </property>
</bean>

groupService :

Permet de récupérer ou constituer des groupes qui seront utiliser pour donner des rôles aux utilisateurs.

Par défaut, esup-sgc propose de récupérer les groupes du ldap de type groupOfNames, groupes usuels dans un annuaire de type supann.

On trouve ainsi la définition du bean comme ceci : 

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

Cette configuration données ci-dessus présuppose que les membres d'un groupe soient référencés dans le groupe mais aussi que les groupes d'un utilisateur soient référencés dans l'entrée ldap de l'utilisateur ; pour ce deuxième point cela se fait usuellement via l'overlay memberOf dans openldap.

Plutôt que d'utiliser cette possibilité de memberOf, esup-sgc peut se baser uniquement sur les groupes, pour ce faire il doit alors pouvoir retrouver l'eppn de chaque utilisateur par construction depuis les attributs de membre des groupes (qui correspondent aux dn des utilisateurs pour les groupOfNames) ; cette implémentation est normalement plus efficace que l'usage de l'overlay memberOf.
Voici un exemple d'une telle configuration: 

	<bean id="groupService" class="org.esupportail.sgc.services.ldap.LdapGroupBaseService">
		<property name="ldapTemplate" ref="ldapTemplate"/>
		<property name="groupSearchBase" value="ou=groups" />
		<property name="groupSearchFilter" value="member={0}"/>
		<property name="memberSearchFilter" value="dn={0}"/>
		<property name="memberAttr" value="member"/>
		<property name="memberAttr2EppnRegexp" value="uid=(.*),ou=people,dc=univ-ville,dc=fr"/>
		<property name="memberAttr2EppnRegexpValue" value="$1@univ-ville.fr"/>
		<property name="groupName2BaseRegexp" value="(.*),dc=univ-ville,dc=fr"/>
		<property name="groupName2BaseRegexpValue" value="$1"/>
	</bean>

Il est possible également de calculer ces groupes via des filtres ldap : 

	<bean id="groupService

<bean id="NoCaduc4All" class="org.esupportail.sgc.services.userinfos.SpelUserInfoService" p:order="5">
  ldap.LdapFilterGroupService">
		<property name="ldapTemplate" ref="ldapTemplate"/>
		<property name="sgcParam2spelExpldapFiltersGroups">
			<map>
				<entry    <map>
      key="supannEntiteAffecation=DSI" value="app-sgc-admins"/>
				<entry key="caducIfEmptyeduPersonAffiliation=student" value="'Carte-OK'app-sgc-students"/>
            </map>
  		</property>
	</bean>

Ou encore via des règles définis en SpEl (Spring Expression Language) :

	<bean id="caducIfNoResourceLeocartegroupService" class="org.esupportail.sgc.services.userinfosldap.SpelUserInfoServiceSpelGroupService" p:order>
		<property name="6groups4eppnSpel">
			<map>
				<entry  <property name="eppnFilter" value=".*@univ-ville\.frkey="app-sgc-admins" value="#user.supannEntiteAffectationPrincipale matches '.*DSI.*'"/>
    <property name="sgcParam2spelExp">
    <map>
                  <entry key="caducIfEmptyapp-sgc-all" value="#userInfosInComputing['memberOf']!=null and #userInfosInComputing['memberOf'].contains('cn=from.si.ressources.carte,ou=groups,dc=univ-ville,dc=fr'))) ? 'Carte-OK' : ''true"/>
    			</map>
  		</property>
	</bean>

Avec une telle configuration, les utilisateurs univ-ville verront leurs cartes devenir caduques si le  memberOf (groupes de l'utilisateur) récupéré depuis le SI ne contient pas cn=from.si.ressources.carte,ou=groups,dc=univ-ville,dc=fr

memberOf étant lui-même récupéré via ldap en l'ajoutant dans les attributs ldap à récupérerEt on peut enfin constituer un groupService qui calculera les groupes via autant de groupService intermédiaires qu'on le souhaite.
Cela peut permettre d'utiliser plusieurs ldap, des groupes ldap et des filtres ldap, des règles pour certains groupes, etc.
Exemple :

	<bean id="ldapUserInfoServicegroupService" class="org.esupportail.sgc.services.userinfosldap.LdapUserInfoService" p:order="2">
  MultiGroupService">
		<property name="eppnFilter" value=".*@univ-ville\.fr"/>
  <property name="ldapTemplate" ref="ldapTemplate"/>
  <property name="sgcParam2ldapAttr">
    <map>
      ....
      <entry key="memberOf" value="memberOf"/>
    </map>
  </property>
</bean>groupServices">
			<list>
				<ref bean="ldapGroupService"/>
				<ref bean="spelGroupService"/>
			</list>
		</property>
	</bean>

Où  ldapGroupService et spelGroupService seront eux-mêmes définis via des configurations comme présentées ci-dessus (en valuant id par ldapGroupService et spelGroupService en lieu et place de groupService).

cardIdsService :

Permet de configurer la génération d'identifiants qui pourront être codés dans la carte par esup-nfc-tag :

...

<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="clientId" value=""/>
 <property name="clientSecret" value=""/>
 <property name="accessUrl" value="https://acces-pp.lescrousnuonet.fr"/>
 <property name="restTemplate" ref="restTemplate" />
</bean>

...

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 accessUrl doit être renseigné à https://acces-pp.nuonet.fr pour la préproduction et https://acces.lescrous.fr pour  pour la pre- production comme la production.
5.  webUrl webUrl doit être renseigné à à https://api-pp.nuonet.fr pour la préproduction et https://api.lescrous.fr pour la production.

...