Re: Alternative proxy-creds API for constrained-delegation
Nico Williams <[email protected]>
| Newsgroups | gmane.comp.encryption.kerberos.devel |
|---|---|
| Message-ID | <20200603032831.GU7856@localhost> |
On Wed, Jun 03, 2020 at 01:16:15AM +0200, Isaac Boukris wrote: > On Wed, Jun 3, 2020 at 12:03 AM Nico Williams <[email protected]> wrote: > > On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote: > > > What does the daemon do once it get a proxy-creds upon accepting with > > > GSS_C_BOTH? Do we have an API to do init_sec(), just get the ticket, > > > extract it and return it to the caller, maybe krb5 api? How does the > > > caller gets it injected to its cache, would that be possible? > > > > If you get a deleg_cred_handle, you should be able to use it in the same > > process without further ado -- no changes needed to code calling > > gss_init_sec_context(), and no gss-proxy should be needed either. > > I agree no changes needed to code calling gss_init_sec_context() > should be made, but if we only have a tgt-less cache someone would > have to do the work, thus a proxy is needed. I was trying to imagine > how the proxy code would look like, and how would it return the > requested ticket to be saved in the client cache for next usages. That still involves no API changes. The proxy _could_ share a cache with the user process calling it if that's a useful optimization, but it's an optimization, and probably not essential. For the optimized case, the proxy client would have to be invoked by the non-proxy krb5 mech if it doesn't find the desired service ticket in the cache. _______________________________________________ krbdev mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/krbdev