[EMAIL PROTECTED] wrote:
Hello Andreas,>
This is very interesting!
But I'm not sure to understand:
First, I have to explain something about our background to let you better understand what we do and why. This way it might be easier for you to decide, whether this applies to you or not.
Background
----------
We are an automobile club from Austria driving two main websites and several intra- and extranet websites. We have about 2500 employees and 1.5 million club members.
We want our users (which are actually non-members, members and employees) to be able to register at our website and take advantage of different services.
We are just starting some major refactoring of the web architecture where Cocoon is playing a big role.
Terminology
-----------
In our terminology we use the term 'group' to classify our users (independent of any application) and not directly to assign them certain roles. A 'role' is for us only defined for a certain application (e.g. CMS: admin, editor, chief editor, ...). So it is not enough to say that user a has the role 'admin'. You have to say user a (which is from the group 'employee') has the role 'admin' in the application 'CMS'.
This way a group is independent from any applications.
Organization of groups
----------------------
Our groups are organized this way, that every group is a subset of another group (see LDAP layout in my last mail below). So the super group is called 'simple user' which have the following attributes entered during registration:
* username
* password
* email address
The bigest subset of the simple users are called the 'extended users', which provide the following attributes additional to those from above:
* street
* zip code
* city
* country
The biggest subset of the extended users are the 'members', which provide a member number during the registration on the webpage. Since we already have their personal information available in backend systems, we just need to identify them but they don't have to enter all the data again. They have the following additional attribute:
* member number
The last subset of the members are now the 'employees' which are automatically club members. They don't have to register at all, since they are already managed by an Active Directory internally. They have the following additional attribute:
* employee number
Data Storage
------------
To be able to handle all of these users in the same way we use on LDAP system (OpenLDAP) for just the authentication (user/password) and autorization (roles) information and a MySQL database for all the additional user attributes (postal address, phone number, ...). The MySQL database is a replica of our internal customer database with just the information we need. It will hold all users. The LDAP entries will be created only during registration to be able to get validated email addresses via activation URLs. Employees are automatically registered, since their authentication information is replicated from the Active Directory.
Authentication
--------------
This is just done against LDAP via standard mechanisms. We might use the authentication framework of cocoon for this task.
This way we can allow single sign-on across several applications.
Authorization
-------------
To know if a certain user is allowed to do a certain task in a certain application we do the following:
Every group has some default roles attached, where the roles are inherited across the groups the same way it is done with the attributs from the explanation of above (Organization of groups). This will be held in the LDAP attribute 'groupOfUniqueNames'.
If certain users have additional roles in certain applications they have the additional role stored in the attribute with the same name.
It still has to be decided how to manage and refer to the different roles, which can have similar names in different applications (e.g. admin of app A vs. admin of app B).
Is your organization tree stored in a LDAP repository?
Our user group hierarchy, yes. Not (yet) the internal structure of our organization.
Your four groups of users are similar to roles?Only indirectly as the explanation above tells you.
You store the role information inside the InetOrgPerson class. Is it a persistence class?In LDAP terminology you have different classes of things.
One is the class 'Person' from which 'inetOrgPerson' inherits (has certain internet attributes like email available). These classes don't have to do anything with Java classes. They just share the same concepts and terminology.
I've compiled a number of helpful LDAP resources on my weblog which can be found here:
http://highstick.blogspot.com/2003_08_01_highstick_archive.html#106015179296211197
Especially this one explains it very well (you will have to click through):
http://ldap.akbkhome.com/objectclasstree/inetOrgPerson.html
Where do you use Cocoon in your authentication process?Via the use of the authentication framework which we might chose.
Thanks for your help. Sylvain
I hope this helps you.
Bye,
Andreas Hochsteger
-----Message d'origine----- De: Andreas Hochsteger [mailto:[EMAIL PROTECTED] Date: mercredi, 3. septembre 2003 07:12 �: [EMAIL PROTECTED] Objet: Re: Cocoon 2.1 Authentication Bug? *Please* Help
Hi!
I'm no LDAP expert, but I can tell you how we are going to do authentication and authorization:
We have 4 groups of users (Simple, Extended, Member, Employee) which are hierarchically organized this way:
+-Simple +-User1 +-... +-Extended +-User2 +-... +-Member +-User3 +-... +-Employee +-User4 +-...
They are organized this way, because the everyone can be treated as a simple user (has just username, password and email address), whereas extended users, members and employees can be treated as extended users (validated additional data is available) and so on ...
This can be achieved by a subtree search.
We use the InetOrgPerson class and store the role information in the attribute 'groupOfUniqueNames'.
We store default roles (which are application dependent) for every group but can attach additional roles to certain users.
I don't know if it will really work this way, but that's how we planned it to do ;-)
Perhaps it's will be of help for you.
BTW we use LDAP *only* for authorization and authentication. All additional user data (postal address, profiles, ...) is stored in a mysql database.
Bye, Andreas
Carsten Ziegeler wrote:
Hi,
if you have different users with different roles, then I would store the information with your users in the LDAP. However, I don't know LDAP, so perhaps someone else can help here?
Carsten
[EMAIL PROTECTED] wrote:
Hello,
Yes, I don't have roles since I'm using the LDAP authentication, all users are "Admin" at this moment.
Do you think to create a static list in a file or database and check which role has the user?
I have thought about creating a static list but my problem is that I have to enter ~1000 users in this list (I have about 20'000 users but only ~1000 have special roles). The solution is maybe to use the groups defined in the LDAP repository, you would have ~10 groups instead of ~1000 users in the static list. But in you have groups, you have to use a LDAP query to know if the authenticated user is in a group. It seems a bit complicated, no?
What do you think about the best practise?
Thanks Regards Sylvain
-----Message d'origine----- De: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Date: lundi, 1. septembre 2003 16:28 �: [EMAIL PROTECTED] Objet: RE: Cocoon 2.1 Authentication Bug? *Please* Help
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote:
OK, I understand the mechanism.
About the roles, since I used LDAP for the authentication I have a problem how to define the roles. By default the authentication uses the file sunrise-user.xml and the role is defined for each user inside this file. With LDAP authentication I retrieve the users from a LDAP repository and the role isn't defined in this repository. Have you an idea how I could define the role for each users?
I guess from the above that you don't have roles. So, I would give each user a default role and create a static list of roles with this one role.
HTH Carsten
