Kerberized authorization service

[Ken Hornstein]

>I presented a paper at the Kerberos/AFS workshop a couple of years ago
>on an open-architecture authorization model and API.  The conceptual
>approach is extremely simple, very powerful and architecturally similar
>to what you propose.

Well, I'm sorry ... I remember that paper, and ... well, I cannot agree
with your statements (and to be fair, I just went and re-read that
presentation again; it's available from the 2006 AFS Workshop archives).

Here are my beefs with your proposal:

- "Simple?"  Uh, you ARE kidding, right?  Right off the bat you start
  talking about n-bit vectors and cryptographic hashes.  And the
  diagram on slide 18 ... ouch.  And you use XML?  What exactly is
  SIMPLE about this idea?  I consider myself reasonably intelligent and
  I've spent a fair amount of time thinking about authorization, and I
  can barely follow your proposal.  Off-line discussions I have had
  with others in the Kerberos community have seen similar reactions to
  mine.  So, in short: your proposal is really complicated.  If this
  complexity was necessary, I could forgive that ...  but we have
  real-world experience that shows that it is not.

- Your proposal did not include an API (there was not one shown in your
  slides).  Well, you included KDC and library plug-ins, but not how this
  API would look on an application server.  I am gathering that it would
  involve LDAP queries (although perhaps you hid that inside of a wrapper
  library).

  During our authz server prototype work, we developed an API.  It was
  one function - it returned a "yes/no" answer, and a text string which
  included a string you could display/log for the "no" reason.  Would have
  been a few lines of code to add to all of the application servers that
  we use.

- History has shown us that adding authorization data to the Kerberos
  protocol isn't the best idea.  DCE did it, Microsoft does it, and there
  are a host of problems with this approach; from an architectural
  perspective (operational experience has shown us repeatedly that having
  the ability to change authorization information more quickly than Kerberos
  ticket lifetimes is very important) to the practical (authz data in Kerberos
  tickets brings larger tickets which present problems for some applications,
  it locks you to a particular KDC, and those are only a few).

- Your model is simply not extensible enough.  For example, it is not
  possible to easily extend it to make the authorization decisions that
  our site needs to make.  Why?  Well, we make authorization decisions
  on the application server based on information that is not available
  at service ticket creation time.  Maybe I am mis-understanding your
  model and perhaps it is possible ... but that just gets back to the
  whole "complexity" issue.  Also, I cannot see how to make use of
  your scheme with cross-realm authentication ... and we use that a lot.

Let's take two real world counter-examples: the AFS PTS server, and
John Hascall's double-secret authz server (Stanford's wallet might
be another example, but I don't know enough about it to say so
let's not bring that into the mix right now).

Both services work in roughly the same way: you send them an identity
which you have derived from your authentication service (Kerberos in
both cases) and the service responds with what you are allowed to
do.  In the AFS PTS server's case you get a set of groups that the
identity belongs to which are used by the AFS fileserver to determine
permissions based on ACLs stored on directories.  In the Hascall
double-secret authz server you get a "yes/no" answer regarding access
to a particular service (John, if I've got this wrong, please correct me).

Note that both of these services are pretty simple, and don't involve
adding bits to the Kerberos protocol.  They both predate LDAP, so it's
hard to say whether or not they would have used them.  Personally, I
think LDAP is a crappy protocol to use for authorization queries ...
it is fine for _managing_ authorization data, but I want something with
fewer round-trips in the authorization path (I would probably do a custom
protocol).

DCE tried to put authz data into Kerberos, and I think everyone would
agree that DCE has been a failure.  Now obviously putting authz data
into Kerberos is not the reason that they failed, but it just shows
one of the fundamental problems with DCE - over-engineering.  You could
bring up Microsoft as a counter-example.  That would be true, but Microsoft
has the advantage of having tons of paid programmers to implement their
designs and they control all aspects of their software at all levels.
In the open-source world we do not have those luxuries ... we need to
be able to have designs that are simple to implement and understand, and
we need to be able to play nicely in heterogenous environments.

BTW, there is a "simple" way to prove that I am full of crap.  All you
have to do is implement your design and get people to use it.  Clearly
there is a desire for a reasonable authorization service that ties into
Kerberos, so if what you come up with is workable you should have plenty
of users.

--Ken