Redback Ldap Integration

NOTE: This has changed dramatically and may not be correct.

With the alpha-3 release of redback limited support for ldap has been added as an authentication source. Limited support for ldap means:

  • Read-Only User Management
  • xml and properties based configuration
  • tested against open ldap on linux and apacheds 1.5.0

Setting up Ldap

Configuration for ldap is actually a relatively simple procedure, a few components definitions need to be declared in an appropriate application.xml and then some configuration options must be set in the security.properties file.

The application.xml Additions

These components should be defined in the applicable application.xml

ldap connection factory
  <component>
      <role>org.codehaus.plexus.redback.common.ldap.connection.LdapConnectionFactory</role>
      <role-hint>configurable</role-hint>
      <implementation>org.codehaus.plexus.redback.common.ldap.connection.ConfigurableLdapConnectionFactory</implementation>
      <description></description>
      <configuration>
        <hostname></hostname>
        <port></port>
        <baseDn></baseDn>
        <contextFactory>com.sun.jndi.ldap.LdapCtxFactory</contextFactory>
        <password></password>
        <bindDn></bindDn>
      </configuration>
    </component>
    
  • hostname - The hostname of the ldap server
  • port - The port of the ldap server
  • baseDn - The baseDn of the ldap system
  • contextFactory - context factory for ldap connections
  • password - password for the bindDn for the root ldap connection
  • bindDn - the core user used for authentication the ldap server, must be able to perform the necessary searches, etc.
user mapper
        
    <component>
      <role>org.codehaus.plexus.redback.common.ldap.UserMapper</role>
      <role-hint>ldap</role-hint>
      <implementation>org.codehaus.plexus.redback.common.ldap.LdapUserMapper </implementation>
      <description></description>
      <configuration>
        <email-attribute>email</email-attribute>
        <full-name-attribute>givenName</full-name-attribute>
        <password-attribute>userPassword</password-attribute>
        <user-id-attribute>cn</user-id-attribute>
        <user-base-dn></user-base-dn>
        <user-object-class>inetOrgPerson</user-object-class>
        <user-filter>(|(attributeName=value1)(attributeName=value2))</user-filter>
      </configuration>
    </component>
    
  • email-attribute - The name of the attribute on a user that contains the email address
  • full-name-attribute - The name of the attribute on a user that contains the users fullName
  • password-attribute - The name of the attribute containing the users password, used for the authentiction using the user manager and not the ldap bind authenticator
  • user-id-attribute - The name of the attribute containing the users userId, most commonly cn or sn.
  • user-base-dn - The base dn that will be subtree searched for users.
  • user-object-class - the objectClass used in the ldap server for indentifying users, most commonly inetOrgPerson.
  • user-filter - the user filter is used to reduce the number of results during a LDAP request. It is optional.
security policy (for the password encoder)
  
    <component>
      <role>org.codehaus.plexus.redback.policy.UserSecurityPolicy</role>
      <role-hint>default</role-hint>
      <implementation>org.codehaus.plexus.redback.policy.DefaultUserSecurityPolicy</implementation>
      <description>User Security Policy.</description>
      <requirements>
        <requirement>          <role>org.codehaus.plexus.redback.configuration.UserConfiguration</role>
          <field-name>config</field-name>
        </requirement>
        <requirement>
          <role>org.codehaus.plexus.redback.policy.PasswordEncoder</role>
          <role-hint>sha1</role-hint>
          <field-name>passwordEncoder</field-name>
        </requirement>
        <requirement>
          <role>org.codehaus.plexus.redback.policy.UserValidationSettings</role>
          <field-name>userValidationSettings</field-name>
        </requirement>
        <requirement>
          <role>org.codehaus.plexus.redback.policy.CookieSettings</role>
          <role-hint>rememberMe</role-hint>
          <field-name>rememberMeCookieSettings</field-name>
        </requirement>
        <requirement>
          <role>org.codehaus.plexus.redback.policy.CookieSettings</role>
          <role-hint>signon</role-hint>
          <field-name>signonCookieSettings</field-name>
        </requirement>
        <requirement>
          <role>org.codehaus.plexus.redback.policy.PasswordRule</role>
          <field-name>rules</field-name>
        </requirement>
      </requirements>
    </component>

security.properties

These properties should be set as shown:

user.manager.impl=ldap
ldap.bind.authenticator.enabled=true
redback.default.admin=admin
redback.default.guest=guest
security.policy.password.expiration.enabled=false

The user.manager.impl is the role hint that is used to determine which user manaher to use while running. The default is 'cached' and if this is desired to be used with ldap then you must include the component declartion below in the caching section for the cached UserManager that sets the underlying userImpl to ldap.

The ldap.bind.authenitcator.enabled boolean value will toggle the use of authenticator that will authenticate using the bind operation. There are two different mechanisms used to authenticate with ldap, either the bind authenticator which is a standard way to authentication, and then the user manager password validation approach. If this is desired then you must ensure that the security policy is configured to use the correct password encoding. Normally the bind authenticator is simply enabled since this bypasses concerns of password encoding.

It is also now possible to redefine the basic admin user and guest user names. Since its unlikely that ldap oriented authentication systems will have a specific admin or guest user these can be redefined simply in the security.properties. Care must be taken that they exist in the ldap system since they are looked up. Guest users can be simple utilitie or application users.

The final setting of security.policy.password.expiration.enabled is a boolean that should be set to false for ldap based authentication. This is because redback will want to attempt to manage and enforce password expiration and that is no longer under the direction of redback but is an artifact of the ldap system in place. Setting this to false prevents issues from cropping up related to redback trying to obtain this type of information.

Caching

If caching is desired the you should also include the following declarition and set the appropriate configuration from ldap to cached

    <component>
      <role>org.codehaus.plexus.redback.users.UserManager</role>
      <role-hint>cached</role-hint>
      <implementation> org.codehaus.plexus.redback.users.cached.CachedUserManager</implementation>
      <description>CachedUserManager</description>
      <requirements>
        <requirement>
          <role> org.codehaus.plexus.redback.users.UserManager</role>
          <role-hint>ldap</role-hint>
          <field-name>userImpl</field-name>
        </requirement>
        <requirement>
          <role>org.codehaus.plexus.cache.Cache</role>
          <role-hint>users</role-hint>
          <field-name>usersCache</field-name>
        </requirement>
      </requirements>
    </component>