Implementing the AppFuse DAO layer with Spring LDAP
This week, I've been helping a click kickstart an application using AppFuse. The first order of business was re-writing the backend to support LDAP. They'd like to keep the Hibernate implementation in place, but they'd also prefer to have the option to use LDAP. Since a database will still be used to manage entities outside of User and Role, the LDAP implementation I have continues to maintain a userId and username in the database.
I'm pretty impressed that I was able to get 90% of the functionality completed in 2 days. Of course, it wouldn't have been possible w/o the excellent Spring LDAP project, nor the good ol' Acegi Security project. I'm deploying on Geronimo using the Apache Directory Plugin for LDAP. Getting a custom UserDetailsService working wasn't too difficult, but I am still having some issues with CRUDing LDAP:
- I get an Undefined Attribute Type error when modifying the non-String attributes in a User. This is quite strange since all the attributes are stored as Strings in LDAP.
- I get the same error when trying to remove a user from a role.
- There's no LdapUnit (like DbUnit) to delete/insert users and roles before running tests. I tried to use the LdapTestServer from Acegi, but no dice.
- Since the project has two versions (Hibernate or LDAP) in the source tree, the LDAP and Hibernate tests won't both pass. This is because the schema for LDAP only has 2 columns in the app_user table, while the Hibernate version of the table has all columns. The simplest solution seems to be removing the not-null constraints on most of the columns in this table.
If anyone has experience implementing User->Role CRUD in LDAP with Spring LDAP, I'd love to hear your thoughts on these issues.
Hey Matt,
It's been over a year since I did some LDAP/Java programming, but I think the error you're getting (Undefined Attribute Type) is related to those attributes not being part of "top", "person", or "inetOrgPerson". (Their being non-Strings is a coincidence.) Those problematic attributes are probably part of the "user" class, so I'd try changing the one line to:
context.setAttributeValues("objectclass", new String[]{"top", "person", "inetOrgPerson", "user"});and see what happens. If I recall correctly, the user class is MS AD specific. Note that different LDAP-compatible directory servers define users differently. Don't expect this code to be portable from AD to eDirectory to OpenLDAP. You may need a different implementation for each platform (unless Spring is doing some magic here. It wouldn't be the first time. :-).
Posted by kelzer on October 11, 2006 at 02:18 PM MDT #
Posted by Matt Raible on October 11, 2006 at 03:09 PM MDT #
Hey Matt,
What LDAP server are you using? I think I'm on the right track, but without more info I can't be much help, because every LDAP server treats users differently. Where are you getting the names of those attributes? (accountEnabled, etc.) I'm pretty sure they have to exist within one of those objects listed in the objectclass list. My guess is you're using OpenLDAP. I've worked with AD, Novell eDirectory, and Oracle Internet Directory (OID). They all do things differently when it comes to users.
Check out these LDAP error codes. Error 17 states: LDAP_UNDEFINED_ENGINE: Indicates that the attribute specified in the modify or add operation does not exist in the LDAP server's schema.
Active Directory actually uses a single attribute named "userAccountControl" that's used by the "user" class which stores flags for the locked state, password expiration state, etc. As I've said, other directory services do things differently. Novell eDirectory has a class named "ndsLoginProperties" that has attributes for those kinds of things. IBM Tivoli LDAP Server uses an attribute named "pwdLockout".
It's unfortunate that the LDAP standard doesn't standardize a lot of this type of thing.
Posted by kelzer on October 11, 2006 at 03:42 PM MDT #
AFAICT, the attributes are all named the same. The strange thing is the error only occurs when I modify certain attributes - most of the attributes can be modified just fine. You're probably right, I'm just not seeing it.
Posted by Matt Raible on October 11, 2006 at 03:49 PM MDT #
Posted by Mattias Arthursson on October 13, 2006 at 07:58 AM MDT #
# Define an entry to contain people dn: ou=users,ou=system objectClass: organizationalUnit ou: users # Define a user entry for Tomcat User dn: uid=tomcat,ou=users,ou=system objectClass: inetOrgPerson objectClass: person objectClass: top uid: tomcat userPassword: {SHA}U2wLM5NFYWwbM8r0VEVNi4oZDWw= cn: Tomcat sn: User displayName: Tomcat User mail: [email protected] telephoneNumber: title: Just a User department: Accounting passwordHint: A male kitty. accountEnabled: true accountExpired: false accountLocked: false credentialsExpired: false version: 1 # Define a user entry for Matt Raible dn: uid=mraible,ou=users,ou=system objectClass: inetOrgPerson objectClass: person objectClass: top uid: mraible userPassword: {SHA}U2wLM5NFYWwbM8r0VEVNi4oZDWw= cn: Matt sn: Raible displayName: Matt Raible mail: [email protected] telephoneNumber: title: Admin and User department: Finance passwordHint: A male kitty. accountEnabled: true accountExpired: false accountLocked: false credentialsExpired: false version: 1 # Define an entry to contain LDAP groups # searches for roles are based on this entry dn: ou=groups,ou=system objectClass: organizationalUnit ou: groups # Define an entry for the "user" role dn: cn=user,ou=groups,ou=system objectClass: groupOfUniqueNames objectClass: top cn: user uniqueMember: uid=mraible,ou=users,ou=system uniqueMember: uid=tomcat,ou=users,ou=system # Define an entry for the "admin" role dn: cn=admin,ou=groups,ou=system objectClass: groupOfUniqueNames objectClass: top cn: admin uniqueMember: uid=mraible,ou=users,ou=systemAnd here's my Java code for removing a user from a role:
public void removeUser(Long userId) { User user = getUser(userId); ldapTemplate.unbind(buildDn(user)); // remove user from roles - this currently doesn't work due to issue in last 3 lines of this block for (Role role : user.getRoles()) { Role r = roleDao.getRoleByName(role.getName()); List<String> members = new ArrayList<String>(r.getMembers().length); for (String member : r.getMembers()) { if (member.indexOf(user.getUsername()) == -1) { members.add(member); } } r.setMembers(members.toArray(new String[0])); // calling saveRole results in javax.naming.directory.SchemaViolationException // todo: fix so users are removed from roles when they're deleted //roleDao.saveRole(r); } // remove from database too jdbcTemplate.update("delete from " + userTableName + " where id=?", new Object[]{userId}); }RoleDaoLdap.saveRole(Role role) is:
public void saveRole(Role role) { Name dn = buildDn(role.getName()); DirContextAdapter context = (DirContextAdapter) ldapTemplate.lookup(dn); mapToContext(role, context); ldapTemplate.modifyAttributes(dn, context.getModificationItems()); } protected void mapToContext(Role role, DirContextAdapter context) { context.setAttributeValues("objectclass", new String[]{"top", "groupOfUniqueNames"}); context.setAttributeValue("cn", role.getName()); context.setAttributeValue("description", role.getDescription()); context.setAttributeValues("uniqueMember", role.getMembers()); }RoleDaoLdap.saveRole() works fine when I adding a new uniquemember attribute, it just fails when I try to remove one.
Posted by Matt Raible on October 13, 2006 at 08:07 AM MDT #
Posted by Ulrik Sandberg on October 13, 2006 at 10:06 AM MDT #
Posted by Matt Raible on October 13, 2006 at 10:14 AM MDT #
Posted by Mattias Arthursson on October 14, 2006 at 12:56 AM MDT #
Posted by anil on September 08, 2008 at 11:02 PM MDT #
Posted by anil on September 09, 2008 at 02:04 AM MDT #