Ken Hornstein wrote:
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 issuesDCE 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.
associated with partially connected network graphs and and mobile clients.
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. In federated environments, the authz decision should be made by the organization that owns the service and that organization should not be forced to stuff additional authz data into the issued service ticket. Note that in the Kerberos cross-realm model the cross-realm TGT is not issued by the organization performing the authz, so there is additional overhead associated for the KDC in reconstructing the authz data for each service ticket that is issued. Finally, for compatibility with pre-existing service protocols that have credential size limitations there needs to be methods of disabling the issuance of authz not only TGS-REPs for general services
but for cross-realm TGTs as well.The Kerberos API krb5_userok() comes fairly close to having the correct interface.
The problem with the implementation is that there is no pluggable mechanismfor calling out to an authz service. Recompiling the libraries for each organization's
authz model is not usable. I believe the model needs to have the following components:1. a mutually authenticated channel between the service issuing the query and the
authz service 2. the protocol should providea. identity of the requesting service (obtained through mutual authentication of the channel)
b. name of client as trusted by the service 3. the protocol should return a. yes or no response b. reason for a no response that can be returned to the clientc. (optional) authz data (group memberships, rights, etc.) as of the present time
That is my two cents worth ... Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
