Kerberized authorization service

[Ken Hornstein]

> From my perspective the problem with DCE and Active Directory is not 
>that they store authz data in the Kerberos ticket.  Doing so addresses a
>large number of issues associated with partially connected network graphs
>and and mobile clients.

"Meh".  I used to think that, but then I finally came to realize ....

>Where I believe there is a failure is that they do not provide the 
>alternative model as well.  A service should not have to trust the authz
>in the service ticket if it believes that it might be out of date.

... if you need an alternative model part of the time, then you have to
solve all of those problems anyway.  And I don't see how mobile clients
are a problem; my idea is that all of the changes happen on the
application server side.  If you have mobile application servers then
that could be a problem, but that has it's own issues.

>The Kerberos API krb5_userok() comes fairly close to having the correct 
>interface.

My issue with krb5_kuserok() is that it can't take enough stuff ... not
a bad starting point in terms of an API, but it needs to be extended
more.  A lot more, actually.  To make me happy, the authz API would
need to be given basically the whole Kerberos ticket and the IP address
of the client of the application server.

--Ken