Introduce Kerberos authentication provider. #36112

azasypkin · 2019-05-06T14:03:12Z

Introduce Kerberos authentication provider.

How to test

In case it's useful, here is how I test it locally:

Prepare all configs/KDC/browser

/etc/krb5.conf
-----------------
[libdefaults]
	default_realm = TEST.ELASTIC.CO

[realms]
	TEST.ELASTIC.CO = {
		admin_server = localhost
		kdc = localhost
		default_principal_flags = +preauth
	}

[domain_realm]
	localhost = TEST.ELASTIC.CO

/etc/krb5.keytab (not actual content, just list of custom principals)
-----------------
HTTP/localhost@TEST.ELASTIC.CO
host/kerberos.test.elastic.co@TEST.ELASTIC.CO
tester@TEST.ELASTIC.CO

about:config in Firefox (note that SPNEGO doesn't work in Firefox Private Mode)
-----------------
network.negotiate-auth.trusted-uris: localhost

Create TGT with kinit tester
Run Elasticsearch with (keytab file will be automatically copied into config directory):

$ ES_JAVA_OPTS="-Djava.security.krb5.conf=/some-accessible-path/krb5.conf" yarn es snapshot \
    --license trial \
    -E xpack.security.authc.token.enabled=true \
    -E xpack.security.authc.realms.kerberos.kerb1.keytab.path=/some-accessible-path/krb5.keytab

Add role mapping for users authenticated with Kerberos realm, e.g.:

POST http://localhost:9200/_security/role_mapping/krb5
Content-Type: application/json

{
  "roles": [ "superuser" ],
  "enabled": true,
  "rules": { "field" : { "realm.name" : "kerb1" } }
}

Run Kibana with xpack.security.authProviders: [kerberos, basic]

Replaces: #27008
Fixes: #18188

elasticmachine · 2019-05-06T14:03:17Z

Pinging @elastic/kibana-security

azasypkin · 2019-05-06T16:04:10Z

x-pack/test/kerberos_api_integration/fixtures/README.md

+* host/kerberos.test.elastic.co@TEST.ELASTIC.CO
+* HTTP/localhost@TEST.ELASTIC.CO
+
+The SPNEGO token used in tests is generated for for `tester@TEST.ELASTIC.CO`. We can re-use it multiple times because we


Hey @bizybot ,

Can you please help us to understand whether the approach we're taking here for integration tests is going to work with Elasticsearch Kerberos support in the long run and we don't make any wrong assumptions?

The key here is that we disable replay cache (-Dsun.security.krb5.rcache=none) so that we can use the same SPNEGO token without any interval between calls and use very large clockskew (2147483647 seconds or ~68 years) to use the same token for a very long time. It looks like in this case we don't need to have a dedicated KDC for tests, unless we're missing something.

Thanks!

And the second question, it seems we can't exchange SPNEGO token to an access token for a "normal" user using this:

POST /_security/oauth2/token { "grant_type" : "client_credentials" }

I'm getting action [cluster:admin/xpack/security/token/create] is unauthorized for user ... . I thought we were supposed to call this API endpoint using Negotiate xxx-spnego-token and user won't need any admin privileges to get the token?

While we discuss this in elastic/elasticsearch#41943, it made more sense to point this out here:

Using the client_credentials grant will get you an access token only, and no refresh token. This access token would only be usable for (usually 20min) max 1 hour depending on the configuration.

Yep, thanks for the note! We're going to return WWW-Authenticate: Negotiate when access token expires to request a new SPNEGO token that we can exchange for a new access token (poor man replacement of refresh token).

The key here is that we disable replay cache (-Dsun.security.krb5.rcache=none) so that we can use the same SPNEGO token without any interval between calls and use very large clockskew (2147483647 seconds or ~68 years) to use the same token for a very long time. It looks like in this case we don't need to have a dedicated KDC for tests, unless we're missing something.

@azasypkin I think this may not be entirely true. -Dsun.security.krb5.rcache=none would disable the cache but there are other protections which might come into play when replay cache is disabled or not working, sun.security.krb5.acceptor.subkey is one more property which we may have to play with (this one seems to be related to some session key). I have not been able to test my finding, I will test tomorrow if there is anything else needed to do here and update. Thank you.

Thanks for looking into this @bizybot ! The SPNEGO token I've generated ~5 days ago is still accepted by the ES in integration tests, so I assume we should be fine, but would be great if you can confirm or refute that.

Hi @azasypkin, Sorry it took time to get back to you.
I took this opportunity to investigate further and sun.security.krb5.acceptor.subkey does not help in the authenticator requests but only to prevent further msg replay.
I think you are fine to disable replay cache during your testing. Thank you.

Awesome, thanks!

azasypkin · 2019-05-09T09:15:22Z

packages/kbn-es/src/cluster.js

@@ -238,6 +238,10 @@ exports.Cluster = class Cluster {

    this._process = execa(ES_BIN, args, {
      cwd: installPath,
+      env: {
+        ...process.env,
+        ...(options.esEnvVars || {}),


question: @elastic/kibana-operations how do you feel about this change? We need to specify some JVM options for the test ES instance (namely -Djava.security.krb5.conf and -Dsun.security.krb5.rcache) and I'm aware of only two ways of doing that, either via config/jvm.options or ES_JAVA_OPTS env variable.

Dealing with ES_JAVA_OPTS seemed easier to me, so I picked that option, but happy to hear about any better ways of doing that. With this change test config would look like this:

{ esTestCluster: { ...xPackAPITestsConfig.get('esTestCluster'), serverArgs: [ ...xPackAPITestsConfig.get('esTestCluster.serverArgs'), `xpack.security.authc.realms.kerberos.kerb1.keytab.path=${kerberosKeytabPath}`, ], serverEnvVars: { ES_JAVA_OPTS: `-Djava.security.krb5.conf=${kerberosConfigPath} -Dsun.security.krb5.rcache=none`, }, }, ... };

Works for me, though I think you might run into problems with paths containing spaces based on your snippet.

Great!

I think you might run into problems with paths containing spaces based on your snippet.

Thanks for pointing out! We shouldn't have spaces there, but yeah, I pretend this problem doesn't exist yet 🙈

azasypkin · 2019-05-09T09:22:38Z

x-pack/plugins/security/server/lib/auth_redirect.js

-      return wrapError(authenticationResult.error);
-    } else {
-      return Boom.unauthorized();
+      const error = wrapError(authenticationResult.error);


note: we could potentially move this if and optional challenges to wrapError, but I'm leaning towards targeted usage at this stage.

I like the explicitness of how it's done currently.

azasypkin · 2019-05-09T09:24:09Z

x-pack/plugins/security/server/lib/authentication/authentication_result.ts

   */
-  public static failed(error: Error) {
+  public static failed(error: Error, challenges?: string[]) {


note: If I understand that correctly challenges makes sense only with 401 error so I made it an optional argument for failed, but based on the way you handled it in your WIP I'd be glad to hear your thoughts or concerns!

If I understand the current implementation correctly, when the Kerberos provider returns with AuthenticationResult.failed(Boom.unauthorized(), ['Negotiate']), this will immediately cause the response to be sent to the user. Assuming the user's browser doesn't support Kerberos, will they still eventually get to the login screen?

The previous WIP approach which I implemented was intending to allow the kerberos provider to behave more seamlessly with the basic provider, which is why the challenges weren't necessarily terminating the way we iterate through the auth providers within the authenticator.

Other internals might have changed where the previous approach is no longer relevant.

If I understand the current implementation correctly, when the Kerberos provider returns with AuthenticationResult.failed(Boom.unauthorized(), ['Negotiate']), this will immediately cause the response to be sent to the user. Assuming the user's browser doesn't support Kerberos, will they still eventually get to the login screen?

Right, the only way user will be able to login using basic auth provider in [kerberos, basic] setup would be to go directly to /login page. Like we do for saml.

The previous WIP approach which I implemented was intending to allow the kerberos provider to behave more seamlessly with the basic provider, which is why the challenges weren't necessarily terminating the way we iterate through the auth providers within the authenticator.

Thanks for pointing out! I've played with this approach last week, it looks interesting, but I'd rather tackle this separately if find out that current approach is annoying for our users. Would that work for you? There are three things that make me think about handling this separately:

Same experience (okay, ^experience^ 🙂 ) even if basic is not enabled

basic in [kerberos, basic] scenario feels more like admin-only and "normal" users that can't exchange Kerberos tickets to access tokens wouldn't benefit from login page too much, and admins know where to go

Authenticator will have to handle challenges in a special manner, that I'd rather avoid unless it's really needed.

I think what you have is perfectly fine :) I think at some point, we'll likely need to add the "choose your login method" when we have multiple auth providers configured.

azasypkin · 2019-05-09T09:26:06Z