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

Security plugin in the new platform #18024

Closed
elasticmachine opened this issue Aug 2, 2017 · 10 comments
Closed

Security plugin in the new platform #18024

elasticmachine opened this issue Aug 2, 2017 · 10 comments
Labels
enhancement New value added to drive a business result Feature:New Platform Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@elasticmachine
Copy link
Contributor

Original comment by @azasypkin:

In current Kibana security plugin is highly coupled with Hapi and its authentication plugins. In the new platform we'll presumably be using Express framework that will affect the way we manage authentication. Ideally that should be internal implementation detail though.

There are two main parts that we should take care of:

  • Route authentication;
  • Session management.

Route authentication

Route authentication will require router-level middleware that will basically work with something like Authenticator we have in LINK REDACTED We likely don't need any special 3rd-party module to handle that.

Session management

It feels OK to leverage middleware cookie session modules provided by Express itself: LINK REDACTED or LINK REDACTED.

The problem with the express-session middleware is that it stores session data on the server and only saves the session ID in the cookie itself, not session data. So it's likely a no-go for us.

The cookie-session middleware implements cookie-backed storage and serializes the entire session to the cookie, rather than just a session key. Exactly like we do it right now. The only problem is that cookie-session can only sign cookie, not encrypt (see expressjs/cookie-session#9). Having ability to encrypt cookie is very important for Kibana in the current state since it stores username:password pair in the cookie itself. Right now LINK REDACTED plugin handles cookie encryption for us and uses LINK REDACTED under the hood.

I'm not sure if we can easily complement cookie-session with encryption and that's what I'm going to check next. If not, we may want to implement something similar to Mozilla's node-client-sessions, although I'm not sure if it's a good idea to do so.

Also I'm wondering if username:password in the cookie is the only reason for cookie encryption, if so maybe we can rely on Token Management API and store authentication token in the cookie instead? In this case we won't need to encrypt the cookie, unless I'm missing something. We can invalidate such token from Kibana on logout and it also has expiration date. We'll use same/similar token API for SAML anyway.

/cc @elastic/kibana-platform

@elasticmachine
Copy link
Contributor Author

Original comment by @azasypkin:

Some thoughts: security is the plugin that affects other plugins and probably the core itself since it is going to intercept other routes for authentication, there is a chance that other plugins will need something like this as well.

In my test branch I temporarily added registerRequestHandler in addition to registerRouter to handle this use case, but this method is available to all plugins that I don't think is a good thing. So I'm wondering if we may want to split all plugins into two buckets: privileged and non-privileged. Privileged plugins we'll have access to such things like registerRequestHandler, but non-privileged won't.

What do you think @elastic/kibana-platform? Do we have other use cases when some plugins are supposed to have more power than others?

@elasticmachine
Copy link
Contributor Author

Original comment by @azasypkin:

WIP code is in LINK REDACTED

@elasticmachine
Copy link
Contributor Author

Original comment by @epixa:

I think implementing our own cookie-based session middleware is probably a good thing, to be honest. We'll need to implement exactly the same cookie/encryption logic initially so that the same cookie can be used to auth requests on the old core and new platform, and I doubt there's any out of the box solution we could use to do this. In the future, we'll want to move to using tokens, and we'll be able to do that more seamlessly if we have full control over the middleware.

@elasticmachine
Copy link
Contributor Author

Original comment by @azasypkin:

I think implementing our own cookie-based session middleware is probably a good thing, to be honest.

Indeed, from my experiments cookie-session is really not something we want to heavily rely on. Still I hope we won't need to replicate cookie parsing/writing logic from scratch so I'm using cookie-parser middleware for now and building session management/encryption on top of this "bare" module.

@elasticmachine
Copy link
Contributor Author

Original comment by @azasypkin:

To summarize or discussion on the "http filters". The platform extension point that security needs should be able to:

  1. Intercept all incoming requests;
  2. Get/set/clear cookies and pass request through to the route handlers (e.g. authenticate user and save token to the cookies);
  3. Abort request and return error (e.g. failed authentication);
  4. Abort request and return 302 with redirect (e.g. SAML handshake);
  5. Possibly get some route-metadata (e.g we want to skip authentication for certain routes like login/logout should not go through authentication filter).

/cc @kjbekkelund

@elasticmachine
Copy link
Contributor Author

Original comment by @kjbekkelund:

All the things that rely on the hapi lifecycle in Kibana today:

And in x-pack:

  • LINK REDACTED that checks scope and path after auth (LINK REDACTED)
  • LINK REDACTED before responding (LINK REDACTED)

@elasticmachine elasticmachine added Feature:New Platform Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc labels Apr 24, 2018
@epixa
Copy link
Contributor

epixa commented May 6, 2018

@elastic/kibana-security Technically, this is a security team thing, but it's something we need to sort out pretty early in the roll out of the new platform, so unless the security team miraculously gets a chunk of free time in the next couple months, I think the @elastic/kibana-platform is going to take a swing at this initial implementation.

@epixa epixa added Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! enhancement New value added to drive a business result and removed Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc labels May 6, 2018
@azasypkin
Copy link
Member

Unassigning myself since I'm not working on this at the moment.

@azasypkin azasypkin removed their assignment Jun 28, 2018
@epixa
Copy link
Contributor

epixa commented Jul 22, 2019

@azasypkin @restrry Sessions and route auth is migrated, right? I think we can close this.

@epixa epixa closed this as completed Jul 22, 2019
@azasypkin
Copy link
Member

@azasypkin @restrry Sessions and route auth is migrated, right

Yes, entire authentication system has been migrated to NP plugin (except for security login\logout\etc API routes, but we'll track them separately).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result Feature:New Platform Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

No branches or pull requests

3 participants