> 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.
> 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/ Agreed. > I also think we need to ping Rana (as he did much modelling for > FtpServer) and some folks from JAMES. Will do. > *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. True. I was thinking about a specialized Realm for use with AvalonDB - which would be hosted with DB. Thanks for the feedback, --Larry > -----Original Message----- > From: Paul Hammant [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 17, 2002 6:08 PM > To: Avalon Developers List > Subject: Re: Security - AAA implementation [was RE: DefaultRoleManager > in Cor nerstone] > > > 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:[EMAIL PROTECTED]] > >>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: > >> > ><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]> > > > > > > > > > > > -- > 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]>
