<Taking [EMAIL PROTECTED] off the list> Henry B. Hotz wrote: > In this case you get tokens when you can and you don't when you can't > (like user/admin isn't in AFS). I believe our existing AFS kernel > code can keep track of the tokens as-is. If the Kerberos GUI showed > afs service tickets only for those identities that got valid afs > tokens and not otherwise then we're good.
AFS stores tokens in the uid of the user that acquired the tokens. If you already obtained tokens for [EMAIL PROTECTED] and then call kinit hotz/[EMAIL PROTECTED], then the AFS tokens belonging to hotz/[EMAIL PROTECTED] for the jpl.nasa.gov cell would replace the tokens obtained for [EMAIL PROTECTED] In Kerberos.app you would see two credential caches with two sets of tickets. One for [EMAIL PROTECTED] and one for hotz/[EMAIL PROTECTED] For each one you would see at least a TGT and an afs/[EMAIL PROTECTED] service ticket. > Just to bring another issue into the discussion. What about if we > use something besides Kerberos to get AFS tokens? Apple seems to be > headed in the direction of using the Keychain Manager to show PKI- > based permissions. That's a pretty disjoint GUI from Kerberos.app. > My belief is that that's far enough off that it's worth doing > something about the UI confusion with tokens and Kerberos anyway. > Something to ponder in odd moments. If you used something other than Kerberos to obtain the AFS tokens then you would not have an afs service ticket in a Kerberos credential cache for that token. However, you would still have a token that you would only be able to list with the afs "tokens" command. What you really want is for Apple to provide an equivalent of the Network Identity Manager that Asanka Herath built for Microsoft Windows. The framework provides a concept of an Identity Module. There can be Identity modules for Kerberos 5, X.509/SmartCards, etc. In addition there are Credential modules. We have Kerberos 5, Kerberos 4, AFS, and there could be KX.509, etc. The user has the ability to obtain credentials for multiple identities at the same time. With each Identity module there is a primary Credential module. The primary credential module is responsible for performing functions such as automatic renewals. After the primary credential defining an identity is obtained either initially or upon a renewal, the identity module calls each of the credential modules to obtain credentials that are derived from that identity. This allows a Kerberos 5 TGT to be used to obtain a Kerberos 4 TGT and as many AFS tokens for as many AFS cells as are required by that identity. Each identity can have a separate list of AFS cells and the mechanism used to obtain the tokens (Kerberos 5, Kerberos 5 to 4 translation, etc. can be specified per cell. If there was a KX.509 credential module then it could be used to obtain X.509 client certificates. Going in the reverse direction, a X.509 Identity manager could use an X.509 client certificate or a smartcard to obtain a Kerberos 5 TGT via PK-INIT. The AFS tokens could then be obtained either with the certifcate or with the derived Kerberos 5 credential. The credential modules are also responsible for feeding all of the credential data into a unified GUI. The users can then choose to display their credentials organized by Identity and Type, or Type and Identity, or by Location (credential store), or by a custom order determined by manual column sorting. Users can also choose how much data is displayed about each credential. This tool could be integrated with support for WS-Trust and become an InfoCard provider. The benefits of a tool such as the Network Identity Manager for the end user is that there is a single location that the users go to in order to display and manage all of their security credentials regardless of how the credentials are obtained. At the moment we don't have such a framework for MacOS X. Therefore, we have to manage with what we've got. In that situation the appropriate thing to do is to provide a separate AFS Token Manager tool that displays AFS tokens for the end user regardless of what is reported by Kerberos.app. Kerberos.app shows the contents of the Kerberos credential caches and that is all. Kerberos service tickets are preserved in the cache to optimize the time it takes to provide applications tickets when they are asked for repeatedly. The Kerberos credential cache is not bound to the contents of the AFS kernel module. Any attempt to use the Kerberos credential store contents to indicate the presence or absence of an afs token is going to result in confused users at one time or another. Support personnel can use the Kerberos credential cache as a debugging tool. They can't use it as an indicator that an AFS token exists for any particular cell and principal name at any given time. I believe the following GUI tools are required for AFS: (1) an AFS token manager. This tool displays the current tokens and can be used to obtain new ones or remove the existing ones. This could be replaced by a Network Identity Manager type tool if it was provided by Apple. (2) an AFS System Preferences tool which can be used to modify the startup parameters for the AFS kernel module, probe the AFS Cache Manager status, and configure the list of cells for which tokens should be obtained when a kinit or login is performed. (3) an AFS Finder Extension that would allow the user to manipulate mount points, ACLs, Flush Files, Directories, or Volumes, and show various AFS related information as reported by "fs examine" or "vos examine". This is not a small amount of code to write and we will need resources in order to be able to produce it. Anyone interested in volunteering is invited to contact the OpenAFS gatekeepers. Jeffrey Altman _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
