|
Home > Archive > Apache Directory Project > January 2007 > [Triplesec] Permissions, Roles and Groups
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[Triplesec] Permissions, Roles and Groups
|
|
| Alex Karasulu 2007-01-25, 1:11 pm |
| 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
| |
| Ersin Er 2007-01-25, 7:11 pm |
| On 1/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.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
| |
|
|
| Alex Karasulu 2007-01-25, 7:11 pm |
| Ersin Er wrote:
> On 1/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> Hi,
>
> I will extend the discussion using my recent experience with the subject.
>
>
> 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
| |
| Alex Karasulu 2007-01-25, 7:11 pm |
| 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 <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
>
>
>
>
> ________________________________________
________________________________________
____
> Bored stiff? Loosen up...
> Download and play hundreds of games for free on Yahoo! Games.
> http://games.yahoo.com/games/front
>
| |
| David Jencks 2007-01-25, 7:11 pm |
| 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>
| |
|
|
| Ole Ersoy 2007-01-25, 7:11 pm |
| 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 <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> 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:
>
> of these entities
> modeled in Triplesec
>
> I think these are useful abstractions
>
> 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.
>
> a bit now as we
> of Triplesec. I'd
> concepts here so we
>
> 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.
>
> access a resource
> large degree the
> within a specific
> accessPayroll may not
> dealing with payroll
> without any
> up to the
>
> 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.
> together to
> actions or
> just say a role
> application specific,
> of granted
> Triplesec have a SINGLE-
> attribute. You just
> 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.
>
> talking more about
> primarily used to make
> and the can be
> the same upkeep
> (groupOfUniqueNames) or
> dynamic groups
>
> 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/
| |
| Ole Ersoy 2007-01-25, 7:11 pm |
| 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 <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> 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:
>
> of these entities
> modeled in Triplesec
>
> I think these are useful abstractions
>
> 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.
>
> a bit now as we
> of Triplesec. I'd
> concepts here so we
>
> 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.
>
> access a resource
> large degree the
> within a specific
> accessPayroll may not
> dealing with payroll
> without any
> up to the
>
> 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.
> together to
> actions or
> just say a role
> application specific,
> of granted
> Triplesec have a SINGLE-
> attribute. You just
> 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.
>
> talking more about
> primarily used to make
> and the can be
> the same upkeep
> (groupOfUniqueNames) or
> dynamic groups
>
> 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/
| |
| Ole Ersoy 2007-01-25, 7:11 pm |
| Yeah - The hierarchical role stuff sounds like a must
have.
+1
--- David Jencks <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> 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:
>
> of these entities
> modeled in Triplesec
>
> I think these are useful abstractions
>
> 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.
>
> a bit now as we
> of Triplesec. I'd
> concepts here so we
>
> 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.
>
> access a resource
> large degree the
> within a specific
> accessPayroll may not
> dealing with payroll
> without any
> up to the
>
> 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.
> together to
> actions or
> just say a role
> application specific,
> of granted
> Triplesec have a SINGLE-
> attribute. You just
> 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.
>
> talking more about
> primarily used to make
> and the can be
> the same upkeep
> (groupOfUniqueNames) or
> dynamic groups
>
> 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
| |
| Ole Ersoy 2007-01-25, 7:11 pm |
| Alex - I sent this before I saw the Hierarchical role
stuff...so we could just scratch it...
--- Ole Ersoy <ole_ersoy-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> 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 <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> is
> access
> permissions.
> it's
> the
> however
> have
> meaning
> modeled
> for
> to
> label
> the
> associated
> or
> collection
> just
> people
>
=== message truncated ===
________________________________________
________________________________________
____
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
| |
| Ole Ersoy 2007-01-25, 7:11 pm |
| OK - So if we have aggregate roles / hierarchical
roles, we can elliminate the concept of groups.
Groovy.
--- David Jencks <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> 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:
>
> of these entities
> modeled in Triplesec
>
> I think these are useful abstractions
>
> 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.
>
> a bit now as we
> of Triplesec. I'd
> concepts here so we
>
> 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.
>
> access a resource
> large degree the
> within a specific
> accessPayroll may not
> dealing with payroll
> without any
> up to the
>
> 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.
> together to
> actions or
> just say a role
> application specific,
> of granted
> Triplesec have a SINGLE-
> attribute. You just
> 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.
>
> talking more about
> primarily used to make
> and the can be
> the same upkeep
> (groupOfUniqueNames) or
> dynamic groups
>
> 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
| |
| Emmanuel Lecharny 2007-01-25, 7:11 pm |
| 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
| |
| David Jencks 2007-01-25, 7:11 pm |
|
On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny wrote:
> Ole Ersoy a =E9crit :
>
> AFAIK, groups are very cool to have if you deal with more than one =20
> application. Roles will be Application related, and groups will be =20
> more Users related.
>
> Those two elements are pretty close, but their semantics are =20
> 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 + =20
role <> group assigment is equivalent to the direct user<>role =20
association I was talking about although looked at from the opposite =20
direction?
For jacc we need some kind of idea of groups of applications. I =20
implemented this by allowing multiple appName=3Dfoo,appName=3Dbar,.... =
in =20
dns, in sandbox/triplesec-jacc2. You can have any level of nesting =20
you want, but for jacc you need 2 levels (application and context =20
within the app). I can see having groups of applications you want to =20=
administer at once, for instance a portal app together with a bunch =20
of portlet apps deployed on the portal. So I can see a use for 3 =20
levels.
So what I was actually thinking of is that within a group of =20
applications you'd want all the role names to be the same. The =20
permissions would still be associated with a particular "leaf" =20
application (context for my jacc example) but you'd expect to have =20
the same role names within each sub-applications. Then you'd have =20
the user <> role association at the level of the group of =20
applications that you wanted to deal with together.
There might still be some difference.... I'm not sure.
thanks
david jencks
>
> Emmanuel
| |
| Ole Ersoy 2007-01-25, 7:11 pm |
| 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 <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Ole Ersoy a écrit :
>
> 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.
| |
| Ole Ersoy 2007-01-25, 7:11 pm |
| 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 <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
>
> On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny
> wrote:
>
> with more than one
> and groups will be
> semantics are
>
> 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
>
>
>
>
________________________________________
________________________________________
____
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com...tures_spam.html
| |
| Emmanuel Lecharny 2007-01-25, 7:11 pm |
| David Jencks a écrit :
>
> On Jan 25, 2007, at 4:20 PM, Emmanuel Lecharny wrote:
>
>
>
> 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
>
>
>
>
>
| |
| Ole Ersoy 2007-01-26, 1:11 am |
| Yeah this is really good stuff!
Thanks Guys!
--- Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> David Jencks a écrit :
>
> wrote:
> hierarchical
> with more than one
> and groups will be
> semantics are
> additional issue.....
> "application" then groups +
> direct user<>role
> from the opposite
> applications. I
> appName=foo,appName=bar,.... in
> level of nesting
> (application and context
> applications you want to
> together with a bunch
> see a use for 3
> a group of
> the same. The
> particular "leaf"
> you'd expect to have
> Then you'd have
> group of
> together.
> 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
>
>
>
________________________________________
________________________________________
____
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/
| |
| Ersin Er 2007-01-26, 1:11 am |
| On 1/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> Ersin Er wrote:
>
> 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
>
> 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
>
> Sure.
>
>
> 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
| |
| David Jencks 2007-01-26, 1:11 pm |
|
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 =20
relate to a permission?
For instance, most Java permissions can be represented as a Java =20
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 =20
meaning of permissions but instead delegate to an external system, =20
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 <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
>
>
> ________________________________________
______________________________=20=
> ______________
> Sucker-punch spam with award-winning protection.
> Try the free Yahoo! Mail Beta.
> http://advision.webevents.yahoo.com...tures_spam.html
| |
| David Jencks 2007-01-26, 1:11 pm |
|
On Jan 25, 2007, at 5:08 PM, Emmanuel Lecharny wrote:
> David Jencks a =E9crit :
>
[vbcol=seagreen]
[vbcol=seagreen]
=20[vbcol=seagreen]
[vbcol=seagreen]
>
> Well, I think here we are just playing with semantic
>
> All in all, I really think those things are very similar. You can =20
> perfectly manage the so called 'groups' within a hierarchy of roles.
>
> Now, let's talk about real life, I mean, you know, those big =20
> companies with an IT management which does not manage anything but =20
> budgets... They just stack applications, and ask poor admin to =20
> manage roles, permissions, grants and deny, and of course all those =20=
> applications aren't compatible or does not use the same semantics.
>
> This is a problem. Let say that when using 'groups', you allow a =20
> sort of flexibility, and you help an administrator to create a =20
> feeling of comfort (it's easy to create a group called 'accountant' =20=
> including people allowed to access SAP, SAS and some kind of web =20
> application. The 'roles' will be defined application by application. )
>
> At this point, real life example could help to understand the =20
> concept of chaos and babelization we are faced with...
>
> But, yes, a role hierarchy seems pretty ok if you can manage it. =20
> 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, =20=
> and maybe tomorow, after a full night, ideas will be clearer
So I think I am starting to see something about the purpose of =20
groups.....
suppose you have 10 applications you have to manage security to at =20
the same time, and they are j2ee apps from different vendors, so they =20=
all come with different built-in role names which however mean =20
similar things, such as admin, ADM, Administrator, etc etc. Now you =20
hire a new administrator person and want to give them these app-level =20=
roles all at once.
Groups are one way to solve this, I'm not sure they are the best way =20
yet.
Another possibility is to have more roles. So far we have been =20
saying roles are associated with the smallest application component =20
we are modeling: in the original tsec model that's just the =20
application, in the sandbox test data a sub-application. We could =20
have roles at any level of the application hierarchy and they could =20
include as sub-roles roles at that level and finer levels. So for =20
the j2ee example, you could have a "top level" ADMIN role that =20
included the variously named admin roles from each application. Then =20=
you could assign users individually to this top level role.
I haven't been able to imagine the user experience of administrating =20
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
>
>
| |
| Ole Ersoy 2007-01-26, 1:11 pm |
|
--- David Jencks <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
>
> On Jan 25, 2007, at 4:58 PM, Ole Ersoy wrote:
>
>
> For JACC I also need application hierarchies.
> permission
>
> 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.
>
>
> maybe getting closer :-)
>
Yeah - This is hot stuff :-) Hooah!
Thanks,
- Ole
> thanks
> david jencks
>
[vbcol=seagreen]
> hierarchical
> direct
> at
> any
> a
> the
> you'd
> together.
>
________________________________________
______________________________
>
>
http://advision.webevents.yahoo.com...tures_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
| |
| Ole Ersoy 2007-01-26, 1:11 pm |
| 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 <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
>
> On Jan 25, 2007, at 5:08 PM, Emmanuel Lecharny
> wrote:
>
> wrote:
> hierarchical
> with more than
> related, and groups
> semantics are
> additional issue.....
> "application" then groups
> direct user<>role
> at from the
> applications. I
> appName=foo,appName=bar,....
> have any level of
> (application
> groups of
> instance a
> deployed on the
> a group of
> the same. The
> particular "leaf"
> you'd expect to
> sub-applications. Then
> level of the group
> together.
> sure.
> semantic
> similar. You can
> hierarchy of roles.
> those big
> manage anything but
> poor admin to
> course all those
> same semantics.
> 'groups', you allow a
> to create a
> called 'accountant'
> some kind of web
> application by application. )
> understand the
> with...
> can manage it.
> different names. IMHO.
> sh*t I just wrote,
> 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.
>
> is really important.
>
> I'm really glad we're having this discussion on the
> mailing list!
>
> thanks
> david jencks
>
>
>
________________________________________
________________________________________
____
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
| |
| Ole Ersoy 2007-01-26, 1:11 pm |
| Sorry - Group Hiearchy, should actually be "User
Hierarchy" below
--- Ole Ersoy <ole_ersoy-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> 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 <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
>
> groups.
> deal
> levels
> for
> apps
> within
> be
> not
> know,
> of
> the
> administrator
> you
> will
> the
> manage
> different
>
=== 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
| |
| Enrique Rodriguez 2007-01-27, 1:11 am |
| 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 <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> 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
| |
| Ole Ersoy 2007-01-27, 1:11 am |
| 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 <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
> wrote:
> ...
> we have been
> application component
> just the
> sub-application. We could
> hierarchy and they could
> levels. So for
> ADMIN role that
> application. Then
> 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.
>
> of administrating
> need both.
>
> Again, it seems to me to be a matter more of UI.
>
> 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
| |
| g.w-D3O3hai0Rwxg9hUCZPvPmw@public.gmane.org 2007-01-27, 1:11 pm |
| On Jan 26, 7:21pm, "Apache Directory Developers List" wrote:
} Subject: Re: [Triplesec] Permissions, Roles and Groups
Good morning, I hope this note finds the weekend going
well for everyone.
> On 1/26/07, David Jencks <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
> ...
[vbcol=seagreen]
> 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.
> 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.
> 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.
I've watched the entire Triplesec/RBAC conversation with some
interest. Just a few observations in the FWIW department.
I've worked on these issues for a long time with field experience in
deployments with tens of thousands of user's. If I was to provide any
counsel to the group in their efforts I would advocate that this stuff
has to get simpler rather than more complex.
I tend to have deep reservations about RBAC in terms of practical
implementation. That is neither here nor there. I appreciate the
desire to have a very flexible, finely grained system for executing
authorization decisions. This has to be taken in the context of an
industry which is already being paralyzed by staggering levels of
complexity.
If as a community ADS wants to have an impact on IT practice you would
do well to help foster the understanding of a need to separate
'implementation' of authorization from 'execution' of authorization.
The paper which Enrique co-authored with us for the Kerberos
conference in Ann Arbor is on the confluence site and goes into the
details of this issue.
TripleSec/RBAC are about how to execute an authorization decision. My
advice to the group is to think carefully about how to isolate
execution from implementation. The struggle in this thread to
conceptualize an authorization model is emblematic of the issues which
drove our work on isolating the two components.
A month or two ago I posted a somewhat lengthy reply to David and
Ersin about these issues. It may be worthwhile to re-read those notes
and/or read the Ann Arbor paper on the confluence site.
The most fundamental concept which I think IDfusion has gotten right
is the inherent genetic relationship between a service, a user and an
instance of a service. That relationship provides a natural
heirarchical implementation mechanism for a higher order model based
on TripleSec or any other alternative RBAC based execution model.
Authorization is no different than any other protocol. The one thing
which has been demonstrated in other venues is the power and utility
of proper layering models. Until the need for this is understood in
authorization the use of TripleSec, RBAC or any other sophisticated
authorization model will prove intractable in common practice.
> Enrique
Best wishes to everyhone for a pleasant remainder of the weekend.
}-- End of excerpt from "Apache Directory Developers List"
As always,
Greg
------------------------------------------------------------------------------
The Hurderos Project
Open Identity, Service and Authorization Management
http://www.hurderos.org
"Never try to catch two frogs with one hand."
-- Chinese proverb
| |
| Stephane Bailliez 2007-01-30, 1:11 pm |
| Ersin Er wrote:
>
> 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
| |
| Ole Ersoy 2007-01-30, 1:11 pm |
| 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 <sbailliez-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> Ersin Er wrote:
> entities:
> names for things they
> generic entity
> powerful access control
> extended to the term
> must have. We just use
> for controlling access
> Beyond selecting the
> more conditions like
> Time etc.
> 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/
|
|
|
|
|
904) 791-2766