>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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
