This won't work atm. because of PicketLink IDM limitations. I have it on my TODO list and started working on it recently but being occupied with higher priorities for now.
If you are willing to dive into PicketLink IDM code and contribute you are more then welcome and I can provide some help. Main problem is that IdentityObjectType (such as USER) is used as one to many mapping between IdentityStoreRepository and IdentityStore. Proper solution would be to allow map several stores per identity object type in repository. This requires some work in FallbackIdentityStoreRepositoryImpl as it should then perform IdentityObject creation in the first store defined in the config while retrieve users from all stores.
We find this use case important and aim to adress it soon but I can't promise on the precise date at the moment.
In the <Realm> configuration there is a <user-mapping> element that appears to be able to be added multiple times Could we look at using this element to map the various "type" of users to the IdentityObjectType USER used by the portal?
And in the each <identity-store> use the above user types to specify that this is a different type of user. If a type is used in multiple stores then you would look to merge the user's attributes, or reject the user from adding based on some attribute set..
Interesting idea but as in PicketLink IDM API there is no notion of different user types it also has some a lot of implications on the PicketLink API implementation to do all the mergers and mappings properly.
For now I guess I will configure my primary group of users with idm, and implement a customer LoginModule for each of the additional user groups.
Problem is in previous trials, I was about to authenticate with my custom loginmodule as part of that authenticate I added the "/platform/users" role to the users list of roles, but was not able to actually login to the portal.. Is this because I need to add that user to the portal's "/platform/users" group, as documented in the CustomerMembershipLoginModule?? And if so do I need to create the user in the portal?
Moritz abd myself did invest some time to extend Gate 3.1.FINAL's Picketlink implementation to support multiple ldap stores.
What we did:
* Modified PersistenceManagerImpl and FallbackIdentityStoreRepository.
* Support multiple usertype mappings that each show to different ldap identity stores.
* Modifications only work for reading ldap access.
* Performance might not be optimal due to unneccessary ldap queries.
Nice work and thanks for sharing! Some improvements in this area were made in PLIDM 1.3 and GateIn 3.2. I will review your code and look for stuff to merge.
We added some stuff:
* define amount of ldap search results for mulitple stores
* set option "maxSearchResults" per xml config file (like implementation in 1.3.0.Final)
* get "USER" from userTypeMappings
Following work left - extend ldap search to allow wildcards*
* Increase performance while excessing multiple contexts per ldap store. Currently, every single context needs to be added to picketlink configuration XML file. Wildcard search against DN would increase performance.
We did some performance tuning and bugfixing.
Finally, we did describe our changes here: http://blog.akquinet.de/2011/12/26/patching-picketlink-to-support-multiple-ldap-stores/
Any feedback welcome.