Display a user friendly view when SAML/OpenID Connect login fails

[azasypkin]

When during the SAML/OpenID Connect IdP initiated login or at the last step of SP initiated handshake Elasticsearch (e.g. Kibana session expired in the middle of SAML handshake #18117) rejects to authenticate user we just display raw error message without guiding user on what to do next.

Here is example where user ends up with if SAMLResponse is rejected because of unknown realm:

We can detect most (all?) of these cases since they're triggered through dedicated endpoints (/api/security/saml/callback, /internal/security/saml/start, /api/security/oidc/callback and /api/security/oidc/initiate_login) and render something that is nicer and more actionable than that.

[elasticmachine]

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

[jowiho]

A similar situation occurs when the SAML authentication succeeds, but the IDP returns an error because the user is not authorized. In that case Kibana shows a bare {"statusCode":403,"error":"Forbidden","message":"Forbidden"} error.

[azasypkin]

A similar situation occurs when the SAML authentication succeeds, but the IDP returns an error because the user is not authorized. In that case Kibana shows a bare {"statusCode":403,"error":"Forbidden","message":"Forbidden"} error.

Well, even though it may look similar it's a completely different use case and has nothing to do with authentication/login. Having said that we're going to handle this in the scope of #18270 instead.

but the IDP returns an error because the user is not authorized

Hmm, how exactly does IdP return this error? Or you mean Kibana/Elasticsearch (application), not IDP?

[jowiho]

The IDP returns the authorization error in the SAML response message. Kibana passes the SAML message to ES, which parses it and returns an error to Kibana.

[azasypkin]

The IDP returns the authorization error in the SAML response message. Kibana passes the SAML message to ES, which parses it and returns an error to Kibana.

Hmm, how can I reproduce this? I don't think Kibana would return 403 even if ES returns it during authenticating via SAML Response, we always return 401 instead. 403 is returned by Kibana if user you successfully authenticated with doesn't have enough privileges.

[jowiho]

I've reproduced it by setting up an account with auth0.com and configuring my cloud deployment to use it as a saml IDP. I created a user in auth0 who I did not allow access to the Kibana SP.

[azasypkin]

I've reproduced it by setting up an account with auth0.com and configuring my cloud deployment to use it as a saml IDP. I created a user in auth0 who I did not allow access to the Kibana SP.

Well, I believe not adding Kibana into Authorized Applications in Auth0 when SAML is used doesn't have any effect (neither of our test apps in Auth0 are authorized for SAML, only OIDC ones). You can introspect SAML response with Auth0 tools to confirm, but I'm pretty sure it doesn't include any errors and you're just hitting the issue I was referring to in #61232 (comment).

[jowiho]

You're right. Initially I still got 403s even after adding the correct role mapping. But when I cleared the site data in my browser, I did get access. Sorry for the noise.

…

On Tue, Apr 14, 2020 at 1:02 PM Aleh Zasypkin ***@***.***> wrote: I've reproduced it by setting up an account with auth0.com and configuring my cloud deployment to use it as a saml IDP. I created a user in auth0 who I did not allow access to the Kibana SP. Well, I believe not adding Kibana into Authorized Applications in Auth0 when SAML is used doesn't have any effect (neither of our test apps in Auth0 are authorized for SAML, only OIDC ones). You can introspect SAML response with Auth0 tools to confirm, but I'm pretty sure it doesn't include any errors and you're just hitting the issue I was referring to in #61232 (comment) <#61232 (comment)>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#61232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQZWFYJUEJHEO5TYXXDY3LRMQ7GBANCNFSM4LTK3DVA> .

[jowiho]

Update: by blocking the user in auth0 I was able to have their IDP send a SAML error to Kibana:

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_cd76a84ac158a6babe61"  InResponseTo="_fbe44f0f5c38e3b702d3df2647ec584508b631cd"  Version="2.0" IssueInstant="2020-04-14T11:56:21.683Z"  Destination="https://1c16071cf36548359bfe1a0d29bee6a9.westeurope.azure.elastic-cloud.com:9243/api/security/v1/saml"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:wiho.eu.auth0.com</saml:Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/><samlp:StatusMessage Value="user is blocked"/></samlp:Status></samlp:Response>

As you predicted, Kibana shows me a bare JSON document with statusCode: 401:

{"statusCode":401,"error":"Unauthorized","message":"[security_exception] unable to authenticate user [<unauthenticated-saml-user>] for action [cluster:admin/xpack/security/saml/authenticate], with { header={ WWW-Authenticate={ 0=\"Bearer realm=\\\"security\\\"\" & 1=\"ApiKey\" & 2=\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\" } } }"}

[azasypkin]

Good, thanks for confirming. That's something we want to improve UX for in the scope of this issue.