Mail.app with multiple accounts using Kerberos

[Ken Hornstein]

>> There are a couple of problems:
>> 
>> - There is something in the credential cache called the "primary principal",
>>   or the "default principal".  It's the first thing printed out by klist.
>
>I want to make sure we are clear here... I am dealing with the problem of > 1
>principals in multiple realms (eg principal a in realm xyz.com and principal b
>in realm abc.com) and not the same realm (eg principal a in realm xyz.com and
>principal b also in realm xyz.com) -- 2 different problems.

Yes, I understand you; that's what I'm talking about as well.

>At first glance, it would seem that given more than 1 principal w. each
>principal in a separate realm, if you want to choose the default, well, there
>is this "default_realm" value in the  kerberos config file. Otherwise, look at
>the dns name of the server to which we want to connect.

Technially, you don't care about the DNS name of the server ... what you
care about is the _realm_ the server is in.  A minor, but important
distinction.

Now ... to answer your question more completely ...

- There isn't a good way for an application to get access to the
  "default_realm" value in the config file.  Yes, there is
  krb5_get_default_realm() ... but that can be overridden by
  krb5_set_default_realm().  But what that configuration option
  really means is "append this when you're converting a user-supplied
  unqualified principal".  It doesn't have any other meaning, and it's
  really designed to be used internally by the library.

- How exactly do I know that I _want_ to use the default, versus some other
  realm's client principal?  This is the crux of the problem, and I don't
  think you've quite grasped the issue here.  There is currently no way
  to determine if I should do cross-realm versus try a different client
  TGT ... and since the current library really doesn't support multiple client
  principals in the credential cache, no one has figured out the right
  behavior to do when you _do_ have multiple client tickets in the
  credential cache.  Even MacOS X cheats; when you switch principals,
  it changes the whole credential cache out.

>Does this no apps making use of the multiple TGTs have to do w. the design of
>the credentials? Or just programmers making the assumption that no one would
>ever want to, say, check mail in 2 different realms at the same time?

Technically, you _can_ check mail in two different realms at the same time.
You just can't use two different client principals in the same credential
cache.

It's a combination of:

- Not-wonderful API

	When you get credentials for a service, you need to fill in the
	client credential structure.  Under the current API, this is not
	optional - so you need to fill it in with _something_.  How
	do you determine what "something" is?  Well, the only way to
	reasonably deal with that today is to take the default principal
	out of the credential cache and use that to fill it in.

	Now, you're going to say, "Well, look at the service realm" ...
	okay, assuming that was a good idea (it would break for sites
	that do cross-realm), _that_ just gets me the realm.  Where
	do I get the username portion of the principal?  You could
	in theory iterate over the credential cache and look for TGTs
	that match the service realm, but that ends up being a lot of
	code.  And that's assuming that you're using the raw Kerberos
	API.  If you're checking email, then you're using GSSAPI, and
	I'm not sure there is a way to pass in a client identity to that
	API (it may be possible, I am not the GSSAPI expert).

- Lack of documentation/example programs

	All of the example programs I've ever seen out there all get
	the client principal from the default principal in the credential
	cache.  So there is now a large body of code that does it this
	way.

- Original model where most people did cross-realm authentication.

	Like I said, the original model for this was that you should
	cross-realm in this scenario.  That of course affected the
	API and application design.

>>   TGTs in seperate "sessions" and switch between them (MacOS X), but
>>   when the "session" is switched, so is the primary principal.
>
>And, interesting things happen if I, say, select the principal from a different
>realm than the server to which I am trying to connect. I've seen it do things
>such as take the principal and slap the wrong realm name on there and send that
>to the server.

That surprises me, but I could believe that it happens.

>> - Let's pretend this isn't a problem.  The problem then becomes ... how do
>>   you decide what to do?  Do you attempt cross-realm authentication?  Do
>>   you search the credential cache for a TGT in the foreign realm and use
>>   that?  There is, unfortunately, no good answer ... although people are
>>   exploring the options.
>> 
>
>The easy out is, what does the config file say to do?

Except the config file doesn't really have a setting today that addresses
this.

>> The sites that I've seen address this today do so by setting up cross-realm
>> authentication.
>
>Unfortunately, this has a whole slew of "do I trust the other realm?" problems
>:(

There's essentially no reason for you to not do cross-realm with anyone.
The real problem is that people don't understand that.

--Ken