Kerberos authentication support

[theS1LV3R]

Is your feature request related to a problem? Please describe. The current authentication system lacks support for Kerberos. Kerberos is great for quick and easy authentication, especially in linux-based environments.

Describe the solution you'd like Implementation of Kerberos authentication to make authentication simpler and faster.

Describe alternatives you've considered Xen Orchestra supports a bunch of other auth methods, but all of them require another form of interaction (OAuth based require authorization on their respective websites, LDAP requires filling in credentials). Kerberos requires no additional action to authenticate the user after loading the website.

Additional context In my organization we use FreeIPA for IDP. It supports joining machines, and having those machines give Kerberos tickets to users to authenticate them on websites that support it. No additional action required.

• GitLab's documentation: https://docs.gitlab.com/ee/integration/kerberos.html
• Jenkins' documentation: https://plugins.jenkins.io/kerberos-sso/
• Kerberos strategy for Passport.js: https://www.passportjs.org/packages/passport-kerberos/

[olivierlambert]

Hi

OIDC is already a very simple strategy to authenticate against XO and doesn't require any complex configuration (see our tutorial with Keycloak).

We do not use Kerberos here, so we do not have any way to test against it. Indeed, our JS library used to connect seems to support it, but we have 0 knowledge on what's needed to provide.

If you want to help, you can already provide a list of fields required (draw like if it was similar to the OIDC plugin for example). Note that's hard for us to maintain many different kind of auth since we need to test them in our environment (so it means installing FreeIPA first and understand how it works).

If you can contribute more (eg with code) we'll be even happier :smiley:

[theS1LV3R]

I'll see what I can do! It would be a sweet feature to have.

I'll get back to you.

[theS1LV3R]

Here is a screenshot of what it could look like.

The general flow for how Kerberos works in this case, also called SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism), would be as follows (Works the same for both FreeIPA and Active Directory:

0. The server (Xen Orchestra in this case) would get a Keytab from the Domain Controller or FreeIPA. This would be valid for a service, in Kerberos5 (KRB5) this would for example be HTTP/xen-orchestra.example.com@EXAMPLE.COM, service/hostname@DOMAIN.
1. The user would go to the website and
2. Get a 401 Unauthorized response back, with a negotiation offer using the WWW-Authenticate: Negotiate header
3. The browser would request a service ticket from the Domain Controller
4. And get a service ticket in return
5. The browser would then send this service ticket to the server
6. Which it would check against the DC using its own keytab for security
7. And if its valid, it would authenticate the user

I.e. the server would need to have gotten a keytab from the DC itself before being able to do anything, so the keyTab argument in the first screenshot

[theS1LV3R]

Whoops, accidentally closed