OpenIDM - Problèmes et solutions

openidm forgerock problèmes

Cette page donnera quelques problèmes et solutions rencontrées lors de la mise en place de OpenIDM.

J'espère qu'elle pourra servir à d'autres, en tout cas elle me servira de pense-bête :-)

Erreur dans l'authentification déléguée

Afin de pouvoir authentifier les utilisateurs sur l'annuaire LDAP d'entreprise, j'ai voulu mettre en place l'authentification déléguée (aussi appelée passthrough authentication). Ceci se paramètre facilement dans le fichier OPENIDM_PROJECT/conf/authentication.json, qui propose par défaut plusieurs modes d'authentification :

  • internal user : ce sont les comptes internes, tels que openidm-admin
  • managed user : ce sont les utilisateurs gérés dans OpenIDM
  • passthrough : authentification déportée sur une ressource (LDAP ou AD par exemple)
  • client cert : authentification par certificat.

Dans notre cas, nous allons authentifier les utilisateurs sur un annuaire LDAP, dont la ressource ldapOffice est définie dans OpenIDM. Le mapping utilisé dans le fichier sync.json s'appelle LdapOffice_User. Du coup, le paramétrage est le suivant :

            {
                "name" : "PASSTHROUGH",
                "properties" : {
                    "augmentSecurityContext" : {
                        "type" : "text/javascript",
                        "file" : "auth/populateAsManagedUser.js"
                    },
                    "queryOnResource" : "system/ldapOffice/account",
                    "propertyMapping" : {
                        "authenticationId" : "uid"
                    },
                    "managedUserLink" : "LdapOffice_User",
                    "defaultUserRoles" : [
                        "openidm-authorized"
                    ]
                },
                "enabled" : true
            }

Pour tester, j'utilise une commande curl sur le endpoint openidm/info/login :

curl -s --insecure --header 'X-OpenIDM-Username: user1' --header 'X-OpenIDM-Password: P@ssw0rd' --header 'Content-Type: application/json' --request GET http://localhost:8080/openidm/info/login

Et j'ai rencontré des erreurs curieuses, alors que le couple user/mot de passe a bien été vérifié dans l'annuaire LDAP :

{"code":401,"reason":"Unauthorized","message":"Access Denied","detail":{"failureReasons":[{"code":401,"reason":"Unauthorized","message":"Invalid credential has been provided to operation ACTION for system object: null"}]}}

Peu d'explications à part cela. Il faut passer le niveau de logs en mode "FINE" pour avoir un peu plus de détails :

FINE: Enter: authenticate(ObjectClass: customPerson, user1, org.identityconnectors.common.security.GuardedString@827d55a1, OperationOptions: {ATTRS_TO_GET:[employeeType,uid,mail,sn,c,uniqueID,givenName,businessCategory,personalTitle...]})     Method: authenticate
Oct 30, 2015 1:04:06 PM org.slf4j.impl.JDK14LoggerAdapter fillCallerData
FINE: Exception:        Method: authenticate
org.identityconnectors.framework.common.exceptions.InvalidCredentialException: Cannot resolve "user1" to an entry
        at org.identityconnectors.ldap.LdapAuthenticate.authenticate(LdapAuthenticate.java:62)

Après quelques heures de recherches, et en comparant la configuration de l'exemple samples/sample2 et ma configuration, j'ai trouvé le souci : dans le fichier définissant la ressource (provisioner.openicf-ldapOffice.json), j'avais défini la valeur de l'attribut nativeType du compte comme étant la classe d'objet LDAP :

"nativeType" : "customPerson"

Ceci avait pour effet de faire planter la recherche. Dans les logs de l'annuaire LDAP, j'avais juste la ligne

base="" scope=baseObject filter="(objectClass=*)" attrs="subschemaSubentry"

Il faut laisser la déclaration du type en

"nativeType" : "__ACCOUNT__"

Et l'authentification déléguée fonctionne. On peut donc alors authentifier les utilisateurs sur l'annuaire LDAP distant, ce qui résoud les problèmes de reprise de mot de passe, généralement impossible à faire.

Previous Post Next Post