cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Casper" <gcas...@s-und-n.de>
Subject Re: Authentication framework - A new Action for multiple roles.
Date Sun, 18 May 2003 20:16:22 GMT
Antonio Gallardo wrote:
> 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?

I for myself won't object :-)

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

There is no need for it (I'll ask for his opinion however :-) as the
authentication components stay untouched. As I stated I believe the
authorization components should be orthogonal to the authentication
components.
That way when somebody comes up with an authentication input module for
container managed security for example, you could use the same authorization
components.

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

This is the only point I disagree.
The authorization action does not check if a user is part of a role. That is
the job of the authentication action. The authorization will only check
wether a particular role is allowed to perform the requested task.

Regards

Guido



Guido Casper
-------------------------------------------------
S&N AG, Open Source Competence Center
                    Tel.: +49-5251-1581-87
Klingenderstr. 5    mailto:gcasper@s-und-n.de
D-33100 Paderborn   http://www.s-und-n.de
-------------------------------------------------


Mime
View raw message