Thoughts on a Kerberos based open-authorization architecture.

[David Boreham]

greg at enjellic.com wrote:

>A cryptographic hash with a message size of m=N provides a convenient
>mechanism for implementing the genetic combination of the user and
>service identity.  We thus implement our authorization model as
>follows:
>
>        Hm(Uii,Sii) = SIii
>
>The model is brought to practicality by thinking about what it means
>with respect to an LDAP directory.  The hexadecimal representations of
>the Uii, Sii and SIii are used to formulate the distinguished names
>(DN's) of the identities in the directory.  The following regex
>shorthand will be used to represent the actual value of the identity:
>  
>
This sounds interesting, but there's one thing I'm not getting : why use a
hash for the naming attribute ? Couldn't you simply use regular DN's
for each service, and have those show up in a multi-valued (DN-syntax) 
attribute
on each user ? Is the goal simply to make the service name's syntax 
acceptable
as an LDAP naming attribute ?

I ask because this looks a _little_ like a thing I invented for the Netscape
LDAP directory a while ago (and since patented by Sun...). We defined an
'nsRole' attribute that contained the DNs of 'role objects', also in the 
Directory.
The role objects I believe have exactly the same purpose as your Sii 
entities.
The server also had (has: now known as Red Hat Directory Server, Fedora
Directory Server and Sun  <insert buzzword du jour> Directory Server)
the capability to generate values for the attribute on-the-fly. This allowed
interesting policy-driven authorization such as 'allow everyone in 
building 16
access to the entry doors in buildings 16 and 14' and 'allow anyone in
the finance group with job level > 3 access to the quarterly reports'.

To my knowledge almost nobody has deployed applications that use this
stuff though :(