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

["MCCAY,LARRY (HP-NewJersey,ex2)" <la...@hp.com>]

Agreed.

> -----Original Message-----
> From: Michael McKibben [mailto:mike@hihat.net]
> 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: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>

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

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

[Paul Hammant <Pa...@yahoo.com>]

>
>
>Agreed.
>
I'm not so sure, However as it evolves I can speak up.  I happen to 
think that group is a better word as it expresses the reverse 
relationship better :

  "In the 'adminstrator' group are Berin, Peter, Stefano, and members of 
the 'PMC' group"

sounds better than :

  "Berin, Peter, Stefano and users with the 'PMC' role have the role of 
'adminstrator ' "

Regards,

- Paul



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