cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Casper" <>
Subject Re: Authentication framework - A new Action for multiple roles.
Date Sat, 17 May 2003 17:52:04 GMT
Hi Antonio,

Antonio Gallardo wrote:
> Hi:
> Since we need to let more than one role to access the same resource.
> I was re-reading the docs about the authentication framework.
> The new action will allow to check permision on a user basis stored
> into the authentication context session.

I think this would be a useful addition to the authentication framework
(which should then be renamed to authentication and authorization framework

> We build 5 tables into our database:
> auth_users       - The users that can use the application.
> auth_roles       - Roles of the users.
> auth_users-roles - Relation between users and roles.
> auth_resources   - List of the protected resources
> auth_permissions - Relationship between roles and resources.

The first 3 tables (the authentication/usermanagement part) IMHO satisfy a
different concern than the latter 2 (authorization) and these should not be
intermingled (architecture wise; they can very well live in the same
database of course). The fact that these information come out of a database
should be abstracted out of the action anyway (like the AuthAction is doing
through the use of internal pipelines). That way you can easily integrate
with other authorization schemes/frameworks.

> As you see from the tables, this allow:
> 1 user can have ONE OR MORE roles
> 1 resource can be accessed by ONE OR MORE roles.

Yes, currently within the Authentication framework each user has a single
role. This sometimes leads to some confusion so maybe it would be better
named *group*.
There are however several use cases where such an approach is indeed needed
such that if you personalize your site based on group profiles (as opposed
to individual user profiles), as the portal framework allows you to do, for

But I agree that for certain authorization schemes it would be better to
have a user be assigned to several roles. This however is (in theory)
already possible with the authentication framework today.
Your authentication pipeline delivers the user id and the group of the
authenticated user which is then stored in the session within the
authentication context. You are however free to return any additional user
data as part of your authentication pipeline and this will be stored within
the authentication context as well. So you could use this to return any
assigned roles in addition to the user and the group.

> It will get:
> 1- The userid from the authentication session context, and
> 2- The "requested resource" from the processed "request"

This action could (and should IMHO) even be orthogonal to the authentication
framework as all these values:
- the userid
- the group
- a list of all assigned roles
- the requested ressource
could be supplied through the sitemap.

To get to the first 3 values however there is missing an authentication
input module :-) (This module ideally delivers the password as well, as this
would allow you to easily integrate 3rd-party applications in a
Single-Sign-On manner). The session input module is not enough since there
is no easy way to get to these values through JXPath, although they are
stored in the session.

That way you have as much as possible decoupled the way your users and roles
are managed from the way your authorization is managed. LDAP for example
manages you users and roles for you but has no idea about the meaning of a
particular role. Roles get their meaning through their use in individual
applications (which in turn could use the authorization components).

> Into the action we will do a simple SQL query that will find the
> relation between the userid and the resource.

Mostly this action would only need to find the relation between the role and
the resource. Since the authentication input modul delivers the userid (the
AuthAction already does this, i.e. delivering the userid and the group,
unfortunately named *role*) as well you are however free to use this
information as well.

> If there is a resultSet the action will return a map. Else it will
> return a NULL map, the action fails.
> ===================================
> Here will go into the play some forms that will take serve as database
> interface to the tables:
> Add user and give them the roles,
> Edit user including enable or disable user, edit roles of the users.
> Delete user.
> Add resources and define the roles that can access this resources.
> Edit resources, including enable/disable resources, edit defined roles
> that access to the resource.
> Delete resource
> Add role
> Edit role, including enable/disable role.
> Delete role.
> Well this is another use case for the authentication framework.
> What do you think about this approach, is this correct?
> Is posible to create another scenario without creating another action?
> I also posted these intro here because maybe we can found an approach
> to authenticate using LDAP or a Java class.

I don't understand. You can already authenticate against any pipeline like
one getting its values from LDAP.

> Best Regards,
> Antonio Gallardo



Guido Casper
S&N AG, Open Source Competence Center
                    Tel.: +49-5251-1581-87
Klingenderstr. 5
D-33100 Paderborn

View raw message