You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/10/24 19:25:13 UTC
[Triplesec] [AuthZ] Applications and Roles
Applications and Roles
---------------------------------
Application designers devise security permissions and roles specific to
applications. These
roles represent a set of rights authorizing principals to perform operations
or access resources
that must be allowed to fulfill a specific coherent function within
applications. These rights to
access resources are the permissions. The set of these permissions, needed
for a logical
function to be conducted in the application, is a role.
To be concise we extract the following glossary definitions:
Permission:
A right required by a system or application to authorize principals to
perform a
specific operation or access a resource in some manner.
Role:
A set of permissions required by a principal to be authorized to fulfill
a logical function
within a system or application.
Thanks,
Alex
Re: [Triplesec] [AuthZ] Applications and Roles
Posted by Alex Karasulu <ak...@apache.org>.
David this is exactly what you promised not to do but you did it anyway!!!
Your
disrupting a delicate process where I was trying to bring in the community
to
discuss these matters.
We were going to take an approach in small steps:
(1) discuss the problems to be solved with clear language
(2) discuss various research papers on the topic to understand existing
approaches
(3) decide on a design which incorporates these and other ideas
It was this community which pointed out these papers to you in the first
place.
We implement standards here. We're not saying don't use them or we would
not say hey here read these materials.
The point is we need first to discuss the problems we want to solve to
understand
what kind of product we are to deliver. If you think these descriptions are
incorrect
then point out why so we can understand you. Don't just hide behind words
like
the "standard". Again we implement standards and know their value more than
most
people.
Don't just say "no this route is wrong just use NIST material." These
discussions
are not in opposition to the NIST paper. But if they are please state why.
How many people do you think we will be able to engage when we start talking
about
the set definitions for symmetric RBAC from the start of a conversation?
Let's factor in these papers to be considered after we define what it is
we're trying to
do. We want them to be considered of course or we would not have pointed
them out. However you cannot design a solid product that solves the
problems
of the enterprise in a vacuum by just reading academic papers. There needs
to
be some balance.
More inline ...
On 10/24/07, David Jencks <da...@yahoo.com> wrote:
>
> I have some problems with these definitions that I have not had time
> to write up comprehensibly but I would appreciate more discussion
> before we put them on the web site.
Yes I did not want to rush to put them on the website. Emmanuel may have
skipped a step. Guys let's discuss if these descriptions are correct and if
not
why not.
Also these are not definitions for the sake of a standard. They're simply
definitions
for clear every day language while discussing the problem to be solved.
Then we'll
move on and get really academic about it as we delve deeper.
I'd like to counter-propose that we use the definitions from the NIST
> paper or better the standard which it has turned into instead.
I have read the NIST paper several times before you even knew it existed.
These
discussions to the mailing list come much in part from the concepts in the
NIST
paper.
Let's define the problems we want to solve clearly then lets pull in these
papers
and discuss that.
To me
> they are a lot more self contained and clearer. For instance, Alex's
> definitions below use the term "principal" which I don't think he's
> defined yet. I think there's a good chance that terms or definitions
> that have been used by the research community for 10-15 years have
> clearer definitions and fewer conceptual holes or redundancies than
> terms or definitions we come up with even if based on common practice.
Yes I should have defined principal. But I think I was pretty damn clear in
my
descriptions. I am not trying to define a standard here or replace NIST.
Everything
that I have said complies with the NIST paper. You're attempting to make it
sound
as if it does not and trying to distract from a simple approach. I am
taking this in
baby steps.
1). Discuss the problems in terms people on this list can understand but be
clear
2). Pull in the existing research on these topics (yes NIST paper)
3). Come to some conclusions
4). Propose an implementation path
NIST paper:
> http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf
>
> ANSI standard based on this: (I have not read this yet):
> http://www.techstreet.com/cgi-bin/detail?product_id=1151353
>
I looked at this one too. But we need discussion because interpretations
can be flawed.
The whole point to this effort is to discuss and define the real world
problem first then to
delve into the research that has dealt with it. This way we can express our
interpretations
and flush out and divergent view points.
Alex
Re: [Triplesec] [AuthZ] Applications and Roles
Posted by David Jencks <da...@yahoo.com>.
I have some problems with these definitions that I have not had time
to write up comprehensibly but I would appreciate more discussion
before we put them on the web site.
I'd like to counter-propose that we use the definitions from the NIST
paper or better the standard which it has turned into instead. To me
they are a lot more self contained and clearer. For instance, Alex's
definitions below use the term "principal" which I don't think he's
defined yet. I think there's a good chance that terms or definitions
that have been used by the research community for 10-15 years have
clearer definitions and fewer conceptual holes or redundancies than
terms or definitions we come up with even if based on common practice.
NIST paper:
http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf
ANSI standard based on this: (I have not read this yet):
http://www.techstreet.com/cgi-bin/detail?product_id=1151353
thanks
david jencks
On Oct 24, 2007, at 2:37 PM, Emmanuel Lecharny wrote:
> Very clear.
>
> Do we have those definitions on the web site, or should we inject
> them ?
>
> On 10/24/07, Alex Karasulu <ak...@apache.org> wrote:
>> Applications and Roles
>> ---------------------------------
>>
>> Application designers devise security permissions and roles
>> specific to
>> applications. These
>> roles represent a set of rights authorizing principals to perform
>> operations
>> or access resources
>> that must be allowed to fulfill a specific coherent function within
>> applications. These rights to
>> access resources are the permissions. The set of these
>> permissions, needed
>> for a logical
>> function to be conducted in the application, is a role.
>>
>> To be concise we extract the following glossary definitions:
>>
>> Permission:
>> A right required by a system or application to authorize
>> principals to
>> perform a
>> specific operation or access a resource in some manner.
>>
>> Role:
>> A set of permissions required by a principal to be authorized
>> to fulfill
>> a logical function
>> within a system or application.
>>
>> Thanks,
>> Alex
>>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
Re: [Triplesec] [AuthZ] Applications and Roles
Posted by Emmanuel Lecharny <el...@gmail.com>.
Very clear.
Do we have those definitions on the web site, or should we inject them ?
On 10/24/07, Alex Karasulu <ak...@apache.org> wrote:
> Applications and Roles
> ---------------------------------
>
> Application designers devise security permissions and roles specific to
> applications. These
> roles represent a set of rights authorizing principals to perform operations
> or access resources
> that must be allowed to fulfill a specific coherent function within
> applications. These rights to
> access resources are the permissions. The set of these permissions, needed
> for a logical
> function to be conducted in the application, is a role.
>
> To be concise we extract the following glossary definitions:
>
> Permission:
> A right required by a system or application to authorize principals to
> perform a
> specific operation or access a resource in some manner.
>
> Role:
> A set of permissions required by a principal to be authorized to fulfill
> a logical function
> within a system or application.
>
> Thanks,
> Alex
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Triplesec] [AuthZ] Applications and Roles
Posted by Alex Karasulu <ak...@apache.org>.
Hi David,
I'm going to start condensing a bit by removing points we agree on again.
On 10/31/07, David Jencks <da...@yahoo.com> wrote:
...
> that we agree on the role-permission side of roles :-)
>
Yes but not on putting users into roles.
...
I don't think so. In my thinking a role or permission is globally unique,
> for instance if we are using ldap its "full name" might be its dn. So far I
> can't imagine any use except increasing confusion for any concept of
> redefining. I'll listen if you have some ideas :-)
>
We both agree on (really like) this idea of using scopes with visibility
rules. Perhaps in a little
bit we can add more clarification to this concept and better define the
scoping rules that govern it.
...
> #2 is about Role assignment and does not belong in the definition of a
> Role.
> Roles are independent of users and groups.
>
>
> I'm not convinced. If roles are associated to either users or groups, we
> can talk about the association at either end: either at the role end or the
> [user|group] end.
>
Well my aim was not to take any particular side by defining an entity in our
model called a
role_assignment. The role_assignment does the association and then
direction does not matter.
Similarly we could talk about the role-permission association at either the
> role end or the permission end. If you don't like this I'm going to request
> that we describe all the associations as separate entities so there is no
> bias about which way the association points.
>
Great this is what I've been doing all along with role assignments.
role-assignment
objects contain the associations of users to roles. This way roles are
purely defined
as a set of references to permissions.
That's an implementation detail.
>
Not really we're still dealing with an abstract model. Furthermore it's a
matter of being impartial.
...
Alex
Re: [Triplesec] [AuthZ] Applications and Roles
Posted by Emmanuel Lecharny <el...@gmail.com>.
My comments inline...
>>
>> > Applications and Roles
>> > ---------------------------------
>> >
>> > Application designers devise security permissions and roles
>> > specific to applications. These
>> > roles represent a set of rights authorizing principals to perform
>> > operations or access resources
>> > that must be allowed to fulfill a specific coherent function within
>> > applications. These rights to
>> > access resources are the permissions. The set of these
>> > permissions, needed for a logical
>> > function to be conducted in the application, is a role.
>> >
>> > To be concise we extract the following glossary definitions:
>> >
>> I think we should start with
>>
>> Users: People (or maybe systems) that need to use the system. Often
>> the term Principal is used but I find it extremely confusing because
>> the principals I know about in java are only aspects of someones
>> identity in the system. A Principal might have started out as
>> something that completely represents a single user but I think it is
>> used in so many other ways now that we should avoid it to describe a
>> single user. Since I find "principal" so confusing I'm going to use
>> "user" instead in what follows: we can always change it back.
>>
>>
>> Although I don't see the complexity or difference of using the term
>> principal
>> to refer to an identity I can stick to applying term user.
>>
>> <an-aside>
>> Incidentally I understand a principal to contain a unique key for
>> referring to an
>> identity for the sake of authorization.
>>
>> I'm fine with simplifying the conversation for now and referring to just
>> users especially since technically non-human users driven by
>> "systems" or processes *USE* the application too. It's all the same
>> to me.
>> Point being, the term user, does not necessarily connotate a human
>> identity. In both cases you must verify (authenticate) the identity
>> using
>> one or more of their credentials.
>> </an-aside>
>>
>> It's a minor point and I really don't want to get anyone
>> distracted but I tend to think of "systems" that need to use the
>> system as "frozen identities" of the people who set them up.
>>
>>
>> Some systems come out of the box with a power user (a.k.a.
>> administrator).
>> I don't see where this "frozen user" term adds to the discussion.
>> Sure the
>> permissions or roles of these kinds of users may not change but
>> that's not
>> set in stone: several systems advise disabling access by such users
>> after
>> setup there by removing their authorization to the system completely.
>>
>> In
>> other words someone had to start the system and they had better have
>> had the authorization to set it up to do whatever it is supposed to.
>> So it seems to me as if they froze part of their identity into the
>> system's authorizations. I'd be interested to know if this seems
>> like a reasonable point of view to others.
>>
>>
>> Such initial administrative users exist and no, they are not necessarily
>> always frozen. I cannot find any value in this term/concept with
>> regard to this
>> discussion.
>
> OK fine, I didn't mean to use it as a definition of anything, its not
> essential so I should have left it out. I was mostly thinking that
> there might be a way to think of "users" that are "systems" as people
> also. I'm happy to think of "systems" as users in their own right.
I hope that I'm not totally off side, but I will try to make some point
here about 'users' and 'principals'.
'users' is limited to real people, somehow. Principals defines much more
things : a service, hosts, users ... At least, this is the way Kerberos
defines Principal.
Extract from RFC 4120, par 1.1 :
"Kerberos provides a means of verifying the identities of principals,
(e.g., a workstation user or a network server) ... "
This is a little bit different from what David defines as a User, but
it's necessary when you define permissions, as a service might have
Roles and Permissions, too. I'm a little bit unconfortable about
designing a service (or a computer :) as a Human. Isn't it, HAL ?
>>
>> > Permission:
>> > A right required by a system or application to authorize
>> > principals to perform a
>> > specific operation or access a resource in some manner.
>> >
>> This is kind of unclear to me and mentions the so-far undefined
>> terms
>> system and application.
>>
>>
>> <discussion-agreement>
>>
>> Let's stop here and make a little agreement to be fair in our approach to
>> disassembling our arguments and counter arguments.
>>
>> You use the terms "system" and "application" freely below even though you
>> don't define them either. And here above you're using the fact that
>> I did not
>> define them as a reason why my definition is flawed.
>>
>> Why would you do that?
>>
>> If we resort to these kinds of hypocritical tactics as a basis to our
>> debate
>> then we're not going to arrive anywhere. This will turn from an
>> intelligent
>> productive debate into a counter productive bickering session.
>>
>> Furthermore if you and I don't know what a system or application is in
>> the abstract sense and we need to define these concepts as well we might
>> as well start writing a dictionary before building Triplesec. Also
>> if we are
>> confused by what is a system or an application then we should not be
>> clogging
>> this ML this with our conversations.
>>
>> Let's draw a reasonable line and respect it. What do you say?
>
> good idea. I make plenty of mistakes and hope you will point them
> out. I was trying to keep my use of undefined terms in general
> discussion rather than the definitions themselves but seem to have
> slipped.
So do we consider that the Permission definition is correct and agreed ?
"A permission is some operation or set of operations that can be
performed on some resource or set of resources."
Are we all ok with this ?
>>
>> To
>> make administering permissions on these objects manageable I
>> think we
>> may want to introduce a hierarchical scope concept.
>>
>>
>> Yes this is the term we adopted after studying a few other
>> authorization managers.
>> Microsoft's AzMan for example has the concept of scopes.
>>
>> I agree that we have scopes where potentially different authorization
>> policies are in
>> effect or applied.
>>
>> Scopes: a tree of scope objects, where we assign each object to one
>> scope. For instance, a module, application, set of applications,
>> division, enterprise...
>>
>>
>> I like this very much. Broadening the use of the scope concept across
>> all the
>> possible hierarchical relationships in an enterprise can serve us well.
Scopes does not seems to be a problem at all :)
So is hierarchy of roles.
<snip>the rest of this long mail</snip>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Triplesec] [AuthZ] Applications and Roles
Posted by David Jencks <da...@yahoo.com>.
On Oct 30, 2007, at 8:04 PM, Alex Karasulu wrote:
> Hi David,
>
> I wanted to wait a little while for others to respond but we're
> running out
> of time so I will continue to engage.
Thanks!
>
> On 10/30/07, David Jencks < david_jencks@yahoo.com> wrote:
>
> On Oct 24, 2007, at 10:25 AM, Alex Karasulu wrote:
>
> > Applications and Roles
> > ---------------------------------
> >
> > Application designers devise security permissions and roles
> > specific to applications. These
> > roles represent a set of rights authorizing principals to perform
> > operations or access resources
> > that must be allowed to fulfill a specific coherent function within
> > applications. These rights to
> > access resources are the permissions. The set of these
> > permissions, needed for a logical
> > function to be conducted in the application, is a role.
> >
> > To be concise we extract the following glossary definitions:
> >
> I think we should start with
>
> Users: People (or maybe systems) that need to use the system. Often
> the term Principal is used but I find it extremely confusing because
> the principals I know about in java are only aspects of someones
> identity in the system. A Principal might have started out as
> something that completely represents a single user but I think it is
> used in so many other ways now that we should avoid it to describe a
> single user. Since I find "principal" so confusing I'm going to use
> "user" instead in what follows: we can always change it back.
>
> Although I don't see the complexity or difference of using the term
> principal
> to refer to an identity I can stick to applying term user.
>
> <an-aside>
> Incidentally I understand a principal to contain a unique key for
> referring to an
> identity for the sake of authorization.
>
> I'm fine with simplifying the conversation for now and referring to
> just
> users especially since technically non-human users driven by
> "systems" or processes *USE* the application too. It's all the
> same to me.
> Point being, the term user, does not necessarily connotate a human
> identity. In both cases you must verify (authenticate) the
> identity using
> one or more of their credentials.
> </an-aside>
>
> It's a minor point and I really don't want to get anyone
> distracted but I tend to think of "systems" that need to use the
> system as "frozen identities" of the people who set them up.
>
> Some systems come out of the box with a power user (a.k.a.
> administrator).
> I don't see where this "frozen user" term adds to the discussion.
> Sure the
> permissions or roles of these kinds of users may not change but
> that's not
> set in stone: several systems advise disabling access by such users
> after
> setup there by removing their authorization to the system completely.
>
> In
> other words someone had to start the system and they had better have
> had the authorization to set it up to do whatever it is supposed to.
> So it seems to me as if they froze part of their identity into the
> system's authorizations. I'd be interested to know if this seems
> like a reasonable point of view to others.
>
> Such initial administrative users exist and no, they are not
> necessarily
> always frozen. I cannot find any value in this term/concept with
> regard to this
> discussion.
OK fine, I didn't mean to use it as a definition of anything, its not
essential so I should have left it out. I was mostly thinking that
there might be a way to think of "users" that are "systems" as people
also. I'm happy to think of "systems" as users in their own right.
>
> > Permission:
> > A right required by a system or application to authorize
> > principals to perform a
> > specific operation or access a resource in some manner.
> >
> This is kind of unclear to me and mentions the so-far undefined terms
> system and application.
>
> <discussion-agreement>
>
> Let's stop here and make a little agreement to be fair in our
> approach to
> disassembling our arguments and counter arguments.
>
> You use the terms "system" and "application" freely below even
> though you
> don't define them either. And here above you're using the fact
> that I did not
> define them as a reason why my definition is flawed.
>
> Why would you do that?
>
> If we resort to these kinds of hypocritical tactics as a basis to
> our debate
> then we're not going to arrive anywhere. This will turn from an
> intelligent
> productive debate into a counter productive bickering session.
>
> Furthermore if you and I don't know what a system or application is in
> the abstract sense and we need to define these concepts as well we
> might
> as well start writing a dictionary before building Triplesec. Also
> if we are
> confused by what is a system or an application then we should not
> be clogging
> this ML this with our conversations.
>
> Let's draw a reasonable line and respect it. What do you say?
good idea. I make plenty of mistakes and hope you will point them
out. I was trying to keep my use of undefined terms in general
discussion rather than the definitions themselves but seem to have
slipped.
>
> </discussion-agreement>
>
> Looking at permissions I know about they
> seem to specify one or more object of some kind and one or more
> operations of some kind. For instance a file read permission
> describes a file (object) and operation (read). A web permission may
> describe a set of urls and a bunch of http methods. To me it is
> clearer to leave out who might want or use a permission or the
> context (application?) in which it is meaningful from its definition
>
> Now this is a good point. I like that. Let's leave out the
> context (application)
> from the definition of a permission. This helps with respect to
> the scope concept
> below.
>
> A permission is some operation or set of operations that can be
> performed on some
> resource or set of resources.
>
> The resource[s] and the operation[s] are specific to some context
> (want to say
> application here) though. It can be specific to a subcontext within
> another context
> etc.
>
> and say that we have a set of objects and a set of operations and a
> permission is a bunch of operations on a bunch of objects.
>
> Yes and some external system determines the semantics of that
> permission generally.
> In the screwed up security landscape of Java this is often not the
> case with Java Permissions
> and the implies() method. But let's not go into that yet - we may
> never get out.
>
> So for this to make sense we need a couple more categories:
>
> Objects: "things" that can be operated on, such as program bits or
> components
>
> Operations: stuff you can do to objects.
>
> Now, objects usually show up in bunches such as applications.
> However applications sometimes have modules inside and sometimes
> themselves come in bunches. For instance javaee ears have web and
> ejb modules inside, and people sometimes deploy large javaee projects
> as more than one ear, that use each other. With many applications
> deployed, there can easily be hundreds or thousands of objects.
>
> See <discussion-agreement> section!
ok, but this is motivating discussion rather than definition text :-)
>
> To
> make administering permissions on these objects manageable I think we
> may want to introduce a hierarchical scope concept.
>
> Yes this is the term we adopted after studying a few other
> authorization managers.
> Microsoft's AzMan for example has the concept of scopes.
>
> I agree that we have scopes where potentially different
> authorization policies are in
> effect or applied.
>
> Scopes: a tree of scope objects, where we assign each object to one
> scope. For instance, a module, application, set of applications,
> division, enterprise...
>
> I like this very much. Broadening the use of the scope concept
> across all the
> possible hierarchical relationships in an enterprise can serve us
> well.
>
> > Role:
> > A set of permissions required by a principal to be authorized to
> > fulfill a logical function
> > within a system or application.
> >
>
> I think there are two ways of looking at roles and permissions. One,
> used here, says that a role is a set of permissions. The other says
> that a role is an entity with permissions associated to it. They are
> really really close but I prefer the second for these reasons:
>
> I don't think there is much difference here. I thought I implied
> association but
> was referring to a set of associations.
I wasn't sure, so wanted us to get very clear. I'm glad you meant
association to a named entity :-)
>
> Associations are accomplished by using some mechanism to refer to
> existing
> objects. This is exactly what we do when we include the names of
> permissions
> inside a role. We are using the name of the permission to refer to
> the permission
> instead of defining the permission in the role.
>
> We can also say roles have a set of references to the permissions
> they are associated
> with. The bottom line is:
>
> Role:
>
> o Has a id/name hence a way we can differentiate it from other
> Roles
>
> o Has a *set* of permissions (often positive grants)
> *associated* with it (negative denials
> are possible too).
>
> Are we not talking about the same thing?
yes!
>
> 1. One of the characteristics of the roles I know about is that they
> have names.
>
> Did you presume my idea of a role was anonymous? How did you think
> I would differentiate
> between two different Roles?
>
> 2. I think its easier to think about role hierarchy with roles as
> entities.
>
> What do you mean: "roles as entities"? An entity is just something
> that exists to me. Roles
> exist. Therefore Roles are entities. A Role is an entity as we
> defined it above.
>
> Its certainly possible to do with sets -- role A contains
> or implies role B if B is a subset of A -- but it is hard to think
> about what this means if you assign or unassign a permission to B.
> Do you unassign it from A as well or does A no longer imply B? With
> role entities
>
> Again I don't think I'm getting what you mean by entities here.
> Seems like you're
> implying something about their security characteristics: as if they
> are authenticated
> users or something. Please clarify because until you do I will
> presume that what you
> really want to say is:
I was confused about what you meant. You've clarified that you meant
the same thing I meant by "role entity".
>
> "let's expand the definition of Role to include Role
> hierarchies." Am I right?
I definitely want role hierarchies.
>
> BTW I very much in favor of Role hierarchies.
>
> you can assign permissions to B and make B a "junior"
> role to A and then A gets B's permissions without explicit assignment
> of permissions to A.
>
> OK this is easy let's expand the definition of a Role now to
> include Role
> hierarchies:
>
> Role:
>
> o has some id/name (call it "Role A") to differentiate it from
> other roles
> o may be associated with a set of zero or more permissions
> o may be associated with a set of zero or more other roles
> ("Role B" and
> "Role C" for example) from which it (Role A) inherits the
> union of the
> permission associations from these other roles (Role B and
> Role C)
>
> (1) Notice these are all set wise operations hence my use of the
> term set - we're
> talking about the same thing here.
>
> (2) The above re-definition of your terms, like your definition,
> presumes multiple inheritance
> in the Role hierarchy since more than one role (Roles B and C)
> can be associated
> with Role A.
>
> (3) I left out the whole thing with positive (grants) and negative
> (denials) permissions
> for simplicity but we can put that in too if you like.
>
> 3. I don't see how to deal with denied permissions with the role-as-
> set-of permissions approach.
>
> You have set wise operators: union, difference, and intersection.
> The difference operator
> would be used when dealing with denials. Regardless denials are not
> required to do the job.
> They're convenient but not necessary and some may debate this too.
>
> With the role-as-entity approach you
> just have more associations with permissions (and roles, for denied
> subsidiary roles).
>
> Again role-as-entity: what does this mean?
that we agree on the role-permission side of roles :-)
>
>
> On the other side, we need to associate roles and users. (If we need
> groups in our model, we need to be able to associate roles and groups
> too).
>
> <WARNING>
> You're now mixing role assignment to users into a thread on defining
> applications and roles breaking with the attempt to divide and conquer
> all the parts of this topic.
> </WARNING>
>
> I'm snipping the assignment of roles to users parts here and taking
> what
> is of value to this thread. I think you make good points about
> using scopes
> instead of applications to enable nestable contexts.
>
> ...
>
> if we decide to use the scope
> idea we want to attach a role to a scope, and say it can only deal
> with permissions on objects in that scope. So I propose:
>
> I like this point you make: "role [in a scope], ... can only [be
> associated] with
> permissions in that scope."
>
> Question:
>
> With scope nesting which I presume you support (and me likes), what
> do you
> propose for visibility (doh scoping) rules?
>
> For example you have 3 nested scopes: A, B, and C. B is
> subordinate to A. C is
> subordinate to B.
>
> Subquestions:
>
> (1) Can a role defined in scope B be associated with the
> permissions defined in scope A?
> Restated: Are roles in scopes including other nested
> scopes able to resolve and hence
> be associate with permissions defined in
> the nested scopes.
IIUC A is larger than and contains B, and B is larger than and
contains C. I mean that a role defined in or attached to scope B can
be associated with permissions in B or C but not A.
>
> (2) Can roles and permissions be redefined in nested scopes?
I don't think so. In my thinking a role or permission is globally
unique, for instance if we are using ldap its "full name" might be
its dn. So far I can't imagine any use except increasing confusion
for any concept of redefining. I'll listen if you have some ideas :-)
>
> (3) If roles and permissions can be redefined (answer to #2 is
> true) then does the definition
> in the nearest scope to the reference have greater
> visibility?
>
> Question:
>
> If I take your statement here literally (repeating here to be
> fluid):
>
> "role [in a scope], ... can only [be associated] with
> permissions in that scope."
>
> then really there are no scoping (visibility) rules since the
> definitions of other
> roles and permissions (even if using the same identifier) are
> not visible outside the
> existing scope. Meaning a role in scope B can only see
> permissions in scope
> B but not the permissions in scope A as would be expected for
> example with
> Java variables with it's scoping rules within nested blocks.
>
> If this is the case then what is the point to nesting and the
> scope concept?
yes., that's what I was thinking for which permissions could be
associated with a role. However the point is that A can have a role
that "includes" roles in B or C. The way I see this working is that
you have an application with several modules in it. The permissions
are defined at the module level. Application level roles (defined by
the app developer) are defined at the application level and contain
permissions in the modules. Then in the larger scope containing the
application, maybe a department or the enterprise, scopes meaningful
to many applications have the application level scopes assigned to
them. I hope that's comprehensible :-)
>
> MS AzMan BTW deals with visibility in the way Java does with
> variables with block
> nesting. It may have some subtle differences tho I cannot
> remember exactly off the
> top of my head.
>
> Role: a named entity where
> 1. permissions are associated to a role
>
> #2 is about Role assignment and does not belong in the definition
> of a Role.
> Roles are independent of users and groups.
I'm not convinced. If roles are associated to either users or
groups, we can talk about the association at either end: either at
the role end or the [user|group] end. Similarly we could talk about
the role-permission association at either the role end or the
permission end. If you don't like this I'm going to request that we
describe all the associations as separate entities so there is no
bias about which way the association points. That's an
implementation detail.
>
>
> 3. there's a (multiple) inheritance relationship between roles.
> From the point of view of permissions
>
> +1
>
> 4. If we need groups, groups are associated to a role.
>
> We don't need to talk about users or groups at all when defining a
> role. Roles are
> independent of users and groups which are environment specific
> entities. Technically
> in an any reality (environment), the role definitions devised by
> developers can be used and
> associated with foobar objects and sets of foobar objects. We
> don't care. This only
> matters when we drop our definitions into some environment.
>
> Just keep in mind a developer or architect need not have users or
> groups to define the roles
> and permissions in their applications.
>
> So let's stop mixing Role assignment on deployment with defining
> what a Role is in it's
> essence (abstractly).
>
> 5. If we have scopes, roles are attached to a scope and all the
> permissions associated to the role (directly or through inheritance)
> have objects in the scope.
>
> Are you suggesting that inheritance of roles can only occur from
> the same scope?
>
> Or are you suggesting that inheritance of roles from other scopes
> is possible and
> this automatically pulls those inherited roles and their associated
> permissions into the
> present scope?
>
> Sorry this last point #5 was not very clear for me.
OK, that's not too clear :-) maybe I can do better :-D
Suppose we have a scope S. It's the root of a subtree of scopes (all
its contained scopes, and theirs, etc ....). Each one of those
scopes has roles and permissions associated with it, so we have a set
of roles and a set of permissions that appear in the subtree. A role
attached to S can only be associated with roles and permissions from
these sets. Once again for a role R attached to S, every role and
permission associated (directly) with R is attached to some scope in
the subtree rooted at S.
Thanks!
I think we are getting somewhere!
david jencks
>
> Thanks,
> Alex
>
>
Re: [Triplesec] [AuthZ] Applications and Roles
Posted by Alex Karasulu <ak...@apache.org>.
Hi David,
I wanted to wait a little while for others to respond but we're running out
of time so I will continue to engage.
On 10/30/07, David Jencks <da...@yahoo.com> wrote:
>
>
> On Oct 24, 2007, at 10:25 AM, Alex Karasulu wrote:
>
> > Applications and Roles
> > ---------------------------------
> >
> > Application designers devise security permissions and roles
> > specific to applications. These
> > roles represent a set of rights authorizing principals to perform
> > operations or access resources
> > that must be allowed to fulfill a specific coherent function within
> > applications. These rights to
> > access resources are the permissions. The set of these
> > permissions, needed for a logical
> > function to be conducted in the application, is a role.
> >
> > To be concise we extract the following glossary definitions:
> >
> I think we should start with
>
> Users: People (or maybe systems) that need to use the system. Often
> the term Principal is used but I find it extremely confusing because
> the principals I know about in java are only aspects of someones
> identity in the system. A Principal might have started out as
> something that completely represents a single user but I think it is
> used in so many other ways now that we should avoid it to describe a
> single user. Since I find "principal" so confusing I'm going to use
> "user" instead in what follows: we can always change it back.
Although I don't see the complexity or difference of using the term
principal
to refer to an identity I can stick to applying term user.
<an-aside>
Incidentally I understand a principal to contain a unique key for referring
to an
identity for the sake of authorization.
I'm fine with simplifying the conversation for now and referring to just
users especially since technically non-human users driven by
"systems" or processes *USE* the application too. It's all the same to me.
Point being, the term user, does not necessarily connotate a human
identity. In both cases you must verify (authenticate) the identity using
one or more of their credentials.
</an-aside>
It's a minor point and I really don't want to get anyone
> distracted but I tend to think of "systems" that need to use the
> system as "frozen identities" of the people who set them up.
Some systems come out of the box with a power user (a.k.a. administrator).
I don't see where this "frozen user" term adds to the discussion. Sure the
permissions or roles of these kinds of users may not change but that's not
set in stone: several systems advise disabling access by such users after
setup there by removing their authorization to the system completely.
In
> other words someone had to start the system and they had better have
> had the authorization to set it up to do whatever it is supposed to.
> So it seems to me as if they froze part of their identity into the
> system's authorizations. I'd be interested to know if this seems
> like a reasonable point of view to others.
Such initial administrative users exist and no, they are not necessarily
always frozen. I cannot find any value in this term/concept with regard to
this
discussion.
> Permission:
> > A right required by a system or application to authorize
> > principals to perform a
> > specific operation or access a resource in some manner.
> >
> This is kind of unclear to me and mentions the so-far undefined terms
> system and application.
<discussion-agreement>
Let's stop here and make a little agreement to be fair in our approach to
disassembling our arguments and counter arguments.
You use the terms "system" and "application" freely below even though you
don't define them either. And here above you're using the fact that I did
not
define them as a reason why my definition is flawed.
Why would you do that?
If we resort to these kinds of hypocritical tactics as a basis to our debate
then we're not going to arrive anywhere. This will turn from an intelligent
productive debate into a counter productive bickering session.
Furthermore if you and I don't know what a system or application is in
the abstract sense and we need to define these concepts as well we might
as well start writing a dictionary before building Triplesec. Also if we
are
confused by what is a system or an application then we should not be
clogging
this ML this with our conversations.
Let's draw a reasonable line and respect it. What do you say?
</discussion-agreement>
Looking at permissions I know about they
> seem to specify one or more object of some kind and one or more
> operations of some kind. For instance a file read permission
> describes a file (object) and operation (read). A web permission may
> describe a set of urls and a bunch of http methods. To me it is
> clearer to leave out who might want or use a permission or the
> context (application?) in which it is meaningful from its definition
Now this is a good point. I like that. Let's leave out the context
(application)
from the definition of a permission. This helps with respect to the scope
concept
below.
A permission is some operation or set of operations that can be performed on
some
resource or set of resources.
The resource[s] and the operation[s] are specific to some context (want to
say
application here) though. It can be specific to a subcontext within another
context
etc.
and say that we have a set of objects and a set of operations and a
> permission is a bunch of operations on a bunch of objects.
Yes and some external system determines the semantics of that permission
generally.
In the screwed up security landscape of Java this is often not the case with
Java Permissions
and the implies() method. But let's not go into that yet - we may never get
out.
So for this to make sense we need a couple more categories:
>
> Objects: "things" that can be operated on, such as program bits or
> components
>
> Operations: stuff you can do to objects.
>
> Now, objects usually show up in bunches such as applications.
However applications sometimes have modules inside and sometimes
> themselves come in bunches. For instance javaee ears have web and
> ejb modules inside, and people sometimes deploy large javaee projects
> as more than one ear, that use each other. With many applications
> deployed, there can easily be hundreds or thousands of objects.
See <discussion-agreement> section!
To
> make administering permissions on these objects manageable I think we
> may want to introduce a hierarchical scope concept.
Yes this is the term we adopted after studying a few other authorization
managers.
Microsoft's AzMan for example has the concept of scopes.
I agree that we have scopes where potentially different authorization
policies are in
effect or applied.
Scopes: a tree of scope objects, where we assign each object to one
> scope. For instance, a module, application, set of applications,
> division, enterprise...
I like this very much. Broadening the use of the scope concept across all
the
possible hierarchical relationships in an enterprise can serve us well.
> Role:
> > A set of permissions required by a principal to be authorized to
> > fulfill a logical function
> > within a system or application.
> >
>
> I think there are two ways of looking at roles and permissions. One,
> used here, says that a role is a set of permissions. The other says
> that a role is an entity with permissions associated to it. They are
> really really close but I prefer the second for these reasons:
I don't think there is much difference here. I thought I implied
association but
was referring to a set of associations.
Associations are accomplished by using some mechanism to refer to existing
objects. This is exactly what we do when we include the names of
permissions
inside a role. We are using the name of the permission to refer to the
permission
instead of defining the permission in the role.
We can also say roles have a set of references to the permissions they are
associated
with. The bottom line is:
Role:
o Has a id/name hence a way we can differentiate it from other Roles
o Has a *set* of permissions (often positive grants) *associated* with it
(negative denials
are possible too).
Are we not talking about the same thing?
1. One of the characteristics of the roles I know about is that they
> have names.
Did you presume my idea of a role was anonymous? How did you think I would
differentiate
between two different Roles?
2. I think its easier to think about role hierarchy with roles as
> entities.
What do you mean: "roles as entities"? An entity is just something that
exists to me. Roles
exist. Therefore Roles are entities. A Role is an entity as we defined it
above.
Its certainly possible to do with sets -- role A contains
> or implies role B if B is a subset of A -- but it is hard to think
> about what this means if you assign or unassign a permission to B.
> Do you unassign it from A as well or does A no longer imply B? With
> role entities
Again I don't think I'm getting what you mean by entities here. Seems like
you're
implying something about their security characteristics: as if they are
authenticated
users or something. Please clarify because until you do I will presume that
what you
really want to say is:
"let's expand the definition of Role to include Role hierarchies." Am I
right?
BTW I very much in favor of Role hierarchies.
you can assign permissions to B and make B a "junior"
> role to A and then A gets B's permissions without explicit assignment
> of permissions to A.
OK this is easy let's expand the definition of a Role now to include Role
hierarchies:
Role:
o has some id/name (call it "Role A") to differentiate it from other
roles
o may be associated with a set of zero or more permissions
o may be associated with a set of zero or more other roles ("Role B" and
"Role C" for example) from which it (Role A) inherits the union of the
permission associations from these other roles (Role B and Role C)
(1) Notice these are all set wise operations hence my use of the term set -
we're
talking about the same thing here.
(2) The above re-definition of your terms, like your definition, presumes
multiple inheritance
in the Role hierarchy since more than one role (Roles B and C) can be
associated
with Role A.
(3) I left out the whole thing with positive (grants) and negative (denials)
permissions
for simplicity but we can put that in too if you like.
3. I don't see how to deal with denied permissions with the role-as-
> set-of permissions approach.
You have set wise operators: union, difference, and intersection. The
difference operator
would be used when dealing with denials. Regardless denials are not required
to do the job.
They're convenient but not necessary and some may debate this too.
With the role-as-entity approach you
> just have more associations with permissions (and roles, for denied
> subsidiary roles).
Again role-as-entity: what does this mean?
On the other side, we need to associate roles and users. (If we need
> groups in our model, we need to be able to associate roles and groups
> too).
<WARNING>
You're now mixing role assignment to users into a thread on defining
applications and roles breaking with the attempt to divide and conquer
all the parts of this topic.
</WARNING>
I'm snipping the assignment of roles to users parts here and taking what
is of value to this thread. I think you make good points about using scopes
instead of applications to enable nestable contexts.
...
if we decide to use the scope
> idea we want to attach a role to a scope, and say it can only deal
> with permissions on objects in that scope. So I propose:
I like this point you make: "role [in a scope], ... can only [be associated]
with
permissions in that scope."
Question:
With scope nesting which I presume you support (and me likes), what do you
propose for visibility (doh scoping) rules?
For example you have 3 nested scopes: A, B, and C. B is subordinate to A.
C is
subordinate to B.
Subquestions:
(1) Can a role defined in scope B be associated with the permissions
defined in scope A?
Restated: Are roles in scopes including other nested scopes able to
resolve and hence
be associate with permissions defined in the nested
scopes.
(2) Can roles and permissions be redefined in nested scopes?
(3) If roles and permissions can be redefined (answer to #2 is true)
then does the definition
in the nearest scope to the reference have greater visibility?
Question:
If I take your statement here literally (repeating here to be fluid):
"role [in a scope], ... can only [be associated] with permissions in
that scope."
then really there are no scoping (visibility) rules since the
definitions of other
roles and permissions (even if using the same identifier) are not
visible outside the
existing scope. Meaning a role in scope B can only see permissions in
scope
B but not the permissions in scope A as would be expected for example
with
Java variables with it's scoping rules within nested blocks.
If this is the case then what is the point to nesting and the scope
concept?
MS AzMan BTW deals with visibility in the way Java does with variables
with block
nesting. It may have some subtle differences tho I cannot remember
exactly off the
top of my head.
Role: a named entity where
> 1. permissions are associated to a role
#2 is about Role assignment and does not belong in the definition of a Role.
Roles are independent of users and groups.
3. there's a (multiple) inheritance relationship between roles.
> From the point of view of permissions
+1
4. If we need groups, groups are associated to a role.
We don't need to talk about users or groups at all when defining a role.
Roles are
independent of users and groups which are environment specific entities.
Technically
in an any reality (environment), the role definitions devised by developers
can be used and
associated with foobar objects and sets of foobar objects. We don't care.
This only
matters when we drop our definitions into some environment.
Just keep in mind a developer or architect need not have users or groups to
define the roles
and permissions in their applications.
So let's stop mixing Role assignment on deployment with defining what a Role
is in it's
essence (abstractly).
5. If we have scopes, roles are attached to a scope and all the
> permissions associated to the role (directly or through inheritance)
> have objects in the scope.
Are you suggesting that inheritance of roles can only occur from the same
scope?
Or are you suggesting that inheritance of roles from other scopes is
possible and
this automatically pulls those inherited roles and their associated
permissions into the
present scope?
Sorry this last point #5 was not very clear for me.
Thanks,
Alex
Re: [Triplesec] [AuthZ] Applications and Roles
Posted by David Jencks <da...@yahoo.com>.
On Oct 24, 2007, at 10:25 AM, Alex Karasulu wrote:
> Applications and Roles
> ---------------------------------
>
> Application designers devise security permissions and roles
> specific to applications. These
> roles represent a set of rights authorizing principals to perform
> operations or access resources
> that must be allowed to fulfill a specific coherent function within
> applications. These rights to
> access resources are the permissions. The set of these
> permissions, needed for a logical
> function to be conducted in the application, is a role.
>
> To be concise we extract the following glossary definitions:
>
I think we should start with
Users: People (or maybe systems) that need to use the system. Often
the term Principal is used but I find it extremely confusing because
the principals I know about in java are only aspects of someones
identity in the system. A Principal might have started out as
something that completely represents a single user but I think it is
used in so many other ways now that we should avoid it to describe a
single user. Since I find "principal" so confusing I'm going to use
"user" instead in what follows: we can always change it back.
It's a minor point and I really don't want to get anyone
distracted but I tend to think of "systems" that need to use the
system as "frozen identities" of the people who set them up. In
other words someone had to start the system and they had better have
had the authorization to set it up to do whatever it is supposed to.
So it seems to me as if they froze part of their identity into the
system's authorizations. I'd be interested to know if this seems
like a reasonable point of view to others.
> Permission:
> A right required by a system or application to authorize
> principals to perform a
> specific operation or access a resource in some manner.
>
This is kind of unclear to me and mentions the so-far undefined terms
system and application. Looking at permissions I know about they
seem to specify one or more object of some kind and one or more
operations of some kind. For instance a file read permission
describes a file (object) and operation (read). A web permission may
describe a set of urls and a bunch of http methods. To me it is
clearer to leave out who might want or use a permission or the
context (application?) in which it is meaningful from its definition
and say that we have a set of objects and a set of operations and a
permission is a bunch of operations on a bunch of objects.
So for this to make sense we need a couple more categories:
Objects: "things" that can be operated on, such as program bits or
components
Operations: stuff you can do to objects.
Now, objects usually show up in bunches such as applications.
However applications sometimes have modules inside and sometimes
themselves come in bunches. For instance javaee ears have web and
ejb modules inside, and people sometimes deploy large javaee projects
as more than one ear, that use each other. With many applications
deployed, there can easily be hundreds or thousands of objects. To
make administering permissions on these objects manageable I think we
may want to introduce a hierarchical scope concept.
Scopes: a tree of scope objects, where we assign each object to one
scope. For instance, a module, application, set of applications,
division, enterprise...
> Role:
> A set of permissions required by a principal to be authorized to
> fulfill a logical function
> within a system or application.
>
I think there are two ways of looking at roles and permissions. One,
used here, says that a role is a set of permissions. The other says
that a role is an entity with permissions associated to it. They are
really really close but I prefer the second for these reasons:
1. One of the characteristics of the roles I know about is that they
have names. Furthermore I think people like to think about assigning
permissions to roles (or maybe roles to permissions). Saying that a
role is a set of permissions tends to suppress the roles' name and
makes it impossible to distinguish a bunch of new roles that don't
have any permissions assigned to them yet -- they are all the empty
set of permissions, so identical.
2. I think its easier to think about role hierarchy with roles as
entities. Its certainly possible to do with sets -- role A contains
or implies role B if B is a subset of A -- but it is hard to think
about what this means if you assign or unassign a permission to B.
Do you unassign it from A as well or does A no longer imply B? With
role entities you can assign permissions to B and make B a "junior"
role to A and then A gets B's permissions without explicit assignment
of permissions to A.
3. I don't see how to deal with denied permissions with the role-as-
set-of permissions approach. With the role-as-entity approach you
just have more associations with permissions (and roles, for denied
subsidiary roles).
On the other side, we need to associate roles and users. (If we need
groups in our model, we need to be able to associate roles and groups
too). Furthermore, we may want to restrict some roles to deal with
permissions in some applications, so if we decide to use the scope
idea we want to attach a role to a scope, and say it can only deal
with permissions on objects in that scope. So I propose:
Role: a named entity where
1. permissions are associated to a role
2. users are associated to a role
3. there's a (multiple) inheritance relationship between roles.
From the point of view of permissions, if role A contains role B, A
gets all of B's permissions from the "contains" relationship without
direct assignment to A. Note that from the point of view of users, B
gets all of A's users, so B contains A. (the fewer permissions you
are talking about [B], the more people have them; the more
permissions [A] the fewer people).
4. If we need groups, groups are associated to a role.
5. If we have scopes, roles are attached to a scope and all the
permissions associated to the role (directly or through inheritance)
have objects in the scope.
thanks
david jencks
> Thanks,
> Alex
Re: [Triplesec] [AuthZ] Applications and Roles
Posted by Alex Karasulu <ak...@apache.org>.
Hi Stefan,
On 10/26/07, Stefan Seelmann <se...@apache.org> wrote:
>
> Is one role limited to aggregate permissions within an application?
>
> What about
> - roles that aggregate roles (hierarchical roles)
Oh yes we can have role hierarchies where roles are a set of permissions
and
a set of other roles. I even like the idea of multiple inheritance with
role hierarchies,
where a role can reference more than one super role. Without multiple
inheritance
a role could only have zero or one superior roles.
Role inheritance is critical for real world use cases.
- roles that aggregate roles and permissions of different applications
> or systems (enterprise roles)
The short answer is yes but there are some details that would need to be
addressed based on the scope in which the role is defined.
Alex
> Applications and Roles
> > ---------------------------------
> >
> > Application designers devise security permissions and roles specific to
> > applications. These
> > roles represent a set of rights authorizing principals to perform
> > operations or access resources
> > that must be allowed to fulfill a specific coherent function within
> > applications. These rights to
> > access resources are the permissions. The set of these permissions,
> > needed for a logical
> > function to be conducted in the application, is a role.
> >
> > To be concise we extract the following glossary definitions:
> >
> > Permission:
> > A right required by a system or application to authorize principals
> > to perform a
> > specific operation or access a resource in some manner.
> >
> > Role:
> > A set of permissions required by a principal to be authorized to
> > fulfill a logical function
> > within a system or application.
> >
> > Thanks,
> > Alex
>
>
Re: [Triplesec] [AuthZ] Applications and Roles
Posted by Stefan Seelmann <se...@apache.org>.
Is one role limited to aggregate permissions within an application?
What about
- roles that aggregate roles (hierarchical roles)
- roles that aggregate roles and permissions of different applications
or systems (enterprise roles)
> Applications and Roles
> ---------------------------------
>
> Application designers devise security permissions and roles specific to
> applications. These
> roles represent a set of rights authorizing principals to perform
> operations or access resources
> that must be allowed to fulfill a specific coherent function within
> applications. These rights to
> access resources are the permissions. The set of these permissions,
> needed for a logical
> function to be conducted in the application, is a role.
>
> To be concise we extract the following glossary definitions:
>
> Permission:
> A right required by a system or application to authorize principals
> to perform a
> specific operation or access a resource in some manner.
>
> Role:
> A set of permissions required by a principal to be authorized to
> fulfill a logical function
> within a system or application.
>
> Thanks,
> Alex