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]>

Reply via email to