Adam Megacz wrote: > Jeff, your solutions are a bit like saying that everybody should just > be happy using an 8086 CPU because it's Turing-complete. It's not > "wrong", but if users have to jump through a lot of hoops, or even one > hoop *per cell*, they'll simply avoid AFS.
I completely agree that ease of use is a serious issue. Its a huge problem for any distributed application service that requires authentication, authorization and auditing. I spend a significant effort working to address this issue. The Network Identity Manager is one outcome of my work. You wish to use an authentication system other than Kerberos. That's fine. You can do so in the manner I have described. OpenAFS is working to separate itself from the provision of authentication services. I can't speak for the other gatekeepers, but I would be very reluctant to adopt a new authentication service into the OpenAFS distribution. Instead, a general purpose PGP-based authentication service should be deployed for which one use can be the acquisition of AFS tokens. If you implement it properly OpenAFS administrators should be able to deploy your service instead of a Kerberos realm and users should be able to install your afspgplog tool to obtain tokens instead of aklog. aklog and asetkey are being integrated into the OpenAFS distribution because the vast majority of all AFS environments use Kerberos and the failure to provide these tools has made migration from Kerberos 4 to Kerberos 5 difficult for many sites. If a new authentication service becomes widely deployed and begins to achieve significant use with OpenAFS, then of course I would consider the integration of additional clients. > Furthermore, while your Network Identity Manager thing is indeed quite > cool, it is unfortunately Windows-specific. You are more than welcome to port it to other platforms. The biggest challenges will be the lack of CCAPI on most UNIX-like operating systems and replacing the UI. A version of CCAPI that can be ported to platforms other than Windows and MacOS X should be available as part of MIT Kerberos 1.5. I must point out that one of the primary reasons a tool such as the Network Identity Manager and the CCAPI do not exist on platforms other than Windows and MacOS X is that none of the organizations that have funded development of such tools have considered the UNIX platforms worth spending the money on. Users have succeeded in using the command line tools for many years even when they have not been bundled with the AFS distribution. Whereas on Windows and MacOS there have been a wide variety of ticket management tools development by organizations. When I discuss the use of PKINIT and PKCROSS as methods for solving the ease of use problems, I am not attempting to solve a problem for AFS but instead for all services. I seriously believe that Kerberos can be an authentication solution for everything from P2P to Federated Systems. I want to see users be able to login to their local standalone system and be able to use their local machine credentials to authenticate to a Yahoo Calendar service that currently the access with an e-mail address and a password they store in their browser's password database. I want users to have the option of choosing which authentication service they want to use for identification to an arbitrary application service. I want application service providers to be able to manage their services and not need to be responsible for identity management. In particular, I want to get application service providers out of the business of storing and managing passwords for end users. These are long term goals that I believe can be addressed over the next seven years. However, it is not the goal of OpenAFS to solve these issues. OpenAFS has its own issues to solve related to distributed file systems. It is important that OpenAFS maintain its focus in order to grow. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
