On 2025-10-24 02:53, Jake Scott wrote:
Hi there..
I've been working on a spec for GSSAPI on Go similar to RFC2744 and RFC2853
for C and Java. I have a working implementation of the described interface
and a provider that wraps the MIT & Heimdal C libraries. The idea is to
provide an idomatic interface for Go developers that supports multiple
providers (like the C provider or a pure Go provider at some point).
I forgot to mention regarding a pure Go provider: This would be the same
situation as in Java. I highly do NOT recomment doing so for at least
these reasons:
* You will constantly lag behind other providers
* You will either miss or be forced to implement custom ticket cache
providers, e.g., SSSD comes with a memory-based one similar to Windows'
LSASS, but JGSS does not support it, therefore Java cannot use it:
ddsnvo@deblndw013x2v:~
$ klist
Ticket cache: KCM:1000:28297
Default principal: [email protected]
Valid starting Expires Service principal
24/10/25 09:41:55 24/10/25 19:41:55 krbtgt/[email protected]
Java's ticket cache is pure memory which means pure crap. I need to
change and fiddle with the Subject between threads in a thread pool
executor while MIT Kerberos does this nicely either with a file-based or
KCM-based cache. The Java approach leads to more code or a cache
per-thread which is slow to populate.
* If you consider to add SSPI to the might at some might you won't never
be able to tap into the TGT because LSASS will never grant to direct
access to it (this busted Java years ago). You have to go through direct
APIs only. This might be the case with Apple Kerberos as well with a
custom cache provider.
Michael
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
