You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "MCCAY,LARRY (HP-NewJersey,ex2)" <la...@hp.com> on 2002/01/17 23:00:09 UTC
Security - AAA implementation [was RE: DefaultRoleManager in Cor
nerstone]
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>
Re: Security - AAA implementation [was RE: DefaultRoleManager in Cor nerstone]
Posted by Peter Donald <pe...@apache.org>.
On Fri, 18 Jan 2002 09:00, MCCAY,LARRY (HP-NewJersey,ex2) wrote:
> Hello all,
>
> I am hoping to propose an implementation of AAA Security functionality for
> Phoenix.
kool.
Just one thing though - what does AAA stand for? ;)
> 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
+1
> * Role Manager for managing the mapping of identity principals to
> roles/permissions
> * Authority Manager for making access decisions for specific users
> to specific resources
I am curious about this. Shouldn't the RoleManager map identitys to roles.
Then the AuthorityManager would manage permissions for a Role. In cases where
you need per-person permissions then you just add a unique role for the
identity?
> * 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
+1
> The initial test-bed will be the AvalonDB application.
>
> Any thoughts on this approach?
sounds good to me.
--
Cheers,
Pete
"The fact that a believer is happier than a skeptic is no more to the
point than the fact that a drunken man is happier than a sober one.
The happiness of credulity is a cheap and dangerous quality."
-- George Bernard Shaw
--
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 Cor nerstone]
Posted by Darrell DeBoer <li...@bigdaz.com>.
Hi,
> 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.
I've done some work on the "UserRepository" in JAMES, and it would be great
to migrate to a new, better, shared User Registry. So I'm +1 for putting it
in Cornerstone.
JAMES's requirements are pretty limited at the moment, but with the
evolution of the IMAP server we might need to store more sophisticated
User/Permission information. The IMAP4 ACL extension (rfc2086) provides
reasonably fine-grained access control on individual mailboxes - not sure
exactly how that will map to a generic AAA implementation.
I'm happy to help out where I can.
ciao
Daz
--
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 Cor nerstone]
Posted by Peter Donald <pe...@apache.org>.
On Fri, 18 Jan 2002 10:07, 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 think you are mixing up terminology here - at least in the Java/J2EE world.
That functionality is available it is just termed differently ;) In java the
group is just another principle. However a single person could have multiple
principles/identitys.
In JAAS this is explicitly represented by the Subject object. A Subject would
represent a particular user. That user may have different principles
associated with them.
For instance consider the Subject "Fred". If "Fred" logs in via SSH then he
aquires the SSHPrinciple, if "Fred" goes in via the biometric
scanners/detectors then he gets the GroovyBioMetricPrinciple, while if he
goes in via telnet he gets the WeenyTelnetPrinciple.
All these principles represent the same person/Subject. However it would be
possible to associate different sets of permissions with different
principles. ie If the GroovyBioMetricPrinciple is going to have a lot more
permissions than the WeenyTelnetPrinciple.
Anyhow if "Fred" the subject belongs to the "admin" group then that just
means "Fred" has the "admin" principle added to his subject.
I guess this is a bit complex. It may be a good idea not to require a mapping
between principles and Roles and make it possible to get permissions via
principle or role. Thoughts?
--
Cheers,
Pete
*------------------------------------------------------*
| "Common sense is the collection of prejudices |
| acquired by age 18. " -Albert Einstein |
*------------------------------------------------------*
--
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
Cor nerstone]
Posted by 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>
Re: Security - AAA implementation [was RE: DefaultRoleManager in Cor nerstone]
Posted by Paul Hammant <Pa...@yahoo.com>.
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>