Thoughts on a Kerberos based open-authorization architecture.

[greg@enjellic.com]

On Mar 3,  4:52pm, Ken Hornstein wrote:
} Subject: Re: Thoughts on a Kerberos based open-authorization architecture.

Hi Ken, thanks for the comments.

> I confess I've thought about authorization as well.  But my ideas
> were a bit different than yours ... but of course there is nothing
> wrong with that.  I admit that I am a lameass and I haven't coded up
> anything yet.

Nothing wrong with that.  All of us lameass's can form a club to work
on this... :-)

> >In formulating our mechanism we went back to the basics of thinking
> >about what authorization actually is.  We concluded the authorization
> >process involves the interaction of two basic components:
> >
> >        1.) User
> >
> >        2.) Service

> I sometimes want to add a third option here ... maybe call it
> "action".  This would indicate what you wanted to do with "Service".
> Maybe this could be folded into the name of "Service" ... I don't
> have a strong feeling on this.  Just something to think about.

Within the framework of our model we try to handle this by defining
attributes which characterize the Service.  Be default SIii's inherit
the attributes from the parent service (Sii).  The management system
allows the attributes at the SIii level to be modified on a user by
user basis.

All of this flexibility is certainly desirable but 8 years of
experience has taught us a lot about the general power of 'on/off'.
Lets take for example the ability to send and receive e-mail.  We
convey this with a service named EMAIL.

We do stuff things like individualized user quotas and the like into
the SIii EMAIL objects.  But at the end of the day most of what our
administrators want to do is turn on and off access.  The same is true
of the WIRELESS service which authorizes user access to the wireless
network(s).  It usually comes down to a simple question of whether or
not the user should have access to the resource.

> >[... description deleted ...]
> >The model inter-operates well with the authorization payload field of
> >Kerberos tickets.  The payload field contains the SIii of the service
> >or services the user has access to.  The application extracts the
> >SIii's and references the appropriate object(s) in the directory to
> >implement the authorization policy decision(s).

> I'm scratching my head a bit here.  Exactly _who_ is placing these
> things into the authorization field of service tickets?  The client?
> The KDC?  You say down below that you implemented a PAM module which
> implements this, which implies to me that it's client driven.

The KDC loads the SIii's into the tickets.  Its the only thing
(besides the management system) which 'knows' how to create them using
the Uii, Sii and the authentication key associated with the Sii
principal.

We implemented the PAM module to handle services which pass a user
identity and password over something like an SSL protected link.  It
currently requires a keytab with the svc/SERVICE principal in it.

The PAM module creates the SIii by looking up the user and service
identities via LDAP and running the construction HMAC with the derived
version of the key from the keytab.  It then goes back to LDAP to see
if the SIii is in the directory and optionally executes a policy based
on the attributes associated with the three identities.

Now that we have written the plug-in architecture which allows us to
modify the AS_REQ's and TGS_REQ's to carry out SIii injection our
design of the PAM module will change.  Since PAM needs to go to the
KDC to authenticate the user and to verify the TGT we will just let
the KDC send us back the SIii.

In a nutshell; The KDC synthesizes the SIii, the client interprets it
via LDAP.

> What I had thought about was something much simpler.  You have a
> directory somewhere (maybe it could be LDAP; I have no strong
> feelings on this) that contains user/service (and "action" if you
> want it) data, with "enabled/ disabled" information.  How you
> organize it is still up in the air at this point.  Anyway, the idea
> is that the application server sends the authz server a simple query
> - "can user X access service Y" (_not_ via LDAP; I was envisioning a
> simple UDP based request/response protocol, single round trip,
> wrapped in a Kerberos AP_REQ/AP_REP, using a ticket acquired via the
> host key).  The authz server replies "yes" or "no".

What you describe is certainly a viable model, one we even
experimented with.  In the context of our model we feel it adds
complexity without necessity since the LDAP directory already
functions as the authz server.

Lets consider what we have to work with:

Our authorization data (SIii, Uii, Sii etc) are already organized and
available in LDAP.

Our API library uses a GSSAPI authenticated connection to the
directory so the request is to an authenticated data store.

The LDAP directory essentially says yes or no based on whether or not
the SIii is found in the directory.  Optionally the application/API
can make a more extended decision based on the object attributes which
come back from the directory.

Since the SIii is intrinsically an authenticated message we know that
if its DN exists in the directory it was something which is authentic
based on our KDC.

The merit of the model is certainly debatable but in sum these issues
seemed to provide a pretty compelling rationale for doing away with
the authorization server.  Particularly given the prevailing sentiment
of 'mash everything into one application glob'.

> Of course, there are a bunch of details to be worked out.  How you
> want to arrange the data, how to manage it, etc etc.  Probably an
> admin interface via LDAP would be fine.  Having seen the various
> "stuff things into Kerberos ticket" authorization schemes, I think
> I'd be happier with something that didn't work that way.

FWIW we have spent a bit of time thinking about the details.... :-)

We certainly don't advocate any more 'ticket-stuffing' than what is
absolutely essential.  We didn't even initially believe in
'ticket-stuffing' but our experiences since implementing it have
changed our opinion on it.

For a given service instance we currently convey the authorization
directive in 20 bytes of payload.  In the most simplistic
implementation this translates into one LDAP lookup on the client side
to execute the directive.

It seems to be a reasonable tradeoff, particularly if a separate
authorization server is avoided.

> --Ken

I appreciate the comments, thanks for taking the time.

Greg

}-- End of excerpt from Ken Hornstein

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
------------------------------------------------------------------------------
"Snow removal teaches all the important elements of succesful corporate
politics:  1.) Be the first one to work.  2.) Always signal your
intentions before moving.  3.) Be damn sure you're driving something
big enough to deal with anything that decides not to get out of your way."
                                -- Dr. G.W. Wettstein
                                   Guerrilla Tactics for Corporate Survival