Support SPNEGO/Kerberos for ExtAuth

[murphye]

For our Enterprise ExtAuth service, I could see adding support for SPNEGO/Kerberos. I have personally seen Kerberos in use at large customers for authentication for back-office types of applications.

This article, while focusing on Spring implementation, offers a nice explainer and links for reference: https://www.baeldung.com/spring-security-kerberos

This Envoy issue offers hints on how this can be implemented for ExtAuth: https://github.com/envoyproxy/envoy/issues/3876

What would be interesting is if Envoy can act as the Kerberos client, and be a 2nd stage of authentication for a request. The first step would be to authenticate the real client via OIDC, and then create the SPNEGO token afterwards. This would support modernization of legacy apps that use Kerberos with APIs that use OIDC.

Keycloak supports SPNEGO/Kerberos so the documentation would be helpful and could act as the Kerberos provider: https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/authentication/kerberos.html

[murphye]

I should add more context around this. First read this article: https://www.quora.com/What-are-the-differences-and-common-points-between-the-oauth-protocol-and-Kerberos

SPNEGO/Kerberos is fine for "back-office" types of applications running on a single LAN together in a data center. You can even set up a web browser to support Single Sign-On with Kerberos when running on this Intranet LAN.

This solution fits in where a company is trying to modernize back-office applications while also moving to the cloud. The concept of a single intranet LAN with consolidated application deployments goes away at that point. Something (i.e. Gloo Edge) needs to become the gateway and also the glue from a security perspective for both SPNEGO/Kerberos and OIDC.

[overbum]

What is about strong FQDN requirement for MIT Kerberos RFC? Any hostname change via proxy means MITM. You will never get a TGS with changed destination host when you ask proxy with another ip (host). There is no way to go around. It is protocol thing. Proxy is good for 2-ways mTLS (CN=username) or OpenID authentication. But UPN goes to specific SPN that has name service/fqdn@REALM asking KDC who will deny that request. Of course there is 3 non-standard solutions to pass through but no one can be accepted by a security team.

And finally classic issue: any ticket has big lifetime (hours). But when you go from external source or browser you can't cache your ticket to repeat new requests. So it will be DDoS to KDC. Any "good senior" says to scale your infrustructure but no one read MIT Kerberos docs. Credential cache is important thing for Kerberos auth in high-loaded area. Proxy is not exclusion.

Try to login to windows then exit and login again and to do it thousand times at same time you can feel what KDC feels when proxying.

The best solution to use special auth gateway (for example Keycloak, Knox, Kerby) that supports various authentication types to authenticate once and to re-authenticate before tickets will be expired, also once. And never use Java language without Sun Native GSS library, becuase Oracle hates open-source community.

[github-actions[bot]]

This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.

[github-actions[bot]]

This issue has been closed due to no activity in the last 12 months.