Adam Megacz <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes:
>> But you're still going to be doing authentication (and therefore >> identity management, since you want your authentication system to >> satisfy certain identity binding requirements which will require at >> least some form of identity management). > I agree. I think the really tough hurdle I'm trying to get over here in > this thread is if OpenAFS is willing to accept use-cases where the task > above is delegated outside the sphere of the "AFS software suite" > (OpenAFS, Kerberos, and various extensions to Kerberos). Well, the fundamental issue with doing so is that you need some way to generate a token and do useful things with that token. Right now, the token format is fairly wide open, and you can actually generate one in many different ways if you're willing to write the code. Longer term, I'm not sure if this is going to continue to be the case in quite the same way. A real Kerberos v5 AFS implementation, which would be an excellent thing to have for a whole host of reasons, is likely to want to be more specific about the contents of the token so that one can, for instance, give file servers independent keys without requiring all of one's file servers to have god-like AFS privileges. Because of that, I think you'd be best off if whatever technical solution you came up with looked like Kerberos from the AFS perspective. AFS has a lot of issues to deal with and, compared to getting Kerberos working properly inside AFS, I think this one is relatively less important for most sites (and much less likely to draw a lot of specifically AFS development). Plus, if you can implement something like this at the Kerberos level rather than the AFS level, you solve the problem not only for AFS but for any Kerberized service. As such, I think you're pursuing a very difficult technical course if you do this as something other than an extension to or a management policy around a Kerberos realm that AFS can otherwise treat as any other Kerberos realm. I don't think you'll find a lot of resources to help you with that, just because AFS development resources are limited and such things as real Kerberos v5 support will make a huge and immediate difference for a lot of people. (It would, for example, potentially allow people who are not strongly trusted with the keys to the kingdom to run their own file servers in an AFS cell, although there are a lot of details to work out before we get to that point and the VLDB interaction is tricky.) On the other hand, I think fast generation of new Kerberos principals, better ways of doing Kerberos trust, and better ways of trusting Kerberos realms within AFS are all areas ripe for exploration and areas where you'd see a lot of support and interest. The problem of identity management and *simple* account creation for loose affiliates is a *huge* problem for many universities and one that many of us would love to see solved in as systematic a fashion as possible. pkinit and pkcross look to me like potentially useful technical components to a larger solution and worth pursuing for that as well as in their own right. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info