LDAP / Kerberos Authentication with ticket retrieval

Hello all,

In a context of securing services for HPC clusters, we need to implement a feature related to Kerberos authentication. We are currently using Keycloak to secure authentication to certain services related to the cluster and this is working great. The authentication is performed via Kerberos through the use of the LDAP User Federation with Kerberos enabled for both Username password and SPNEGO.

The feature we would need is the follwing : upon successful authentication, have the ability to keep the Kerberos ticket (TGT) so that keycloak would be able to “forward” it to a dedicated component that we have the control of within our environment.

By looking at the code for Kerberos authentication, it seems obvious that the Kerberos ticket received after a successful authentication is not kept, for instance, for Username / Password Kerberos auth, we have :

(I have yet to dig into the SPNEGO code but I assume it is not looking for a forwardable TGT in the received TGS)

**In a nutshell, the feature we need is this : **
1. User authenticates to the service via Keycloak via Kerberos
2. Upon successful authentication, Keycloak keeps the Kerberos TGT and is able to do something with it (forward it or whatever action we would need)

In your opinion, what would be the best way to perform this kind of feature ? I see 3 possible paths :

  1. Update the Keycloak code for Kerberos auth (https://github.com/keycloak/keycloak/tree/575851d45c8c770bee02ef6682def665f0370636/federation/kerberos/src/main/java/org/keycloak/federation/kerberos) but that seems like heavy changes.
  2. Implement a Kerberos Authenticator SPI (https://www.keycloak.org/docs/latest/server_development/index.html#_auth_spi) that would do just what I described
  3. Implement a UserStorage SPI that would mimick the existing one with the additional features of Kerberos TGT handling that I described. (https://www.keycloak.org/docs/latest/server_development/index.html#_user-storage-spi)

Thank you for reading.