Implement Kibana Login Selector #53010

azasypkin · 2019-12-13T17:55:49Z

Summary:

This PR includes two major parts:

Introduced optional Login Selector UI that is basically extended mode of the existing Login page
Added support for the setup when Kibana is configured to use multiple SAML/OIDC realms at the same time or multiple different SSO authentication providers

Notable changes:

Improved support for PKI/Kerberos authentication when optional authentication mode is used
Current format of xpack.security.authc.providers (including xpack.security.authc.saml|oidc) is deprecated and became mutually exclusive with the new one
SAML/OIDC callback URLs were re-defined as ones that don't require XSRF check and hence we don't need server.xsrf.whitelist setting anymore.
Since we started to use optional authentication mode for the Login view route, Cannot open default log in page if SAML authentication is enabled #25257 and Don't rely just on presence of the cookie to detect active user session #50634 should be fixed now
Removed dependency on secureCookies injected variable

Note to reviewers: only existing tests are fixed and just a few new were added. I'm working on covering new functionality with tests at the moment. Also cannot test UI in IE 11 because of #58108.

Login Selector UI states:

Multiple SSO with Basic/Token (username/password based):

Multiple SSO without Basic/Token (username/password based):

Only Basic/Token (username/password based):

Old description

In this PoC I'm going to check the following:

If it's possible to use the same SSO provider to login with different realms
If it's possible to login with two different SSO providers on the same Kibana instance
What is needed to preserve current UX for users if Login Selector isn't enabled, but mutiple SSO providers are enabled

There are three major changes here:

Security plugin will allow passing custom realm to SAML and OIDC providers
SAML provider will NOT be sending realm name to Elasticsearch during IdP initiated login and logout
HTTP Authentication logic (authentication based on Authorization: xxx HTTP header) is moved out of separate providers and consolidated in a dedicated authentication provider that is enabled by default (likely will be split into dedicated PR)
Security plugin will have an optional login-selector chromeless app that we can use to choose what provider and what parameters for login we should use exactly (either through shortcut URL or through a dedicated screen)

Results:

Problems/limitations I've noticed so far:

We need Elasticsearch to return realm name it used to authentication request via provided SAMLResponse when realm name is not specified (e.g. during IdP initiated login) SAML _security/saml/authenticate API should return realm name used for authentication elasticsearch#52053 (not blocker, but nice to have)
We need Kibana Platform to allow to XSRF whitelist certain routes at the route definition time Allow HTTP routes to programmatically opt out of XSRF protection #53823 (not blocker, but nice to have)
Currently Elasticsearch _security/saml/invalidate API requires realm name, but we don't have one for IdP initiated logouts when user doesn't have an active session. It's not super critical issue, but we need to figure out if we can handle it better.
IdP initiated login and logouts (without active session) will always be used with default realm. We can protentially expose separate login/logout routes for different realms (technically same route, but realm name can be embedded into URL) We decided to not provide ES with realm name in this case at all.
Recently we started to define provider specific routes only if provider is enabled explicitly through configuration, we may need to drop this idea so that we always have all routes (I believe ES always defines all security related routes as well). Plugin's own configuration can be used to configure any behavior we'd like to support without affecting Security plugin. It seems it's not an issue for now.

How to test:

Run ES with multiple SSO realms configured, e.g. (ping me to get command with all secrets):

$ yarn es snapshot --license trial \
    -E xpack.security.authc.token.enabled=true \
    -E xpack.security.authc.realms.native.native1.order=0 \
    -E xpack.security.authc.realms.saml.saml1.order=1 \
    -E xpack.security.authc.realms.saml.saml1.idp.metadata.path=/path-to/es/config/saml/elastic-dev_auth0_com-metadata-new.xml \
    -E xpack.security.authc.realms.saml.saml1.idp.entity_id="urn:elastic-dev.auth0.com" \
    -E xpack.security.authc.realms.saml.saml1.sp.entity_id="https://localhost:5601/" \
    -E xpack.security.authc.realms.saml.saml1.sp.acs="https://localhost:5601/api/security/saml/callback" \
    -E xpack.security.authc.realms.saml.saml1.sp.logout="https://localhost:5601/logout" \
    -E xpack.security.authc.realms.saml.saml1.attributes.principal="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" \
    -E xpack.security.authc.realms.saml.saml1.attributes.groups="http://schemas.xmlsoap.org/claims/Group" \
    -E xpack.security.authc.realms.saml.saml2.order=2 \
    -E xpack.security.authc.realms.saml.saml2.idp.metadata.path=/path-to/es/config/saml/elastic-okta-preview-metadata-new.xml \
    -E xpack.security.authc.realms.saml.saml2.idp.entity_id="http://www.okta.com/exkovi0ixs9rdxHjO0h7" \
    -E xpack.security.authc.realms.saml.saml2.sp.entity_id="https://localhost:5601/" \
    -E xpack.security.authc.realms.saml.saml2.sp.acs="https://localhost:5601/api/security/saml/callback" \
    -E xpack.security.authc.realms.saml.saml2.sp.logout="https://localhost:5601/logout" \
    -E xpack.security.authc.realms.saml.saml2.attributes.principal="urn:oid:0.9.2342.19200300.100.1.1" \
    -E xpack.security.authc.realms.saml.saml2.attributes.groups="urn:oid:2.16.840.1.113719.1.1.4.1.25" \
    -E xpack.security.authc.realms.oidc.oidc1.order=3 \
    -E xpack.security.authc.realms.oidc.oidc1.rp.client_id=....client....id \
    -E xpack.security.authc.realms.oidc.oidc1.rp.client_secret=.....client....secret \
    -E xpack.security.authc.realms.oidc.oidc1.rp.response_type=code \
    -E xpack.security.authc.realms.oidc.oidc1.rp.requested_scopes=profile \
    -E xpack.security.authc.realms.oidc.oidc1.rp.redirect_uri=https://localhost:5601/api/security/oidc/callback \
    -E xpack.security.authc.realms.oidc.oidc1.op.authorization_endpoint=https://elastic-dev.auth0.com/authorize \
    -E xpack.security.authc.realms.oidc.oidc1.op.token_endpoint=https://elastic-dev.auth0.com/oauth/token \
    -E xpack.security.authc.realms.oidc.oidc1.op.userinfo_endpoint=https://elastic-dev.auth0.com/userinfo \
    -E xpack.security.authc.realms.oidc.oidc1.op.issuer=https://elastic-dev.auth0.com/ \
    -E xpack.security.authc.realms.oidc.oidc1.op.jwkset_path=https://elastic-dev.auth0.com/.well-known/jwks.json \
    -E xpack.security.authc.realms.oidc.oidc1.claims.principal=sub \
    -E xpack.security.authc.realms.oidc.oidc1.claims.groups=https://myapp.example.com/kbn_groups \
    -E xpack.security.authc.realms.oidc.oidc1.claims.name=name

Blocked by: #60406, #53823, elastic/elasticsearch#52053, #58126

Fixes: #39313, #25257, #50634

"Release Note: Kibana can now be configured to work with multiple Single Sign-On authentication mechanisms at the same time."

cc @arisonl

elasticmachine · 2019-12-13T17:55:52Z

Pinging @elastic/kibana-security (Team:Security)

tvernum · 2019-12-17T03:36:50Z

@azasypkin Can you elaborate on this point:

IdP initiated login and logouts (without active session) will always be used with default realm

Is this:

A current limitation of the PoC
A genuine limitation of Kibana
A limitation from ES?

For SAML, Elasticsearch should be able handle IdP initiated login against an unspecified realm and process the auth with the first valid realm (typically which ever realm matches the SP and IdP Entity IDs).
I'll need to do a bit more investigation for OIDC because OP initiated login works in a very different way and I haven't traced through that code path yet.

azasypkin · 2019-12-17T10:37:26Z

Is this:

A current limitation of the PoC
A genuine limitation of Kibana
A limitation from ES?

I think at this stage it's a little bit of everything @tvernum.

For SAML, Elasticsearch should be able handle IdP initiated login against an unspecified realm and process the auth with the first valid realm (typically which ever realm matches the SP and IdP Entity IDs).

Yeah, but as far as I understand even though this parameter is an optional one it still helps Elasticsearch to process request more efficiently (for both SAML and OIDC) and also a bit more secure (for OIDC case, elastic/elasticsearch#45331). So after elastic/elasticsearch#45767 Kibana started to always pass realm name to Elasticsearch in POST /_security/saml/authenticate[invalidate] request for both IdP and user initiated requests.

We can probably stop sending realm name for the IdP initiated logins/logouts, but does Elasticsearch force SAML realms to have a unque (SP Entity ID, IdP Entity ID) tuple? If it doesn't and even though it's hard to think of a valid use case where admins would want to configure two very similar realms I'm still a bit worried that for the IdP initiated logins/logouts we'll depend on realm order unlike user initiated logins/logouts. Optional, but nice-to-have feature request for ES here would be to return realm name within POST /_security/saml/authenticate response otherwise we'll have to make an additional call to _security/_authenticate with newly issued token and extract realm from authentication_realm field.

So it sounds like here we'd need a trade-off anyway. For now I picked the one that's easier and seems to favor what Kibana user would want (based on "default" realm name configured in kibana.yml), but I'm still trying to wrap my head around that.

What do you think?

tvernum · 2019-12-17T10:51:52Z

does Elasticsearch force SAML realms to have a unique (SP Entity ID, IdP Entity ID) tuple

For the SAML case, if it's the same SP and the same IdP then I think it's quite reasonable to rely on realm order.
If you have 2 LDAP realms connecting to the same LDAP directory (in the same sub-tree), then we will always authenticate against the first one. The 2nd one is useless.

We need to support IdP initiated auth from 2 different IdPs.

azasypkin · 2019-12-17T11:27:24Z

For the SAML case, if it's the same SP and the same IdP then I think it's quite reasonable to rely on realm order.

Agree, that's reasonable. The thing is that right now you don't have to rely on order for IdP initiated logins since you can configure two different Kibana instances differently (specifying different realms for each of them to have different role mappings or something like that as a result). But obviously this is just purely theoretical use case and if we don't see much value in it (or just see it as a not recommended/wrong configuration) and want to have IdP initiated login for non-default realm (in Kibana we should have something as a default anyway, at least until next major) we can surely change that.

Let's see how we can do that for OIDC and try to come up with the solutions that work in a similar way.

If you have 2 LDAP realms connecting to the same LDAP directory (in the same sub-tree), then we will always authenticate against the first one. The 2nd one is useless.

It's good to know, thanks.

azasypkin · 2019-12-17T12:51:36Z

Alternatively we can expose separate login/logout endpoints for separate realms (technically same endpoint, but realm name may be embedded into URL).

kobelb · 2019-12-18T22:25:27Z

I don't have much to add to the discussion outside of what has already been discussed, and perhaps the following is just stating the obvious.

It seems like instead of having a singular xpack.security.authc.oidc.realm and xpack.security.authc.saml.realm, that once we have a login selector we can conceptually start supporting multiple realms. It doesn't seem like conceptually we even need a priority/order for these realms in Kibana. When it's an IdP initiated login, we don't need to be providing the realm.

However, we do potentially want the ability for one of the realms to not be displayed on the "login selector screen", but to be usable with an IdP initiated login.

Instead of requiring the user to configure the realms in Kibana, should Elasticsearch have an API to return all of the realms for Kibana to use for displaying on the login selector screen? Or should we be requiring the end-user to specify all of the realms themselves, and allow them to provide additional descriptions and whether or not they should be hidden?

tvernum · 2019-12-18T23:17:10Z

should Elasticsearch have an API to return all of the realms for Kibana to use for displaying on the login selector screen?

Maybe.

Looking at the 3 configuration values Kibana currently needs for SAML

xpack.security.authc.providers: [saml]
xpack.security.authc.saml.realm: saml1
server.xsrf.whitelist: [/api/security/v1/saml]

I think we can derive each of those from info in ES

The default for authc.providers could be to enable every provider for which there is a matching realm (with an optional override, see below)
We could configure a saml.realm for each matching ES realm (but again, you'd want a way to override that). Likewise for OIDC.
xsrf.whitelist always struck me as pushing a bit too much work onto the admin. If SAML is enabled you need to set this, so it would be nice to automatically imply it based on the authc providers.

There are edge cases where the auto realm config could do the wrong thing, but as long as there are options to configure Kibana explicitly then I think we can accept them:

Having a password realm enabled (particularly reserved realm) should default to including password authc (otherwise as soon as you added a SAML realm you could effectively lose access to Kibana (because you might not have working role mappings yet). But we should have an opt-out config because it's also quite common to have a policy of "LDAP for ES Rest API, SAML for Kibana"
A SAML/OIDC realm existing in ES does not mean that Kibana is supposed to use it even if that authc.provider is enabled, so again a per-realm opt-out would be needed
Realms are per node, and Kibana supports multiple nodes (and sniffing). So the auto-config would be based on whichever node Kibana first connects to. For 99% of cases that's correct. For the other 1%, the admin needs to fall back to manual config. I think that's OK.

We don't provide an API that would give you this info right now, but I think we can. All you would need is a list of { "name": "okta", "type" : "saml", "protocol": "saml" } etc, in the order that ES will try them.
protocol would be something like basic, saml, oidc, pki, kerberos so that all the Username/Password realm types can be categorised the same way ("basic").

I think we'd just skip disabled realms (either by config or license), but probably have ES issue a warning in its logs if a realm is skipped via licensing.
We could return a list of disabled realms in the API if we wanted the Kibana logs to also have warnings, but that seems like overkill.

We should also consider including whenther tokens and api-keys are enabled in that response, something roughly like:

{
  "realms": [ ... ],
  "other": [ "token", "apikey" ]
}

("other" isn't a nice name, but we can work out the details).

From our side, it seems like a simple enough API that we could squeeze it in for 7.7 if it's useful to you.

CC: @elastic/es-security

azasypkin · 2019-12-19T12:48:37Z

Instead of requiring the user to configure the realms in Kibana, should Elasticsearch have an API to return all of the realms for Kibana to use for displaying on the login selector screen? Or should we be requiring the end-user to specify all of the realms themselves, and allow them to provide additional descriptions and whether or not they should be hidden?

Whichever option we choose, I believe Kibana admin should be able to completely control what authc mechanisms are used at the optional "selector" screen (including "synthetic" authc providers that don't map 1:1 to ES realms, pick token instead of basic etc.) and fine tune every of them. It'd be great to have smarter defaults in any case, but If we go the "automatic" route then Kibana admin should be able to easily understand which authc mechanisms are allowed automatically even if "selector" screen isn't enabled.

Maybe we can quickly sync once you all get back from holidays and discuss pros and cons of these options.

xsrf.whitelist always struck me as pushing a bit too much work onto the admin. If SAML is enabled you need to set this, so it would be nice to automatically imply it based on the authc providers.

I'm pretty sure we'll get rid of it entirely, I'm talking to the platform team about dropping this setting and just "marking" all necessary routes as whitelisted at the definition time (no admin involvement). We should be able to do that since Security is now New Platform plugin.

azasypkin · 2020-03-10T18:56:05Z

packages/kbn-config-schema/src/internals/index.ts

@@ -314,7 +314,8 @@ export const internals = Joi.extend([
          for (const [entryKey, entryValue] of value) {
            const { value: validatedEntryKey, error: keyError } = Joi.validate(
              entryKey,
-              params.key
+              params.key,


note: This fixes the issue that's is a blocker for us (without this we can't have required fields within schema.recordOf value schema), I'll prepare a separate PR for kbn/config-schema next week or ask Platform team for a help if it turns out to be more complex than I think.

Handled in #60406.

azasypkin · 2020-03-10T18:57:33Z

x-pack/plugins/security/public/authentication/login/login_page.tsx

    }
+
+    const loginSelector =


note: we probably would need a separate component for that button, but it doesn't feel mandatory at this point.

x-pack/plugins/security/public/authentication/login/login_page.tsx

+  };
+
+  private login = (providerType: string, providerName: string) => {
+    const query = parse(window.location.href, true).query;


azasypkin · 2020-03-10T19:05:04Z

x-pack/plugins/security/server/authentication/authenticator.ts

@@ -225,11 +241,18 @@ export class Authenticator {
      this.setupHTTPAuthenticationProvider(
        Object.freeze({
          ...providerCommonOptions,
+          name: '__http__',


note: have mixed feelings about this "reserved" name, but haven't managed to come with anything better yet. We can also forbid this name during config validation instead, but I'm not sure if it's worth the complexity 🤷‍♂️

I think what you have here is reasonable

azasypkin · 2020-03-10T19:05:45Z

x-pack/plugins/security/server/authentication/authenticator.ts

-        idleTimeoutExpiration,
-        lifespanExpiration,
-        path: this.serverBasePath,
+      this.updateSessionValue(sessionStorage, {


note: it seems we can finally re-use this function in login as well.

azasypkin · 2020-03-10T19:09:04Z

x-pack/plugins/security/server/authentication/providers/basic.ts

+  public async logout(request: KibanaRequest, state?: ProviderState | null) {
+    this.logger.debug(`Trying to log user out via ${request.url.path}.`);
+
+    if (!state) {


note: need this check here and in other providers since I can call logout on multiple providers if there is no session (e.g. in case IdP initiated logout).

azasypkin · 2020-03-10T19:11:54Z

x-pack/plugins/security/server/authentication/providers/kerberos.ts

+   * Performs initial login request.
+   * @param request Request instance.
+   */
+  public async login(request: KibanaRequest) {


note: didn't test this scenario. Will test later to make sure it works as expected.

Struggling to setup environment for some reason, but technically it works now 🙂 Will make sure to check that it actually works before merging though.

Kerberos Login Selector integration tests are passing, we should be good.

azasypkin · 2020-03-10T19:29:06Z

x-pack/plugins/security/server/authentication/providers/saml.ts

+      // Since we don't know upfront what realm is targeted by the Identity Provider initiated login
+      // there is a chance that it failed because of realm mismatch and hence we should return
+      // `notHandled` and give other SAML providers a chance to properly handle it instead.
+      return isIdPInitiatedLogin


note: more correct solution here would be to not send realm to Elasticsearch and:

If request failed - return failed()

If request succeeded and returned realm equal to the one this provider relies on - return succeeded()

If request succeeded, but returned realm not equal to the one this provider relies on - invalidate created tokens and return notHandled

But I really don't like the invalidate created tokens step.

The other solution I was thinking about was to re-use the same provider instance for all enabled providers of the same type. This solution wouldn't have the problem I'm trying to solve here, but it has the set of its own issues. Happy to discuss if you think current solution isn't acceptable.

Would do you think?

Does having to support xpack.security.public.* settings in 7.x affect this at all? Perhaps we could discuss this specific flow over Zoom. I'm not sure I'm following all of the complexities entirely.

Does having to support xpack.security.public.* settings in 7.x affect this at all?

As I replied to another comment I expect to not have problem with xpack.security.public.* if we forbid multiple SAML providers if there any without realm specified (basically when Kibana is already configured to use SAML with old config format without specified realm).

Perhaps we could discuss this specific flow over Zoom. I'm not sure I'm following all of the complexities entirely.

Sure, let's discuss over Zoom.

What we discussed on Zoom makes sense, no concerns on this point.

azasypkin · 2020-03-10T19:29:52Z

x-pack/plugins/security/server/authentication/providers/saml.ts

-    if (attempt.step === SAMLLoginStep.RedirectURLFragmentCaptured) {
+    // It may happen that Kibana is re-configured to use different realm for the same provider name,
+    // we should clear such session an log user out.
+    if (state?.realm && state.realm !== this.realm) {


note: this is check is the main/only reason why I started to store realm in the session.

azasypkin · 2020-03-10T19:31:43Z

x-pack/plugins/security/server/routes/authentication/common.ts

+    return undefined;
+  }
+
+  router.get(


note: we need to properly handle redirects that's why I'm using GET here.

Redirects from other web-servers using a 301/302?

I meant that this endpoint responds with 302 and we won't be able to easily handle this on the client side if use HTTP client to do that POST.

We can alternatively use hidden <form /> to do the POST here and mark route as requireXsrf: false and somehow preserve current hash fragment (I'm not sure if browser preserves it if we get redirect on form submit like it does for normal redirects), but I'm not sure how I feel about that added complexity yet...

What do you think? Am I missing something here?

I think it's worth seeing how the hidden <form /> works or using a XHR and manually doing the redirect. If either of these aren't super ugly, they'd add a bit of additional protection.

azasypkin · 2020-03-10T20:42:51Z

x-pack/plugins/security/server/config.ts

@@ -40,15 +112,8 @@ export const ConfigSchema = schema.object({
  }),
  secureCookies: schema.boolean({ defaultValue: false }),
  authc: schema.object({
-    providers: schema.arrayOf(schema.string(), { defaultValue: ['basic'], minSize: 1 }),


note: I'm still considering two different ways of changing configuration structure:

Define only new structure here and handle transformation of the old format to the new one via deprecation transformation (current one). The benefit is that config schema is a bit easier to understand and handle. The drawback is that validation messages for old format will be confusing (e.g. if user enables saml and forget to configure xpack.security.authc.saml.realm the error message will be complaining about xpack.security.authc.providers.saml.saml.realm instead - that's ideally - currently recordOf validation errors are even worse and need to be fixed). Another potential drawback is that we won't have a reliable way to know whether admin used old config format in case we need it (e.g. to not enable login selector by default, see below).

Define both old and new structures in the schema via schema.oneOf([oldSchema, newSchema]) - benefits and drawbacks are opposite to those described in the previous approach.

As for enabling Login Selector UI by default (xpack.security.authc.selector.enabled) Ideally I'd enable it only if:

new config format is used
and

admin enabled more than one provider (e.g when Cloud enables SAML in addition to basic or anything else Kibana admin would specify in new format)
and

xpack.security.authc.selector.enabled isn't explicitly set to false

Soo because of the first point I'll see what it'd cost to switch to option 2 instead.

Implemented approach 2. and now enabling selector as described above.

cchaos

👍 Thanks!

kibanamachine · 2020-03-23T21:44:15Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request
Commit: ceba57b

History

💚 Build #35480 succeeded f6b1d4f
💚 Build #35338 succeeded 37c6489
💚 Build #34876 succeeded 1204619
💚 Build #34800 succeeded db2f4b3
💔 Build #34635 failed a572c52

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

* master: (34 commits) [APM] add service map config options to legacy plugin (elastic#61002) [App Arch] migrate legacy CSS to new platform (core_plugins/kibana_react) (elastic#59882) Migrated styles for "share" plugin to new platform (elastic#59981) [ML] Module setup with dynamic model memory estimation (elastic#60656) Drilldowns (elastic#59632) Upgrade mocha dev-dependency from 6.2.2 to 7.1.1 (elastic#60779) [SIEM] Overview: Recent cases widget (elastic#60993) [ML] Functional tests - stabilize df analytics clone tests (elastic#60497) [SIEM] Updates process and TLS tables to use ECS 1.5 fields (elastic#60854) Migrate doc view part of discover (elastic#58094) Revert "[APM] Collect telemetry about data/API performance (elastic#51612)" fix(NA): log rotation watchers usage (elastic#60956) [SIEM] [CASES] Build lego blocks case details view (elastic#60864) Create Painless Lab app (elastic#57538) [SIEM] Move Timeline Template field to first step of rule creation (elastic#60840) [Reporting/New Platform Migration] Use a new config service on server-side (elastic#55882) [Alerting] allow email action to not require auth (elastic#60839) [Maps] Default ES document layer scaling type to clusters and show scaling UI in the create wizard (elastic#60668) [APM] Collect telemetry about data/API performance (elastic#51612) Implement Kibana Login Selector (elastic#53010) ...

azasypkin · 2020-03-24T09:59:40Z

7.x/7.7.0: 89a76b0

setting xpack.security.authc.selector.enabled introduced in 7.7.0 by #53010 is currently missing for docker entrypoint script

azasypkin added Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Feature:Security/Authentication Platform Security - Authentication v7.7.0 labels Dec 13, 2019

azasypkin force-pushed the issue-xxx-cloud-sso branch from f3c57a0 to cbdae0b Compare February 7, 2020 14:06

azasypkin changed the title ~~[PoC] Kibana Login Selector~~ Implement Kibana Login Selector Feb 7, 2020

azasypkin force-pushed the issue-xxx-cloud-sso branch from cbdae0b to b39c5cb Compare February 19, 2020 18:20

azasypkin mentioned this pull request Feb 21, 2020

Implement HTTP Authentication provider and allow ApiKey authentication by default. #58126

Merged

azasypkin added the blocked label Feb 21, 2020

Introduce Login Selector functionality.

f442437

azasypkin force-pushed the issue-xxx-cloud-sso branch from b39c5cb to f442437 Compare March 10, 2020 18:48

azasypkin commented Mar 10, 2020

View reviewed changes

x-pack/plugins/security/public/authentication/login/login_page.tsx Outdated

};

private login = (providerType: string, providerName: string) => {

const query = parse(window.location.href, true).query;

This comment was marked as resolved.

Sign in to view

azasypkin commented Mar 10, 2020

View reviewed changes

azasypkin added 3 commits March 23, 2020 20:43

Merge branch 'master' into issue-xxx-cloud-sso

c197b9c

Integrate latest upstream changes after master merge.

aed4521

Review#5: remove redundant user icon from login selector button.

ceba57b

cchaos approved these changes Mar 23, 2020

View reviewed changes

azasypkin merged commit fa69765 into elastic:master Mar 23, 2020

azasypkin deleted the issue-xxx-cloud-sso branch March 23, 2020 21:45

azasypkin added the backport pending label Mar 23, 2020

azasypkin mentioned this pull request Mar 24, 2020

[7.x] Implement Kibana Login Selector (#53010) #61036

Merged

azasypkin added backported and removed backport pending labels Mar 24, 2020

This was referenced Mar 24, 2020

Cannot open default log in page if SAML authentication is enabled #25257

Closed

Don't rely just on presence of the cookie to detect active user session #50634

Closed

legrego mentioned this pull request Mar 24, 2020

[7.7] Document new auth provider configuration options and login selector #61117

Closed

ryankeairns mentioned this pull request Mar 24, 2020

Login page layout improvements #61144

Closed

jportner mentioned this pull request May 28, 2020

User cannot login to Kibana without clearing session after upgrading #67478

Closed

kobelb mentioned this pull request Jun 1, 2020

[Meta] - 8.0 Upgrade Assistant #67915

Closed

12 tasks

jguay added a commit that referenced this pull request Nov 17, 2020

adds xpack.security.authc.selector.enabled setting

245bcdb

setting xpack.security.authc.selector.enabled introduced in 7.7.0 by #53010 is currently missing for docker entrypoint script

jguay mentioned this pull request Nov 17, 2020

adds xpack.security.authc.selector.enabled setting #83551

Merged

jbudz pushed a commit that referenced this pull request Nov 17, 2020

adds xpack.security.authc.selector.enabled setting (#83551)

7c8b9a1

setting xpack.security.authc.selector.enabled introduced in 7.7.0 by #53010 is currently missing for docker entrypoint script

jbudz pushed a commit that referenced this pull request Nov 17, 2020

adds xpack.security.authc.selector.enabled setting (#83551)

69e869a

setting xpack.security.authc.selector.enabled introduced in 7.7.0 by #53010 is currently missing for docker entrypoint script

jbudz pushed a commit that referenced this pull request Nov 17, 2020

adds xpack.security.authc.selector.enabled setting (#83551)

f1f7f70

setting xpack.security.authc.selector.enabled introduced in 7.7.0 by #53010 is currently missing for docker entrypoint script

jportner mentioned this pull request Jan 12, 2021

Client cert chain is sometimes incomplete with PKI auth via the login selector #88100

Closed

azasypkin mentioned this pull request Apr 8, 2021

[7.3] [DOCS] Adds authentication settings #96473

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement Kibana Login Selector #53010

Implement Kibana Login Selector #53010

azasypkin commented Dec 13, 2019 •

edited

Loading

elasticmachine commented Dec 13, 2019

tvernum commented Dec 17, 2019

azasypkin commented Dec 17, 2019 •

edited

Loading

tvernum commented Dec 17, 2019

azasypkin commented Dec 17, 2019

azasypkin commented Dec 17, 2019

kobelb commented Dec 18, 2019 •

edited

Loading

tvernum commented Dec 18, 2019

azasypkin commented Dec 19, 2019

azasypkin Mar 10, 2020

azasypkin Mar 18, 2020

azasypkin Mar 10, 2020

This comment was marked as resolved.

azasypkin Mar 10, 2020

legrego Mar 19, 2020

azasypkin Mar 10, 2020

azasypkin Mar 10, 2020

azasypkin Mar 10, 2020

azasypkin Mar 18, 2020

azasypkin Mar 20, 2020

azasypkin Mar 10, 2020

kobelb Mar 13, 2020

azasypkin Mar 16, 2020

kobelb Mar 16, 2020

azasypkin Mar 10, 2020

azasypkin Mar 10, 2020

kobelb Mar 13, 2020

azasypkin Mar 16, 2020 •

edited

Loading

kobelb Mar 16, 2020

azasypkin Mar 10, 2020

azasypkin Mar 18, 2020

cchaos left a comment

kibanamachine commented Mar 23, 2020

azasypkin commented Mar 24, 2020

Implement Kibana Login Selector #53010

Implement Kibana Login Selector #53010

Conversation

azasypkin commented Dec 13, 2019 • edited Loading

elasticmachine commented Dec 13, 2019

tvernum commented Dec 17, 2019

azasypkin commented Dec 17, 2019 • edited Loading

tvernum commented Dec 17, 2019

azasypkin commented Dec 17, 2019

azasypkin commented Dec 17, 2019

kobelb commented Dec 18, 2019 • edited Loading

tvernum commented Dec 18, 2019

azasypkin commented Dec 19, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment was marked as resolved.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azasypkin Mar 16, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cchaos left a comment

Choose a reason for hiding this comment

kibanamachine commented Mar 23, 2020

💚 Build Succeeded

History

azasypkin commented Mar 24, 2020

azasypkin commented Dec 13, 2019 •

edited

Loading

azasypkin commented Dec 17, 2019 •

edited

Loading

kobelb commented Dec 18, 2019 •

edited

Loading

azasypkin Mar 16, 2020 •

edited

Loading