Thoughts on a Kerberos based open-authorization architecture.

[Ken Hornstein]

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.

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

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

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

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.

--Ken