> So Role would be another principle? In effect you would do a 
> mapping from 
> "identity" principle to "ROle" principle and then just use 
> that?

Actually, I was thinking that the concept of role could be implemented in
policy by a collection of permissions.  Specifying the mapping between any
given principal - say a group principal representing membership to a group
called adminstrators - is mapped to a set of permissions within a given
policy context (application) thereby granting these permissions to any
Subject containing the AdministratorPrincipal - this collection of
permissions can be identified by name - which is basically role-name in J2EE
terms.

This approach removes the need for any actual "role" entity.

The mapping of the principals to permissions would be done in terms of
principal type and value to necessary permissions within a given policy
context (application) and accomplished through the administrative interface
exposed through JMX.

This is very much in line with the JSR 115 effort - which is in community
draft, currently.  Providing this JSR is successful, compliance would enable
the ability to plug in arbitrary authorization providers.

http://www.jcp.org/jsr/detail/115.jsp

BTW - AAA is Authentication, Authorization and Administration - I usually
add a fourth - Auditing.

:-)

> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 17, 2002 6:57 PM
> To: Avalon Developers List
> Subject: Re: Security - AAA implementation [was RE: DefaultRoleManager
> in Cor nerstone]
> 
> 
> On Fri, 18 Jan 2002 10:29, MCCAY,LARRY (HP-NewJersey,ex2) wrote:
> > > I'd be much keener on 'group' than 'role' per se.  A user
> > > belongs to one
> > > or more groups.  Groups can belong to groups.  Some groups can be
> > > mandatory and considered as roles.
> > > I can't remember where I first encoutered this design.
> > > Nearly a decade
> > > on AS/400's I guess.
> >
> > Perhaps, the RoleManager should really be PermissionManager 
> - in the end a
> > role can be represented by a permission collection.  A permission
> > collection can be associated with any arbitrary principal, including
> > identity and group principals.  Within the spirit of J2EE 
> we can still
> > support an abstraction of role-based access control - 
> implemented without
> > any actual role per se.
> 
> So Role would be another principle? In effect you would do a 
> mapping from 
> "identity" principle to "ROle" principle and then just use 
> that? I like that.
> 
> -- 
> Cheers,
> 
> Pete
> 
> -----------------------------------------------------------
>  "Remember, your body is a temple; however, it's also your 
>  dancehall and bowling alley"   -- Dharma Montgomery
> -----------------------------------------------------------
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to