Add support for SAML IdP initiated login when user already has active session. #33644

azasypkin · 2019-03-21T11:30:12Z

Summary

This PR adds support for the Identity Provider (IdP) initiated login when user already has an active session. This usually happens when user opens Kibana from IdP app dashboard. Previously we were returning 403 error to the user explaining that we don't support that scenario.

There are two cases we'll start to support with this PR:

If IdP initiated login is for the same user we'll exchange new SAML payload to new pair of access/refresh tokens invalidating existing ones (SAML local logout) and user will be automatically redirected to Kibana home page.
If IdP initiated login is for different user (either usernames or authentication realms are different) we'll exchange new SAML payload to new pair of access/refresh tokens invalidating existing ones (SAML local logout) as in the case above, but redirect user to a special page that will warn user that now they will act on behalf of a different user. We do this to avoid any confusion since new user may have a different set of roles, permissions etc. We don't expect this scenario to be hit frequently, it's mostly for admins who may test or configure Kibana on behalf of different users.

I've tested two aforementioned scenarios with Auth0 and Okta. PR includes unit and integration tests.

"Release Note: user is now able to open Kibana from SAML Identity Provider dashboard (e.g. Okta App Dashboard or Auth0 Single Sign-On (SSO) Dashboard). Previously this way of accessing Kibana wasn't supported."

Original description

In this PR I'm experimenting with one of the options mentioned in https://github.com//issues/26714:

Once we receive SAMLResponse, but we already have an active valid session, we:

Get user for the existing session via /_security/_authenticate
Send this SAMLResponse to /_security/saml/authenticate to see if it's valid one
- If this request fails, we return error to the user. Existing session is kept untouched unless we get 401
- If this request succeeds we compare user and realm name with the ones from the current user
  - If these match user is forwarded to the Kibana home page and continues to use existing session
  - If these DON'T match user is forwarded to a custom page that explains what happened and allows user to choose what to do next: either continue with existing session or logout and try again.
  - Access and refresh tokens created during this check are invalidated

Demo

Issues

Once user chooses different credentials at the IdP page, old IdP session is invalidated. So when they try to open Kibana and see this new page with a warning they won't be able to do a proper SLO since ES will create LogoutRequest for the IdP session that doesn't exist anymore. E.g with Auth0 ES will properly invalidate ES tokens, but when user is forwarded to Auth0 portal for SLO user will see Oops!, something went wrong with No active session(s) found matching LogoutRequest . We likely can't anything about that.
Just to get this username for the SAMLResponse we have to use /_security/saml/authenticate that will create unnecessary access and refresh tokens which is bad. Ideally we'd rather have another lighter endpoint to do that, but the use case is very narrow 🤷‍♂️
The /_security/saml/authenticate returns only username and doesn't return real name. And if I understand correctly we can easily have the same username within different SAML realms, so we need to take realm name into account if we want to make sure that new SAMLResponse corresponds to exactly same user? If true then either /_security/saml/authenticate should return realm name or we'll have to additionally query /_security/_authenticate to get full user info using this new access token
If we keep using /_security/saml/authenticate just to get username to cover this use case we'll have to invalidate created tokens right after we created them and the only way to that I know of is calling /_security/saml/logout. This endpoint may return LogoutRequest that Kibana we'll always drop.

Would be great to hear your thoughts on this @kobelb @jkakavas! Based on the Issues it feels a bit like we'll be abusing /_security/saml/authenticate and /_security/saml/logout if we go this route (and authenticate/logout, authenticate/logout, ... ES logs may look confusing).

Fixes: #26714

elasticmachine · 2019-03-21T11:30:16Z

Pinging @elastic/kibana-security

elasticmachine · 2019-03-21T12:14:18Z

💔 Build Failed

continuous-integration/kibana-ci/pull-request

kobelb · 2019-03-21T18:14:24Z

I think this is an interesting approach, and I really appreciate the detailed description of the issues it presents. What if we were to change the behavior to allow the user to continue as the "new user", that way we wouldn't be abusing the /_security/saml/authenticate endpoint but also warning the user that they're not logged in as someone different? It seems like if the user chose to login as a different user, that they'd want to continue the one they just chose, not the one they were previously logged in using.

jkakavas · 2019-03-22T05:45:52Z

The /_security/saml/authenticate returns only username and doesn't return real name. And if I understand correctly we can easily have the same username within different SAML realms, so we need to take realm name into account if we want to make sure that new SAMLResponse corresponds to exactly same user? If true then either /_security/saml/authenticate should return realm name or we'll have to additionally query /_security/_authenticate to get full user info using this new access token

~~It does return the realm name https://www.elastic.co/guide/en/elasticsearch/reference/6.6/security-api-authenticate.html , this was added in 6.6~~ never mind me, I didn't notice the /_security/saml/authenticate

and the only way to that I know of is calling /_security/saml/logout

Tokens can be invalidated explicitly using the respective API: https://www.elastic.co/guide/en/elasticsearch/reference/6.6/security-api-invalidate-token.html

jkakavas · 2019-03-22T06:08:56Z

I think this has a lot to do with UX (deciding what to do with the user's session, overwrite or throw error, allowing them to decide etc ) and in such cases I find it helpful to see how other SSO enabled apps are handling it to get ideas about good and bad experiences. I don't have a strong opinion but I believe session overwriting (invalidating the old) is the way to go

Once user chooses different credentials at the IdP page, old IdP session is invalidated. So when they try to open Kibana and see this new page with a warning they won't be able to do a proper SLO

this issue would be no longer relevant. We can assume that the IDP session is already invalidated when the user switched auth context so we won;t need to do an SLO for the old session , just a local logout, or simply invalidating the access/refresh tokens we have tied to the old session.

azasypkin · 2019-03-22T07:52:55Z

What if we were to change the behavior to allow the user to continue as the "new user", that way we wouldn't be abusing the /_security/saml/authenticate endpoint but also warning the user that they're not logged in as someone different? It seems like if the user chose to login as a different user, that they'd want to continue the one they just chose, not the one they were previously logged in using.

Yeah, that's an option too. The more I think about it the more I'm leaning towards it. Technically almost everything will stay the same, except for these things:

We'll be invalidating tokens from the existing session instead of ones returned from /_security/saml/authenticate (local logout) and rewriting session with new tokens every time IdP initiated login happens
The page that will warn users about brand new session that will effect all other browser contexts (tabs, windows) won't have Logout action since it doesn't make much sense anymore. So the page will just explain implications and propose to Continue as .....

~~It does return the realm name https://www.elastic.co/guide/en/elasticsearch/reference/6.6/security-api-authenticate.html , this was added in 6.6~~ never mind me, I didn't notice the /_security/saml/authenticate

Is there any reason to not return name of authentication realm from /_security/saml/authenticate? It's not a blocker for Kibana, just would be more convenient to have it.

Tokens can be invalidated explicitly using the respective API: https://www.elastic.co/guide/en/elasticsearch/reference/6.6/security-api-invalidate-token.html

Great, wasn't sure that it was enough to invalidate SAML session. So we have a "local logout" support, one problem less.

I find it helpful to see how other SSO enabled apps are handling it to get ideas about good and bad experiences.

Yeah, that's funny, but the only production-like SSO enabled app I have multiple accounts in is GMail and it just supports multiple concurrent sessions. I'll see if I can deploy some locally, but honestly I'm not super worried about the best possible UX for the use case with different credentials as majority of the users won't ever experience it, except for admins maybe.

jkakavas · 2019-03-22T08:18:14Z

Is there any reason to not return name of authentication realm from /_security/saml/authenticate? It's not a blocker for Kibana, just would be more convenient to have it.

No not really. It's not currently returned as there was no use case for it, but I have nothing against making that change. If we move forward with #26171 (which I really need to pick up and get the tests added :/ ) , there might be the case that kibana knows the realm name in advance. In any case though, since Kibana can only use 1 ES SAML Realm at any given time, this shouldn't be that much of a concern. right ?

azasypkin · 2019-03-22T08:36:44Z

If we move forward with #26171 (which I really need to pick up and get the tests added :/ ) , there might be the case that kibana knows the realm name in advance.

Oh, haven't seen this one.

In any case though, since Kibana can only use 1 ES SAML Realm at any given time, this shouldn't be that much of a concern. right ?

Hmm, the use case I have in mind with the current implementation:

There are IdP#1 and IdP#2 that can allow user to log in into Kibana
To support these two IdPs we have two separate realms configured in ES
User has the same username within these two IdPs
Role mapping is different and based on realm name (at least that's how I do it locally)
When user has Kibana session based on IdP#1 and there is a IdP initiated login from the same IdP we check that it's exactly same user and silently allow user to proceed
When user has Kibana session based on IdP#1 and there is a IdP initiated login from IdP#2 we see that these users are different (same username, but different realm names) and hence may have different permissions and whatnot so we may want to warn user about that

Am I over-complicating things and we don't want to support this use case or it doesn't work like I assume?

jkakavas · 2019-03-22T09:03:20Z

There are IdP#1 and IdP#2 that can allow user to log in into Kibana

To support these two IdPs we have two separate realms configured in ES

Am I over-complicating things and we don't want to support this use case or it doesn't work like I assume?

No, you are right, I was thinking of only SP initiated SSO. (I know you know this but )for future reference, the way we currently match Kibana instance to a SAML Realm in ES is that kibana builds an ACS url from its known configuration and sends that to ES in the prepare saml authentication request so that ES knows which realm config to use.
At any given time, Kibana can only construct 1 ACS url from it's current config, and as such it can only use 1 saml realm in ES. That means that IDP#1 and IDP#2 need to have the same exact configuration if they can both be served by the same saml realm in ES.

In order for this to be supported as a use case for SP initiated SSO, we would need to implement a SAML Discovery Service of sorts where the user gets to select the IDP they want to authenticate against.

For the IDP initiated SSO use case that you were describing, my gut feeling is that the case where multiple IDPs will be configured and where the principal will be mapped to an unscoped SAML Attribute ( i.e. ioannis instead of ioannis@idp#1 or even better NameIDs containing IDP qualifiers ) will be a very rare one. But if we can support this in way that makes sense, I'm +1

azasypkin · 2019-03-22T10:10:53Z

For the IDP initiated SSO use case that you were describing, my gut feeling is that the case where multiple IDPs will be configured and where the principal will be mapped to an unscoped SAML Attribute ( i.e. ioannis instead of ioannis@idp#1 or even better NameIDs containing IDP qualifiers ) will be a very
rare one.

Yeah, that makes sense, I used very naive email --> principal mapping for my local tests with Auth0 and Okta, in production principal will likely be more complex and tied to IdP.

But if we can support this in way that makes sense, I'm +1

Good, I'll incorporate your and Brandon's feedback into this WIP and we'll see how it works :)

Thank you @jkakavas and @kobelb !

azasypkin · 2019-03-27T12:21:27Z

docs/security/authentication/index.asciidoc

@@ -49,8 +49,6 @@ IMPORTANT: The {kib} user-facing origin should be the same in {kib}, {es}, and t

 Users will be able to log in to {kib} via SAML Single Sign-On by navigating directly to the {kib} URL. Users who aren't authenticated are redirected to the Identity Provider for login. Most Identity Providers maintain a long-lived session—users who logged in to a different application using the same Identity Provider in the same browser are automatically authenticated. An exception is if {es} or the Identity Provider is configured to force user to re-authenticate. This login scenario is called _Service Provider initiated login_.

-NOTE: Some Identity Providers support a portal or dashboard from which users can open an application that is integrated with the Identity Provider. This login scenario is known as _Identity Provider initiated login_, and {kib} has limitations with this scenario. Users cannot open {kib} in multiple tabs from the Identity Provider portal in the same browser context if an active {kib} session exists. No issues exist if users open {kib} in multiple tabs using _direct_ {kib} URL.


note: I was thinking about mentioning the case when user logs in with different credentials, but it should be a rare case and probably we don't want to overload docs with such details....

That sounds reasonable to me.

azasypkin · 2019-03-27T12:22:28Z

x-pack/plugins/security/public/views/overwritten_session/_overwritten_session.scss

@@ -0,0 +1,25 @@
+.overwrittenSession {


note: proudly copied from logged_out view :)

Is there ANY way we can start making this pattern a re-usable component instead of copy/pasting? It's getting hard to manage all the usages to make sure updates get applied everywhere.

We can try, let me check how many times this one is actually copy-pasted. Do you have any re-usable component in mind we can use as an example here?

The latest one we tackled was the help menu popover that had default content but also allowed for custom content https://github.com/elastic/kibana/blob/master/src/legacy/ui/public/chrome/directives/header_global_nav/components/header_help_menu.tsx.

I'd assume the customizable bits would be the title string and the main content.

azasypkin · 2019-03-27T12:23:15Z

...ck/plugins/security/public/views/overwritten_session/components/overwritten_session_page.tsx

+              <h1>
+                <FormattedMessage
+                  id="xpack.security.overwrittenSession.title"
+                  defaultMessage="You had an active session previously, but logged in as a different user."


note: wording is the hardest part, would gladly accept any better alternatives.

I don't mind the current wording, perhaps @gchaps can provide her input. For some context Gail, we're displaying this screen when the user was previously logged into Kibana as a different user, and they're now logging in as a new user.

How about making it a little simpler:

You previously logged in as a different user.

Notes:

In the demo, I noticed this text "Last time you logged in with" in the login screen. It should be "Last time you logged in as"

Thanks Gail!

In the demo, I noticed this text "Last time you logged in with" in the login screen. It should be "Last time you logged in as

Haha, luckily that's Auth0 login page, not Kibana :)

azasypkin · 2019-03-27T12:24:14Z

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

+        // If user has been authenticated via session, but request also includes SAML payload
+        // we should check whether this payload is for the exactly same user and if not
+        // we'll re-authenticate user and forward to a page with the respective warning.
+        authenticationResult = await this.authenticateViaNewPayload(


note: couldn't find a better name for authenticateViaNewPayload :/

When reading through the code and seeing this name and the comment, I wasn't surprised, so it seems like a find name for the time being.

azasypkin · 2019-03-27T12:26:35Z

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

+    this.debug('Local logout has been initiated by the Identity Provider.');
+
+    // First invalidate old access token.
+    const {


note: we do the same for token provider (copied from there), we'll need to unify that at some point.

azasypkin · 2019-03-27T12:27:20Z

x-pack/plugins/security/server/lib/get_user.ts

+  type: string;
+}
+
+export interface User {


note: just defined a couple of props we need or may need soon.

note I'm also introducing a User interface as part of #30977 (https://github.com/elastic/kibana/pull/30977/files#diff-31444acbfefac2d86a416260887ab8cbR7)

Whoever merges last should try to consolidate the interfaces

Ha, good to know! Any reason why authentication_realm and lookup_realm are optional?

I marked them optional because we don't always have that information in all UI contexts. We only get authentication_realm and lookup_realm for the currently logged in user, but pages like the user management screen allow you to view/create/update arbitrary users, and that information isn't available nor necessary then.

If it's easier/better for your use case to mark them required, then maybe we end up having a couple of interfaces, where one extends the other? Maybe something like User and AuthenticatedUser?

Yeah, I think these two are different interfaces even though they look similar. The one I use is more like AuthenticatedUser\Principal\Identity.

azasypkin · 2019-03-27T12:29:33Z

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

+   */
+  private debug(message: string) {
+    this.options.log(['debug', 'security', 'saml'], message);
+  }
 }


note: if we need to add anything else to saml we may want to create a dedicated folder for it and split this file..... It's getting too big.

azasypkin · 2019-03-27T12:35:17Z

Hey @kobelb!

Would you mind giving a preliminary feedback on the UX and the approach itself (~~only last commit, previous are from PR this one depends on~~)? I haven't touched tests yet.

kobelb

This is looking and working great!

kobelb · 2019-03-27T14:09:06Z

docs/security/authentication/index.asciidoc

@@ -49,8 +49,6 @@ IMPORTANT: The {kib} user-facing origin should be the same in {kib}, {es}, and t

 Users will be able to log in to {kib} via SAML Single Sign-On by navigating directly to the {kib} URL. Users who aren't authenticated are redirected to the Identity Provider for login. Most Identity Providers maintain a long-lived session—users who logged in to a different application using the same Identity Provider in the same browser are automatically authenticated. An exception is if {es} or the Identity Provider is configured to force user to re-authenticate. This login scenario is called _Service Provider initiated login_.

-NOTE: Some Identity Providers support a portal or dashboard from which users can open an application that is integrated with the Identity Provider. This login scenario is known as _Identity Provider initiated login_, and {kib} has limitations with this scenario. Users cannot open {kib} in multiple tabs from the Identity Provider portal in the same browser context if an active {kib} session exists. No issues exist if users open {kib} in multiple tabs using _direct_ {kib} URL.


That sounds reasonable to me.

kobelb · 2019-03-28T14:42:44Z

...ck/plugins/security/public/views/overwritten_session/components/overwritten_session_page.tsx

+              <h1>
+                <FormattedMessage
+                  id="xpack.security.overwrittenSession.title"
+                  defaultMessage="You had an active session previously, but logged in as a different user."


I don't mind the current wording, perhaps @gchaps can provide her input. For some context Gail, we're displaying this screen when the user was previously logged into Kibana as a different user, and they're now logging in as a new user.

kobelb · 2019-03-28T14:46:00Z

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

+        // If user has been authenticated via session, but request also includes SAML payload
+        // we should check whether this payload is for the exactly same user and if not
+        // we'll re-authenticate user and forward to a page with the respective warning.
+        authenticationResult = await this.authenticateViaNewPayload(


When reading through the code and seeing this name and the comment, I wasn't surprised, so it seems like a find name for the time being.

kobelb · 2019-03-28T14:50:00Z

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

-        ['debug', 'security', 'saml'],
-        'User session has been successfully invalidated.'
-      );
+      const redirect = isSAMLRequestQuery(request.query)


azasypkin · 2019-04-15T07:40:55Z

retest

azasypkin · 2019-04-15T09:09:05Z

x-pack/plugins/security/server/routes/api/v1/__tests__/authenticate.js

@@ -295,17 +295,15 @@ describe('Authentication routes', () => {
      const unhandledException = new Error('Something went wrong.');
      serverStub.plugins.security.authenticate.throws(unhandledException);



note: actually these tests were potentially buggy, we should never have assertions in a catch or then, if we have main assertions in catch then then should fail the test if it's called (noticed that because one of the tests was green, but I expected it to be red :)).

azasypkin · 2019-04-16T14:41:49Z

Removing review request for now:

will try to combine User interface @legrego introduced recently with the one I'm introducing in this PR
will try to extract common component from overwritten_session and logget_out pages

…ponent from `LoggedOut` and `OverwrittenSession` views.

azasypkin · 2019-04-17T12:56:51Z

x-pack/plugins/security/common/model/authenticated_user.ts

+  lookup_realm: UserRealm;
+}
+
+export function canUserChangePassword(user: AuthenticatedUser) {


note: if I read code correctly this method can only be used with AuthenticatedUser from ChangePassword component (not ChangePasswordForm) that is rendered only within AccountManagementPage that is rendered only for currently authenticated user. That's why I moved this method here.

@legrego please correct me if I didn't get this right :)

that's absolutely right!

Awesome, thanks!

azasypkin · 2019-04-17T13:05:58Z

x-pack/plugins/security/public/components/authentication_state/_authentication_state.scss

@@ -1,22 +1,21 @@
-
-.loggedOut {
+.authenticationState {


note: that the only name I managed to find that would be somewhat related to both logged_out and overwritten_session :) Please share any other naming ideas that would work better!

How about just changing State to Page? Then it could work for the login page as well. Also, these need a 3-letter prefix to conform to our BEM naming scheme. Can you add sec as the prefix to all of these? So this one would be: .secAuthenticationPage.

How about just changing State to Page?

Hmm, I can change it to ...StatePage since this is going to describe the finite "state of the authentication". Does that sound good?

Then it could work for the login page as well.

Not sure, I don't feel these have enough in common (logically) to generalize, the intention here is a bit different. I'd rather wait and see how it evolves.

Also, these need a 3-letter prefix to conform to our BEM naming scheme. Can you add sec as the prefix to all of these?

Sure!

Not sure, I don't feel these have enough in common (logically) to generalize, the intention here is a bit different. I'd rather wait and see how it evolves.

Well the point of making this layout re-usable is more for the layout and visuals that come with it rather than for "purpose". So eventually, I'd like this to be surfaced even higher so that the login and welcome screens can use it as well so we minimize the copy/pasting of styles since that's all it's really applying here.

Yeah, I definitely see your point and thanks for sharing your thoughts it's just that it should be a broader unification effort that's clearly out of scope of this PR IMO. This PR is already not a small/easy-to-review one.

So eventually, I'd like this to be surfaced even higher so that the login and welcome screens can use it as well so we minimize the copy/pasting of styles since that's all it's really applying here.

That would be great, but will take some time 🙈

Yeah I don't think that needs to happen now. Just wanted to respond to the worry about it not being general enough. When we do surface it up for those other pages we can rename the classes again so ...StatePage is fine for now.

azasypkin · 2019-04-17T13:13:31Z

x-pack/plugins/security/public/views/logged_out/logged_out.tsx

@@ -22,7 +23,18 @@ chrome
      const domNode = document.getElementById('reactLoggedOutRoot');
      render(
        <I18nContext>
-          <LoggedOutPage addBasePath={chrome.addBasePath} />
+          <AuthenticationState


note: I defined this entire tree here, but let me know if you prefer it to be in a separate file.

elasticmachine · 2019-04-17T13:43:57Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request

…me `AuthenticationState` to `AuthenticationStatePage`.

cchaos

Code lgtm, don't know how to test it

elasticmachine · 2019-04-17T15:42:08Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request

kobelb

Nice work! This is working great with good test coverage!

elasticmachine · 2019-04-18T08:49:02Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request

… session. (elastic#33644)

azasypkin · 2019-04-18T10:14:48Z

7.x/7.1.0: eb4940d

Contrary to what happens in the SAML realm, we do not support consuming unsolicited Responses from OpenID Connect Providers. This means that the only way that a behavior such as the one described in elastic#33644 can be observed is when - a user initiates a login in a tab but stalls in the OP authentication form - user opens a new tab in the same browser and completes authentication - user returns to original tab, submits the OP form and lands in Kibana's oidc endpoint while actually already having a session. Not sure if this is a corner case we need to cater for, so removing this for now.

azasypkin added Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Feature:Security/Authentication Platform Security - Authentication labels Mar 21, 2019

azasypkin force-pushed the issue-xxx-saml-concurrent-login branch from cd0a7fc to 1eb7722 Compare March 27, 2019 12:16

azasypkin added the feedback_needed label Mar 27, 2019

azasypkin commented Mar 27, 2019

View reviewed changes

azasypkin requested a review from kobelb March 27, 2019 12:35

azasypkin added the v7.2.0 label Mar 27, 2019

azasypkin force-pushed the issue-xxx-saml-concurrent-login branch from 1eb7722 to 26cef9f Compare March 27, 2019 14:15

kobelb reviewed Mar 28, 2019

View reviewed changes

azasypkin removed the feedback_needed label Mar 29, 2019

azasypkin force-pushed the issue-xxx-saml-concurrent-login branch from 26cef9f to fd297be Compare April 15, 2019 07:27

azasypkin marked this pull request as ready for review April 15, 2019 07:40

azasypkin commented Apr 15, 2019

View reviewed changes

azasypkin requested a review from kobelb April 15, 2019 09:11

azasypkin added the review label Apr 15, 2019

azasypkin removed the request for review from kobelb April 16, 2019 14:42

azasypkin added 3 commits April 17, 2019 14:16

Add support for IdP initiated login with existing session.

e184b0a

Review#1: cleaning up and tests.

938485e

Split User into User and AuthenticatedUser models. Extract common com…

3ff0e00

…ponent from `LoggedOut` and `OverwrittenSession` views.

azasypkin force-pushed the issue-xxx-saml-concurrent-login branch from fd297be to 3ff0e00 Compare April 17, 2019 12:54

azasypkin commented Apr 17, 2019

View reviewed changes

azasypkin requested a review from kobelb April 17, 2019 13:45

Review#2: use sec prefix for AuthenticationStatePage styles. Rena…

a1f79bd

…me `AuthenticationState` to `AuthenticationStatePage`.

cchaos approved these changes Apr 17, 2019

View reviewed changes

kobelb approved these changes Apr 17, 2019

View reviewed changes

Merge branch 'master' into issue-xxx-saml-concurrent-login

a1496c4

azasypkin merged commit 7c2ff2e into elastic:master Apr 18, 2019

azasypkin deleted the issue-xxx-saml-concurrent-login branch April 18, 2019 08:51

azasypkin added backport pending and removed review labels Apr 18, 2019

azasypkin mentioned this pull request Apr 18, 2019

[7.x] Add support for SAML IdP initiated login when user already has active session. (#33644) #35281

Merged

azasypkin added a commit to azasypkin/kibana that referenced this pull request Apr 18, 2019

Add support for SAML IdP initiated login when user already has active…

da79d29

… session. (elastic#33644)

azasypkin added backported and removed backport pending labels Apr 18, 2019

		@@ -49,8 +49,6 @@ IMPORTANT: The {kib} user-facing origin should be the same in {kib}, {es}, and t

		Users will be able to log in to {kib} via SAML Single Sign-On by navigating directly to the {kib} URL. Users who aren't authenticated are redirected to the Identity Provider for login. Most Identity Providers maintain a long-lived session—users who logged in to a different application using the same Identity Provider in the same browser are automatically authenticated. An exception is if {es} or the Identity Provider is configured to force user to re-authenticate. This login scenario is called _Service Provider initiated login_.

		NOTE: Some Identity Providers support a portal or dashboard from which users can open an application that is integrated with the Identity Provider. This login scenario is known as _Identity Provider initiated login_, and {kib} has limitations with this scenario. Users cannot open {kib} in multiple tabs from the Identity Provider portal in the same browser context if an active {kib} session exists. No issues exist if users open {kib} in multiple tabs using _direct_ {kib} URL.

		@@ -295,17 +295,15 @@ describe('Authentication routes', () => {
		const unhandledException = new Error('Something went wrong.');
		serverStub.plugins.security.authenticate.throws(unhandledException);

		@@ -1,22 +1,21 @@

		.loggedOut {
		.authenticationState {

Add support for SAML IdP initiated login when user already has active session. #33644

Add support for SAML IdP initiated login when user already has active session. #33644

Conversation

azasypkin commented Mar 21, 2019 • edited Loading

Summary

Demo

Issues

elasticmachine commented Mar 21, 2019

elasticmachine commented Mar 21, 2019

💔 Build Failed

kobelb commented Mar 21, 2019

jkakavas commented Mar 22, 2019 • edited Loading

jkakavas commented Mar 22, 2019

azasypkin commented Mar 22, 2019

jkakavas commented Mar 22, 2019

azasypkin commented Mar 22, 2019

jkakavas commented Mar 22, 2019

azasypkin commented Mar 22, 2019 • 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

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

Choose a reason for hiding this comment

azasypkin commented Mar 27, 2019 • edited Loading

kobelb left a comment • 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

Choose a reason for hiding this comment

azasypkin commented Apr 15, 2019

Choose a reason for hiding this comment

azasypkin commented Apr 16, 2019

azasypkin Apr 17, 2019 • 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

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

elasticmachine commented Apr 17, 2019

💚 Build Succeeded

cchaos left a comment

Choose a reason for hiding this comment

elasticmachine commented Apr 17, 2019

💚 Build Succeeded

kobelb left a comment

Choose a reason for hiding this comment

elasticmachine commented Apr 18, 2019

💚 Build Succeeded

azasypkin commented Apr 18, 2019

azasypkin commented Mar 21, 2019 •

edited

Loading

jkakavas commented Mar 22, 2019 •

edited

Loading

azasypkin commented Mar 22, 2019 •

edited

Loading

azasypkin commented Mar 27, 2019 •

edited

Loading

kobelb left a comment •

edited

Loading

azasypkin Apr 17, 2019 •

edited

Loading