"bvogt" wrote : Sorry for being so short in my comment. | | May be I do not see the complete picture, but I guess that using LDAP means authentication | against the LDAP server too? | In portal user authentication is done using JAAS in ApplicationServer. So you could just authenticate to ldap by configuring it properly even now with 2.2 and 2.4. But you still need to retrieve the user data so you use database. anonymous wrote : | 1. where to store user/role data | There are few posible scenarios like: 1) keep it in LDAP - thats what is planned in current implementation. So this means no user/role data in DB. But still you should be able to keep personalization data in DB like user properties. 2) authenticate in LDAP and keep in DB - this is possible at the moment. You just need to configure authentication on the app server side and keep LDAP/DB in sync manually. So here we may consider to make JAAS LoginModule implementation that authenticate against LDAP and update user/role data in DB. 3) keep all in DB - current implementation anonymous wrote : | -------------------------------- | The decision where to store the user/role data depends on external critera like: | - amount of expected data objects | - availability of additional resources (Memory, CPUs, Servers) | If there are a few thousands of users expected, the database solution might be | the way to choose. | Yes. The difference between DB and LDAP is that directory server is designed to keep huge amount of data optymized for read operations. So you rather choose LDAP server if you have many users and want to authenticate them among many systems (so portal is not the only client). anonymous wrote : | On the other hand the LDAP based solution requires at least a service on the | portal server (if CPUs and amount of memory permits this). | I don't understand. anonymous wrote : | We think, that for our use case the dabase solution is enough for the current | requirements. | I agree that for many systems DB is enough. anonymous wrote : With 2.6 a new let's say 'grouping feature' is introduced by means of the | MembershipModule. For LDAP usage the is intended to be implemented, but (as I can see | right now) for database not. Nope. MembershipModule, UserModule, RoleModule and UserProfileModule is general API that hides the way you access identity objects. So both ldap and db will implement this. anonymous wrote : | I guess you intend the 'GroupOfNames' LDAP class to reflect the group memberships of | users? A counterpart in the database is missing. | Yes. This is the plan for the standard ldap MembershipModule implementation. But architecture of modules is open so you are free to implement another strategy just by implementing this interface. Database implementation will just use current hibernate configuration. You cannot compare it like this. This API just hides the implementation. anonymous wrote : | In order to have the portal admin decide which way to choose the database part should | be extended in an appropriate way. | The idea is to keep it flexible. So you for exemple you may be able use LdapUserModuleImpl, LdapRoleModuleImpl, LdapStaticGroupMembershipModuleImpl and HibernateUserProfileModuleImplementation that will keep user profile data in Database. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981734#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...