[ http://issues.apache.org/jira/browse/GERONIMO-454?page=all ]

Aaron Mulder updated GERONIMO-454:
----------------------------------

    Fix Version: 1.0
    Description: 
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.


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


    Environment: 

Not sure what the status of this is; we should probably consider it again after 
M5.

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

>
> 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://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to