...
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
<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 | ||||
|---|---|---|---|---|
| ||||
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 | ||||
|---|---|---|---|---|
| ||||
{
"@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 | ||||
|---|---|---|---|---|
| ||||
<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.
...