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
