You can configure gatein to store users in LDAP and then it will use this as a source of authentication. Other benefit is that users will be able to update their password.
1) Edit the idm-configuration.xml to point to the "picketlink-idm-ldap-config.xml" instead of "picketlink-idm-config.xml"
2) Edit "picketlink-idm-ldap-config.xml" to have proper LDAP settings in "PortalLDAPStore".
If you don't want to store groups in LDAP and only users then you need to make the following changes:
... <repository> <id>PortalRepository</id> <class>org.picketlink.idm.impl.repository.FallbackIdentityStoreRepository</class> <external-config/> <default-identity-store-id>HibernateStore</default-identity-store-id> <default-attribute-store-id>HibernateStore</default-attribute-store-id> <identity-store-mappings> <identity-store-mapping> <identity-store-id>HibernateStore</identity-store-id> <identity-object-types> <identity-object-type>GTN_GROUP_TYPE</identity-object-type> </identity-object-types> <options/> </identity-store-mapping> <identity-store-mapping> <identity-store-id>PortalLDAPStore</identity-store-id> <identity-object-types> <identity-object-type>USER</identity-object-type> </identity-object-types> <options/> </identity-store-mapping> </identity-store-mappings> <options> <option> <name>allowNotDefinedAttributes</name> <value>true</value> </option> </options> </repository> ...
and under "<identity-store><id>PortalLDAPStore</id>..." section remove the whole "<identity-object-type><name>GTN_GROUP_TYPE</name>" section. If you use the sample-portal then you need to alter "SamplePortalRepository" and "SamplePortalLDAPStore" the same way
If you need to learn more about the picketlink-idm-config.xml file please refer to the docs:
I will try to come up with more examples and a sample ldif and config file for such scenario next week.
You said: "You can configure gatein to store users in LDAP and then..." and this case is for brand new portals only.
What if the company already has LDAP server set-up and it has couple hundreds of active users and the server is used by several applications across the organization. Those companies usually already have some way to manage records in the LDAP and they don't need other system to override it. I see some attributes in the documentation that designed to support this use case but there is no real examples. Can you please provide some examples like it is done in Tomcat Documentation about JNDI Realm? This example will be very useful for many different companies that use LDAP or Active Directory to manage user identities.
LDAP support is not designed to support fresh and empty directories only . The documentation should be improved soon and configuration examples will follow.
Could you share with us what kind of LDAP integration use case do you have? Which LDAP server you are using, how is your directory tree organized and which parts of it would you like to plug into portal? I will try to provide some real life configuration examples in a form of wiki or blog later and this knowledge would be useful.
It would be too easy for you if you will work with real examples. That's why I pointed you to generic examples from Tomcat documentation so you will not try to make some shortcuts. Please read it through and you'll find that it covers many different scenarious form real life.
In our company we use Active Directory and all web applications have read-only access for authentication. MS Administrator tools are used to manage users and groups (roles). Realm configuration is following (some real data replaced with generic names for educational purposes):
<Realm className="org.apache.catalina.realm.JNDIRealm" debug="99"
Our realm configuration is combination of examples #2 and #3 from Tomcat configuration.
LDAP Tree looks like this:
"Security Groups" used as roles in terms of authentication, "Users\SBSUsers" contains all users.
As you can see from realm config, every user record has "sAMAccountName" property which is used as user login, every security group has "member" property where all group members are specified and it is used to detect which roles belong to the user. To connect to our LDAP we use special account created to exactly that (see "connectionName" and "connectionPassword").
Later in web.xml we just map security group names to application role names like this:
This logical role includes all authenticated users
This logical role includes all administrative users
<role-name>Dev Tools Admin</role-name>
Of course JBoss Portal usually work differently but if this new version will support read-only access to LDAP for authentication it would be great. I understand that this use case is kinda weird for portals where users can create logins for themselves. Although in my experience many of regular businesses that potentially would be interested in portal application for their intranet already have all infrastructure for network security so portal should be able to use it instead of creation separate user database. What you think? Is it possible in Gate In?
Thanks a lot for sharing your usecase. I will have it in mind when preparing examples. First of all we want to have "at least" the same level of LDAP support in GateIn as we had in JBoss Portal. The main difference is that in GateIn groups are organized in a tree as it was inherited from exo portal. Current integration with PicketLink IDM storage enables you to plug your LDAP groups container as a single branch. In current trunk there is configuration example where only groups under "/platfrom/..." (and/or "/organization/...") are stored in LDAP. You need to make a switch in idm-configuration.xml to use picketlink-idm-ldap-config.xml and uncomment few additional lines in configuration below.
It is easy to try it out with OpenDS with default root DN (dc=example, dc=com) as all needed non existing LDAP entries will be created. So the rest is a matter of proper configuration to match MSAD schema. PicketLink IDM testsuite is run against Active Directory in our QA (including entry creation support). You can find such MSAD PicketLink IDM config here:
I will try to provide example MSAD configuration as soon as possible. At the moment we are really focused on the upcomming face to face meeting (http://blog.gatein.org/) and on polishing things for candidate release.
It is good to know that you are working on it. But in general for end users like us is more important that your product will completely support specifications that you claim to support. So if you open JSR-268 PDF, you can find following simple clear statement in section PLT.24 Security: "The portlet container is responsible for informing portlets of the roles users are in when accessing them. The portlet container does not deal with user authentication. It should leverage the authentication mechanisms provided by the underlying servlet container defined in the Servlet Specification, SRV.12.1 Section." See full specification text in the attachment.
If you will keep that in mind then it would be easier to design your security layer that conforms all specifications without extra work. We are not expecting from portal container all flexibility and power of RSA or CA products. There is no requirement to use something like Acegi or similar frameworks (but if you do of course it would be a plus). What I don't like that when application developers forget the roots and start reinventing wheels instead of using all those things they already have. In your case you should not forget that Gate In will be deployed into sevrlet containter (Tomcat, Jetty, Websphere, Weblogic etc...) that already supports J2EE security and it has all facilities for authentication. All you need to do: communicate with it properly. When you done with basic J2EE security support you will know how you can extend it with additional features.
So thank you again for your hard work. I hope my comments will help.
PortletSpec_20.pdf 1.2 MB
In terms of authentication GateIn uses plain JAAS LoginModule stack so nothing fancy is going on here and it goes along with the spec. We don't reinvent authentication/authorization and rely on standars. JAAS LoginModule implementation uses GateIn identity API to query and authenticate users. It is quite natural that portal needs a bit more flexible user and group store - a bit more that JNDIRealm mentioned by you provides... So as GateIn is using plain JAAS in Tomcat and JBoss Application Server it is possible to just alter its configuration and use container provided authentication mechanisms like LoginModule implementations available there. However you still need to configure user store so portal can retrieve and store more information about users and groups. Then you end up with two configs instead of one...