Recherche
Historique de la page
Introduction
<uidHeader
...
idpUrl="url2">uid2</uidHeader>
...
permet
...
de
...
dire
...
que
...
pour
...
idpUrl
...
valant
...
par
...
exemple
...
https://ident-shib-test.univ-rennes1.fr/shibboleth
...
(en
...
fait
...
d'URL
...
, c'est
...
ID
...
de
...
l'
...
IdP)
...
on
...
peut
...
dire
...
à
...
nuxeo
...
d'utiliser
...
l'attribut
...
uid2
...
envoyé
...
par
...
cet
...
IdP
...
et
...
pas
...
<default>.
On peut imaginer 2 cas :
- Un IdP externe nous enverrait ses username avec un autre attribut que <default>eppn</default> alors on pourrait le préciser via <uidHeader>
- Un IdP local on peut décider de ne pas utiliser eppn mais uid par exemple. Ceci évite, au niveau de la conf LDAP de nuxeo de dire que l'ID utilisé est eppn et de garder uid. Ceci a comme impact de continuer à faire des requête LDAP sur uid ce qui est plus naturel que sur l'eppn
Dysfonctionnement
Je viens de tester le fait d'utiliser uid pour mon IdP --> Ca ne semble pas marcher car :
- ShibbolethAuthenticationPlugin.handleRetrieveIdentity() fait un userDir.getEntry(userId) avec userId=bourges et ne trouve pas l'entrée dans nuxeo --> Normal
- Il essaie alors de la créer dans SQLSession.createEntry() mais là j'ai une erreur : "Entry with id bourges@univ-rennes1.fr already exists". En effet il reprend l'info de <fieldMapping header="eppn">username</fieldMapping> et travaille donc maintenant avec l'eppn
| Remarque |
|---|
Ce bug a été détecté avant la mise en place d'une configuration avec un MultiDirectory. Cf. 7) configuration shib + LDAP fonctionnelle |
Patch possible
forcer l'attribut "surname" dans la map :
| Bloc de code |
|---|
-- > > Donc on peut imaginer 2 cas : > 1) un IdP externe nous enverrais ses uid@domain.fr avec un autre attribut que <default>eppn</default> alors on pourrait le préciser via <uidHeader> > 2) pour un IdP local on peut décider de ne pas utiliser eppn mais uid par exemple \--> Ceci évite au niveau de la conf LDAP de nuxeo de dire que l'ID utilisé est eppn et de garder uid \--> Ceci a comme impact de continuer à faire des requête LDAP sur uid ce qui est plus naturel que sur l'eppn > > Je crois que le point 2 est à tester et à préconiser si ça marche bien... > > A\+ h1. Patch possible forcer l'attribut "surname" dans la map : \--\- a/nuxeo-platform-login-shibboleth/src/main/java/org/nuxeo/ecm/platform/shibboleth/auth/ShibbolethAuthenticationPlugin.java Tue Nov 09 00:10:12 2010 \+0100 \++\+ b/nuxeo-platform-login-shibboleth/src/main/java/org/nuxeo/ecm/platform/shibboleth/auth/ShibbolethAuthenticationPlugin.java Wed Dec 01 12:44:26 2010 \+0100 @@ \-116,6 \+116,7 @@ Map<String, Object> fieldMap = getService().getUserMetadata(httpRequest); DocumentModel entry = userDir.getEntry(userId); if (entry == null) { \+ // patch RB :+ fieldMap.put("surname", userId); userDir.createEntry(fieldMap); } else { entry.getDataModel(userManager.getUserSchemaName()).setMap( |
| Remarque |
|---|
Si le bug n'existe plus (pas testé) avec une configuration avec un MultiDirectory. Le patch reste néanmoins nécessaire pour les établissements qui voudraient utiliser comme surname une valeur d'entête déjà utilisée pour un autre attribut du user nuxeo. ex : email. En effet, nuxeo ne sait pas, dans son ShibbolethAuthenticationService, mapper une même entête sur 2 attributs du user. Le patch rend aussi obsolète le besoin de définir un <fieldMapping header="truc">username</fieldMapping> pour username. |
Vue d'ensemble
Gestion des contenus