directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [Triplesec] [AuthZ] Applications and Roles
Date Wed, 31 Oct 2007 18:54:09 GMT
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

View raw message