I have my own login module for doing Single Sign-on. That part works. What doesn't work is the ability to get UserProfile information from the Active Directory server.
Using this forum, the closest problem I could find is:
This article indicates that what I want isn't possible because this isn't supported in Synchronizing* login modules.
So the only way the delegating UserProfile works is by using the IdentityLoginModule?
I thought the SynchronizingLoginModule was supposed to handle allowing different login modules to be used and then it would handle all the portal voodoo by adding it to the end of the login chain.
I have a working solution.
I will try and give some details about what I've found in case it can help somebody else.
First, let me state where I am coming from. When I think of a Portal, I think of something that is a self contained resource. If it needs LDAP, it can use it, but doesn't need it. But for convenience of keeping users and rights in a central location, it should be able to use LDAP. And mostly as a read-only resource.
Based on that, I wanted to keep the Portal DB configuration and just go to the AD server to get additional user info. Therefore, I thought I could use the regular identity-config.xml and just modify the profile-config.xml to add properties with LDAP mappings.
I figured this would work because the docs say that anything that has an LDAP mapping will be delegated to LDAP first. And it looks like it would have worked except for the fact that it has been specifically excluded in the code.
In the DelegatingUserProfileModule the code is this:
if (property.isMappedLDAP() && isLDAPSupported() && user instanceof LDAPUserImpl)
log.debug("Delegating to LDAP module");
getLDAPModule().setProperty(user, name, propertyValue);
else if (property.isMappedDB())
log.debug("Delegating to DB module");
getDBModule().setProperty(user, name, propertyValue);
fireUserProfileChangedEvent(user.getId(), user.getUserName(), name, propertyValue);
So, because I have used the regular DB configuration, my user will not be an instance of LDAPUserImpl, so the code WON'T EVEN TRY to get the data from LDAP.
In order to get make my user an instance of LDAPUserImpl, I need to change the type in identity-config.xml so that User has an implementation type of LDAP.
Therefore, I decided to start over using the ldap_identity-config.xml (which I probably didn't need to), but it has the sections for and /<options-group> that will need to be configured already in it.
However, leaving the Roles and Membership modules set to LDAP was a big mistake because of the way Portal hard codes the Admin/User roles. That was a nightmare. But I didn't want to run into more cases where the code specifically excluded what I was trying to do.
After changing the Roles and Membership modules back to DB, I was able to manipulate my LoginModule to get the proper role mappings done.