 |
|
 |
|
|
 |
[Triplesec] Permissions, Roles and Groups |
 |
 |
|
|
01-25-07 06: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
[ Post a follow-up to this message ]
|
|
|
 |
|
 |
|
 |
|
|
|
Re: [Triplesec] Permissions, Roles and Groups |
|
|
|
|
01-26-07 12:11 AM
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
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: [Triplesec] Permissions, Roles and Groups |
|
|
|
|
01-26-07 12:11 AM
Ersin Er wrote:
> On 1/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.o
rg> 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
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: [Triplesec] Permissions, Roles and Groups |
|
|
|
|
01-26-07 12:11 AM
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> wrot
e:
>
>
>
>
>
> ________________________________________
__________________________________
__________
> Bored stiff? Loosen up...
> Download and play hundreds of games for free on Yahoo! Games.
> http://games.yahoo.com/games/front
>
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: [Triplesec] Permissions, Roles and Groups |
|
|
|
|
01-26-07 12:11 AM
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>
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: [Triplesec] Permissions, Roles and Groups |
|
|
|
|
01-26-07 12:11 AM
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> wrot
e:
> 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/
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: [Triplesec] Permissions, Roles and Groups |
|
|
|
|
01-26-07 12:11 AM
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> wrot
e:
> 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/
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: [Triplesec] Permissions, Roles and Groups |
|
|
|
|
01-26-07 12:11 AM
Yeah - The hierarchical role stuff sounds like a must
have.
+1
--- David Jencks <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrot
e:
> 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
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Sponsored Links |
|
|
|
|
 |
All times are GMT. The time now is 02:28 AM. |
 |
|
|
 |
|
 |
|
|
 |
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is OFF
vB code is ON
Smilies are ON
| |
| | |
|
904) 791-2766
> tel;fax
