Arborescence des pages

Vous regardez une version antérieure (v. /wiki/display/SGC/Multi+Etablissements) 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. 2) afficher la version suivante »

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

Dans le cadre

  • Aucune étiquette