[jboss-dev-forums] [Design of JBoss Portal] - Re: Identity model

olivwalt do-not-reply at jboss.com
Fri Nov 24 07:31:38 EST 2006


Hello bdaw,

finally i could get through all discussion about LDAP and portal. Even if i`m not 100% up to date, with current status, i want to make some considerations here.

In real life, (anyway in our company), we store only application independent data in LDAP. This means we get the following scenario:

A. Datastore 
------------------------------
LDAP Store

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

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.)


B. 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

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


C. 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


D. 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 />





What do think think about that, bdaw? 

Regards Oliver

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

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



More information about the jboss-dev-forums mailing list