cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hochsteger <>
Subject Re: Cocoon 2.1 Authentication Bug? *Please* Help
Date Wed, 03 Sep 2003 19:42:39 GMT
Hi Sylvain! 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.

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.

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 

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.

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:
Especially this one explains it very well (you will have to click through):

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

	Andreas Hochsteger

> -----Message d'origine-----
> De: Andreas Hochsteger []
> Date: mercredi, 3. septembre 2003 07:12
> À:
> 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:
>>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?
>> wrote:
>>>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?
>>>-----Message d'origine-----
>>>De: Carsten Ziegeler []
>>>Date: lundi, 1. septembre 2003 16:28
>>>Objet: RE: Cocoon 2.1 Authentication Bug? *Please* Help
>>> [] 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.

View raw message