David: The goal is not to have a command line interface in place of a GUI. The goal is for the user to never have to be involved or at least to minimize the user involvement in authentication decisions as much as possible. Granted, there needs to be a mechanism by which users can configure the bindings between the resource and the authentication credential to be used.
Today in order to minimize the interactions with end users, we desire
the ability to utilize single sign-on and automatic credential renewal
via the Kerberos Login Library plug-in. (Unfortunately, this is not
working quite right on Tiger.)
A binding is established by the Kerberos principal name stored in the
default credentials cache combined with the cell listed in the ThisCell
file. When aklog is executed an AFS token is stored for the user in
the AFS kernel module. The AFS kernel module then selects the
credential to use for any given directory by matching the
cellname the directory resides in to the cellname associated with the
token. This produces a binding of one token per cell per user.
For users that have multiple cells they need to acquire tokens for
there is the "TheseCells" file. Assuming all the tokens are acquired
using the same Kerberos principal, tokens for each cell listed in the
file are acquired in addition to the cell listed in the "ThisCell" file.
(Note to self, aklog must be modified to support "TheseCells".)
What we do not have at present is a mechanism by which tokens can
be obtained automatically for users when multiple Kerberos principals
must be used.
Assuming we can get this to work then AFS users only need to become
involved in obtaining credentials for use with AFS when:
(1) the Kerberos credentials could not be initially obtained at
system login time (perhaps because there was no network
connectivity)
(2) the Kerberos credentials expire
Since the AFS kernel module cannot prompt the user for tokens in that
case, we need a GUI such as "AFS Tokens.app" to provide end users the
interface required to request tokens. I believe that in the short term
the "AFS Tokens.app" should work like this, a user should be
able to obtain a token with:
+ Cellname
+ Kerberos Principal Name
+ specify method (Kerberos 5 or Kerberos 5 to 4 translation)
"AFS Tokens.app" should call into the Kerberos Login Library to obtain
the credentials and the KLL should prompt the user for the Kerberos
password if required.
Thoughts?
Jeffrey Altman
David Botsch wrote:
> I've seen the opposite here... users much prefer a gui to having to do things
> in a commandline interface. As soon as you tell a user to go to the terminal
> or
> start up X11, the user's face blanks over.
>
> On Tue, Mar 21, 2006 at 09:12:39AM -0800, Ernest Prabhakar wrote:
>> Hi lxs,
>>
>> On Mar 21, 2006, at 7:01 AM, Alexandra Ellwood wrote:
>>> 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).
>> Um, I'm having trouble following this argument, but I want to make
>> sure I understand your issue. I completely understand that AFS users
>> don't want to run a GUI application. But, I'm confused with how that
>> impacts the issue of using "Keychain Services" as the underlying API
>> and storage mechanism for managing AFS tickets:
>>
>> http://developer.apple.com/documentation/Security/Conceptual/
>> Security_Overview/Security_Services/chapter_4_section_6.html
>>
>> Presumably, it would be straightforward for AFS and Kerberos to use
>> Keychain Services and provide their own CLI interface, no? Or are
>> you concerned about something completely different?
>>
>> -- Ernie P.
>>
>> _______________________________________________
>> OpenAFS-devel mailing list
>> [email protected]
>> https://lists.openafs.org/mailman/listinfo/openafs-devel
>
smime.p7s
Description: S/MIME Cryptographic Signature
