ccache using linux keyring
Alexandra Ellwood
lxs at MIT.EDU
Fri Apr 15 14:04:23 EDT 2005
On Apr 14, 2005, at 2:39 PM, Kevin Coffman wrote:
>>
>>> This assumes that my default realm is CITI.UMICH.EDU and I've gotten
>>> several ticket for the CITI.UMICH.EDU realm. Then I've done
>>> % setenv KRB5CCNAME KEYRING:/tmp/krb5cc_20010_umich
>>> % kinit kwc at UMICH.EDU
>>> and then ran the utility to make /tmp/krb5cc_20010_umich my active
>>> ccache. gssd will then try to use my UMICH.EDU tickets to get
>>> service tickets to negotiate NFSv4 gss contexts.
>>>
>
> After discussing this here with Bruce, I think having more than one
> ccache in the session ring is unnecessary. If you want to do this
> sort of thing, you would do the equivalent of a setpag and get into
> a new session keyring. That still leaves the problem of gssd finding
> the ccache w/o environment variables. However, naming the keyring
> something like "krb5ccache:<residual>" and having only one ccache
> in a session ring would allow it to work.
There are a bunch of Kerberos sites with multiple realms which for
various (political) reasons cannot share keys. As a result, users at
these sites need to get multiple TGTs for different client principals
(ie: me at A.EXAMPLE.COM, me at B.EXAMPLE.COM, etc). When using file or
CCAPI based ccaches, these sites currently get one ccache per client
principal and use KRB5CCNAME or the CCAPI default ccache concept to
control which applications are using which sets of tickets.
Single sign-on issues aside, these sites would like their users to
not have to constantly switch which ccache they are looking at.
Instead, they want the Kerberos libraries to search for the correct
principal (based on heuristics yet to be determined). Given the way
the existing ccache formats work, this would most likely involve
searching over a list of ccaches.
Anyway, you might want to keep these sites is mind when deciding
whether or not the keyring implementation will support multiple
ccaches in a single keyring. Even if it is possible to search across
multiple keyrings, doing so would add keyring-specific code to the
searching code in the krb5 libraries. This would be undesirable
because of the increased complexity.
--lxs
Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>
More information about the krbdev
mailing list