directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [Triplesec] [AuthZ] Applications and Roles
Date Wed, 31 Oct 2007 03:04:15 GMT
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 <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.

> 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

Mime
View raw message