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 21:31:49 GMT
Guido Casper dijo:
> Antonio Gallardo wrote:
>>>> 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.
>
OK. I finally understand the point and I totally agree. Lets sumarize this:

1-We will load the roles to the authentication session context at the
authentication time. Example: The authentication context will look like:

<ID>userid</ID>
<data>
  <roles>
    <role>admin</role>
    <role>operator</role>
    <role>auditor</role>
    ....
  </roles>
</data>

This is allowed by the current authentication model. We are not breaking
any rule with this model. ;)

2-When we call the action it will have 3 parameters:

a) auth_handler - The authentication handler
b) keyword - A keyword that define the resource group we need to control.
c) check_roles - a resource for internal call. It will returns a list of
roles allowed to process a given keyword.

******************************
Can we ask to include the a "check_roles" property into the
authentication-fw configuration? Of course as a optional property.
Or it can be better to define it at <map:component-configurations>
******************************

The action will try to match the two roles list (roles of the users and
roles allowed to process the resources).
If it found a match then it returns: authentication:true.
Else it fails.

HOW THE ACTION WORKS:

A-The will check if the user is loggedIn using the Authentication Manager.
B-Action will call:

cocoon://check_roles?key=keyword

This resource must returns something like:

<permissions>
  <role>admin</role>
  <role>other role</role>
<permissions>

C-Validate the lists.

OTHER POSIBILITIES:
Another option:
At start time we can load a the list of roles res_key pairs and store it
in a DocumentFragment.
Pro: Memory acces is faster
Cons: Need to create a process that reload the paors when a user changes
the permissions.

Is in this way you think? BTW, I sent a mail with the first draft that
interact directly with the database. I done ir just to try if we can get
the info directly from the Authentication Manager. It works! ;)

please comments.

Best Regards,

Antonio Gallardo.



Mime
View raw message