On Fri, Oct 24, 2025 at 4:15 AM Osipov, Michael (IN IT IN) via Kerberos < [email protected]> wrote:
> 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. > This is the biggest problem with security APIs in general and is not specific to Java. RFCs, drafts and implementations tend to focus on authentication and crypto but what is equally important and almost completely overlooked is the management of secrets, accounts and trusts. Ideally every device should have a virtualized program that manages secrets like plaintext, base keys, tickets, access tokens etc associated and accounts (probably non-authoritative proxy account but could also be authoritative local) and trusts (which implicitly covers the concepts of realms and domains). Programs would connect to this program over a pipe or socket, get a session id and then let it produce / consume tokens like GSS, bearer etc and leave the specifics of "providers" and protection of secrets up to the host device. Of course I'm leaving a lot out like syncing data between devices (the achilles heel of passkeys), role mapping, ... Mike -- Michael B Allen Java AD DS Integration https://www.ioplex.com/ <http://www.ioplex.com/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
