Re: subjects in LDAP ACMs

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 05:15 PM 4/12/01 +0200, robert byrne wrote:

>Kurt,
>
>Conceptually it's certainly helpful to seperate the authzid type
>subjects from factors like authnLevel, ipaddress/dns name etc.  However,
>in so far as a factor is typically an extra refinement on authzID's (eg.
>grant the access if it's cn=rob,o=sun.com AND he's authenticated using
>SASL-DIGEST-MD5) I think factors are still very "subjecty" things.  Is
>the trend of your thought to move factors into a say "factor" keyword
>and then require that the subject AND factor keywords are satisfied ?

No.  My thought is to come up with an extensible set of orthogonal
factors which then are expressed in the syntax as such.  What
authorization identity some user has independent of the mechanism
used to authenticate the user.  What host that user appears to
on is orthogonal to the mechanism used.


>What do you mean by "authorized" below ?

Meaning that the user was "authorized" to assume an identity.
That is, the user has been authenticated and some authorization
identity has been associated with the session (this might be
an authorization identity derived from the user's authentication
identity or another authorization identity which the user is
allowed to assert).

>BTW, do you think it would be interesting to allow boolean combinations
>of subjects in the same aci ?

Interesting, yes, but too complex.  I suggest that factors be
AND'ed together and or's created by multiple values.  We use
this logic in our ACM, it's simple and effective.


>Rob.
>
>"Kurt D. Zeilenga" wrote:
>> 
>> I note that the LDAP ACI syntax only allows a single
>> subject per value though it is likely quite desirable
>> to treat certain kinds of subjects as orthogonal factors
>> in the ACM.  For example, it might be useful to say
>> "authzId X via Y method gets Z permission".
>> 
>> However, adding additional, independent factors to
>> the ACM adds to the complexity of specification so
>> we must tread lightly.
>> 
>> My first suggestion would be remove subjects based
>> upon orthogonal factors from the ACM, then to discuss
>> support for orthogonal factors such as authnLevel.
>> 
>> I suggest Subjects be based solely upon presence, absence,
>> or value of the authorization identity.  Hence, I suggest
>> (provided in suggested precedence order):
>> 
>>   subject = this          ; self
>>   subject /= "authzID-" authzID)
>>   subject /= ("role:" dn)
>>   subject /= ("group:" dn)
>>   subject /= ("subtree:" dn)
>>   subject /= authorized   ; authenticated and authorized
>>   subject /= anonymous    ; unauthenticated
>>   subject /= public       ; any user
>> 
>> Kurt