-
Type:
Bug
-
Status: Closed
-
Resolution: Won't Fix
-
Affects Version/s: 6.1.0 CE GA1
-
Fix Version/s: 6.1.1 CE GA2
-
Component/s: Environments, Environments > Databases
-
Labels:
-
Environment:Debian / ArchLinux 64bits ; JDK 1.7u3, Tomcat 7.0.25, PostgreSQL 9.1, OpenDJ 2.4.4, OpenAM 10, Apache 2.2
I have Liferay on Tomcat running behind Apache HTTPd with OpenAM's Policy Agent which fills HTTP headers with user data values. I'm thus authenticating Liferay by using HTTP Header through SiteMinder (since OpenSSO auth doesn't support HTTP headers).
I activated the option siteminder.import.from.ldap=true so that Liferay creates Users from OpenAM's underlying LDAP. I then set the typical LDAP configuration corresponding to OpenDJ and tried to login.
Liferay manages to get the HTTP_HEADER and then tries to fetch its attributes from LDAP. When preparing LDAP request, class com.liferay.portal.security.ldap.PortalLDAPUtil fetches user Attributes keys by reading portal properties (function public static Attributes getUserAttributes line 499). When trying to reach Contact and Expando related properties, it crashes since I didn't set ldap.user.custom.mappings.0 nor ldap.contact.custom.mappings.0 nor ldap.contact.mappings.0
I don't have any expando properties neither do I use Contacts. Thus, I don't see why I should set those values. When I set them to an empty value (ldap.user.custom.mappings.0=), everything works like a charm (which makes this a workaround).
I saw that the following values are commented out in portal-impl.jar!portal.properties :
#ldap.user.custom.mappings.0=
#ldap.contact.mappings.0=
#ldap.contact.custom.mappings.0=
In my humble opinion, it would be great if at least those keys where enabled by default with an empty value so that any user trying to import from LDAP without using Contacts or Expando doesn't waist time trying to figure out what happens (in my case, Liferay just threw a "ERROR [SiteMinderAutoLogin:106] com.liferay.portal.NoSuchUserException: No User exists with the key" exception, which is not self explanatory in that case). In fact, one just needs to uncomment the aforementioned keys in portal-impl.jar!portal.properties
See ya