geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <...@geronimo.apache.org>
Subject [jira] Commented: (GERONIMO-454) Support Group Name = Role Name Role Mapping
Date Sun, 19 Dec 2004 21:07:16 GMT
     [ http://nagoya.apache.org/jira/browse/GERONIMO-454?page=comments#action_56872 ]
     
David Jencks commented on GERONIMO-454:
---------------------------------------

After discussion with alan, we realized that the automapper gbean doesn't actually need to
do any computation, so the required info can be rearranged to be available from gbean attributes,
available when the gbean is loaded but stopped, at deployment time.  Also, the current runtime
use of the automap assistant to construct the default principal can be moved to deployment
time.  I'll look into implementing this.

It would be possible to move the automap configuration from the security realm into the applications
(xml) security configuration.  This would allow separate automap configuration per app (such
as different sets of automap principal classes).  This might be useful in some circumstances
and would simplify the deployment code but is likely to prove annoying in most common cases.
 This needs more thought.

> Support Group Name = Role Name Role Mapping
> -------------------------------------------
>
>          Key: GERONIMO-454
>          URL: http://nagoya.apache.org/jira/browse/GERONIMO-454
>      Project: Apache Geronimo
>         Type: Improvement
>   Components: deployment, security
>     Versions: 1.0-M2
>     Reporter: Aaron Mulder
>     Assignee: Alan Cabrera

>
> Currently, you must manually map principals to roles in the security component of a deployment
descriptor.  In the common case where group names match role names, this seems like unnecessary
overhead.
> Alan and I talked and our plan is to make the role-mapping parts of the security elements
look something like this:
> <security>
>   ...
>   <automatic-role-mapping>?
>     <principal-class>foo.GroupPrincipal</principal-class>*
>   </automatic-role-mapping>
>   <role-mapping>?
>     ...
>   </role-mapping>
> </security>
> The automatic-role-mapping is the new bit.  If you specify that element empty, it would
map every principal type the security realm considers to be a group to roles.  For example,
if you configure the seucrity realm to consider the principal class "foo.GroupPrincipal" as
a role, and use an empty automatic-role-mapping element, that's what you'd get.  You can also
manually specify one or more principal classes that should be automatically mapped to roles.
 In any of these cases, the "automatic" mapping is done based on the role name and group name
matching.
> If you specify automatic mapping *and* individual role mapping, then the user just needs
to qualify for the role based on either one or the other (not both).  So you could use a manual
role mapping to add eligible users on top of the automatic role mapping, but not to subtract
users from the automatic role mapping.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message