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 < [EMAIL PROTECTED]> 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
