You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/01/25 20:02:06 UTC
[Triplesec] Permissions, Roles and Groups
Hello,
I would like to have a discussion on the meaning of these entities in
general and with respect to how they are modeled in Triplesec today in
the trunk:
o Permissions
o Roles
o Groups
I've been talking to djencks about this stuff for a bit now as we have
started working together on various aspects of Triplesec. I'd like to
have a general discussion about these concepts here so we can all be on
the same page with what they are. Let me kick this off.
Permissions
===========
To me a permission is a right that is granted to access a resource or
perform some kind of protected operation. To a large degree the
semantics of permissions are undefined except within a specific
application. For example the permission to accessPayroll may not have
much meaning outside of an application dealing with payroll management.
In Triplesec (trunk) a permission is just a label without any meaning.
The semantics of the permission is left up to the application to define.
Roles
=====
A Role is a collection of permissions associated together to represent
the rights need by one to perform the actions or activities of a
function. For our purposes we can just say a role is a collection of
permissions.
As a collection of permissions which are application specific, roles
themselves become application specific.
In Triplesec (trunk) a role is just a collection of granted permissions
with a name. Roles entries in Triplesec have a SINGLE-VALUED 'roleName'
and a MULTI-VALUED 'grants' attribute. You just add the names of
permissions to a role entry to add them to the role.
Groups
======
Although you can group anything I think we're talking more about groups
of users in this context. Groups are primarily used to make
administration tasks easier. By grouping people and the can be managed
as a single group rather than performing the same upkeep operations on
all the members of the group.
In Triplesec a group is a static LDAP group (groupOfUniqueNames) or user
DNs right now. We may expand this to include dynamic groups in the future.
Thoughts? Corrections?
Alex
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
David,
I'm going through your thoughts.
Could you please help me understand when it makes
sense
to have overlapping permissions. Since Java has it,
I'm sure there must be a good reason, I'm just having
a tricky time coming up with one myself :-) Seems
like permissions should always be atomic, aggregated
by role when necessary.
Thanks,
- Ole
--- David Jencks <da...@yahoo.com> wrote:
> Ersin pointed me to a very interesting paper
> http://csrc.nist.gov/
> rbac/rbacSTD-ACM.pdf that has considerably
> influenced my ideas on
> where tsec should head, and some of the ideas from
> that paper are (I
> hope) represented in my comments below.
>
> On Jan 25, 2007, at 11:02 AM, Alex Karasulu wrote:
>
> > Hello,
> >
> > I would like to have a discussion on the meaning
> of these entities
> > in general and with respect to how they are
> modeled in Triplesec
> > today in the trunk:
> >
> > o Permissions
> > o Roles
>
> I think these are useful abstractions
> > o Groups
>
> I don't think groups are a useful abstraction if you
> have the right
> kind of roles.
>
> I also don't think it's possible to discuss this
> subject without also
> including Users and User-Role associations.
>
> >
> > I've been talking to djencks about this stuff for
> a bit now as we
> > have started working together on various aspects
> of Triplesec. I'd
> > like to have a general discussion about these
> concepts here so we
> > can all be on the same page with what they are.
>
> To me, we get to define our terms, and then they
> mean what we say the
> mean. I don't see any of these concepts as having
> an immutable
> meaning outside what we want the system to do.
>
> Also to set the context here, I think the overall
> goal is to start
> with something representing the identity of a person
> using the
> system, possibly some other description of the
> activities they wish
> to perform, and determine what they are allowed to
> do in the system.
>
> > Let me kick this off.
> >
> > Permissions
> > ===========
> >
> > To me a permission is a right that is granted to
> access a resource
> > or perform some kind of protected operation. To a
> large degree the
> > semantics of permissions are undefined except
> within a specific
> > application. For example the permission to
> accessPayroll may not
> > have much meaning outside of an application
> dealing with payroll
> > management.
> >
> > In Triplesec (trunk) a permission is just a label
> without any
> > meaning. The semantics of the permission is left
> up to the
> > application to define.
>
> I basically agree with this, the label is a
> meaningless abstract
> identifier. We do need to make sure we can attach
> more information
> to the label for specific uses, e.g. attaching
> sufficient information
> to construct a java permission for use in java apps.
> I've done this
> in sandbox/triplesec-jacc2.
> >
> > Roles
> > =====
> >
> > A Role is a collection of permissions associated
> together to
> > represent the rights need by one to perform the
> actions or
> > activities of a function. For our purposes we can
> just say a role
> > is a collection of permissions.
> >
> > As a collection of permissions which are
> application specific,
> > roles themselves become application specific.
> >
> > In Triplesec (trunk) a role is just a collection
> of granted
> > permissions with a name. Roles entries in
> Triplesec have a SINGLE-
> > VALUED 'roleName' and a MULTI-VALUED 'grants'
> attribute. You just
> > add the names of permissions to a role entry to
> add them to the role.
>
> This is really making a big assumption about the
> meaning of
> permissions, namely that they aren't overlapping in
> any way, so that
> to deny a permission you just remove it from the set
> of granted
> permissions. If permissions overlap, as java
> permissions can, you
> really need to be able to deny permissions as well.
> So you need to
> have roles have a set of granted permissions and a
> set of denied
> permissions.
>
> Furthermore, as suggested in the NIST paper,
> hierarchical roles
> provide great power and convenience for
> administering roles and
> permissions. They're fairly trivial to implement in
> terms of the
> data model, and you don't have to use them if you
> don't want to. So
> I'd say a role is <name, grantsSet, denialsSet,
> rolesSet}
>
> Note that with this role model, you can easily
> represent any
> combination of existing roles, with individualized
> tweaks, as another
> role. Therefore we can represent any set of
> permissions as a role.
> To avoid duplication of concepts we should represent
> every
> interesting set of permissions as a role.
>
> Very little I have to say makes sense if you
> disagree with this....
> the following is predicated entirely on this model
> of a role. If you
> don't agree, stop here and lets talk about why.
>
> >
> > Groups
> > ======
> >
> > Although you can group anything I think we're
> talking more about
> > groups of users in this context. Groups are
> primarily used to make
> > administration tasks easier. By grouping people
> and the can be
> > managed as a single group rather than performing
> the same upkeep
> > operations on all the members of the group.
> >
> > In Triplesec a group is a static LDAP group
> (groupOfUniqueNames) or
> > user DNs right now. We may expand this to include
> dynamic groups
> > in the future.
> >
>
> OK, here's where we part company :-) As the nist
> paper points out,
> the idea of groups is a precursor to the idea of
> general RBAC. We
> definitely need a concept of identity (user), and we
> definitely need
> a concept of set of permissions (role), and we
> definitely need a
> concept of associating these two. Alex is proposing
> at least two
> mechanisms for associating a user and a set of
> permissions. I'm not
> happy with any of the existing associations and
> think we can do better.
>
> I think these are the requirements:
>
> each user can be associated with several sets of
> permissions (roles)
> each set of permissions (role) can be associated
> with several users
> at any time, at most one role can be active for a
> user
>
> If we had a relational database this would be pretty
> easy to model --
>
=== message truncated ===
____________________________________________________________________________________
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
Yeah - The hierarchical role stuff sounds like a must
have.
+1
--- David Jencks <da...@yahoo.com> wrote:
> Ersin pointed me to a very interesting paper
> http://csrc.nist.gov/
> rbac/rbacSTD-ACM.pdf that has considerably
> influenced my ideas on
> where tsec should head, and some of the ideas from
> that paper are (I
> hope) represented in my comments below.
>
> On Jan 25, 2007, at 11:02 AM, Alex Karasulu wrote:
>
> > Hello,
> >
> > I would like to have a discussion on the meaning
> of these entities
> > in general and with respect to how they are
> modeled in Triplesec
> > today in the trunk:
> >
> > o Permissions
> > o Roles
>
> I think these are useful abstractions
> > o Groups
>
> I don't think groups are a useful abstraction if you
> have the right
> kind of roles.
>
> I also don't think it's possible to discuss this
> subject without also
> including Users and User-Role associations.
>
> >
> > I've been talking to djencks about this stuff for
> a bit now as we
> > have started working together on various aspects
> of Triplesec. I'd
> > like to have a general discussion about these
> concepts here so we
> > can all be on the same page with what they are.
>
> To me, we get to define our terms, and then they
> mean what we say the
> mean. I don't see any of these concepts as having
> an immutable
> meaning outside what we want the system to do.
>
> Also to set the context here, I think the overall
> goal is to start
> with something representing the identity of a person
> using the
> system, possibly some other description of the
> activities they wish
> to perform, and determine what they are allowed to
> do in the system.
>
> > Let me kick this off.
> >
> > Permissions
> > ===========
> >
> > To me a permission is a right that is granted to
> access a resource
> > or perform some kind of protected operation. To a
> large degree the
> > semantics of permissions are undefined except
> within a specific
> > application. For example the permission to
> accessPayroll may not
> > have much meaning outside of an application
> dealing with payroll
> > management.
> >
> > In Triplesec (trunk) a permission is just a label
> without any
> > meaning. The semantics of the permission is left
> up to the
> > application to define.
>
> I basically agree with this, the label is a
> meaningless abstract
> identifier. We do need to make sure we can attach
> more information
> to the label for specific uses, e.g. attaching
> sufficient information
> to construct a java permission for use in java apps.
> I've done this
> in sandbox/triplesec-jacc2.
> >
> > Roles
> > =====
> >
> > A Role is a collection of permissions associated
> together to
> > represent the rights need by one to perform the
> actions or
> > activities of a function. For our purposes we can
> just say a role
> > is a collection of permissions.
> >
> > As a collection of permissions which are
> application specific,
> > roles themselves become application specific.
> >
> > In Triplesec (trunk) a role is just a collection
> of granted
> > permissions with a name. Roles entries in
> Triplesec have a SINGLE-
> > VALUED 'roleName' and a MULTI-VALUED 'grants'
> attribute. You just
> > add the names of permissions to a role entry to
> add them to the role.
>
> This is really making a big assumption about the
> meaning of
> permissions, namely that they aren't overlapping in
> any way, so that
> to deny a permission you just remove it from the set
> of granted
> permissions. If permissions overlap, as java
> permissions can, you
> really need to be able to deny permissions as well.
> So you need to
> have roles have a set of granted permissions and a
> set of denied
> permissions.
>
> Furthermore, as suggested in the NIST paper,
> hierarchical roles
> provide great power and convenience for
> administering roles and
> permissions. They're fairly trivial to implement in
> terms of the
> data model, and you don't have to use them if you
> don't want to. So
> I'd say a role is <name, grantsSet, denialsSet,
> rolesSet}
>
> Note that with this role model, you can easily
> represent any
> combination of existing roles, with individualized
> tweaks, as another
> role. Therefore we can represent any set of
> permissions as a role.
> To avoid duplication of concepts we should represent
> every
> interesting set of permissions as a role.
>
> Very little I have to say makes sense if you
> disagree with this....
> the following is predicated entirely on this model
> of a role. If you
> don't agree, stop here and lets talk about why.
>
> >
> > Groups
> > ======
> >
> > Although you can group anything I think we're
> talking more about
> > groups of users in this context. Groups are
> primarily used to make
> > administration tasks easier. By grouping people
> and the can be
> > managed as a single group rather than performing
> the same upkeep
> > operations on all the members of the group.
> >
> > In Triplesec a group is a static LDAP group
> (groupOfUniqueNames) or
> > user DNs right now. We may expand this to include
> dynamic groups
> > in the future.
> >
>
> OK, here's where we part company :-) As the nist
> paper points out,
> the idea of groups is a precursor to the idea of
> general RBAC. We
> definitely need a concept of identity (user), and we
> definitely need
> a concept of set of permissions (role), and we
> definitely need a
> concept of associating these two. Alex is proposing
> at least two
> mechanisms for associating a user and a set of
> permissions. I'm not
> happy with any of the existing associations and
> think we can do better.
>
> I think these are the requirements:
>
> each user can be associated with several sets of
> permissions (roles)
> each set of permissions (role) can be associated
> with several users
> at any time, at most one role can be active for a
> user
>
> If we had a relational database this would be pretty
> easy to model --
>
=== message truncated ===
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
Yeah this is really good stuff!
Thanks Guys!
--- Emmanuel Lecharny <el...@gmail.com> wrote:
> David Jencks a écrit :
>
> >
> > On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny
> wrote:
> >
> >> Ole Ersoy a écrit :
> >>
> >>> OK - So if we have aggregate roles /
> hierarchical
> >>> roles, we can elliminate the concept of groups.
> >>>
> >>> Groovy.
> >>>
> >>>
> >> AFAIK, groups are very cool to have if you deal
> with more than one
> >> application. Roles will be Application related,
> and groups will be
> >> more Users related.
> >>
> >> Those two elements are pretty close, but their
> semantics are
> >> different, if I understand.
> >
> >
> > OK, so I was hoping to delay getting into this
> additional issue.....
> >
> > Would you agree that if there's only one
> "application" then groups +
> > role <> group assigment is equivalent to the
> direct user<>role
> > association I was talking about although looked at
> from the opposite
> > direction?
> >
> > For jacc we need some kind of idea of groups of
> applications. I
> > implemented this by allowing multiple
> appName=foo,appName=bar,.... in
> > dns, in sandbox/triplesec-jacc2. You can have any
> level of nesting
> > you want, but for jacc you need 2 levels
> (application and context
> > within the app). I can see having groups of
> applications you want to
> > administer at once, for instance a portal app
> together with a bunch
> > of portlet apps deployed on the portal. So I can
> see a use for 3
> > levels.
> >
> > So what I was actually thinking of is that within
> a group of
> > applications you'd want all the role names to be
> the same. The
> > permissions would still be associated with a
> particular "leaf"
> > application (context for my jacc example) but
> you'd expect to have
> > the same role names within each sub-applications.
> Then you'd have
> > the user <> role association at the level of the
> group of
> > applications that you wanted to deal with
> together.
> >
> > There might still be some difference.... I'm not
> sure.
>
> Well, I think here we are just playing with semantic
> :)
>
> All in all, I really think those things are very
> similar. You can
> perfectly manage the so called 'groups' within a
> hierarchy of roles.
>
> Now, let's talk about real life, I mean, you know,
> those big companies
> with an IT management which does not manage anything
> but budgets... They
> just stack applications, and ask poor admin to
> manage roles,
> permissions, grants and deny, and of course all
> those applications
> aren't compatible or does not use the same
> semantics.
>
> This is a problem. Let say that when using 'groups',
> you allow a sort of
> flexibility, and you help an administrator to create
> a feeling of
> comfort (it's easy to create a group called
> 'accountant' including
> people allowed to access SAP, SAS and some kind of
> web application. The
> 'roles' will be defined application by application.
> )
>
> At this point, real life example could help to
> understand the concept of
> chaos and babelization we are faced with...
>
> But, yes, a role hierarchy seems pretty ok if you
> can manage it. And
> Groups are also another way to do it, with different
> names. IMHO.
>
> Ok, I have to further my thinking about all this
> sh*t I just wrote, and
> maybe tomorow, after a full night, ideas will be
> clearer :)
>
> Anyway, this is important concepts and this convo is
> really important.
> Thanks Alex, David, Ersin and Ole !
>
> Emmanuel
>
> >
> > thanks
> > david jencks
> >
> >
> >>
> >> Emmanuel
> >
> >
> >
>
>
____________________________________________________________________________________
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
Enrique,
Lots of good points there, especially with respect to
ticket expiration.
Just one thing though.
Suppose we have an administrator that wants to
assign joe, harry, and sally the same role.
If we have a hierarchy of users, then joe, harry, and
sally can be grouped at a node above the
user level, where all the individual user nodes are.
Then the administrator just assigns the the role to
that group.
Thoughts?
Cheers,
- Ole
--- Enrique Rodriguez <en...@gmail.com> wrote:
> I finally got a chance to read the NIST RBAC paper
> and catch up on
> this thread. In general I like the approach in the
> paper and I really
> like that it gives a spec to base work on. More
> inline.
>
> On 1/26/07, David Jencks <da...@yahoo.com>
> wrote:
> ...
> > Another possibility is to have more roles. So far
> we have been
> > saying roles are associated with the smallest
> application component
> > we are modeling: in the original tsec model that's
> just the
> > application, in the sandbox test data a
> sub-application. We could
> > have roles at any level of the application
> hierarchy and they could
> > include as sub-roles roles at that level and finer
> levels. So for
> > the j2ee example, you could have a "top level"
> ADMIN role that
> > included the variously named admin roles from each
> application. Then
> > you could assign users individually to this top
> level role.
>
> IMO, matching the paper and what I think is David's
> opinion, we don't
> need to model Groups as anything different from
> Roles. An application
> might ship with Roles and enterprise admins will
> want to define their
> own Roles. In both cases they are modeled the same,
> but, to
> Emmanuel's point, we may still call the
> enterprise-defined Role a
> Group in the admin UI to alleviate confusion.
>
> Incidentally, the OSGi UserAdmin service comes to a
> similar
> conclusion, in that Group inherits from Role. I'm
> curious if the spec
> authors read up on RBAC.
>
> > I haven't been able to imagine the user experience
> of administrating
> > either this model or the group model :-) We might
> need both.
>
> Again, it seems to me to be a matter more of UI.
>
> > I'm really glad we're having this discussion on
> the mailing list!
>
> Yeah, it's great to see "authorization" picking up.
> I have 2 items of
> "food for thought."
>
> 1) The paper states, on p.17:
>
> "... permissions do not persist beyond the time that
> they are required
> for performance of duty. This aspect of least
> privilege is often
> referred to as timely revocation of trust. Dynamic
> revocation of
> permissions can be a rather complex issue without
> the facilities of
> dynamic separation of duty, and as such it has been
> generally ignored
> in the past for reasons of expediency."
>
> Eventually we'll come to the issue of how access
> control is
> communicated. The Guardian approach was LDAP
> queries. The Kerberos
> model is for Tickets to contain Authorization
> payload, which is what
> Microsoft uses to great success in the enterprise.
> Authorization
> "dies" when the ticket expires, governed by Kerberos
> Ticket lifetime,
> which is roughly analogous to the NIST-RBAC concept
> of SESSION. Also,
> Kerberos is naturally "service oriented," in that
> Tickets are given
> out for access to a service, which in the NIST-RBAC
> model is, I think,
> an "OBJS data set" aka application.
>
> 2) One of the key capabilities of Greg Wettstein's
> IDFusion is to
> physically separate the authentication store from
> the authorization
> store, limiting the damage caused by a compromise.
> I realize
> integrating all of this is way down the road, but I
> think this is a
> key point not immediately obvious from his work.
>
> Enrique
>
____________________________________________________________________________________
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
Re: [Triplesec] Permissions, Roles and Groups
Posted by Enrique Rodriguez <en...@gmail.com>.
I finally got a chance to read the NIST RBAC paper and catch up on
this thread. In general I like the approach in the paper and I really
like that it gives a spec to base work on. More inline.
On 1/26/07, David Jencks <da...@yahoo.com> wrote:
...
> Another possibility is to have more roles. So far we have been
> saying roles are associated with the smallest application component
> we are modeling: in the original tsec model that's just the
> application, in the sandbox test data a sub-application. We could
> have roles at any level of the application hierarchy and they could
> include as sub-roles roles at that level and finer levels. So for
> the j2ee example, you could have a "top level" ADMIN role that
> included the variously named admin roles from each application. Then
> you could assign users individually to this top level role.
IMO, matching the paper and what I think is David's opinion, we don't
need to model Groups as anything different from Roles. An application
might ship with Roles and enterprise admins will want to define their
own Roles. In both cases they are modeled the same, but, to
Emmanuel's point, we may still call the enterprise-defined Role a
Group in the admin UI to alleviate confusion.
Incidentally, the OSGi UserAdmin service comes to a similar
conclusion, in that Group inherits from Role. I'm curious if the spec
authors read up on RBAC.
> I haven't been able to imagine the user experience of administrating
> either this model or the group model :-) We might need both.
Again, it seems to me to be a matter more of UI.
> I'm really glad we're having this discussion on the mailing list!
Yeah, it's great to see "authorization" picking up. I have 2 items of
"food for thought."
1) The paper states, on p.17:
"... permissions do not persist beyond the time that they are required
for performance of duty. This aspect of least privilege is often
referred to as timely revocation of trust. Dynamic revocation of
permissions can be a rather complex issue without the facilities of
dynamic separation of duty, and as such it has been generally ignored
in the past for reasons of expediency."
Eventually we'll come to the issue of how access control is
communicated. The Guardian approach was LDAP queries. The Kerberos
model is for Tickets to contain Authorization payload, which is what
Microsoft uses to great success in the enterprise. Authorization
"dies" when the ticket expires, governed by Kerberos Ticket lifetime,
which is roughly analogous to the NIST-RBAC concept of SESSION. Also,
Kerberos is naturally "service oriented," in that Tickets are given
out for access to a service, which in the NIST-RBAC model is, I think,
an "OBJS data set" aka application.
2) One of the key capabilities of Greg Wettstein's IDFusion is to
physically separate the authentication store from the authorization
store, limiting the damage caused by a compromise. I realize
integrating all of this is way down the road, but I think this is a
key point not immediately obvious from his work.
Enrique
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
Sorry - Group Hiearchy, should actually be "User
Hierarchy" below
--- Ole Ersoy <ol...@yahoo.com> wrote:
> Here's a set of developer / administrator use cases
> that might help:
>
>
>
> Challenge
>
> Assigning a role to a single user.
>
> Solution
>
> Combine a role from the permission hiearchy,
> with the user (Which is a node at the
> lowest level of the user hierarchy)
>
>
> Challenge
>
> Assigning a permission to a group.
>
> Solution
>
> Combine the permission (Which is a node at
> the lowest level of the permission hiearchy)
> with the group (Which is a node above the
> lowest
> level in the group hierarchy)
>
> And so on and so forth. I could keep going, but
> I'm sure you see the pattern. There is a tree
> representing aggregated permissions. A tree
> representing aggregated users. And one for
> aggregated
> permission targets or URIs. When 3 nodes from each
> of
> these trees are combined, it forms a complete
> picture
> of what a user is allowed to do.
>
> Cheers,
> - Ole
>
>
>
>
>
>
>
>
>
> --- David Jencks <da...@yahoo.com> wrote:
>
> >
> > On Jan 25, 2007, at 5:08 PM, Emmanuel Lecharny
> > wrote:
> >
> > > David Jencks a écrit :
> > >
> > >>
> > >> On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny
> > wrote:
> > >>
> > >>> Ole Ersoy a écrit :
> > >>>
> > >>>> OK - So if we have aggregate roles /
> > hierarchical
> > >>>> roles, we can elliminate the concept of
> groups.
> > >>>>
> > >>>> Groovy.
> > >>>>
> > >>>>
> > >>> AFAIK, groups are very cool to have if you
> deal
> > with more than
> > >>> one application. Roles will be Application
> > related, and groups
> > >>> will be more Users related.
> > >>>
> > >>> Those two elements are pretty close, but their
> > semantics are
> > >>> different, if I understand.
> > >>
> > >>
> > >> OK, so I was hoping to delay getting into this
> > additional issue.....
> > >>
> > >> Would you agree that if there's only one
> > "application" then groups
> > >> + role <> group assigment is equivalent to the
> > direct user<>role
> > >> association I was talking about although looked
> > at from the
> > >> opposite direction?
> > >>
> > >> For jacc we need some kind of idea of groups of
> > applications. I
> > >> implemented this by allowing multiple
> > appName=foo,appName=bar,....
> > >> in dns, in sandbox/triplesec-jacc2. You can
> > have any level of
> > >> nesting you want, but for jacc you need 2
> levels
> > (application
> > >> and context within the app). I can see having
> > groups of
> > >> applications you want to administer at once,
> for
> > instance a
> > >> portal app together with a bunch of portlet
> apps
> > deployed on the
> > >> portal. So I can see a use for 3 levels.
> > >>
> > >> So what I was actually thinking of is that
> within
> > a group of
> > >> applications you'd want all the role names to
> be
> > the same. The
> > >> permissions would still be associated with a
> > particular "leaf"
> > >> application (context for my jacc example) but
> > you'd expect to
> > >> have the same role names within each
> > sub-applications. Then
> > >> you'd have the user <> role association at the
> > level of the group
> > >> of applications that you wanted to deal with
> > together.
> > >>
> > >> There might still be some difference.... I'm
> not
> > sure.
> > >
> > > Well, I think here we are just playing with
> > semantic :)
> > >
> > > All in all, I really think those things are very
> > similar. You can
> > > perfectly manage the so called 'groups' within a
> > hierarchy of roles.
> > >
> > > Now, let's talk about real life, I mean, you
> know,
> > those big
> > > companies with an IT management which does not
> > manage anything but
> > > budgets... They just stack applications, and ask
> > poor admin to
> > > manage roles, permissions, grants and deny, and
> of
> > course all those
> > > applications aren't compatible or does not use
> the
> > same semantics.
> > >
> > > This is a problem. Let say that when using
> > 'groups', you allow a
> > > sort of flexibility, and you help an
> administrator
> > to create a
> > > feeling of comfort (it's easy to create a group
> > called 'accountant'
> > > including people allowed to access SAP, SAS and
> > some kind of web
> > > application. The 'roles' will be defined
> > application by application. )
> > >
> > > At this point, real life example could help to
> > understand the
> > > concept of chaos and babelization we are faced
> > with...
> > >
> > > But, yes, a role hierarchy seems pretty ok if
> you
> > can manage it.
> > > And Groups are also another way to do it, with
> > different names. IMHO.
> > >
> > > Ok, I have to further my thinking about all this
> > sh*t I just wrote,
> > > and maybe tomorow, after a full night, ideas
> will
> > be clearer :)
> >
> > So I think I am starting to see something about
> the
> > purpose of
> > groups.....
> >
> > suppose you have 10 applications you have to
> manage
> > security to at
> > the same time, and they are j2ee apps from
> different
> > vendors, so they
> > all come with different built-in role names which
> > however mean
> > similar things, such as admin, ADM, Administrator,
> > etc etc. Now you
>
=== message truncated ===
____________________________________________________________________________________
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
Here's a set of developer / administrator use cases
that might help:
Challenge
Assigning a role to a single user.
Solution
Combine a role from the permission hiearchy,
with the user (Which is a node at the
lowest level of the user hierarchy)
Challenge
Assigning a permission to a group.
Solution
Combine the permission (Which is a node at
the lowest level of the permission hiearchy)
with the group (Which is a node above the lowest
level in the group hierarchy)
And so on and so forth. I could keep going, but
I'm sure you see the pattern. There is a tree
representing aggregated permissions. A tree
representing aggregated users. And one for aggregated
permission targets or URIs. When 3 nodes from each of
these trees are combined, it forms a complete picture
of what a user is allowed to do.
Cheers,
- Ole
--- David Jencks <da...@yahoo.com> wrote:
>
> On Jan 25, 2007, at 5:08 PM, Emmanuel Lecharny
> wrote:
>
> > David Jencks a écrit :
> >
> >>
> >> On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny
> wrote:
> >>
> >>> Ole Ersoy a écrit :
> >>>
> >>>> OK - So if we have aggregate roles /
> hierarchical
> >>>> roles, we can elliminate the concept of groups.
> >>>>
> >>>> Groovy.
> >>>>
> >>>>
> >>> AFAIK, groups are very cool to have if you deal
> with more than
> >>> one application. Roles will be Application
> related, and groups
> >>> will be more Users related.
> >>>
> >>> Those two elements are pretty close, but their
> semantics are
> >>> different, if I understand.
> >>
> >>
> >> OK, so I was hoping to delay getting into this
> additional issue.....
> >>
> >> Would you agree that if there's only one
> "application" then groups
> >> + role <> group assigment is equivalent to the
> direct user<>role
> >> association I was talking about although looked
> at from the
> >> opposite direction?
> >>
> >> For jacc we need some kind of idea of groups of
> applications. I
> >> implemented this by allowing multiple
> appName=foo,appName=bar,....
> >> in dns, in sandbox/triplesec-jacc2. You can
> have any level of
> >> nesting you want, but for jacc you need 2 levels
> (application
> >> and context within the app). I can see having
> groups of
> >> applications you want to administer at once, for
> instance a
> >> portal app together with a bunch of portlet apps
> deployed on the
> >> portal. So I can see a use for 3 levels.
> >>
> >> So what I was actually thinking of is that within
> a group of
> >> applications you'd want all the role names to be
> the same. The
> >> permissions would still be associated with a
> particular "leaf"
> >> application (context for my jacc example) but
> you'd expect to
> >> have the same role names within each
> sub-applications. Then
> >> you'd have the user <> role association at the
> level of the group
> >> of applications that you wanted to deal with
> together.
> >>
> >> There might still be some difference.... I'm not
> sure.
> >
> > Well, I think here we are just playing with
> semantic :)
> >
> > All in all, I really think those things are very
> similar. You can
> > perfectly manage the so called 'groups' within a
> hierarchy of roles.
> >
> > Now, let's talk about real life, I mean, you know,
> those big
> > companies with an IT management which does not
> manage anything but
> > budgets... They just stack applications, and ask
> poor admin to
> > manage roles, permissions, grants and deny, and of
> course all those
> > applications aren't compatible or does not use the
> same semantics.
> >
> > This is a problem. Let say that when using
> 'groups', you allow a
> > sort of flexibility, and you help an administrator
> to create a
> > feeling of comfort (it's easy to create a group
> called 'accountant'
> > including people allowed to access SAP, SAS and
> some kind of web
> > application. The 'roles' will be defined
> application by application. )
> >
> > At this point, real life example could help to
> understand the
> > concept of chaos and babelization we are faced
> with...
> >
> > But, yes, a role hierarchy seems pretty ok if you
> can manage it.
> > And Groups are also another way to do it, with
> different names. IMHO.
> >
> > Ok, I have to further my thinking about all this
> sh*t I just wrote,
> > and maybe tomorow, after a full night, ideas will
> be clearer :)
>
> So I think I am starting to see something about the
> purpose of
> groups.....
>
> suppose you have 10 applications you have to manage
> security to at
> the same time, and they are j2ee apps from different
> vendors, so they
> all come with different built-in role names which
> however mean
> similar things, such as admin, ADM, Administrator,
> etc etc. Now you
> hire a new administrator person and want to give
> them these app-level
> roles all at once.
>
> Groups are one way to solve this, I'm not sure they
> are the best way
> yet.
>
> Another possibility is to have more roles. So far
> we have been
> saying roles are associated with the smallest
> application component
> we are modeling: in the original tsec model that's
> just the
> application, in the sandbox test data a
> sub-application. We could
> have roles at any level of the application hierarchy
> and they could
> include as sub-roles roles at that level and finer
> levels. So for
> the j2ee example, you could have a "top level" ADMIN
> role that
> included the variously named admin roles from each
> application. Then
> you could assign users individually to this top
> level role.
>
> I haven't been able to imagine the user experience
> of administrating
> either this model or the group model :-) We might
> need both.
>
> >
> > Anyway, this is important concepts and this convo
> is really important.
> > Thanks Alex, David, Ersin and Ole !
>
> I'm really glad we're having this discussion on the
> mailing list!
>
> thanks
> david jencks
>
> >
> > Emmanuel
> >
> >>
> >> thanks
> >> david jencks
> >>
> >>
> >>>
> >>> Emmanuel
> >>
> >>
> >>
> >
>
>
____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
Re: [Triplesec] Permissions, Roles and Groups
Posted by David Jencks <da...@yahoo.com>.
On Jan 25, 2007, at 5:08 PM, Emmanuel Lecharny wrote:
> David Jencks a écrit :
>
>>
>> On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny wrote:
>>
>>> Ole Ersoy a écrit :
>>>
>>>> OK - So if we have aggregate roles / hierarchical
>>>> roles, we can elliminate the concept of groups.
>>>>
>>>> Groovy.
>>>>
>>>>
>>> AFAIK, groups are very cool to have if you deal with more than
>>> one application. Roles will be Application related, and groups
>>> will be more Users related.
>>>
>>> Those two elements are pretty close, but their semantics are
>>> different, if I understand.
>>
>>
>> OK, so I was hoping to delay getting into this additional issue.....
>>
>> Would you agree that if there's only one "application" then groups
>> + role <> group assigment is equivalent to the direct user<>role
>> association I was talking about although looked at from the
>> opposite direction?
>>
>> For jacc we need some kind of idea of groups of applications. I
>> implemented this by allowing multiple appName=foo,appName=bar,....
>> in dns, in sandbox/triplesec-jacc2. You can have any level of
>> nesting you want, but for jacc you need 2 levels (application
>> and context within the app). I can see having groups of
>> applications you want to administer at once, for instance a
>> portal app together with a bunch of portlet apps deployed on the
>> portal. So I can see a use for 3 levels.
>>
>> So what I was actually thinking of is that within a group of
>> applications you'd want all the role names to be the same. The
>> permissions would still be associated with a particular "leaf"
>> application (context for my jacc example) but you'd expect to
>> have the same role names within each sub-applications. Then
>> you'd have the user <> role association at the level of the group
>> of applications that you wanted to deal with together.
>>
>> There might still be some difference.... I'm not sure.
>
> Well, I think here we are just playing with semantic :)
>
> All in all, I really think those things are very similar. You can
> perfectly manage the so called 'groups' within a hierarchy of roles.
>
> Now, let's talk about real life, I mean, you know, those big
> companies with an IT management which does not manage anything but
> budgets... They just stack applications, and ask poor admin to
> manage roles, permissions, grants and deny, and of course all those
> applications aren't compatible or does not use the same semantics.
>
> This is a problem. Let say that when using 'groups', you allow a
> sort of flexibility, and you help an administrator to create a
> feeling of comfort (it's easy to create a group called 'accountant'
> including people allowed to access SAP, SAS and some kind of web
> application. The 'roles' will be defined application by application. )
>
> At this point, real life example could help to understand the
> concept of chaos and babelization we are faced with...
>
> But, yes, a role hierarchy seems pretty ok if you can manage it.
> And Groups are also another way to do it, with different names. IMHO.
>
> Ok, I have to further my thinking about all this sh*t I just wrote,
> and maybe tomorow, after a full night, ideas will be clearer :)
So I think I am starting to see something about the purpose of
groups.....
suppose you have 10 applications you have to manage security to at
the same time, and they are j2ee apps from different vendors, so they
all come with different built-in role names which however mean
similar things, such as admin, ADM, Administrator, etc etc. Now you
hire a new administrator person and want to give them these app-level
roles all at once.
Groups are one way to solve this, I'm not sure they are the best way
yet.
Another possibility is to have more roles. So far we have been
saying roles are associated with the smallest application component
we are modeling: in the original tsec model that's just the
application, in the sandbox test data a sub-application. We could
have roles at any level of the application hierarchy and they could
include as sub-roles roles at that level and finer levels. So for
the j2ee example, you could have a "top level" ADMIN role that
included the variously named admin roles from each application. Then
you could assign users individually to this top level role.
I haven't been able to imagine the user experience of administrating
either this model or the group model :-) We might need both.
>
> Anyway, this is important concepts and this convo is really important.
> Thanks Alex, David, Ersin and Ole !
I'm really glad we're having this discussion on the mailing list!
thanks
david jencks
>
> Emmanuel
>
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> Emmanuel
>>
>>
>>
>
Re: [Triplesec] Permissions, Roles and Groups
Posted by Emmanuel Lecharny <el...@gmail.com>.
David Jencks a écrit :
>
> On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny wrote:
>
>> Ole Ersoy a écrit :
>>
>>> OK - So if we have aggregate roles / hierarchical
>>> roles, we can elliminate the concept of groups.
>>>
>>> Groovy.
>>>
>>>
>> AFAIK, groups are very cool to have if you deal with more than one
>> application. Roles will be Application related, and groups will be
>> more Users related.
>>
>> Those two elements are pretty close, but their semantics are
>> different, if I understand.
>
>
> OK, so I was hoping to delay getting into this additional issue.....
>
> Would you agree that if there's only one "application" then groups +
> role <> group assigment is equivalent to the direct user<>role
> association I was talking about although looked at from the opposite
> direction?
>
> For jacc we need some kind of idea of groups of applications. I
> implemented this by allowing multiple appName=foo,appName=bar,.... in
> dns, in sandbox/triplesec-jacc2. You can have any level of nesting
> you want, but for jacc you need 2 levels (application and context
> within the app). I can see having groups of applications you want to
> administer at once, for instance a portal app together with a bunch
> of portlet apps deployed on the portal. So I can see a use for 3
> levels.
>
> So what I was actually thinking of is that within a group of
> applications you'd want all the role names to be the same. The
> permissions would still be associated with a particular "leaf"
> application (context for my jacc example) but you'd expect to have
> the same role names within each sub-applications. Then you'd have
> the user <> role association at the level of the group of
> applications that you wanted to deal with together.
>
> There might still be some difference.... I'm not sure.
Well, I think here we are just playing with semantic :)
All in all, I really think those things are very similar. You can
perfectly manage the so called 'groups' within a hierarchy of roles.
Now, let's talk about real life, I mean, you know, those big companies
with an IT management which does not manage anything but budgets... They
just stack applications, and ask poor admin to manage roles,
permissions, grants and deny, and of course all those applications
aren't compatible or does not use the same semantics.
This is a problem. Let say that when using 'groups', you allow a sort of
flexibility, and you help an administrator to create a feeling of
comfort (it's easy to create a group called 'accountant' including
people allowed to access SAP, SAS and some kind of web application. The
'roles' will be defined application by application. )
At this point, real life example could help to understand the concept of
chaos and babelization we are faced with...
But, yes, a role hierarchy seems pretty ok if you can manage it. And
Groups are also another way to do it, with different names. IMHO.
Ok, I have to further my thinking about all this sh*t I just wrote, and
maybe tomorow, after a full night, ideas will be clearer :)
Anyway, this is important concepts and this convo is really important.
Thanks Alex, David, Ersin and Ole !
Emmanuel
>
> thanks
> david jencks
>
>
>>
>> Emmanuel
>
>
>
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
--- David Jencks <da...@yahoo.com> wrote:
>
> On Jan 25, 2007, at 4:58 PM, Ole Ersoy wrote:
>
> > Hmmm
> >
> > OK
> >
> > Suppose we have:
> >
> > - Role Hierarchies
> > - User Hierarchies
> > - URI Hierarchies
>
> For JACC I also need application hierarchies.
> >
> > The URI hierarchies would be for grouping
> permission
> > targets.
> >
> > A single URI would represent an atomic permission
> > target. Thus permissions would not overlap with
> > respect to URI's.
>
> Can you explain the meaning of URI in this context?
> How does it
> relate to a permission?
The URI hierarchy is the "Application Hierarchy".
A single application is broken down into a group of
URIs.
So for instance when you press a JSP button, then
browser translates that into a URI. Parts of the URI
are used to route the request to say Tomcat on some
server in China. Then tomcat uses the rest to find
the command / action that corresponds to the push of
the button. But before invoking that it checks with
Triplesec to see whether the Authenticated User has
the permission.
So that's how it would work for "Commands/Actions".
Then for files/resources the URI is just pointing to
some static file on the net, or maybe a dynamic one,
but if it is dynamic we will just lump it in the
"Command/Actions" category.
>
> For instance, most java permissions can be
> represented as a java
> class name, a permission name, and an actions
> string. For instance:
>
> java class name:
> javax.security.jacc.WebUserDataPermission
> name: /:/admin/*:basic/foo:*.jsp
> actions: !GET,POST,FOO:CONFIDENTIAL
>
> I don't think that triplesec should contemplate
> understanding the
> meaning of permissions but instead delegate to an
> external system,
> such as the java permission interface method
> p1.implies(p2)
Sure, I'm using URI's just a a unique key that points
to something that a user is requesting permission for.
I think most developers are used to this, so it's
pretty a pretty straightforward concept to explain,
when presenting triplesec developer use cases.
So the URI just represents something that a user is
requesting permission to access. If permission is
granted, it's up to the application to decide what
that means.
>
> >
> > Now we are covering everything right?
>
> maybe getting closer :-)
>
Yeah - This is hot stuff :-) Hooah!
Thanks,
- Ole
> thanks
> david jencks
>
> >
> > Cheers,
> > - Ole
> >
> >
> >
> >
> > --- David Jencks <da...@yahoo.com> wrote:
> >
> >>
> >> On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny
> >> wrote:
> >>
> >>> Ole Ersoy a écrit :
> >>>
> >>>> OK - So if we have aggregate roles /
> hierarchical
> >>>> roles, we can elliminate the concept of groups.
> >>>>
> >>>> Groovy.
> >>>>
> >>>>
> >>> AFAIK, groups are very cool to have if you deal
> >> with more than one
> >>> application. Roles will be Application related,
> >> and groups will be
> >>> more Users related.
> >>>
> >>> Those two elements are pretty close, but their
> >> semantics are
> >>> different, if I understand.
> >>
> >> OK, so I was hoping to delay getting into this
> >> additional issue.....
> >>
> >> Would you agree that if there's only one
> >> "application" then groups +
> >> role <> group assigment is equivalent to the
> direct
> >> user<>role
> >> association I was talking about although looked
> at
> >> from the opposite
> >> direction?
> >>
> >> For jacc we need some kind of idea of groups of
> >> applications. I
> >> implemented this by allowing multiple
> >> appName=foo,appName=bar,.... in
> >> dns, in sandbox/triplesec-jacc2. You can have
> any
> >> level of nesting
> >> you want, but for jacc you need 2 levels
> >> (application and context
> >> within the app). I can see having groups of
> >> applications you want to
> >> administer at once, for instance a portal app
> >> together with a bunch
> >> of portlet apps deployed on the portal. So I can
> >> see a use for 3
> >> levels.
> >>
> >> So what I was actually thinking of is that within
> a
> >> group of
> >> applications you'd want all the role names to be
> the
> >> same. The
> >> permissions would still be associated with a
> >> particular "leaf"
> >> application (context for my jacc example) but
> you'd
> >> expect to have
> >> the same role names within each sub-applications.
> >> Then you'd have
> >> the user <> role association at the level of the
> >> group of
> >> applications that you wanted to deal with
> together.
> >>
> >> There might still be some difference.... I'm not
> >> sure.
> >>
> >> thanks
> >> david jencks
> >>
> >>
> >>>
> >>> Emmanuel
> >>
> >>
> >
> >
> >
> >
> >
>
______________________________________________________________________
>
> > ______________
> > Sucker-punch spam with award-winning protection.
> > Try the free Yahoo! Mail Beta.
> >
>
http://advision.webevents.yahoo.com/mailbeta/features_spam.html
>
>
____________________________________________________________________________________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097
Re: [Triplesec] Permissions, Roles and Groups
Posted by David Jencks <da...@yahoo.com>.
On Jan 25, 2007, at 4:58 PM, Ole Ersoy wrote:
> Hmmm
>
> OK
>
> Suppose we have:
>
> - Role Hierarchies
> - User Hierarchies
> - URI Hierarchies
For JACC I also need application hierarchies.
>
> The URI hierarchies would be for grouping permission
> targets.
>
> A single URI would represent an atomic permission
> target. Thus permissions would not overlap with
> respect to URI's.
Can you explain the meaning of URI in this context? How does it
relate to a permission?
For instance, most java permissions can be represented as a java
class name, a permission name, and an actions string. For instance:
java class name: javax.security.jacc.WebUserDataPermission
name: /:/admin/*:basic/foo:*.jsp
actions: !GET,POST,FOO:CONFIDENTIAL
I don't think that triplesec should contemplate understanding the
meaning of permissions but instead delegate to an external system,
such as the java permission interface method p1.implies(p2)
>
> Now we are covering everything right?
maybe getting closer :-)
thanks
david jencks
>
> Cheers,
> - Ole
>
>
>
>
> --- David Jencks <da...@yahoo.com> wrote:
>
>>
>> On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny
>> wrote:
>>
>>> Ole Ersoy a écrit :
>>>
>>>> OK - So if we have aggregate roles / hierarchical
>>>> roles, we can elliminate the concept of groups.
>>>>
>>>> Groovy.
>>>>
>>>>
>>> AFAIK, groups are very cool to have if you deal
>> with more than one
>>> application. Roles will be Application related,
>> and groups will be
>>> more Users related.
>>>
>>> Those two elements are pretty close, but their
>> semantics are
>>> different, if I understand.
>>
>> OK, so I was hoping to delay getting into this
>> additional issue.....
>>
>> Would you agree that if there's only one
>> "application" then groups +
>> role <> group assigment is equivalent to the direct
>> user<>role
>> association I was talking about although looked at
>> from the opposite
>> direction?
>>
>> For jacc we need some kind of idea of groups of
>> applications. I
>> implemented this by allowing multiple
>> appName=foo,appName=bar,.... in
>> dns, in sandbox/triplesec-jacc2. You can have any
>> level of nesting
>> you want, but for jacc you need 2 levels
>> (application and context
>> within the app). I can see having groups of
>> applications you want to
>> administer at once, for instance a portal app
>> together with a bunch
>> of portlet apps deployed on the portal. So I can
>> see a use for 3
>> levels.
>>
>> So what I was actually thinking of is that within a
>> group of
>> applications you'd want all the role names to be the
>> same. The
>> permissions would still be associated with a
>> particular "leaf"
>> application (context for my jacc example) but you'd
>> expect to have
>> the same role names within each sub-applications.
>> Then you'd have
>> the user <> role association at the level of the
>> group of
>> applications that you wanted to deal with together.
>>
>> There might still be some difference.... I'm not
>> sure.
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> Emmanuel
>>
>>
>
>
>
>
> ______________________________________________________________________
> ______________
> Sucker-punch spam with award-winning protection.
> Try the free Yahoo! Mail Beta.
> http://advision.webevents.yahoo.com/mailbeta/features_spam.html
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
Hmmm
OK
Suppose we have:
- Role Hierarchies
- User Hierarchies
- URI Hierarchies
The URI hierarchies would be for grouping permission
targets.
A single URI would represent an atomic permission
target. Thus permissions would not overlap with
respect to URI's.
Now we are covering everything right?
Cheers,
- Ole
--- David Jencks <da...@yahoo.com> wrote:
>
> On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny
> wrote:
>
> > Ole Ersoy a écrit :
> >
> >> OK - So if we have aggregate roles / hierarchical
> >> roles, we can elliminate the concept of groups.
> >>
> >> Groovy.
> >>
> >>
> > AFAIK, groups are very cool to have if you deal
> with more than one
> > application. Roles will be Application related,
> and groups will be
> > more Users related.
> >
> > Those two elements are pretty close, but their
> semantics are
> > different, if I understand.
>
> OK, so I was hoping to delay getting into this
> additional issue.....
>
> Would you agree that if there's only one
> "application" then groups +
> role <> group assigment is equivalent to the direct
> user<>role
> association I was talking about although looked at
> from the opposite
> direction?
>
> For jacc we need some kind of idea of groups of
> applications. I
> implemented this by allowing multiple
> appName=foo,appName=bar,.... in
> dns, in sandbox/triplesec-jacc2. You can have any
> level of nesting
> you want, but for jacc you need 2 levels
> (application and context
> within the app). I can see having groups of
> applications you want to
> administer at once, for instance a portal app
> together with a bunch
> of portlet apps deployed on the portal. So I can
> see a use for 3
> levels.
>
> So what I was actually thinking of is that within a
> group of
> applications you'd want all the role names to be the
> same. The
> permissions would still be associated with a
> particular "leaf"
> application (context for my jacc example) but you'd
> expect to have
> the same role names within each sub-applications.
> Then you'd have
> the user <> role association at the level of the
> group of
> applications that you wanted to deal with together.
>
> There might still be some difference.... I'm not
> sure.
>
> thanks
> david jencks
>
>
> >
> > Emmanuel
>
>
____________________________________________________________________________________
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html
Re: [Triplesec] Permissions, Roles and Groups
Posted by David Jencks <da...@yahoo.com>.
On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny wrote:
> Ole Ersoy a écrit :
>
>> OK - So if we have aggregate roles / hierarchical
>> roles, we can elliminate the concept of groups.
>>
>> Groovy.
>>
>>
> AFAIK, groups are very cool to have if you deal with more than one
> application. Roles will be Application related, and groups will be
> more Users related.
>
> Those two elements are pretty close, but their semantics are
> different, if I understand.
OK, so I was hoping to delay getting into this additional issue.....
Would you agree that if there's only one "application" then groups +
role <> group assigment is equivalent to the direct user<>role
association I was talking about although looked at from the opposite
direction?
For jacc we need some kind of idea of groups of applications. I
implemented this by allowing multiple appName=foo,appName=bar,.... in
dns, in sandbox/triplesec-jacc2. You can have any level of nesting
you want, but for jacc you need 2 levels (application and context
within the app). I can see having groups of applications you want to
administer at once, for instance a portal app together with a bunch
of portlet apps deployed on the portal. So I can see a use for 3
levels.
So what I was actually thinking of is that within a group of
applications you'd want all the role names to be the same. The
permissions would still be associated with a particular "leaf"
application (context for my jacc example) but you'd expect to have
the same role names within each sub-applications. Then you'd have
the user <> role association at the level of the group of
applications that you wanted to deal with together.
There might still be some difference.... I'm not sure.
thanks
david jencks
>
> Emmanuel
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
Yeah,
Wait a minute...
Emmanuel I think you are onto something.
I was trying to talk myself out of needing groups, and
I think you are right.
Roles and aggregated roles are just aggregated
permissions.
So if I want to assign these to more than one user, I
still need groups...perhaps aggregated
groups...right...?
So if we have groups...and aggregated groups...
and
roles and aggregated roles we cover all the bases
right?
Cheers,
Ole
--- Emmanuel Lecharny <el...@gmail.com> wrote:
> Ole Ersoy a écrit :
>
> >OK - So if we have aggregate roles / hierarchical
> >roles, we can elliminate the concept of groups.
> >
> >Groovy.
> >
> >
> >
> AFAIK, groups are very cool to have if you deal with
> more than one
> application. Roles will be Application related, and
> groups will be more
> Users related.
>
> Those two elements are pretty close, but their
> semantics are different,
> if I understand.
>
> Emmanuel
>
____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.
Re: [Triplesec] Permissions, Roles and Groups
Posted by Emmanuel Lecharny <el...@gmail.com>.
Ole Ersoy a écrit :
>OK - So if we have aggregate roles / hierarchical
>roles, we can elliminate the concept of groups.
>
>Groovy.
>
>
>
AFAIK, groups are very cool to have if you deal with more than one
application. Roles will be Application related, and groups will be more
Users related.
Those two elements are pretty close, but their semantics are different,
if I understand.
Emmanuel
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
OK - So if we have aggregate roles / hierarchical
roles, we can elliminate the concept of groups.
Groovy.
--- David Jencks <da...@yahoo.com> wrote:
> Ersin pointed me to a very interesting paper
> http://csrc.nist.gov/
> rbac/rbacSTD-ACM.pdf that has considerably
> influenced my ideas on
> where tsec should head, and some of the ideas from
> that paper are (I
> hope) represented in my comments below.
>
> On Jan 25, 2007, at 11:02 AM, Alex Karasulu wrote:
>
> > Hello,
> >
> > I would like to have a discussion on the meaning
> of these entities
> > in general and with respect to how they are
> modeled in Triplesec
> > today in the trunk:
> >
> > o Permissions
> > o Roles
>
> I think these are useful abstractions
> > o Groups
>
> I don't think groups are a useful abstraction if you
> have the right
> kind of roles.
>
> I also don't think it's possible to discuss this
> subject without also
> including Users and User-Role associations.
>
> >
> > I've been talking to djencks about this stuff for
> a bit now as we
> > have started working together on various aspects
> of Triplesec. I'd
> > like to have a general discussion about these
> concepts here so we
> > can all be on the same page with what they are.
>
> To me, we get to define our terms, and then they
> mean what we say the
> mean. I don't see any of these concepts as having
> an immutable
> meaning outside what we want the system to do.
>
> Also to set the context here, I think the overall
> goal is to start
> with something representing the identity of a person
> using the
> system, possibly some other description of the
> activities they wish
> to perform, and determine what they are allowed to
> do in the system.
>
> > Let me kick this off.
> >
> > Permissions
> > ===========
> >
> > To me a permission is a right that is granted to
> access a resource
> > or perform some kind of protected operation. To a
> large degree the
> > semantics of permissions are undefined except
> within a specific
> > application. For example the permission to
> accessPayroll may not
> > have much meaning outside of an application
> dealing with payroll
> > management.
> >
> > In Triplesec (trunk) a permission is just a label
> without any
> > meaning. The semantics of the permission is left
> up to the
> > application to define.
>
> I basically agree with this, the label is a
> meaningless abstract
> identifier. We do need to make sure we can attach
> more information
> to the label for specific uses, e.g. attaching
> sufficient information
> to construct a java permission for use in java apps.
> I've done this
> in sandbox/triplesec-jacc2.
> >
> > Roles
> > =====
> >
> > A Role is a collection of permissions associated
> together to
> > represent the rights need by one to perform the
> actions or
> > activities of a function. For our purposes we can
> just say a role
> > is a collection of permissions.
> >
> > As a collection of permissions which are
> application specific,
> > roles themselves become application specific.
> >
> > In Triplesec (trunk) a role is just a collection
> of granted
> > permissions with a name. Roles entries in
> Triplesec have a SINGLE-
> > VALUED 'roleName' and a MULTI-VALUED 'grants'
> attribute. You just
> > add the names of permissions to a role entry to
> add them to the role.
>
> This is really making a big assumption about the
> meaning of
> permissions, namely that they aren't overlapping in
> any way, so that
> to deny a permission you just remove it from the set
> of granted
> permissions. If permissions overlap, as java
> permissions can, you
> really need to be able to deny permissions as well.
> So you need to
> have roles have a set of granted permissions and a
> set of denied
> permissions.
>
> Furthermore, as suggested in the NIST paper,
> hierarchical roles
> provide great power and convenience for
> administering roles and
> permissions. They're fairly trivial to implement in
> terms of the
> data model, and you don't have to use them if you
> don't want to. So
> I'd say a role is <name, grantsSet, denialsSet,
> rolesSet}
>
> Note that with this role model, you can easily
> represent any
> combination of existing roles, with individualized
> tweaks, as another
> role. Therefore we can represent any set of
> permissions as a role.
> To avoid duplication of concepts we should represent
> every
> interesting set of permissions as a role.
>
> Very little I have to say makes sense if you
> disagree with this....
> the following is predicated entirely on this model
> of a role. If you
> don't agree, stop here and lets talk about why.
>
> >
> > Groups
> > ======
> >
> > Although you can group anything I think we're
> talking more about
> > groups of users in this context. Groups are
> primarily used to make
> > administration tasks easier. By grouping people
> and the can be
> > managed as a single group rather than performing
> the same upkeep
> > operations on all the members of the group.
> >
> > In Triplesec a group is a static LDAP group
> (groupOfUniqueNames) or
> > user DNs right now. We may expand this to include
> dynamic groups
> > in the future.
> >
>
> OK, here's where we part company :-) As the nist
> paper points out,
> the idea of groups is a precursor to the idea of
> general RBAC. We
> definitely need a concept of identity (user), and we
> definitely need
> a concept of set of permissions (role), and we
> definitely need a
> concept of associating these two. Alex is proposing
> at least two
> mechanisms for associating a user and a set of
> permissions. I'm not
> happy with any of the existing associations and
> think we can do better.
>
> I think these are the requirements:
>
> each user can be associated with several sets of
> permissions (roles)
> each set of permissions (role) can be associated
> with several users
> at any time, at most one role can be active for a
> user
>
> If we had a relational database this would be pretty
> easy to model --
>
=== message truncated ===
____________________________________________________________________________________
Now that's room service! Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
David,
One more thing.
I'm trying to understand the process I would use to
work with granted permissions and denied permissions.
It seems to imply that if I find a granted permission,
I have to do more checking to see if that permission
is denied or vice versa.
Thoughts?
Thanks,
- Ole
--- David Jencks <da...@yahoo.com> wrote:
> Ersin pointed me to a very interesting paper
> http://csrc.nist.gov/
> rbac/rbacSTD-ACM.pdf that has considerably
> influenced my ideas on
> where tsec should head, and some of the ideas from
> that paper are (I
> hope) represented in my comments below.
>
> On Jan 25, 2007, at 11:02 AM, Alex Karasulu wrote:
>
> > Hello,
> >
> > I would like to have a discussion on the meaning
> of these entities
> > in general and with respect to how they are
> modeled in Triplesec
> > today in the trunk:
> >
> > o Permissions
> > o Roles
>
> I think these are useful abstractions
> > o Groups
>
> I don't think groups are a useful abstraction if you
> have the right
> kind of roles.
>
> I also don't think it's possible to discuss this
> subject without also
> including Users and User-Role associations.
>
> >
> > I've been talking to djencks about this stuff for
> a bit now as we
> > have started working together on various aspects
> of Triplesec. I'd
> > like to have a general discussion about these
> concepts here so we
> > can all be on the same page with what they are.
>
> To me, we get to define our terms, and then they
> mean what we say the
> mean. I don't see any of these concepts as having
> an immutable
> meaning outside what we want the system to do.
>
> Also to set the context here, I think the overall
> goal is to start
> with something representing the identity of a person
> using the
> system, possibly some other description of the
> activities they wish
> to perform, and determine what they are allowed to
> do in the system.
>
> > Let me kick this off.
> >
> > Permissions
> > ===========
> >
> > To me a permission is a right that is granted to
> access a resource
> > or perform some kind of protected operation. To a
> large degree the
> > semantics of permissions are undefined except
> within a specific
> > application. For example the permission to
> accessPayroll may not
> > have much meaning outside of an application
> dealing with payroll
> > management.
> >
> > In Triplesec (trunk) a permission is just a label
> without any
> > meaning. The semantics of the permission is left
> up to the
> > application to define.
>
> I basically agree with this, the label is a
> meaningless abstract
> identifier. We do need to make sure we can attach
> more information
> to the label for specific uses, e.g. attaching
> sufficient information
> to construct a java permission for use in java apps.
> I've done this
> in sandbox/triplesec-jacc2.
> >
> > Roles
> > =====
> >
> > A Role is a collection of permissions associated
> together to
> > represent the rights need by one to perform the
> actions or
> > activities of a function. For our purposes we can
> just say a role
> > is a collection of permissions.
> >
> > As a collection of permissions which are
> application specific,
> > roles themselves become application specific.
> >
> > In Triplesec (trunk) a role is just a collection
> of granted
> > permissions with a name. Roles entries in
> Triplesec have a SINGLE-
> > VALUED 'roleName' and a MULTI-VALUED 'grants'
> attribute. You just
> > add the names of permissions to a role entry to
> add them to the role.
>
> This is really making a big assumption about the
> meaning of
> permissions, namely that they aren't overlapping in
> any way, so that
> to deny a permission you just remove it from the set
> of granted
> permissions. If permissions overlap, as java
> permissions can, you
> really need to be able to deny permissions as well.
> So you need to
> have roles have a set of granted permissions and a
> set of denied
> permissions.
>
> Furthermore, as suggested in the NIST paper,
> hierarchical roles
> provide great power and convenience for
> administering roles and
> permissions. They're fairly trivial to implement in
> terms of the
> data model, and you don't have to use them if you
> don't want to. So
> I'd say a role is <name, grantsSet, denialsSet,
> rolesSet}
>
> Note that with this role model, you can easily
> represent any
> combination of existing roles, with individualized
> tweaks, as another
> role. Therefore we can represent any set of
> permissions as a role.
> To avoid duplication of concepts we should represent
> every
> interesting set of permissions as a role.
>
> Very little I have to say makes sense if you
> disagree with this....
> the following is predicated entirely on this model
> of a role. If you
> don't agree, stop here and lets talk about why.
>
> >
> > Groups
> > ======
> >
> > Although you can group anything I think we're
> talking more about
> > groups of users in this context. Groups are
> primarily used to make
> > administration tasks easier. By grouping people
> and the can be
> > managed as a single group rather than performing
> the same upkeep
> > operations on all the members of the group.
> >
> > In Triplesec a group is a static LDAP group
> (groupOfUniqueNames) or
> > user DNs right now. We may expand this to include
> dynamic groups
> > in the future.
> >
>
> OK, here's where we part company :-) As the nist
> paper points out,
> the idea of groups is a precursor to the idea of
> general RBAC. We
> definitely need a concept of identity (user), and we
> definitely need
> a concept of set of permissions (role), and we
> definitely need a
> concept of associating these two. Alex is proposing
> at least two
> mechanisms for associating a user and a set of
> permissions. I'm not
> happy with any of the existing associations and
> think we can do better.
>
> I think these are the requirements:
>
> each user can be associated with several sets of
> permissions (roles)
> each set of permissions (role) can be associated
> with several users
> at any time, at most one role can be active for a
> user
>
> If we had a relational database this would be pretty
> easy to model --
>
=== message truncated ===
____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
Re: [Triplesec] Permissions, Roles and Groups
Posted by David Jencks <da...@yahoo.com>.
Ersin pointed me to a very interesting paper http://csrc.nist.gov/
rbac/rbacSTD-ACM.pdf that has considerably influenced my ideas on
where tsec should head, and some of the ideas from that paper are (I
hope) represented in my comments below.
On Jan 25, 2007, at 11:02 AM, Alex Karasulu wrote:
> Hello,
>
> I would like to have a discussion on the meaning of these entities
> in general and with respect to how they are modeled in Triplesec
> today in the trunk:
>
> o Permissions
> o Roles
I think these are useful abstractions
> o Groups
I don't think groups are a useful abstraction if you have the right
kind of roles.
I also don't think it's possible to discuss this subject without also
including Users and User-Role associations.
>
> I've been talking to djencks about this stuff for a bit now as we
> have started working together on various aspects of Triplesec. I'd
> like to have a general discussion about these concepts here so we
> can all be on the same page with what they are.
To me, we get to define our terms, and then they mean what we say the
mean. I don't see any of these concepts as having an immutable
meaning outside what we want the system to do.
Also to set the context here, I think the overall goal is to start
with something representing the identity of a person using the
system, possibly some other description of the activities they wish
to perform, and determine what they are allowed to do in the system.
> Let me kick this off.
>
> Permissions
> ===========
>
> To me a permission is a right that is granted to access a resource
> or perform some kind of protected operation. To a large degree the
> semantics of permissions are undefined except within a specific
> application. For example the permission to accessPayroll may not
> have much meaning outside of an application dealing with payroll
> management.
>
> In Triplesec (trunk) a permission is just a label without any
> meaning. The semantics of the permission is left up to the
> application to define.
I basically agree with this, the label is a meaningless abstract
identifier. We do need to make sure we can attach more information
to the label for specific uses, e.g. attaching sufficient information
to construct a java permission for use in java apps. I've done this
in sandbox/triplesec-jacc2.
>
> Roles
> =====
>
> A Role is a collection of permissions associated together to
> represent the rights need by one to perform the actions or
> activities of a function. For our purposes we can just say a role
> is a collection of permissions.
>
> As a collection of permissions which are application specific,
> roles themselves become application specific.
>
> In Triplesec (trunk) a role is just a collection of granted
> permissions with a name. Roles entries in Triplesec have a SINGLE-
> VALUED 'roleName' and a MULTI-VALUED 'grants' attribute. You just
> add the names of permissions to a role entry to add them to the role.
This is really making a big assumption about the meaning of
permissions, namely that they aren't overlapping in any way, so that
to deny a permission you just remove it from the set of granted
permissions. If permissions overlap, as java permissions can, you
really need to be able to deny permissions as well. So you need to
have roles have a set of granted permissions and a set of denied
permissions.
Furthermore, as suggested in the NIST paper, hierarchical roles
provide great power and convenience for administering roles and
permissions. They're fairly trivial to implement in terms of the
data model, and you don't have to use them if you don't want to. So
I'd say a role is <name, grantsSet, denialsSet, rolesSet}
Note that with this role model, you can easily represent any
combination of existing roles, with individualized tweaks, as another
role. Therefore we can represent any set of permissions as a role.
To avoid duplication of concepts we should represent every
interesting set of permissions as a role.
Very little I have to say makes sense if you disagree with this....
the following is predicated entirely on this model of a role. If you
don't agree, stop here and lets talk about why.
>
> Groups
> ======
>
> Although you can group anything I think we're talking more about
> groups of users in this context. Groups are primarily used to make
> administration tasks easier. By grouping people and the can be
> managed as a single group rather than performing the same upkeep
> operations on all the members of the group.
>
> In Triplesec a group is a static LDAP group (groupOfUniqueNames) or
> user DNs right now. We may expand this to include dynamic groups
> in the future.
>
OK, here's where we part company :-) As the nist paper points out,
the idea of groups is a precursor to the idea of general RBAC. We
definitely need a concept of identity (user), and we definitely need
a concept of set of permissions (role), and we definitely need a
concept of associating these two. Alex is proposing at least two
mechanisms for associating a user and a set of permissions. I'm not
happy with any of the existing associations and think we can do better.
I think these are the requirements:
each user can be associated with several sets of permissions (roles)
each set of permissions (role) can be associated with several users
at any time, at most one role can be active for a user
If we had a relational database this would be pretty easy to model --
a table with 2 columns, userId, and roleId, both part of the pk, and
the db would figure out how to navigate for us. However since we are
in a navigation-oriented database the best data model depends on the
expected access pattern. This unfortunately leads into a discussion
of typical login capabilities.... Lets start by assuming that we
start by identifying the user and then try to choose what role to put
them in, and exactly how we do that is not determined. Note that
this is NOT how triplesec is currently organized.
Having decided on an access pattern, our model should look like
UserRoles { userId, roleSet}. With this model groups are not needed,
nor are profiles which Alex didn't mention.
Lets look at how groups and profiles get modeled now.
groups: The purpose of the administration simplicity alex mentioned
is to assign a user to a set of permissions. The set of permissions
is a role, so you add the role to the users roleset. This is the
same action as assigning a user to a group, looked at from the other
end of the relationship.
profiles: profiles currently have 2 functions, constructing a set of
permissions out of other roles, and associating that set of
permissions with a user or group. The set of permissions is now a
role, so the remaining function is associating that role with one or
more users. This is done by adding the role to the UserRoles for
each user involved.
------------
Alternate suggestion
As noted profiles currently combine specifying a role (my
hierarchical definition) with associating a user with the role. If
we take out the aspect of subclassing role, we are left with a
profile containing a unique name, a user id, and a roleId. This is an
acceptable alternative data model for a n-n user role association,
although there is no obvious uniqueness constraint on (userId,
roleId). Here the user would identify themselves using the
profileId, the login framework would lookup their userId and
authenticate them using that, then we would determine the role from
the roleId. This is the same access pattern as currently in triplesec.
With this alternate suggestion the admin actions are basically the
same as with the first suggestion, except you add/remove profiles
rather than modifying UserRole contents. In either case groups
aren't needed.
My basic philosophical objection to including something called a
group in our model is that it duplicates the ideas we model better in
roles and user-role association.
Hopefully this is sufficiently coherent that everyone can understand
what I'm trying to say :-)
thanks
david jencks
> Thoughts? Corrections?
>
> Alex
>
> <akarasulu.vcf>
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
Another cool thing about having a SDO DAS is that EMF
works very well with Biz Rules. See:
http://www.eclipse.org/articles/Article-Rule Modeling
With EMF/article.html
We're starting the design discussions around it on the
Tuscany dev list if anyone is interested.
--- Stephane Bailliez <sb...@gmail.com> wrote:
>
>
> Ersin Er wrote:
> >> > These can be extended to the following
> entities:
> >> >
> >> > Policies
> >> > Subjects
> >> > Rules
> >> > Conditions
> >>
> >> Where is this from? Is this SUN's commercialized
> names for things they
> >> have in their access control manager?
> >
> > Well, these are not only SUN's terminology but
> generic entity
> > descriptors that needs to be provided by a
> powerful access control
> > system.
> >
> > What we call Users and Roles in Triplesec can be
> extended to the term
> > Subject.
> >
> > We don't have anything like Rules, although we
> must have. We just use
> > abstract strings as David said. But this is not
> for controlling access
> > but for storing abstract permission information.
> >
> > And Conditions are still a required property.
> Beyond selecting the
> > subjects and resources, we may need to satisfy
> more conditions like
> > Authentication Level, IP Address, LDAP Filter,
> Time etc.
> >
> > These all are also proposed by NIST spec and
> XACML.
>
> Good point.
>
> A permission could indeed be temporal or subject to
> other bizrules.
>
>
> -- stephane
>
>
____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
Re: [Triplesec] Permissions, Roles and Groups
Posted by Stephane Bailliez <sb...@gmail.com>.
Ersin Er wrote:
>> > These can be extended to the following entities:
>> >
>> > Policies
>> > Subjects
>> > Rules
>> > Conditions
>>
>> Where is this from? Is this SUN's commercialized names for things they
>> have in their access control manager?
>
> Well, these are not only SUN's terminology but generic entity
> descriptors that needs to be provided by a powerful access control
> system.
>
> What we call Users and Roles in Triplesec can be extended to the term
> Subject.
>
> We don't have anything like Rules, although we must have. We just use
> abstract strings as David said. But this is not for controlling access
> but for storing abstract permission information.
>
> And Conditions are still a required property. Beyond selecting the
> subjects and resources, we may need to satisfy more conditions like
> Authentication Level, IP Address, LDAP Filter, Time etc.
>
> These all are also proposed by NIST spec and XACML.
Good point.
A permission could indeed be temporal or subject to other bizrules.
-- stephane
Re: [Triplesec] Permissions, Roles and Groups
Posted by Stephane Bailliez <sb...@gmail.com>.
Ersin Er wrote:
>> > These can be extended to the following entities:
>> >
>> > Policies
>> > Subjects
>> > Rules
>> > Conditions
>>
>> Where is this from? Is this SUN's commercialized names for things they
>> have in their access control manager?
>
> Well, these are not only SUN's terminology but generic entity
> descriptors that needs to be provided by a powerful access control
> system.
>
> What we call Users and Roles in Triplesec can be extended to the term
> Subject.
>
> We don't have anything like Rules, although we must have. We just use
> abstract strings as David said. But this is not for controlling access
> but for storing abstract permission information.
>
> And Conditions are still a required property. Beyond selecting the
> subjects and resources, we may need to satisfy more conditions like
> Authentication Level, IP Address, LDAP Filter, Time etc.
>
> These all are also proposed by NIST spec and XACML.
Good point.
A permission could indeed be temporal or subject to other bizrules.
-- stephane
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ersin Er <er...@gmail.com>.
On 1/25/07, Alex Karasulu <ak...@apache.org> wrote:
> Ersin Er wrote:
> > On 1/25/07, Alex Karasulu <ak...@apache.org> wrote:
> >> Hello,
> >
> > Hi,
> >
> > I will extend the discussion using my recent experience with the subject.
> >
> >> I would like to have a discussion on the meaning of these entities in
> >> general and with respect to how they are modeled in Triplesec today in
> >> the trunk:
> >>
> >> o Permissions
> >> o Roles
> >> o Groups
> >
> > These can be extended to the following entities:
> >
> > Policies
> > Subjects
> > Rules
> > Conditions
>
> Where is this from? Is this SUN's commercialized names for things they
> have in their access control manager?
Well, these are not only SUN's terminology but generic entity
descriptors that needs to be provided by a powerful access control
system.
What we call Users and Roles in Triplesec can be extended to the term Subject.
We don't have anything like Rules, although we must have. We just use
abstract strings as David said. But this is not for controlling access
but for storing abstract permission information.
And Conditions are still a required property. Beyond selecting the
subjects and resources, we may need to satisfy more conditions like
Authentication Level, IP Address, LDAP Filter, Time etc.
These all are also proposed by NIST spec and XACML.
Let me state where Triplesec's simple String permissions sit in my
proposed scheme (well this is not my stuff of course). You may have
different Rule types. One of them may be URL Access Rule. Triplesec
can store this information and work with agents to decide if a client
has access to a URL or not. Basically the agent component in action
here is a Servlet Filter like thing. For Triplesec's simple string
permissions, you may have a Rule named String Permission Rule. In this
case neither the agent nor Triplesec controls any access but just
replies to queries to determine whether a principal (Subject) is
associated with a certain string permission. In this case the
application (resource) itself should "control access" to itself. And
this is what is currently happening in Triplesec.
Sorry for extending the subject more :)
--
Ersin
> > Subjects include any LDAP representable (or somewhat more abstract)
> > user group: LDAP Group, LDAP User, Different User Selections based on
> > some filter or bind options etc.
> >
> > Rules are the actions that can be permitted to subjects. The most
> > common rule type is URL Access Rules. In Triplesec's case, the thing
> > supported by this scheme can be named as String Rules. Triplesec does
> > not really control access but only allows it to be queried. (May be I
> > am wrong.)
>
> No you are right we would need to supply agents that use Triplesec to do
> this.
>
> A real Access Control server should really take the control
> > of access to the resources it is protecting. The resource in case of a
> > URL Access Rule is a URL for example. An Access Control system should
> > be aware of or should be in contact with the resource it's protecting.
> > This can generally be provided by an agent installed on the resource
> > side without effecting the resource itself.
>
> Sure.
>
> > Conditions may depend on the type of Rules or may be generic. For
> > example, you may specify the time period a resource is allowed to be
> > accessed.
> >
> > I will not go on inlining my comments below because I think I have
> > changed the topic a little bit. If what I am talking is far different
> > from Triplesec's model or aims, we ca just ignore them. Or we may
> > merge the schemes as we're discussing.
>
> No this is not on the topic :) but it is an important topic to have on
> this ML about SUN's access manager terminology and how their stuff
> works. This will help us build a better mouse trap. Perhaps you can
> put these kinds of things on another thread.
>
> Alex
>
>
>
>
>
>
--
Ersin
Re: [Triplesec] Permissions, Roles and Groups
Posted by Alex Karasulu <ak...@apache.org>.
Ersin Er wrote:
> On 1/25/07, Alex Karasulu <ak...@apache.org> wrote:
>> Hello,
>
> Hi,
>
> I will extend the discussion using my recent experience with the subject.
>
>> I would like to have a discussion on the meaning of these entities in
>> general and with respect to how they are modeled in Triplesec today in
>> the trunk:
>>
>> o Permissions
>> o Roles
>> o Groups
>
> These can be extended to the following entities:
>
> Policies
> Subjects
> Rules
> Conditions
Where is this from? Is this SUN's commercialized names for things they
have in their access control manager?
> Subjects include any LDAP representable (or somewhat more abstract)
> user group: LDAP Group, LDAP User, Different User Selections based on
> some filter or bind options etc.
>
> Rules are the actions that can be permitted to subjects. The most
> common rule type is URL Access Rules. In Triplesec's case, the thing
> supported by this scheme can be named as String Rules. Triplesec does
> not really control access but only allows it to be queried. (May be I
> am wrong.)
No you are right we would need to supply agents that use Triplesec to do
this.
A real Access Control server should really take the control
> of access to the resources it is protecting. The resource in case of a
> URL Access Rule is a URL for example. An Access Control system should
> be aware of or should be in contact with the resource it's protecting.
> This can generally be provided by an agent installed on the resource
> side without effecting the resource itself.
Sure.
> Conditions may depend on the type of Rules or may be generic. For
> example, you may specify the time period a resource is allowed to be
> accessed.
>
> I will not go on inlining my comments below because I think I have
> changed the topic a little bit. If what I am talking is far different
> from Triplesec's model or aims, we ca just ignore them. Or we may
> merge the schemes as we're discussing.
No this is not on the topic :) but it is an important topic to have on
this ML about SUN's access manager terminology and how their stuff
works. This will help us build a better mouse trap. Perhaps you can
put these kinds of things on another thread.
Alex
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ersin Er <er...@gmail.com>.
On 1/25/07, Alex Karasulu <ak...@apache.org> wrote:
> Hello,
Hi,
I will extend the discussion using my recent experience with the subject.
> I would like to have a discussion on the meaning of these entities in
> general and with respect to how they are modeled in Triplesec today in
> the trunk:
>
> o Permissions
> o Roles
> o Groups
These can be extended to the following entities:
Policies
Subjects
Rules
Conditions
Subjects include any LDAP representable (or somewhat more abstract)
user group: LDAP Group, LDAP User, Different User Selections based on
some filter or bind options etc.
Rules are the actions that can be permitted to subjects. The most
common rule type is URL Access Rules. In Triplesec's case, the thing
supported by this scheme can be named as String Rules. Triplesec does
not really control access but only allows it to be queried. (May be I
am wrong.) A real Access Control server should really take the control
of access to the resources it is protecting. The resource in case of a
URL Access Rule is a URL for example. An Access Control system should
be aware of or should be in contact with the resource it's protecting.
This can generally be provided by an agent installed on the resource
side without effecting the resource itself.
Conditions may depend on the type of Rules or may be generic. For
example, you may specify the time period a resource is allowed to be
accessed.
I will not go on inlining my comments below because I think I have
changed the topic a little bit. If what I am talking is far different
from Triplesec's model or aims, we ca just ignore them. Or we may
merge the schemes as we're discussing.
Cheers,
--
Ersin
> I've been talking to djencks about this stuff for a bit now as we have
> started working together on various aspects of Triplesec. I'd like to
> have a general discussion about these concepts here so we can all be on
> the same page with what they are. Let me kick this off.
>
> Permissions
> ===========
>
> To me a permission is a right that is granted to access a resource or
> perform some kind of protected operation. To a large degree the
> semantics of permissions are undefined except within a specific
> application. For example the permission to accessPayroll may not have
> much meaning outside of an application dealing with payroll management.
>
> In Triplesec (trunk) a permission is just a label without any meaning.
> The semantics of the permission is left up to the application to define.
>
> Roles
> =====
>
> A Role is a collection of permissions associated together to represent
> the rights need by one to perform the actions or activities of a
> function. For our purposes we can just say a role is a collection of
> permissions.
>
> As a collection of permissions which are application specific, roles
> themselves become application specific.
>
> In Triplesec (trunk) a role is just a collection of granted permissions
> with a name. Roles entries in Triplesec have a SINGLE-VALUED 'roleName'
> and a MULTI-VALUED 'grants' attribute. You just add the names of
> permissions to a role entry to add them to the role.
>
> Groups
> ======
>
> Although you can group anything I think we're talking more about groups
> of users in this context. Groups are primarily used to make
> administration tasks easier. By grouping people and the can be managed
> as a single group rather than performing the same upkeep operations on
> all the members of the group.
>
> In Triplesec a group is a static LDAP group (groupOfUniqueNames) or user
> DNs right now. We may expand this to include dynamic groups in the future.
>
> Thoughts? Corrections?
>
> Alex
>
>
>
>
--
Ersin
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
Alex - I sent this before I saw the Hierarchical role
stuff...so we could just scratch it...
--- Ole Ersoy <ol...@yahoo.com> wrote:
> Permissions
> ===========
>
> Ah - Gotcha - If the Permission is present, then
> access is automatically true. Makes sense.
>
> Groups
> ===========
>
> Hmmm - trying to get the profiles part...
>
> I think you are saying it's an efficient way of
> doing
> this:
>
> Suppose I want to know if
>
> "Ole"
>
> has access to
>
> "http://some.typical.resource.watteva"
>
> So I pass "Ole" and
> "http://some.typical.resource.watteva"
>
> to triplesec.
>
> triplesec first checks some indexed structure
> if "Ole" is allowed to get
> "http://some.typical.resource.watteva"
>
> But can't find Ole.
>
> So,
> Triplesec finds groups that "Ole" belongs
> to in some other indexed structure.
>
> Then triplesec retrieves roles assigned to the
> groups.
> Then searches through the rolse for a permission
> containing,
> "http://some.typical.resource.watteva"?
>
> Cheers,
> - Ole
>
>
>
> --- Alex Karasulu <ak...@apache.org> wrote:
>
> > Ole Ersoy wrote:
> > >
> > > Permissions
> > > ===========
> > > So would it be correct to say that a permission
> > > is a Class with 3 properties:
> > >
> > > String name; //The name of the permission
> > > URI resource; //The resource/method/operation
> > > Boolean access; //Whether access is allowed
> >
> > Hmm I don't think I agree. The boolean parameter
> is
> > not necessary in my
> > mind. In general I like simpler systems where you
> > either have a
> > permission to do something or you don't have
> access
> > at all. I don't
> > like the idea of positive and negative
> permissions.
> > IMHO they make
> > things more complex.
> >
> > This is one of my issues with Java security and
> it's
> > implies method.
> >
> > >
> > > Groups
> > > ===========
> > >
> > > Can we create a group of users and assign a role
> > to
> > > that group, thereby assigning the role to all
> the
> > > users in that group?
> >
> > Yes effectively you can achieve this result
> however
> > you would not add
> > the role directly to the group. At least I don't
> > recommend this. The
> > best way IMO to model this in LDAP would be to
> have
> > a profile for the
> > group. This is kind of like a link table.
> >
> > But essentially the answer is yes.
> >
> > Alex
> >
> > > --- Alex Karasulu <ak...@apache.org> wrote:
> > >
> > >> Hello,
> > >>
> > >> I would like to have a discussion on the
> meaning
> > of
> > >> these entities in
> > >> general and with respect to how they are
> modeled
> > in
> > >> Triplesec today in
> > >> the trunk:
> > >>
> > >> o Permissions
> > >> o Roles
> > >> o Groups
> > >>
> > >> I've been talking to djencks about this stuff
> for
> > a
> > >> bit now as we have
> > >> started working together on various aspects of
> > >> Triplesec. I'd like to
> > >> have a general discussion about these concepts
> > here
> > >> so we can all be on
> > >> the same page with what they are. Let me kick
> > this
> > >> off.
> > >>
> > >> Permissions
> > >> ===========
> > >>
> > >> To me a permission is a right that is granted
> to
> > >> access a resource or
> > >> perform some kind of protected operation. To a
> > >> large degree the
> > >> semantics of permissions are undefined except
> > within
> > >> a specific
> > >> application. For example the permission to
> > >> accessPayroll may not have
> > >> much meaning outside of an application dealing
> > with
> > >> payroll management.
> > >>
> > >> In Triplesec (trunk) a permission is just a
> label
> > >> without any meaning.
> > >> The semantics of the permission is left up to
> the
> > >> application to define.
> > >>
> > >> Roles
> > >> =====
> > >>
> > >> A Role is a collection of permissions
> associated
> > >> together to represent
> > >> the rights need by one to perform the actions
> or
> > >> activities of a
> > >> function. For our purposes we can just say a
> > role
> > >> is a collection of
> > >> permissions.
> > >>
> > >> As a collection of permissions which are
> > application
> > >> specific, roles
> > >> themselves become application specific.
> > >>
> > >> In Triplesec (trunk) a role is just a
> collection
> > of
> > >> granted permissions
> > >> with a name. Roles entries in Triplesec have a
> > >> SINGLE-VALUED 'roleName'
> > >> and a MULTI-VALUED 'grants' attribute. You
> just
> > add
> > >> the names of
> > >> permissions to a role entry to add them to the
> > role.
> > >>
> > >> Groups
> > >> ======
> > >>
> > >> Although you can group anything I think we're
> > >> talking more about groups
> > >> of users in this context. Groups are primarily
> > used
> > >> to make
> > >> administration tasks easier. By grouping
> people
> > and
>
=== message truncated ===
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
Permissions
===========
Ah - Gotcha - If the Permission is present, then
access is automatically true. Makes sense.
Groups
===========
Hmmm - trying to get the profiles part...
I think you are saying it's an efficient way of doing
this:
Suppose I want to know if
"Ole"
has access to
"http://some.typical.resource.watteva"
So I pass "Ole" and
"http://some.typical.resource.watteva"
to triplesec.
triplesec first checks some indexed structure
if "Ole" is allowed to get
"http://some.typical.resource.watteva"
But can't find Ole.
So,
Triplesec finds groups that "Ole" belongs
to in some other indexed structure.
Then triplesec retrieves roles assigned to the groups.
Then searches through the rolse for a permission
containing,
"http://some.typical.resource.watteva"?
Cheers,
- Ole
--- Alex Karasulu <ak...@apache.org> wrote:
> Ole Ersoy wrote:
> >
> > Permissions
> > ===========
> > So would it be correct to say that a permission
> > is a Class with 3 properties:
> >
> > String name; //The name of the permission
> > URI resource; //The resource/method/operation
> > Boolean access; //Whether access is allowed
>
> Hmm I don't think I agree. The boolean parameter is
> not necessary in my
> mind. In general I like simpler systems where you
> either have a
> permission to do something or you don't have access
> at all. I don't
> like the idea of positive and negative permissions.
> IMHO they make
> things more complex.
>
> This is one of my issues with Java security and it's
> implies method.
>
> >
> > Groups
> > ===========
> >
> > Can we create a group of users and assign a role
> to
> > that group, thereby assigning the role to all the
> > users in that group?
>
> Yes effectively you can achieve this result however
> you would not add
> the role directly to the group. At least I don't
> recommend this. The
> best way IMO to model this in LDAP would be to have
> a profile for the
> group. This is kind of like a link table.
>
> But essentially the answer is yes.
>
> Alex
>
> > --- Alex Karasulu <ak...@apache.org> wrote:
> >
> >> Hello,
> >>
> >> I would like to have a discussion on the meaning
> of
> >> these entities in
> >> general and with respect to how they are modeled
> in
> >> Triplesec today in
> >> the trunk:
> >>
> >> o Permissions
> >> o Roles
> >> o Groups
> >>
> >> I've been talking to djencks about this stuff for
> a
> >> bit now as we have
> >> started working together on various aspects of
> >> Triplesec. I'd like to
> >> have a general discussion about these concepts
> here
> >> so we can all be on
> >> the same page with what they are. Let me kick
> this
> >> off.
> >>
> >> Permissions
> >> ===========
> >>
> >> To me a permission is a right that is granted to
> >> access a resource or
> >> perform some kind of protected operation. To a
> >> large degree the
> >> semantics of permissions are undefined except
> within
> >> a specific
> >> application. For example the permission to
> >> accessPayroll may not have
> >> much meaning outside of an application dealing
> with
> >> payroll management.
> >>
> >> In Triplesec (trunk) a permission is just a label
> >> without any meaning.
> >> The semantics of the permission is left up to the
> >> application to define.
> >>
> >> Roles
> >> =====
> >>
> >> A Role is a collection of permissions associated
> >> together to represent
> >> the rights need by one to perform the actions or
> >> activities of a
> >> function. For our purposes we can just say a
> role
> >> is a collection of
> >> permissions.
> >>
> >> As a collection of permissions which are
> application
> >> specific, roles
> >> themselves become application specific.
> >>
> >> In Triplesec (trunk) a role is just a collection
> of
> >> granted permissions
> >> with a name. Roles entries in Triplesec have a
> >> SINGLE-VALUED 'roleName'
> >> and a MULTI-VALUED 'grants' attribute. You just
> add
> >> the names of
> >> permissions to a role entry to add them to the
> role.
> >>
> >> Groups
> >> ======
> >>
> >> Although you can group anything I think we're
> >> talking more about groups
> >> of users in this context. Groups are primarily
> used
> >> to make
> >> administration tasks easier. By grouping people
> and
> >> the can be managed
> >> as a single group rather than performing the same
> >> upkeep operations on
> >> all the members of the group.
> >>
> >> In Triplesec a group is a static LDAP group
> >> (groupOfUniqueNames) or user
> >> DNs right now. We may expand this to include
> >> dynamic groups in the future.
> >>
> >> Thoughts? Corrections?
> >>
> >> Alex
> >>
> >>> begin:vcard
> >> fn:Alex Karasulu
> >> n:Karasulu;Alex
> >> org:Apache Software Foundation;Apache Directory
> >> adr:;;1005 N. Marsh Wind Way;Ponte Vedra
> >> ;FL;32082;USA
> >> email;internet:akarasulu@apache.org
> >> title:Member, V.P.
> >> tel;work:(904) 791-2766
> >> tel;fax:(904) 808-4789
> >> tel;home:(904) 808-4789
> >> tel;cell:(904) 315-4901
> >> note;quoted-printable:AIM: alexokarasulu=0D=0A=
> >> MSN: aok123@bellsouth.net=0D=0A=
> >> Yahoo!: alexkarasulu=0D=0A=
> >> IRC: aok=0D=0A=
> >> PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4
> >> 014A 3662 F96F 4E13 70F8=0D=0A=
> >>
> >> x-mozilla-html:FALSE
> >> url:http://people.apache.org/~akarasulu
> >> version:2.1
> >> end:vcard
> >>
> >>
> >
> >
> >
> >
> >
>
____________________________________________________________________________________
> > Bored stiff? Loosen up...
> > Download and play hundreds of games for free on
> Yahoo! Games.
> > http://games.yahoo.com/games/front
> >
>
> > begin:vcard
> fn:Alex Karasulu
> n:Karasulu;Alex
> org:Apache Software Foundation;Apache Directory
> adr:;;1005 N. Marsh Wind Way;Ponte Vedra
> ;FL;32082;USA
> email;internet:akarasulu@apache.org
> title:Member, V.P.
> tel;work:(904) 791-2766
> tel;fax:(904) 808-4789
> tel;home:(904) 808-4789
> tel;cell:(904) 315-4901
> note;quoted-printable:AIM: alexokarasulu=0D=0A=
> MSN: aok123@bellsouth.net=0D=0A=
> Yahoo!: alexkarasulu=0D=0A=
> IRC: aok=0D=0A=
> PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4
> 014A 3662 F96F 4E13 70F8=0D=0A=
>
> x-mozilla-html:FALSE
> url:http://people.apache.org/~akarasulu
> version:2.1
> end:vcard
>
>
____________________________________________________________________________________
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front
Re: [Triplesec] Permissions, Roles and Groups
Posted by Alex Karasulu <ak...@apache.org>.
Ole Ersoy wrote:
>
> Permissions
> ===========
> So would it be correct to say that a permission
> is a Class with 3 properties:
>
> String name; //The name of the permission
> URI resource; //The resource/method/operation
> Boolean access; //Whether access is allowed
Hmm I don't think I agree. The boolean parameter is not necessary in my
mind. In general I like simpler systems where you either have a
permission to do something or you don't have access at all. I don't
like the idea of positive and negative permissions. IMHO they make
things more complex.
This is one of my issues with Java security and it's implies method.
>
> Groups
> ===========
>
> Can we create a group of users and assign a role to
> that group, thereby assigning the role to all the
> users in that group?
Yes effectively you can achieve this result however you would not add
the role directly to the group. At least I don't recommend this. The
best way IMO to model this in LDAP would be to have a profile for the
group. This is kind of like a link table.
But essentially the answer is yes.
Alex
> --- Alex Karasulu <ak...@apache.org> wrote:
>
>> Hello,
>>
>> I would like to have a discussion on the meaning of
>> these entities in
>> general and with respect to how they are modeled in
>> Triplesec today in
>> the trunk:
>>
>> o Permissions
>> o Roles
>> o Groups
>>
>> I've been talking to djencks about this stuff for a
>> bit now as we have
>> started working together on various aspects of
>> Triplesec. I'd like to
>> have a general discussion about these concepts here
>> so we can all be on
>> the same page with what they are. Let me kick this
>> off.
>>
>> Permissions
>> ===========
>>
>> To me a permission is a right that is granted to
>> access a resource or
>> perform some kind of protected operation. To a
>> large degree the
>> semantics of permissions are undefined except within
>> a specific
>> application. For example the permission to
>> accessPayroll may not have
>> much meaning outside of an application dealing with
>> payroll management.
>>
>> In Triplesec (trunk) a permission is just a label
>> without any meaning.
>> The semantics of the permission is left up to the
>> application to define.
>>
>> Roles
>> =====
>>
>> A Role is a collection of permissions associated
>> together to represent
>> the rights need by one to perform the actions or
>> activities of a
>> function. For our purposes we can just say a role
>> is a collection of
>> permissions.
>>
>> As a collection of permissions which are application
>> specific, roles
>> themselves become application specific.
>>
>> In Triplesec (trunk) a role is just a collection of
>> granted permissions
>> with a name. Roles entries in Triplesec have a
>> SINGLE-VALUED 'roleName'
>> and a MULTI-VALUED 'grants' attribute. You just add
>> the names of
>> permissions to a role entry to add them to the role.
>>
>> Groups
>> ======
>>
>> Although you can group anything I think we're
>> talking more about groups
>> of users in this context. Groups are primarily used
>> to make
>> administration tasks easier. By grouping people and
>> the can be managed
>> as a single group rather than performing the same
>> upkeep operations on
>> all the members of the group.
>>
>> In Triplesec a group is a static LDAP group
>> (groupOfUniqueNames) or user
>> DNs right now. We may expand this to include
>> dynamic groups in the future.
>>
>> Thoughts? Corrections?
>>
>> Alex
>>
>>> begin:vcard
>> fn:Alex Karasulu
>> n:Karasulu;Alex
>> org:Apache Software Foundation;Apache Directory
>> adr:;;1005 N. Marsh Wind Way;Ponte Vedra
>> ;FL;32082;USA
>> email;internet:akarasulu@apache.org
>> title:Member, V.P.
>> tel;work:(904) 791-2766
>> tel;fax:(904) 808-4789
>> tel;home:(904) 808-4789
>> tel;cell:(904) 315-4901
>> note;quoted-printable:AIM: alexokarasulu=0D=0A=
>> MSN: aok123@bellsouth.net=0D=0A=
>> Yahoo!: alexkarasulu=0D=0A=
>> IRC: aok=0D=0A=
>> PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4
>> 014A 3662 F96F 4E13 70F8=0D=0A=
>>
>> x-mozilla-html:FALSE
>> url:http://people.apache.org/~akarasulu
>> version:2.1
>> end:vcard
>>
>>
>
>
>
>
> ____________________________________________________________________________________
> Bored stiff? Loosen up...
> Download and play hundreds of games for free on Yahoo! Games.
> http://games.yahoo.com/games/front
>
Re: [Triplesec] Permissions, Roles and Groups
Posted by Ole Ersoy <ol...@yahoo.com>.
Permissions
===========
So would it be correct to say that a permission
is a Class with 3 properties:
String name; //The name of the permission
URI resource; //The resource/method/operation
Boolean access; //Whether access is allowed
Groups
===========
Can we create a group of users and assign a role to
that group, thereby assigning the role to all the
users in that group?
--- Alex Karasulu <ak...@apache.org> wrote:
> Hello,
>
> I would like to have a discussion on the meaning of
> these entities in
> general and with respect to how they are modeled in
> Triplesec today in
> the trunk:
>
> o Permissions
> o Roles
> o Groups
>
> I've been talking to djencks about this stuff for a
> bit now as we have
> started working together on various aspects of
> Triplesec. I'd like to
> have a general discussion about these concepts here
> so we can all be on
> the same page with what they are. Let me kick this
> off.
>
> Permissions
> ===========
>
> To me a permission is a right that is granted to
> access a resource or
> perform some kind of protected operation. To a
> large degree the
> semantics of permissions are undefined except within
> a specific
> application. For example the permission to
> accessPayroll may not have
> much meaning outside of an application dealing with
> payroll management.
>
> In Triplesec (trunk) a permission is just a label
> without any meaning.
> The semantics of the permission is left up to the
> application to define.
>
> Roles
> =====
>
> A Role is a collection of permissions associated
> together to represent
> the rights need by one to perform the actions or
> activities of a
> function. For our purposes we can just say a role
> is a collection of
> permissions.
>
> As a collection of permissions which are application
> specific, roles
> themselves become application specific.
>
> In Triplesec (trunk) a role is just a collection of
> granted permissions
> with a name. Roles entries in Triplesec have a
> SINGLE-VALUED 'roleName'
> and a MULTI-VALUED 'grants' attribute. You just add
> the names of
> permissions to a role entry to add them to the role.
>
> Groups
> ======
>
> Although you can group anything I think we're
> talking more about groups
> of users in this context. Groups are primarily used
> to make
> administration tasks easier. By grouping people and
> the can be managed
> as a single group rather than performing the same
> upkeep operations on
> all the members of the group.
>
> In Triplesec a group is a static LDAP group
> (groupOfUniqueNames) or user
> DNs right now. We may expand this to include
> dynamic groups in the future.
>
> Thoughts? Corrections?
>
> Alex
>
> > begin:vcard
> fn:Alex Karasulu
> n:Karasulu;Alex
> org:Apache Software Foundation;Apache Directory
> adr:;;1005 N. Marsh Wind Way;Ponte Vedra
> ;FL;32082;USA
> email;internet:akarasulu@apache.org
> title:Member, V.P.
> tel;work:(904) 791-2766
> tel;fax:(904) 808-4789
> tel;home:(904) 808-4789
> tel;cell:(904) 315-4901
> note;quoted-printable:AIM: alexokarasulu=0D=0A=
> MSN: aok123@bellsouth.net=0D=0A=
> Yahoo!: alexkarasulu=0D=0A=
> IRC: aok=0D=0A=
> PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4
> 014A 3662 F96F 4E13 70F8=0D=0A=
>
> x-mozilla-html:FALSE
> url:http://people.apache.org/~akarasulu
> version:2.1
> end:vcard
>
>
____________________________________________________________________________________
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front