Hello Andreas, Thanks for your explanation. I'll try to explain my situation too:
Background ---------- I'm working for Swisscom, the swiss phone company. There are about 20'000 employees (about 2'000 in IT department). My "clients" are the Swisscom employees. The purpose of my project is to allow Swisscom employees to access to some web applications concerning their computers through a portal. Organization of groups ---------------------- The employees have lot of attributes in the Active Directory system (LDAP structure). There are plenty of groups of users and groups of groups. It's really an hudge and very complicated structure. Authentication -------------- I have chosen the Cocoon portal. I have replaced the default authentication (users were stored inside a XML file) by a LDAP authentication. When you try to enter inside the portal, a LDAP query is sent to the Active Directory system where all the Swisscom employees are stored. If the query returns a response (you exist in the active directory system), you are able to enter inside the portal. If not, there is an error page. Authorization ------------- That's my problem! To know if a certain user is allowed to access to a certain part of the portal I have decided that each user has a certain role (Admin, simple user, ...). This role information is already implemented in the Cocoon portal. The "ideal" solution would be to store the role information inside the Active Directory system (the LDAP repository) but that's not possible for me because I'm not able to modify this system. The other solution is to store each user with its role inside a database. The problem here is that there are about 20'000 users to enter and to manage. So I'm looking for a solution... A possible solution would be to create my own LDAP repository, replicate the authentication information from the Active Directory system and add a role information for each user. How do you replicate your Active Directory structure and at which frequency? Are the information always up-to-date? Regards Sylvain -----Message d'origine----- De: Andreas Hochsteger [mailto:[EMAIL PROTECTED] Date: mercredi, 3. septembre 2003 21:43 �: [EMAIL PROTECTED] Objet: Re: Cocoon 2.1 Authentication Bug? *Please* Help Hi Sylvain! [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 >>> >> >> >> > >
