Agreed. > -----Original Message----- > From: Michael McKibben [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 17, 2002 6:22 PM > To: Avalon Developers List > Subject: Re: Security - AAA implementation [was RE: DefaultRoleManager > in Cor nerstone] > > > 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:[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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
