cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agsoftware.dnsalias.com>
Subject Re: Authentication framework - A new Action for multiple roles.
Date Sun, 18 May 2003 05:55:35 GMT
Hi Guido:

Thanks for take your time reading and commenting this crazy idea ;).

We can write a wiki page as the specification of this requirement. What
you think?

Comments below....

Guido Casper dijo:
> 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 :-)

Yep, many people is looking for this kind of solution. I hope the BIG
MASTER (Carsten) will thumb up this.  ;)

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

Good point. For the authorization we can make a similar interface as
authentication. That way it will be wise as you suggested.

The authorization Action will check if the user "is part of" the role that
the resource require to be processed.

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

We prefer to call it groups too. It sounds better to us. We wrote about
"roles", because this term was used into the authentication framework and
we dont want to break the defined concepts.

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

We are thinking about if is correct or not to store the "roles" into the
authentication context session. How much memory it will get?

This model can works well with small used websites, says some 10s or 100s
users, but what happen in a large used webapp with 10000s of users?

On the other way, retrieve this info from a database can be (but not
necesary MUST BE) slower. The memory will be used just a fraction of the
time as oposite. Well, but we need a wise architecture. we guess in
that.....

First we thought we can go in our own way, but after thinking a little
bit, we want to provide to others Cocoon users a standarization about this
issue. Similar as the authentication framework. The advantage is that the
code will be part of Cocoon and any enhancement will be avaliable for all.
We want to donate it in the worst case as an example of this.

Our intention is to deliver a solution to any kind of sites. If this
cannot be done then we will concentrate on small used webapps. By the way,
our applications runs into a Intranet environment. We have not more than
100-200 users. This is easily manageable. But what if we will have 1000s
of users? Or someone need it? That is the question in the implementation
design. Maybe someone can show us the path into this way.

But for now we can store the roles into the data element of the
authentication session context.

>
>>
>> THE NEW ACTION
>> 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 resource
> 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.

We already have <xsp-session:getxml> tag. It can get the values from the
session. I know many people does not like this tag, because in the future
will be a drastical change in how the sessions works. We will try to write
and XSP action to get advantage of the tag. Currently, I dont know if this
will work. But I hope it works. If not, we will find another way to do
that.

About a input module for the authentication framework will be cool! I
think it is a MUST in the current model. It will make easy many things.
>
> 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.
We agree.
>
>>
>> If there is a resultSet the action will return a map. Else it will
>> return a NULL map, the action fails.
>>
>> ADMIN OF USERS, ROLES and RESOURCES
>> ===================================
>> Here will go into the play some forms that will take serve as database
>> interface to the tables:
>>
>> USERS FORMS:
>>
>> Add user and give them the roles,
>> Edit user including enable or disable user, edit roles of the users.
>> Delete user.
>>
>> RESOURCES FORMS:
>> 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
>>
>> ROLES:
>> 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.

Yes, this forms are just a list of the forms we already have to interact
with the database. This is not too important. Sorry about the include of
this here. We are too database oriented. ;)
>
>>
Best Regards,
Antonio Gallardo




Mime
View raw message