Thoughts on a Kerberos based open-authorization architecture.

David Boreham david_list at
Fri Mar 3 15:22:17 EST 2006

greg at 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
>        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) 
on each user ? Is the goal simply to make the service name's syntax 
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 
The role objects I believe have exactly the same purpose as your Sii 
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 :(

More information about the krbdev mailing list