Pourquoi BindAuthenticator de Spring Security a-t-il besoin d'autorisations de lecture pour les utilisateurs?

Question

Je suis actuellement en train d'implémenter/configurer l'authentification LDAP d'une application web Java en utilisant Spring Security 3.0. J'utilise Microsoft AD LDS en tant que serveur LDAP et j'ai choisi le BindAuthenticator du Spring. J'ai découvert que l'authentification ne fonctionne que si l'utilisateur authentifié est membre du rôle Readers de la partition. Le BindAuthenticator essaie de lire les attributs de l'utilisateur après l'authentification, ce qui semble raisonnable dans les scénarios où les autorités sont extraites du service d'annuaire. Étant nouveau pour LDAP et AD, est-ce une pratique acceptable lorsque l'application est intégrée dans une structure AD existante? Peut-on affiner un dn donne à l'utilisateur dns seulement lire les permissions pour leurs propres attributs plutôt que de les ajouter au groupe de lecteurs?

Merci Thomas

---

Modifier 3/8/2010: Voici ce que je fini par faire: j'ai copié BindAuthenticator de printemps (la classe entière) et a changé la méthode bindWithDn() comme ci-dessous. Les différences sont marquées avec DIFF.

private DirContextOperations bindWithDn(String userDn, String username, String password) { 
    BaseLdapPathContextSource ctxSource = (BaseLdapPathContextSource) getContextSource(); 
    DistinguishedName fullDn = new DistinguishedName(userDn); 
    fullDn.prepend(ctxSource.getBaseLdapPath()); 

    logger.debug("Attempting to bind as " + fullDn); 

    DirContext ctx = null; 
    try { 
     ctx = getContextSource().getContext(fullDn.toString(), password); 
     // Check for password policy control 
     PasswordPolicyControl ppolicy = PasswordPolicyControlExtractor.extractControl(ctx); 

     // *DIFF* Attributes attrs = ctx.getAttributes(userDn, getUserAttributes()); 

     DirContextAdapter result = new DirContextAdapter(null, new DistinguishedName(userDn), // *DIFF* 
       ctxSource.getBaseLdapPath()); 

     if (ppolicy != null) { 
      result.setAttributeValue(ppolicy.getID(), ppolicy); 
     } 

     return result; 
    } catch (NamingException e) { 
     // This will be thrown if an invalid user name is used and the method may 
     // be called multiple times to try different names, so we trap the exception 
     // unless a subclass wishes to implement more specialized behaviour. 
     if ((e instanceof org.springframework.ldap.AuthenticationException) 
       || (e instanceof org.springframework.ldap.OperationNotSupportedException)) { 
      handleBindException(userDn, username, e); 
     } else { 
      throw e; 
     } 
    // *DIFF* } catch (javax.naming.NamingException e) { 
    // *DIFF*  throw LdapUtils.convertLdapException(e); 
    } finally { 
     LdapUtils.closeContext(ctx); 
    } 

    return null; 
} 

Answer 1

Il est logique pour moi, ce BindAuthenticator détecter la effectue une liaison LDAP « comme » l'utilisateur authentifié, et utilise le protocole LDAP pour remplir l'utilisateur objet de détails. Je suppose que le serveur LDAP demande à l'utilisateur d'avoir un rôle lui permettant de lire ses propres attributs.

Avez-vous essayé de restreindre l'ensemble des attributs (via setUserAttributes) à seulement quelques attributs. Je pense que dans AD, vous pouvez mettre RBAC sur des attributs individuels, donc vous lisez peut-être un attribut qui a la protection du rôle 'Reader' et d'autres qui ne sont pas protégés.

Vos autres options seraient:

• Modification RBAC sur le serveur LDAP comme vous le suggérez, mais je n'ai pas une prescription pour vous.
• Utilisez une méthode d'authentification différente qui effectue une liaison en tant que serveur principal générique et lit les attributs. Vous devrez peut-être encore lier en tant qu'utilisateur afin de vérifier leur mot de passe.