[jboss-dev-forums] [Design of JBoss Portal] - Re: LDAP Support expectations

[olivwalt]

Hi bdaw,

i think i posted into the wrong forum http://jboss.org/index.html?module=bb&op=viewtopic&t=94631, but i will repeat my ldap expectations here.

In our company only application independent data is stored in LDAP. This means we get the following scenario:

Datastore:
------------

LDAP Store

- Basic user data
- Basic group data
- User -> group assignmrent

Therefor we would need in Portal DB

- User/group -> Role assignment
- Role -> Content assignment
- Portal user data

This leads to 3 problems

1. LDAP doesn`t have portal related attributes, therefor we need Attribute based data partitioning

- Base User data -> LDAP (e.g uid, password, mail, status, a.s.o)
- Portal User data -> Portal DB (theme, lastlogin, a.s.o)

2. LDAP doesn`t know default Portal Users (admin, user, a.s.o), so we need User based data partitioning

- Company user employee -> LDAP
- Portal user "admin" -> Portal DB, this should still work, even if LDAP is configured (e.g. emergency access, initial setup, system users, a.s.o)

3. LDAP doesn`t know default portal Groups, so we need Group based data partitioning (same as user based part.)


Operations in Portal:
------------------------
1. Read,create,update,delete Users
2. Read,create,update,delete Groups
3. Assign/revoke Users to Groups
4. Assign/revoke Users/Groups to Portal Roles

Depending on the user persistence store configuration, this would lead into the following scenarios:

Read-write LDAP configartion

1. Read,create,update,delete Users from LDAP
2. Read,create,update,delete Groups from LDAP
3. Assign/revoke LDAP Users to LDAP Groups
4. Assign/revoke LDAP Users to Portal DB Groups
5. Assign/revoke LDAP Users/Groups to Portal Roles
6. Read,update,delete Users from Portal DB
7. Read,update,delete Groups from Portal DB
8. Assign/revoke Portal DB Users/Groups to Portal Roles

Read-only LDAP configartion

1. Read Users from LDAP
2. Read Groups from LDAP
3. Assign/revoke LDAP Users to Portal DB Groups
4. Assign/revoke LDAP Users/Groups to Portal Roles
5. Read,create,update,delete Users from Portal DB
6. Read,create,update,delete Groups from Portal DB
7. Assign/revoke Portal DB Users/Groups to Portal Roles

For both LDAP configurations, you need to update according Portal DB attributes as well (lastlogin, etc), independend, if it`s read or write.

No LDAP configuration

1. Read,create,update,delete Users
2. Read,create,update,delete Groups
3. Assign/revoke Users to Groups
4. Assign/revoke Users/Groups to Portal Roles 


Principals
--------------
I would do a different implementation, then in your post http://jboss.org/index.html?module=bb&op=viewtopic&t=92487
1. MembershipModule makes no sense to me, you always should work with Objects of type principal
2. The missing Group portal functionality mentioned by bvogt is really a pain for larger projects

Here is what would suggest, based on your draft and on SAP`s implemtation of the User Management Engine.


UserModuleUserModule - provides functionality to get User objects by providing required information.
  | - instantiate user objects
  | - create new users (possibly by copying the data of an existing one)
  | - delete users
  | - search for users based on different criteria

UserUser -- provides read and write acces to principals of type User.
  | - Get and set User attributes
  | - Perform Group operations dd and revoke Users to Group
  | - Perform Role operations dd and revoke Users to Role
  | - Authorization checks isMemberOf Group or Role	

GroupModuleGroupModule - provides functionality to get Group objects by providing required information.
  | - instantiate group objects
  | - create new groups
  | - delete groups
  | - search for groups based on different criteria 	

GroupGroup - read and write access to principals of type Group. 
  | - Perform User operation add and revoke Users to Group
  | - Perform Role operations add and revoke Group to Role
  | - Get and Set Group attributes	

RoleModuleRoleModule - provides functionality to get Role objects by providing required information.
  | - instantiate Role objects
  | - create new Roles
  | - delete Roles
  | - search for Roles based on different criteria 	

RoleRole - read and write access to principals of type Role. 
  | - Perform User operation add and revoke Users to Role
  | - Perform Group operations add and revoke Group to Role
  | - Get and Set Group attributes	

Persistence configuration
----------------------------

I checked your idendity draft under http://anonsvn.jboss.org/repos/portal/trunk/identity/src/resources/draft/ .

As bvogt already mentioned i would merge the config files into one.

- standardidentity-config.xml -> Maps all information to default Portal DB
- ldapidendity-config.xml -> overwrites configured options to LDAP, not configured attributes/principals are still mapped over the standardidendity-config.xml to Portal DB

Therefor the options section in ldapidendity-config.xml wolud look like<options>
  |   <module type=UserModule>
  |     <property>
  |       <name>portal.user.realEmail</name>
  |       <type>java.lang.String</type>				
  |       <access-mode>read-write</access-mode>			<!-- Why at attribute scope, imho this should be global setting -->
  |       <usage>optional</usage>						
  |       <display-name xml:lang="EN">Real Email</display-name>	<!-- Why here? -->
  |       <description xml:lang="EN">The real email</description>	<!-- Why here? -->
  |       <mapping>
  |         <type>attribute</type>
  |         <value>mail</value>
  |       </mapping>
  |     </property>
  |   </property>
  | </option />

As you mentioned earlier in this post, the roadmap for 2.6 is already defined and you won`t change it, so this maybe helpful for release 3.0. Both solutions anonymous wrote : 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.  would be enough for us to start working, but not to use it productive.

Whereas i personally prefer the first solution, to avoid redundant data and synchronisation delay.

As i understand your implemetation,  Roles and User Objects maintained in LDAP, and also the relationship. Roles are used in JBoss Portal to control access rights to portal objects. Please correct me, if i`m worng, but this would mean application dependend data has to be stored in LDAP, that is not usable in larger companies, as you already mentioned, Portal is just another client application, and we have several of it. 

Maintaining Users/Groups in LDAP and map to Roles in Portal would also increas the flexibility of LDAP configuration.

What i don`t understand right now is, why do you want to decouple Users and Roles in a MembershipModule, what is the advantage of this?

Regards Oliver


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988893#3988893

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988893