Thoughts on a Kerberos based open-authorization architecture.

[greg@enjellic.com]

On Mar 3,  1:22pm, david_list at boreham.org wrote:
} Subject: Re: Thoughts on a Kerberos based open-authorization architecture.

Good morning David, thanks for the note.

> greg at enjellic.com wrote:

> >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 ?

A very astute observation.  There is no formal requirement for the Sii
(Service) object to be named with its intrinsic identity.  In fact in
the reference implementation we are not currently doing that.

Here are a pair of cutdown LDAP objects from our current testing
system:

dn: service=KERBEROS,dc=something,dc=com
kvno: 3
Sii: 5451a5bacb028cd9518490df5bebf3758981a567
state: enabled

dn: SIii=fc5d62b45f096f1f45c8ec210966b68b9e7fe4a3,dc=something,dc=com
krb5PrincipalName: k9
krb5RealmName: SOMETHING.COM
Uii: ff902330580fd1fa1e0a15baa1562e300342a1ad
state: enabled

The first object object is the identity object for the KERBEROS
service.  The second describes an instance of the KERBEROS service for
my dog Iggy authorizing him for authentication services.

The rationale for using the intrinsic identity in the SIii object
flows back to the principle of intrinsic directory security.  The SIii
is actually an authenticated message, protected by the symmetric key
associated with the authentication principle for the service.

A compromise of the directory does not provide sufficient information
for the formulation of SIii objects:

	SIii = HmKn(Sii,Uii)

The lack of Kn provides the cryptographic barrier to the production of
SIii.

> 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.

I would surmise your role objects are very similar in principal to our
Service identities.  The only subtle difference is that our Service
identities may be something which the organization is conveying
authorization for while your role objects are used in formulating
policy for an authorization decision.  A very subtle difference
though.

> 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'.

Makes perfect sense.  It also underscore the conceptual similarity of
our strategies to some extent.  An API call within our system for an
application to request authorization goes something like this:

	KerDAP_Authorize_Service(identity, svcname)

Where identity is an authenticated token such as a Kerberos principal
name and svname is the name of the service.  To verify whether my dog
Iggy can access the ERP system the call would look something like
this:

	KerDAP_Authorize_Service("k9 at SOMETHING.COM", "ERP");

With a bit of assistance from the management system it would certainly
be possible to request an SIii composited from the user and multiple
services:

	KerDAP_Authorize_Service("k9 at SOMETHING.COM", "ERP^BUSINESSHOURS");

Currently we would probably implement this type of policy by
specifying attributes in the ERP Sii object.  The SIii object inherits
the default attributes which can be overridden if needed.

We actually use your strategy in a slightly different way for
something which we call host specific authorizations.  The SIii
objects for these authorizations are of the form:

	SIii = HmKn(Uii,Sii,Hii)

Where Hii is the intrinsic identity of a host delivering the service.
The sudo utility is a good example of where this would be used.

Global access to sudo formulated as:

	SIii = HmKn(Uii,Sii)

Creates a different intrinsic identity than sudo tied to a particular
host by the form of:

	SIii = HmKn(Uii,Sii,Hii)

The most important thing in all this is that we are both working under
what is conceptually a very powerful model.  The conceptual
implementation of a service or role involves the genetic combination,
if you will, of the user and the role or services being accessed.

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

Unfortunately that seems to be a fairly common problem.  Everyone sort
of 'wants' authorization but without a standardized method of
implementing it or requesting it or managing it there is no traction
from the application end of things.

It would be such a powerful arena for Open-Source to play in.

Thanks for the comments, they were great.  They actually inspired me
to do a bunch more thinking.

Best wishes for a pleasant weekend.

Greg

}-- End of excerpt from david_list at boreham.org

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg at enjellic.com
------------------------------------------------------------------------------
"If we thought this was a trap, we wouldn't be doing it, and as you know,
we have a lot of lawyers."
                                -- Irving Wladawsky-Berger