Re: Security - AAA implementation [was RE: DefaultRoleManager in Cor nerstone]

[Michael McKibben <mi...@hihat.net>]

Isn't a group just another 'identity' and or 'principal'? I.e. I can map
group "users" to the role "userRole". Likewise I could just match the user
"user1" to the role "userRole". I think there is a misunderstanding on
terms.

Regards,

--mike

On Thu, 17 Jan 2002, Paul Hammant wrote:

> Larry, Peter,
> 
> 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.
> 
> I am +1 for it being used in AvalonDB*, but think the hosting for the 
> service/blocks should be in <cornerstone>src/java/ rather than 
> <cornerstone>apps/db/
> I also think we need to ping Rana (as he did much modelling for 
> FtpServer) and some folks from JAMES.
> 
> *Lastly, part of the original SQL dream (Codd's twelve rules?) was that 
> for user & metadata storage, it itself must be in tables.  I think a 
> common adaptation is for it to appear to be in tables.  It is more 
> compilcated than just having one block-impl to store these details.
> 
> Regards,
> 
> - Paul H
> 
> 
> 
> >Hello all,
> >
> >I am hoping to propose an implementation of AAA Security functionality for
> >Phoenix.
> >
> >Based on a breif discussion with Peter (below), the design would have a J2EE
> >flavor for roles-based access control.
> >
> >Some of the components to make up the implementation would be:
> >	* Identity Manager for access to user identity and attribute
> >information through disperate user registries.
> >	* Pluggable Realms to abstract the underlying user registry access -
> >initially XMLRealm, JDBCRealm, JNDIRealm
> >	* Role Manager for managing the mapping of identity principals to
> >roles/permissions
> >	* Authority Manager for making access decisions for specific users
> >to specific resources
> >	* Authentication Manager - verfies the identity of user against the
> >user registry - one concrete implementation would be an abstraction of the
> >use of JAAS.
> >	* Auditing Manager for recording relevant security related events
> >	* Administration interfaces to be exposed through JMX
> >
> >The initial test-bed will be the AvalonDB application.
> >
> >Any thoughts on this approach?
> >
> >Thanks,
> >
> >--Larry
> >
> >>-----Original Message-----
> >>From: Peter Donald [mailto:peter@apache.org]
> >>Sent: Sunday, January 13, 2002 3:36 AM
> >>To: Avalon Developers List
> >>Subject: Re: DefaultRoleManager in Cornerstone
> >>
> >>
> >>On Sun, 13 Jan 2002 16:08, MCCAY,LARRY (HP-NewJersey,ex2) wrote:
> >>
> >>>Peter,
> >>>
> >>>Is there still effort needed in the area of security?
> >>>
> >>yep ;)
> >>
> >>>I would be interested in helping here.
> >>>
> >>And we'd be interested in seeing you help here ;)
> >>
> >>Theres definetly some space there for you to make something 
> >>very useful. SOme 
> >>of the things that we have identified the need for in the past is
> >>
> >>* Identity Manager with pluggable Realms: ie basically list 
> >>of users and 
> >>some attributes about them (from generic attributes like 
> >>email address to 
> >>domain specific attributes). It would als be nice to be able to have 
> >>pluggable realms so that we could load users from the "Unix" 
> >>realm, NT 
> >>domain, properties files, xml files, database, ldap etc - Of 
> >>course you don't 
> >>need to do this all straight away ;)
> >>* RoleManager: Maps users/identitys to Roles - ie Fred is an 
> >>administrator, 
> >>Wilma is a user
> >>* Authority Manager: ie does role X have permission to do Y
> >>* Authentication Manager: ie essentially hookup with JAAS in 
> >>a flexible 
> >>manner.
> >>
> >>You will notice this has a sort of J2EE flavour - this was largely 
> >>intentional and theres probably lots more useful information 
> >>in the J2EE 
> >>Blueprints.
> >>
> >>I think Paul has looked at this sort of thing more recently. 
> >>If you are up 
> >>for having a go at this it may be interesting to integrate 
> >>this with DB or 
> >>the James server just to see test it out and all ;)
> >>
> >>-- 
> >>Cheers,
> >>
> >>Pete
> >>
> >>----------------------------------------
> >>Why does everyone always overgeneralize?
> >>----------------------------------------
> >>
> >>--
> >>To unsubscribe, e-mail:   
> >>
> ><ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >--
> >To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> >
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>