ESUPSGC

Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

Bloc de code
languagexml
themeRDark
	<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

...

shibboleth et ldap sont obligatoires ?

L'authentification / identification par shibboleth est obligatoire. Ldap était aussi obligatoire au début du projet.et ldap sont préconisés car ils correspondent à des briques usuelles dans la communauté de l'ESR.

Aussi : 

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

...

Notez qu'à l'inverse, il est aussi possible d'utiliser plusieurs LDAP.

Concernant Shibboleth, la documentation esup-sgc propose une intégration de l'authentification dans esup-sgc (comme dans bons nombres d''applications shibbolethisées, notamment proposées par le consortium ESUP-Portail) en la déportant sur le frontal Apache.
Aussi, en réalité, on peut tout à fait utiliser une autre technologie pour authentifier l'utilisateur dans esup-sgc (comme dans esup-nfc-tag).

ESUP-SGC supporte donc une authentification autre que shibboleth ? CAS ? OpenID ? LDAP ?

Oui.

L'application esup-sgc (comme esup-nfc-tag) attend simplement en entête (header) un HTTP une variable REMOTE_USER (nom de la variable par défaut).

Si on propose dans nos documentations de monter un mod_shib avec Apache pour proposer une authentification fédérée via la fédération d'identités ESR, vous pouvez en réalité utiliser d'autres mécansimes/briques (et même d'autres frontaux) du moment que vous renvoyer en tant que REMOTE_USER le 'usernme' de l'utilisateur - qui doit être l'eduPersonPrincipalName (eppn).

Aussi, plutôt que d'utiliser sous Apache, mod_shib, vous pouvez par exemple utiliser mod_auth_openidc pour faire de l'openId connect, ou mod_auth_cas pour utiliser le protocole CAS, mod_authnz_ldap pour ldap, etc.

De même vous pouvez utiliser d'autres briques d'authentification depuis un autre frontal comme Nginx.

A tritre d'exemple, la configuration suivante utilisant Apache/mod_authnz_ldap peut fonctionner par exemple pour transmettre un REMOTE_USER à esup-sgc en backend :

Bloc de code
languageerl
themeRDark
OIDCProviderMetadataURL https://cas.univ-ville.fr/oidc/.well-known/openid-configuration
OIDCClientID esupsgc
OIDCClientSecret esupsgcOidcSecret
OIDCRemoteUserClaim preferred_username
OIDCScope "openid email profile"
OIDCRedirectURI https://esup-sgc.univ-ville.fr/secureoidc/redirect_uri                                                                                                                                                     
OIDCCryptoPassphrase petitePassPhraseQuelconque

RequestHeader     set   Remote_User    "expr=%{REMOTE_USER}"

<Location />
 AuthType openid-connect
 Require valid-user
</Location>

Si on imagine avoir pour serveur OpenId Connect un serveur Apereo CAS, on pourra avoir comme configuration de service :

Bloc de code
languagejs
themeRDark
{
  "@class" : "org.apereo.cas.services.OidcRegisteredService",
  "clientId": "esupsgc",
  "clientSecret": "esupsgcOidcSecret",
  "serviceId" : "https://esup-sgc.univ-ville.fr/secureoidc/redirect_uri",
  "name": "ESUP-SGC - authentification via OpenId Connect",
    "id": 32,
    "scopes" : [ "java.util.HashSet", [ "openid", "profile", "email" ] ],
    "attributeReleasePolicy": {
    "@class": "org.apereo.cas.oidc.claims.OidcProfileScopeAttributeReleasePolicy",
    "claimMappings" : {
      "@class" : "java.util.TreeMap",
      "preferred_username" : "eduPersonPrincipalName"
    }
  }
}

Comment puis-je voir les entêtes HTTP transmises par mon frontal à esup-sgc ?

Afin de faciliter la mise en place de l'authentification et pour débuguer plus simplement l'authentificcation/identification opérée au niveau du frontal, vous pouvez utiliser le traditionnel /secure lié au script printenv.pl que propose Renater dans la configuration du mod_shib apache.
Celui-ci fonctionnera très bien aussi pour les autres technologies d'authentification.

esup-sgc propose une page similaire intégré directement : demander https://esup-sgc.univ-ville.fr/user/shib vous permettra en effet de voir les entêtes HTTP récupérées par esup-sgc.

Cette page, malgré son nom en /user/shib, fonctionnera très bien pour visualiser les paramètres utilisateurs d'identification portés par les entêtes (headers) HTTP positionnés par le plugin mod_shib d'Apache, mais aussi tout autre plugin d'authentification/identification similaire ( cf questions ci-avant).

Comment affecter des rôles en utilisant plusieurs ldap, en combinant des groupes ldap, des filtres ldap, des règles n'utilisant pas ldap mais définis sur les attributs utilisateurs directement ?

...

Bloc de code
languagexml
themeRDark
	<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.

...