Ken Hornstein <[EMAIL PROTECTED]> writes: > 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).
The wallet is not an authz service. It's a secret data management service which lets you acquire various private keys, passwords, and similar secret data upon proof of your identity. It implements authorization checks, of course, but does not provide them as a general service. Stanford's authz story right now isn't particularly coherent, like most sites. We use a wide variety of different mechanisms (PTS groups, LDAP entitlements, file-based Kerberos ACLs, AD groups, and other things) depending on the application and they're not particularly well-integrated. I should note, though, that in my experience with authorization, the network protocol isn't really the hard problem. It's usually not too difficult to find some way to convert from one protocol to another or to export authorization data into the form that a particular application wants it. The really hard part of authorization isn't communicating the information; it's dealing with lifecycle. There are a lot of lifecycle problems, but the one that best illustrates the general problem in my experience is this: If someone in your organization changes roles, how does their authorization data get updated across all of the systems and applications to which they have access? If your answer involves any manual process apart from the HR change, you lose. :) Stanford currently very much loses on this, in a wide variety of ways. We really only have one authorization system that copes correctly with role status changes (provided that it's used properly), and it only knows how to talk to the financial system and isn't (currently) usable as a general authorization solution. There is some active work in the Internet2 arena on this, but not to the point where I think people are deploying it. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
