[security] Token auth provider #26997
Conversation
epixa
force-pushed
the
token-auth-provider
branch
from
35a6b0f to
0f15d2f
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
epixa
force-pushed
the
token-auth-provider
branch
from
0f15d2f to
ea187b1
Compare
This comment has been minimized.
This comment has been minimized.
epixa
force-pushed
the
token-auth-provider
branch
from
ea187b1 to
44075e8
Compare
This comment has been minimized.
This comment has been minimized.
From a user perspective, the token provider behaves similarly to the basic provider in that it can power the native login experience and can also be used for API calls via the authorization header (albeit with the Bearer realm). From a technical perspective, the token provider deals with authentication via the token service in Elasticsearch, so while it handles user credentials in the case of login, a temporary, refreshable access token is stored in the session cookie instead. This means that when you log out, not only is the cookie invalidated, but the token itself cannot be reused.
epixa
force-pushed
the
token-auth-provider
branch
from
44075e8 to
bf191a8
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
💚 Build Succeeded |
epixa
added
review
v7.0.0
Team:Security
|
Pinging @elastic/kibana-security |
epixa
added
release_note:enhancement
and removed
enhancement
There was a problem hiding this comment.
The provider is working beautifully! I tested it with SAML enabled as well, and it's working great.
The only concern that I have with the provider is that when using only the token provider, users will find it rather complicated to execute cURL requests against Kibana APIs, and they'll have to authenticate against ES APIs to get a Bearer token to submit, or they'll have to enable the basic provider additionally. I'm not necessarily suggesting that we change this, just noting it to see if you had any thoughts.
x-pack/plugins/security/server/lib/authentication/providers/token.js
Outdated
Show resolved
Hide resolved
x-pack/plugins/security/server/lib/authentication/providers/__tests__/token.js
Show resolved
Hide resolved
x-pack/plugins/security/server/lib/authentication/providers/__tests__/token.js
Show resolved
Hide resolved
Realistically the token provider is not something folks will wire together manually for curl requests. They could use the Bearer header for programmatic integrations using the upcoming api token feature that allows for long term api tokens, or they might choose to back some sort of hacked oauth2 setup on top of this provider instead of basic auth. A configuration of |
This comment has been minimized.
This comment has been minimized.
|
This does not provide an integration test to verify that a expired refresh token results in session invalidation. This would be impractical to test because the refresh window is 24h and it is hardcoded into Elasticsearch. We have unit test coverage for this behavior, so we're assuming the Elasticsearch token service handles the refresh expiration consistently. |
This comment has been minimized.
This comment has been minimized.
💚 Build Succeeded |
* [security] Token auth provider From a user perspective, the token provider behaves similarly to the basic provider in that it can power the native login experience and can also be used for API calls via the authorization header (albeit with the Bearer realm). From a technical perspective, the token provider deals with authentication via the token service in Elasticsearch, so while it handles user credentials in the case of login, a temporary, refreshable access token is stored in the session cookie instead. This means that when you log out, not only is the cookie invalidated, but the token itself cannot be reused. * token provider integration tests * include token api integration tests by default * remove unused ProviderOptions from typedef * assert that valid login sets an authorization header * unit tests for refresh token and failure cases * integration tests for headers and sessions * clean up login/logout tests for consistent setup functions * test for header rejection scenarios
* [security] Token auth provider From a user perspective, the token provider behaves similarly to the basic provider in that it can power the native login experience and can also be used for API calls via the authorization header (albeit with the Bearer realm). From a technical perspective, the token provider deals with authentication via the token service in Elasticsearch, so while it handles user credentials in the case of login, a temporary, refreshable access token is stored in the session cookie instead. This means that when you log out, not only is the cookie invalidated, but the token itself cannot be reused. * token provider integration tests * include token api integration tests by default * remove unused ProviderOptions from typedef * assert that valid login sets an authorization header * unit tests for refresh token and failure cases * integration tests for headers and sessions * clean up login/logout tests for consistent setup functions * test for header rejection scenarios
From a user perspective, the token provider behaves similarly to the
basic provider in that it can power the native login experience and can
also be used for API calls via the authorization header (albeit with the
Bearer realm).
From a technical perspective, the token provider deals with
authentication via the token service in Elasticsearch, so while it
handles user credentials in the case of login, a temporary, refreshable
access token is stored in the session cookie instead. This means that
when you log out, not only is the cookie invalidated, but the token
itself cannot be reused.