-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Comments
Pinging @elastic/es-security |
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
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
Is this piece implemented: "We can make use of existing AD/LDAP role mapping settings" 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)? |
@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. |
Support for Kerberos
Requirements:
RFC: https://tools.ietf.org/html/rfc4559, https://www.ietf.org/rfc/rfc2478.txt
Typical Use case:
WWW-Authenticate: Negotiate
with the login pageHTTP/service@REALM
, creates base64 Kerberos SPNEGO token and send it as HTTP headerAuthorization: Negotiate base64-encoded-kerberos-ticket
, else will display the login page to the userWWW-Authenticate:
, else will return HTTP 401 Unauthorized statusHigh-level tasks with priority (P? - Priority levels 0 being the highest priority task):
Refer Java
Krb5LoginModule
Proxy-support: Session- Based-Authentication
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 headerWWW-Authenticate: token-for-mutual-auth
. On failure returns with HTTP 401 Unauthorized status and HTTP headerWWW-Authenticate: Negotiate
.POST /_xpack/security/kerberos/authenticate
). If successful, will return HTTP 200 OK, headerWWW-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
)Security Considerations:
Future:
The text was updated successfully, but these errors were encountered: