Credential Cache for multiple client principal names

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Credential Cache for multiple client principal names

Rick van Rein (OpenFortress)
Hello,

I'm trying to create [1] a mechanism to be used from multiple client
principal names, each with their own service tickets.  Secure separation
between the identities is not an issue.

It is not clear to me how to do this.  I suspect I should use
DIR:/var/mytool and perhaps KEYRING: on Linux, but it is not clear if
I'm supposed to read and write tickets (including krbtgt) for various
client principal names in the same cache, or that I should instead
iterate it as a credential cache collection, and prod each credentials
cache for the (default) client principal name and add a new one to the
collection if I need it.

Can you help me, or perhaps show me some examples that do this?

Thanks,
 -Rick

[1] I'm working on a "TLS Pool" daemon [2] that takes TLS logic away
from applications and that will incorporate a mode for Kerberos [3].

[2] http://tlspool.arpa2.net

[3] https://tools.ietf.org/html/draft-vanrein-tls-kdh-04
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Credential Cache for multiple client principal names

Simo Sorce-3
On Wed, 2016-06-29 at 16:15 +0200, Rick van Rein wrote:

> Hello,
>
> I'm trying to create [1] a mechanism to be used from multiple client
> principal names, each with their own service tickets.  Secure separation
> between the identities is not an issue.
>
> It is not clear to me how to do this.  I suspect I should use
> DIR:/var/mytool and perhaps KEYRING: on Linux, but it is not clear if
> I'm supposed to read and write tickets (including krbtgt) for various
> client principal names in the same cache, or that I should instead
> iterate it as a credential cache collection, and prod each credentials
> cache for the (default) client principal name and add a new one to the
> collection if I need it.

DIR or KEYRING should be equivalent for your purpose, they are both
cache collections.

> Can you help me, or perhaps show me some examples that do this?

Have you looked in kinit/kvno/gssapi code ?

If you set up two realms in two separate DNS domains and then kinit to
two different principals, you can see how kvno or any gssapi application
will work to store tickets in the caches to access services in the two
realms.

> Thanks,
>  -Rick
>
> [1] I'm working on a "TLS Pool" daemon [2] that takes TLS logic away
> from applications and that will incorporate a mode for Kerberos [3].
>
> [2] http://tlspool.arpa2.net
>
> [3] https://tools.ietf.org/html/draft-vanrein-tls-kdh-04


--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Credential Cache for multiple client principal names

Rick van Rein (OpenFortress)
Hello,

Thanks Simo!
> DIR or KEYRING should be equivalent for your purpose, they are both
> cache collections.

Good, I seem to be onto something then :)
>> Can you help me, or perhaps show me some examples that do this?
>
> Have you looked in kinit/kvno/gssapi code ?

Thanks!  I found that kinit has another instrument, where it has one
cache, but supportive of krb5_cc_support_switch() so I could use
krb5_cc_cache_match() instead of the iteration over a cache collection,
and krb5_cc_new_unique() to add a new identity.

The kinit approach sounds lighter-weight, though I'm not yet clear if it
will let me work on any but the current cache, which could be
problematic since my TLS Pool is multi-threaded, to handle multiple TLS
connections for multiple users.

Any hints on that are welcome of course :)
> If you set up two realms in two separate DNS domains and then kinit to
> two different principals, you can see how kvno or any gssapi application
> will work to store tickets in the caches to access services in the two
> realms.

Hmm, I tried that with kinit and it was confusing me -- but that might
be because its sole purpose is to initiate a cache.  I will try kvno as
well then, good hint :)


Best wishes,
 -Rick
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev