Mail.app with multiple accounts using Kerberos
Ken Hornstein
kenh at cmf.nrl.navy.mil
Fri Aug 19 16:20:46 EDT 2005
>> 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
More information about the Kerberos
mailing list