Kerberos Auth does not exist

[Naarcha-AWS]

Is your feature request related to a problem? Please describe.

Upon investigation, it seems like Kerberos authentication was not added to Security Dashboard Plugin, despite existing in OpenSearch. Specifically, according to Eliatra, the Dashboards plugin did not include a full fork of the Search Guard plugin. Instead, the contents of the fork were recreated piece by piece, with OIDC, SAML, and basic auth implemented incrementally (https://github.com/opensearch-project/security-dashboards-plugin/tree/main/server/auth/types vs https://git.floragunn.com/search-guard/search-guard-kibana-plugin/-/tree/master/server/applications/searchguard/auth/types).

This will prove to be a significant blocker for users, as evidence by the following issue from the Documentation repo (opensearch-project/documentation-website#398 (comment)).

Describe the solution you'd like

Implement the full Search Guard plugin into the Dashboard's plugin. Or, implement Kerberos authentication into the plugin.

[melokk97]

Any updates on this?

[mercury131]

Can you tell when this issue will be resolved?
Because of this bug it is impossible to use kerberos in opensearch.
If I set order 0 for kerberos in security plugin config, opensearch dashboards can't authorize anymore.

[gpchelkin]

Kerberos auth is widely used in my environment. It would be great if you fix it in the near future.

[denMko]

It would be great to use kerberos auth with dashboards, so..
Сan we wait the fix in the near future/release?

[samuelcostae]

I've started looking into this @scrawfor99 . Commenting so it can be assigned.

[samuelcostae]

Had to leave this for a bit to focus on other issues, but started again last week and now started to working on testing

[samuelcostae]

Im currently working on Unit tests.

Regarding integration testing , like we mentioned in the last call, we were discussing if would be worth it to have integration tests in dashboards as there isn't much logic/ code involved and most of the authentication of process is done by the browser, the kerberos KDC and the Kerberos configuration on the user machine.

It seems that the backend security plugin doesn't have tests for Kerberos, so it could be the case the effort would better applied in adding the tests to the backend?

Any thoughts on this?

@jochen-kressin feel free to add to my summary of the scenario

[davidlago]

@samuelcostae could we get a description of the current situation and proposed changes with pros/cons of the approach and different testing strategies? that way we'll be able to make a call to move forward. Thanks!

[samuelcostae]

I will try to be more specific

• Kerberos support already existed in the OS Security Plugin
• There are no tests for Kerberos on OS Security Plugin (Neither unit or integration)
• As part of this issue, Kerberos support was/ added to Dashboards Security Plugin
• This process is basically:
  Send Browser's Auth request to OS Security Plugin
  The server will respond with '401 Negotiate' and Dashboards pass that to response to Browser
  The Browser(if configured correctly and access to valid keytab) will then Request a Kerberos ticket to the Kerberos's KDC(Key Distribution Center)
  The browser will include that Ticket in the request header and send the auth request again
  OS Security Plugin reads the ticket in the request and asks the KDC to validate it. If valid, the user is authenticated.

Proposal 1: Only do unit tests for Dashboards integration
Pros:
- Less work
- Existing authentication methods on dashboards are done like this.
- Faster test execution
Cons:
- Less throughout Testing

Proposal 2: Do full Integration tests for Dashboards
Pros:
- More throughout Testing

Cons:

• Slower to run
• Extra configuration and moving parts required, like:
  Additional Container for Kerberos's KDC
  Kerberos configuration on the client
  Client and Server keytabs for accessing the KDC
  Cypress seems to have issues with Kerberos from what I've seen.
• This extra work would be covering a pretty basic process from the Dashboards point of view.

[peternied]

@samuelcostae Thanks for looking into this. We shouldn't invest any effort into this space right now. Without end to end validation we cannot know if the feature works and we don't have a strong commitment (sadly) to invest in this space. As much as it pains me that we aren't investing into kerberos, this isn't the right time with the other considerations.

[Nihlus]

Are there any plans to revisit this? Having Kerberos support is quite important for single sign-on, especially in an LDAP/FreeIPA environment where external SSO alternatives are relatively limited.