Security plugin in the new platform

[elasticmachine]

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]

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]

Original comment by @azasypkin:

WIP code is in LINK REDACTED

[elasticmachine]

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]

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]

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]

Original comment by @kjbekkelund:

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

• attach custom headers before response, including kbn-name and kbn-version
• verify version after auth
• verify xsrf after auth
• stop health checks when shutting down
• redirect from http port to https port on request (this is actually setting up a another http server, so not as relevant, can just be a pure node http server)

And in x-pack:

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

[epixa]

@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.

[azasypkin]

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

[epixa]

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

[azasypkin]

@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).