This issue is used to track progress and blockers for Security plugin New Platform migration:
Status
- ✔️ Client-side
- Everything is migrated except for two request interceptors to support plugins that still use Angular HTTP client
- ✔️ Server-side
Blockers (in order of priority)
Possible improvements
Previous description
Security needs New Platform to provide a way to intercept all incoming requests to perform auth check. Security plugin is optional, thus flow shouldn't be affected if it is disabled.
We can provide **async handler** that supports pausing request handling and finishing with one of the next scenarios:
- resume execution if auth is succeeded.
- interrupt in case of rejection.
- redirect
Security plugin operates low-level primitives and needs a way to controls:
- cookie header (get/set/clear operations), cookie params are configured by Security plugin as well.
- auth header (get/set/clear operations).
Downstream plugins shouldn't have access to user credentials stored via those mechanisms. It's not a problem while we don't expose raw request to plugins.
Original summary from #18024 (comment)
To summarize or discussion on the "http filters". The platform extension point that security needs should be able to:
- Intercept all incoming requests;
- Get/set/clear cookies and pass request through to the route handlers (e.g. authenticate user and save token to the cookies);
- Abort request and return error (e.g. failed authentication);
- Abort request and return 302 with redirect (e.g. SAML handshake);
- Possibly get some route-metadata (e.g we want to skip authentication for certain routes like login/logout should not go through authentication filter).
Won't be implemented in the first iteration
- The ability to render hidden apps. NP doesn't provide rendering mechanism at the moment. We still can relay on LP doing it for us.
Related: #18024
Implementation
This auth handler can be Security specific, because it specifies cookie parameters - name, password(encryptionKey), path, secure, cookie validation.
```js
setup(core, dependencies){
// If we don't want to expose registerAuth as a core capability
// we can provide it only to Security plugin
core.http.configureCookie({ name, password ...});
core.http.registerAuthMiddleware(async function(({cookie, headers}), authToolkit){
cookie.set(...)
return authToolkit.succeeded();
```
Or the platform can provide the ability to register a request middleware. Middleware specifies to what request headers it wants to have access to
setup(core, dependencies){
core.http.registerMiddleware(
'*', // apply to all requests
{ // declare access to
headers: ['cookie', 'authorization'], // only one middleware has access to a specified header
},
async function(({method, headers}), authToolkit){
// in this case Security plugin has to manage session cookie and parse it
// In the legacy platform that functionality is implemented by 'hapi-auth-cookie' hapi plugin.
This issue is used to track progress and blockers for Security plugin New Platform migration:
Status
Blockers (in order of priority)
Provide a way to retrieve status changes of the Elasticsearch so that we can properly register privileges with the ES cluster Migrate status service and status page to New Platform #41983Get rid of dependency on XPack Main'sregisterLicenseCheckResultsGeneratorKibana Platform plugins cannot access available features instartmethod Kibana Platform plugins cannot access available features instartmethod #65461Provide a way to render custom views HTML page rendering service #41964, [new-platform] Add support for chromeless applications #41981Allow defining SO mappings in the Kibana Platform plugin [Platform] SavedObject Mappings #50309Migrate Kibana plugin "System API" to New Platform Migrate Kibana plugin "System API" to New Platform #43970Allow rendering of "hidden"/chromeless apps (/login,/logoutetc.) Update istanbul package #4198ExposeSavedObjectsClient& Co. to NP plugins (e.g. register customScopedSavedObjectsClientFactory, it's not a pressing need, this code can live in LP for some time) Migrate saved object service #33587Capabilities service. Plugin registers CapabilitiesModifier. Migrate capabilities mixin to New Platform service #45393Allow NP client-side plugins to access configuration values (e.g.xpack.security.sessionTimeout) Add config value support in frontend to New Platform #41990Exposekibana.indexto NP plugins (used to prefix "applications" to apply Elasticsearch's application privileges). We can probably expose it as a part ofkibanaNP oss plugin if it's planned. need new platform plugin access tokibana.indexconfig value currently available in legacy plugins #46240Figure out how we can support or eliminate circular dependency between Spaces and Security NP plugins(added workaround for now, not a blocker)Add ability to retrieve current license information akaLicensingNP plugin Migrate away from legacy xpack_main to new licensing plugin #43378NP loggers should be able to log optionalmetareplicating legacylogWithMetadata(we need this to migrateAuditLoggerto NP). Logging service should log meta data #44983Allow NP server-side plugins to accesspkg.version(used to prefix API actions that are associated with the Elasticsearch's application privileges, and are used to perform the authorization checks) Expose packageInfo to the new platform plugins #45262Provide a way to define API routes and views with URLs relative to root or agree on a new BWC convention Introduce HttpApi and HttpResource services #44620ExposeserverBasePaththrough CoreBasePathservice in addition to existing request scoped base pathFix issues with NP client-side HTTP interception http interception promise resolves when calling controller.halt() #42990 http interception responseError missing response #42311 http interception responseError missing request #42307addregisterAuthbasic implementation. PR: [New platform] HTTP & Security integration #34631addsuperseded byregisterOnRequestbasic implementation. PR: [New platform] HTTP & Security integration #34631OnPreAuthhookintroduce separated Pre-Auth and Post-Auth hooks. PR: introduce pre-/post-auth request hooks for HttpServer #36690Protected/unprotected route definition. Any route should have the ability to declare itself asunprotectedto disable authentication. PR: introduce pre-/post-auth request hooks for HttpServer #36690The ability to "tag" routes as a part of authorization rules declaration. PR: Route tags #37344RefactorregisterAuthto allow manipulating [cookie] session storage from any place ofregisterAuthcaller. PR: Session storage refactoring #37992restrict access to Hapi Request object in AuthenticationHandler. Discuss with Security team what extension points they need to implement authorization logic (access to authorization header, a resource tags, etc.) context: [New platform] HTTP & Security integration #34631 (comment)PR: Restrict access to hapi Request in registerAuth #38763
integrates NP and LP http servers to simplify Security integration. PR: New Platform and Legacy platform servers integration #39047extendkbn/config-schemato supportunknownkeys forobjecttype. PR: support unknown keys for object type in @kbn/schema-config #39448ScopedCookieSessionStorageshould gracefully handle case with multiple cookies to repeat Legacy platform logic, logging. PR: handle mupltiple cookies sent from a browser #39431Possible improvements
same sitesession storage cookie option is configurable Allow for cookie'sSameSiteattribute to be configurable #60522Previous description
Security needs New Platform to provide a way to intercept all incoming requests to perform auth check. Security plugin is optional, thus flow shouldn't be affected if it is disabled. We can provide **async handler** that supports pausing request handling and finishing with one of the next scenarios: - resume execution if auth is succeeded. - interrupt in case of rejection. - redirectSecurity plugin operates low-level primitives and needs a way to controls:
Downstream plugins shouldn't have access to user credentials stored via those mechanisms. It's not a problem while we don't expose raw
requestto plugins.Original summary from #18024 (comment)
Won't be implemented in the first iteration
Related: #18024
Implementation
This auth handler can be Security specific, because it specifies cookie parameters - name, password(encryptionKey), path, secure, cookie validation. ```js setup(core, dependencies){ // If we don't want to expose registerAuth as a core capability // we can provide it only to Security plugin core.http.configureCookie({ name, password ...}); core.http.registerAuthMiddleware(async function(({cookie, headers}), authToolkit){ cookie.set(...) return authToolkit.succeeded(); ```Or the platform can provide the ability to register a request middleware. Middleware specifies to what request headers it wants to have access to