Esup-SGC a initialement été développé dans le cadre du projet COMUE Normandie Université nommé Léocarte.

C'est ainsi un projet par nature répondant à une problématique de multi-établissements.

Il y répond en fait à 2 niveaux et permet ainsi des mises en places différentes suivant les besoins et ressources ds établissements.

On peut en effet le qualifier à la fois de "multi-tenants" et de "multi-instances".

ESUP-SGC supporte la connexion à plusieurs Système d'Information sur une seule et même instance, c'est ce qui caractétrise son côté "multi-tenants".

Authentification / identification shibboleth

ESUP-SGC propose une authentification shibboleth qui a donc vocation à s'intégrer dans la fédération d'identités RENATER.

Ainsi une même instance SGC peut accepter l'authentification d'utilisateurs provenant d'établissements divers.

L'authentification / identification shibboleth permet au passage de récupérer des champs utilisateurs (nommés 'userinfo' dans esup-sgc) provenant de l'IdP de l'utilisateur.

Récupération d'informations depuis des bases de données et ldap multiples

Suite à cette authentification / identification, des champs provenant de bases de données ou/et de ldap (éventuellement multiples) peuvent permettre de récupérer et compléter les champs utilisateurs userinfo.

Cette récupération par bases de données et/ou ldap a l'avantage (par rapport à shibboleth) de pouvoir ensuite être rejouée régulièrement par ESUP-SGC pour que celui-ci mette à jour les informations utilisateurs sans nécessiter que l'utilisateur se réauthentifie à nouveau.

A nouveau, souligons ici que plusieurs bases de données et plusieurs ldap peuvent être configurées ; on pourra indiquer à ESUP-SGC quelles sources solliciter pour un utilisateur donné en spécifiant un 'filtre' de type regexp sur le champs eppn ; on pourra ainsi dire que pour les utilisateurs dont les eppn finissent en @univ-ville.fr on sollicite la base ldap ldap.univ-ville.fr (avec configurations associées) et les bases de données sql x ou y (avec requêtes sql associées).

Attribution des rôles en fonction de groupes issus de plusieurs ldap / bases de données / ...

En fonction des configurations et du profil utilisateur (champs userinfo remontés ou/et groupes), ESUP-SGC peut proposer à l'utilisateur qui se connecte

• la vue 'utilisateur'
  • qui lui propose de voir et (dés)activer des cartes si il en a effectivement dans le SGC
  • qui lui permet de demander une carte si il a les droits de le faire, avec paiement préalable si cela est configuré pour également
  • qui lui permet d'"importer" sa carte d'un autre SGC si une carte extérieure est effectivement détectée dans les champs userinfo remontés, cest ce qui caractérise le côté "multi-instances".
• la vue 'manager'
  • avec éventuellement +/- d'accès et de possibilités
  • un manager restreint à la gestion d'un type de public uniquement (userType) ne voit alors que certains onglets (un par userType).
• la vue 'admin' 

Envoi des cartes sur différents contrôles d'accès, annuaires ldap, ...

Lorsque la carte est activée ou désactivée, ESUP-SGC est capable d'informer plusieurs services cibles de la nouvelle carte qui a doit être prise en compte pour l'utilisateur donnée.

Ces services peuvent être des ldap, contrôles d'accès, gestionnaires d'impressions papercut, esc, crous/izly ...

On peut filtrer l'activation de ces services en fonction du champs eppn.

Ainsi on n'activera pas esc ni crous/izly pour les cartes dites 'importées' c'est à dire venant d'une autre instance d'ESUP-SGC.

Multi instances vs multi tenants

En résumé, ESUP-SGC peut donc supporter un projet de cartes multi-établissements à la fois par le fait qu'une instance ESUP-SGC peut gérer les cartes de plusieurs établissements et aussi par le fait que les instances d'ESUP-SGC peuvent s'échanger des cartes.

Dans la mise en place d'ESUP-SGC pour un projet de cartes multi-établissements, la question se pose alors sur le choix de cette mise en oeuvre : une instance mutualisée pour plusieurs établissements ou une instance par établissement.

Le choix devra être fait au cas par cas en considérant un certain nombre d'éléments.

Dans les faits, on privilégiera néanmoins autant que possible une instance par établissement, pour un certain nombre de rainsons : 

•  le Système de Gestion de Cartes est une brique structurante du Système d'Information, au même titre que le gestionnaire d'identités, le SI étudiant, le SI RH ... ;
• pour un établissement, disposer de sa propre instance ESUP-SGC lui permet de s'approprier véritablement le SGC et la carte ; de fait celà favorisera l'intégration de la carte dans son système d'information, notamment au travers d'esup-sgc, mais aussi d'esup-nfc-tag ;
• pour un établissement qui a de nombreux services à intégrer comme des contrôles d'accès, gestionnaires d'impression, annuaires (etc.), ESUP-SGC permet de configurer cette intégration directement dans les configurations ; si il doit être configuré pour se connecter à tous ces services de plusieurs établissements, la configuration et l'exploitation sont de fait plus lourdes à mettre en place ;
• un SGC par établissement permet de proposer à l'utilisateur d'importer ou non ses informations dans l'instance ESUP-SC du partenaire, cela facilite la conformité RGPD de la mise en oeuvre du SGC.

Pour autant, certaines situations peuvent justifier l'hébergement par une instance de plusieurs établissements / partenaires : 

• ...