directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [Triplesec] [AuthZ] Applications and Roles
Date Wed, 31 Oct 2007 08:50:36 GMT

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
>
>


Mime
View raw message