cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hochsteger Andreas /INFO-MA <Andreas.Hochste...@oeamtc.at>
Subject Re: Cocoon 2.1 Authentication Bug? *Please* Help
Date Thu, 04 Sep 2003 06:52:26 GMT
Hi Silvain!

Sorry for replying to myself, but I have to correct one statement I did:
'groupOfUniqueNames' is not an attribute but rather an objectClass on it's
own.
You can view it here:
http://ldap.akbkhome.com/objectclasstree/groupOfUniqueNames.html
(again you have to click through with the link above the coments since you
always com to a start page first, no matter what URL you use :-(

Credit goes to Guido Casper, who advised me about that.

As I said before, I'm no LDAP expert ;-)

Bye,
	Andreas

> -----Original Message-----
> From: Hochsteger Andreas /INFO-MA 
> Sent: Thursday, September 04, 2003 8:45 AM
> To: Andreas Hochsteger (E-Mail 2)
> Subject: 
> 
> 
> Hi Sylvain!
> 
> Sylvain.Thevoz@swisscom.com 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.htm
> l#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:e9625392@student.tuwien.ac.at]
> > Date: mercredi, 3. septembre 2003 07:12
> > @: dev@cocoon.apache.org
> > 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
> >>
> >>Sylvain.Thevoz@swisscom.com 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:cziegeler@s-und-n.de]
> >>>Date: lundi, 1. septembre 2003 16:28
> >>>@: dev@cocoon.apache.org
> >>>Objet: RE: Cocoon 2.1 Authentication Bug? *Please* Help
> >>>
> >>>
> >>>Sylvain.Thevoz@swisscom.com 
[mailto:Sylvain.Thevoz@swisscom.com] 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
>>>
>>
>>
>>
> 
> 



Mime
View raw message