Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kerberos support #30243

Closed
7 of 8 tasks
bizybot opened this issue Apr 30, 2018 · 3 comments · Fixed by #32263
Closed
7 of 8 tasks

Kerberos support #30243

bizybot opened this issue Apr 30, 2018 · 3 comments · Fixed by #32263
Assignees
Labels
>feature Meta :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)

Comments

@bizybot
Copy link
Contributor

bizybot commented Apr 30, 2018

Support for Kerberos

Requirements:

  • Single Sign-on for Kibana using Kerberos
  • Using Kerberos for REST API clients

RFC: https://tools.ietf.org/html/rfc4559, https://www.ietf.org/rfc/rfc2478.txt

Kerberos

Typical Use case:

  • User logs into her desktop with credentials (eg. windows machine in AD domain) get Kerberos ticket from AuthenticationService (TGS, KDC)
  • User uses a browser to access web application server secured by Kerberos
  • Server rejects the request with HTTP 401 Unauthorized status and HTTP header WWW-Authenticate: Negotiate with the login page
  • If the browser supports SPNEGO will request TGS for session ticket for given service principal name HTTP/service@REALM, creates base64 Kerberos SPNEGO token and send it as HTTP header Authorization: Negotiate base64-encoded-kerberos-ticket, else will display the login page to the user
  • The server verifies session ticket from the browser, if successful sends HTTP 200 status with final header WWW-Authenticate: , else will return HTTP 401 Unauthorized status
  • Browser authenticates server for mutual authentication and displays next page

KibanaSPNEGO

High-level tasks with priority (P? - Priority levels 0 being the highest priority task):

  • P0 As ES Admin, I would like to use Kerberos as an authentication mechanism to protect my data
    • KerberosRealm supporting SPENGO mechanism authentication only
      • Based on the client (Kibana or REST) selects appropriate service keytab completes service login.
        Refer Java Krb5LoginModule
      • After login, creates GSSContext and continues with the SPNEGO authentication.
    • Cache User after authentication avoiding unnecessary calls to AD/LDAP for UPN to user DN and group queries
    • Take care when servers behind proxy verify HTTP header Proxy-support: Session- Based-Authentication
  • P0 As ES Admin, I would like to configure KerberosRealm
    • Configure SPN (Service principal name) for ES and Kibana HTTP service
    • Single keytab for multiple SPNs, readonly in config directory.
    • Use krb5.conf to define kerberos config properties. -Djava.security.krb5.conf=
    • Bootstrap checks for stronger settings validations
  • P0 As ES Admin, I would like to audit log all authentication, authorization events.
    • Note: This is already done just need to test
  • P0 As ES Admin, I would like to use Kerberos with or without AD/LDAP integration
    • Uses LDAP realm configuration if integration is required
  • P0 As ES Admin, I would like to have user/user group role mapping
    • We can make use of existing AD/LDAP role mapping settings
  • P0 As ES client (Kibana), I would like to use Kerberos SPNEGO to authenticate with ES for SSO
    • Option 1 (Preferred): We could make use of token API (POST /_xpack/security/oauth2/token, DELETE /_xpack/security/oauth2/token) where we use the Kerberos ticket as the password. On successful authentication, the response would be oauth2 token and header WWW-Authenticate: token-for-mutual-auth. On failure returns with HTTP 401 Unauthorized status and HTTP header WWW-Authenticate: Negotiate.
    • Option 2: Separate API for Kibana, ES will use Kibana service principal name for authentication by validating user Kerberos ticket (POST /_xpack/security/kerberos/authenticate). If successful, will return HTTP 200 OK, header WWW-Authenticate: and token generated by token service for future use by Kibana for that user session else returns HTTP 401 Unauthorized. Logout API for invalidating the token ( POST /_xpack/security/kerberos/logout)
    • Kibana acts as a proxy passing on the SPNEGO tokens to ES and responds to the client with appropriate headers as expected in SPNEGO
  • P1 As ES client (REST API), I would like to use Kerberos SPENGO to authenticate with ES
    • Uses Elasticsearch principal name for authentication by validating user Kerberos ticket
  • P0 As ES ops/developer, I would like Kerberos documentation and How-To guide

Security Considerations:

  • Support for channel binding will be considered as future enhancement.

Future:

  • Support for Microsoft PAC
  • Kerberizing Elastic stack - this is cross team and needs discussions to gather requirements from all teams (Kibana, Beats/Logstash, Clients etc.)
@bizybot bizybot added >feature :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) labels Apr 30, 2018
@bizybot bizybot self-assigned this Apr 30, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@bizybot bizybot added the Meta label May 2, 2018
jaymode pushed a commit that referenced this issue Jul 24, 2018
This commit adds support for Kerberos authentication with a platinum
license. Kerberos authentication support relies on SPNEGO, which is
triggered by challenging clients with a 401 response with the
`WWW-Authenticate: Negotiate` header. A SPNEGO client will then provide
a Kerberos ticket in the `Authorization` header. The tickets are
validated using Java's built-in GSS support. The JVM uses a vm wide
configuration for Kerberos, so there can be only one Kerberos realm.
This is enforced by a bootstrap check that also enforces the existence
of the keytab file.

In many cases a fallback authentication mechanism is needed when SPNEGO
authentication is not available. In order to support this, the
DefaultAuthenticationFailureHandler now takes a list of failure response
headers. For example, one realm can provide a
`WWW-Authenticate: Negotiate` header as its default and another could
provide `WWW-Authenticate: Basic` to indicate to the client that basic
authentication can be used in place of SPNEGO.

In order to test Kerberos, unit tests are run against an in-memory KDC
that is backed by an in-memory ldap server. A QA project has also been
added to test against an actual KDC, which is provided by the krb5kdc
fixture.

Closes #30243
jaymode pushed a commit that referenced this issue Jul 24, 2018
This commit adds support for Kerberos authentication with a platinum
license. Kerberos authentication support relies on SPNEGO, which is
triggered by challenging clients with a 401 response with the
`WWW-Authenticate: Negotiate` header. A SPNEGO client will then provide
a Kerberos ticket in the `Authorization` header. The tickets are
validated using Java's built-in GSS support. The JVM uses a vm wide
configuration for Kerberos, so there can be only one Kerberos realm.
This is enforced by a bootstrap check that also enforces the existence
of the keytab file.

In many cases a fallback authentication mechanism is needed when SPNEGO
authentication is not available. In order to support this, the
DefaultAuthenticationFailureHandler now takes a list of failure response
headers. For example, one realm can provide a
`WWW-Authenticate: Negotiate` header as its default and another could
provide `WWW-Authenticate: Basic` to indicate to the client that basic
authentication can be used in place of SPNEGO.

In order to test Kerberos, unit tests are run against an in-memory KDC
that is backed by an in-memory ldap server. A QA project has also been
added to test against an actual KDC, which is provided by the krb5kdc
fixture.

Closes #30243
@bluikko
Copy link

bluikko commented Oct 1, 2018

Is this piece implemented: "We can make use of existing AD/LDAP role mapping settings"
The documentation is not clear on this point, or at least I did not find anything about it.

Currently is it possible to configure Kerberos for authentication and use AD/LDAP for authorization (user group membership is read from LDAP for assigning roles)?

@tvernum
Copy link
Contributor

tvernum commented Oct 4, 2018

@bluikko Please ask questions like this on our discussion forums instead. Elastic uses Github issues for tracking actual development tasks, not for handling user questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>feature Meta :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants