Kerberized authorization service
Ken Hornstein
kenh at cmf.nrl.navy.mil
Mon Feb 11 10:57:04 EST 2008
> 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
More information about the Kerberos
mailing list