[OpenAFS-devel] aklog on MacOS X was Re: Service Ticket Questions

[Alexandra Ellwood]

On Mar 20, 2006, at 9:34 PM, Jeffrey Altman wrote:

> 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.
>

Apple has such a tool.  It's called Keychain Access.  It stores  
certs, passwords, identity preferences... basically anything living  
in your keychain.  I can't speak for Apple (I'm not even an Apple  
employee) but I'd place good money on this being where Apple would  
display Kerberos and AFS credentials if they were doing the support  
themselves.

That being said I've never placed high priority on Kerberos support  
in Keychain Access because Mac users don't seem to want it.  Mac  
users want Kerberos to work without any interaction with any tools.   
They want to be prompted for tickets when they need new ones (or have  
them automatically acquired in the pkinit case).

For example, we've provided automatic ticket renewal via Kerberos.app  
in KfM for several years now, yet we still receive numerous bug  
reports asking for automatic ticket renewal.  When we point out the  
support in Kerberos.app, users invariably reply that having to run an  
application to get that support is unacceptable, even if that  
application is automatically launched as part of their startup  
items.  From the user's standpoint the only acceptable solutions  
involve seamless behavior with minimal interaction on their part.

As a result I bet that a Network Identity Manager or Kerberized  
Keychain Access would be just as unloved on Mac OS X as Kerberos.app  
is.  At best it would be used as a tool for support staff to diagnose  
authentication problems.  Which makes it very low priority given the  
development resources available to the KfM product (ie: me).  This is  
why I've been putting all my effort into the new KLL.  The goal of  
the new KLL is to provide prompt-based identity selection similar to  
the way passwords are prompted for already.  Note that this is  
effectively what Apple already does with the keychain access when it  
asks whether you want to use something stored in the keychain.


Note that I suspect this mentality is unique to the Mac and  
intentionally fostered by Apple.  Apple consistently provides  
interfaces which emphasize simplicity and seamlessness.  You can see  
this with the existing uses of the keychain.  Users basically only  
visit Keychain Access when something has gone wrong.  Normally cert/ 
password/identity selection is done by keychain dialogs which are  
automatically spawned by the application that needs the cert/password/ 
identity.


--lxs

Alexandra Ellwood <lxs@mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>