OpenID error after authenticating against AWS Cognito

#1

Attempting to configure a Elastic Cloud Kibana instance to use AWS Cognito for login but running into a the below error after successful login at the OP (AWS Cognito) side.

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

Have an EC2 instance running nginx in front of Kibana, to make sure my domain name is correctly reflected & secure.

xpack.security.authc.realms:
  oidc.cloud-oidc:
    order: 2
      rp.client_id: "<clientid>"
      rp.response_type: code
    rp.redirect_uri: "https://<KIBANA EXTEARNAL URL>/api/security/v1/oidc"
    op.issuer: "https://cognito-idp.eu-west-1.amazonaws.com/xxxxxxxxxxxxxx"
    op.authorization_endpoint: "https://xxxx.auth.eu-west-1.amazoncognito.com/oauth2/authorize"
    op.token_endpoint: "https://xxxx.auth.eu-west-1.amazoncognito.com/oauth2/token"
    op.jwkset_path: https://cognito-idp.eu-west-1.amazonaws.com/xxxxxxxxxxxxxx/.well-known/jwks.json
    op.userinfo_endpoint: "https://xxxx.auth.eu-west-1.amazoncognito.com/oauth2/userInfo"
    op.endsession_endpoint: "https://xxxx.auth.eu-west-1.amazoncognito.com/logout"
    rp.post_logout_redirect_uri: "https://<KIBANA EXTEARNAL URL>/logged_out"
    claims.principal: sub
    claims.groups: "cognito:groups"

In Kibana, I have configured the following

    xpack.security.public:
      protocol: https
      hostname: "<KIBANA EXTERNAL URL>"
      port: 443

There is a slight delay before I get the above error, which feels like its a comms problem, but cant be sure.

I tried to enable the logs in ES but my settings dont seem to have any effect:

   PUT /_cluster/settings
    {
      "transient": {
        "logger.org.elasticsearch.xpack.security.authc.saml" : "TRACE",
        "logger.org.elasticsearch.xpack.security.authc.oidc": "TRACE",
        "logger.org.elasticsearch.xpack.security.authc": "TRACE",
        "logger.org.elasticsearch.xpack.security" : "TRACE"
      }
    }

Anyone had a similar issue?

Thanks,

Johan

1 Like
#2

Hi there

You only need

"logger.org.elasticsearch.xpack.security.authc.oidc": "TRACE"

There should be a few related log lines in your elasticsearch log. If you can't see them, could you please engage with your support engineer and reference this post If needed ?

#3

Hi,

I tried that initially with no luck. Will do what you suggest.

Thanks,

Johan

1 Like
#4

Hi,
I have observed the same issue with Okta, the authentication is succesful but Elastic Cloud returns the error below.
{"statusCode":401,"error":"Unauthorized","message":"[security_exception] unable to authenticate user [<OIDC Token>] for action [cluster:admin/xpack/security/oidc/authenticate], with { header={ WWW-Authenticate={ 0=\"Bearer realm=\\\"security\\\"\" & 1=\"ApiKey\" & 2=\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\" } } }"}
It seems this feature is probably not working.

#5

Hi @Olumide_Ajiboye ,

Please open an issue for your problem and share your configuration and the logs from your instance so that we can help you address the issues you're facing.

#6

We're hitting the exact same issue with 7.4.
This is the first time for us to configure OpenID auth.

We're in the cloud and enabling trace for oidc doesn't produce any new logs in deployments -> logs.

Any hints?

#7

@Olumide_Ajiboye @nahojkap wonder which version of stack are you having? Is it 7.4 for you both?

#8

Hi @nickbabkin,

There is currently an unintended limitation prohibiting you from seeing the OpenID Connect related logs in the Elastic Cloud interface. While we are working to resolve this, please contact your support engineer and they would be able to relay the necessary logs to you that will allow you to troubleshoot your configuration.

#9

Just FYI,
after bit of playing around I was able to fix this by changing principal claim from:

claims.principal: sub

to:

claims.principal: preferred_username

#10

@nickbabkin indeed, on 7.4 here as well. Can you confirm if your token contained the sub claim?

#11

Glad you got this figured out

This would mean that the ID Token didn't contain a sub claim which is rather strange. The logs ( if you get them from your support engineer ) would contain a line that says

claims.principal not found in {your ID Tokens claims here in json format}

#12

@ikakavas Resorted to debugging this locally and it seem AWS is returning claims with values of different types in token request vs user info:

"email_verified": true
vs
"email_verified": "true"

Parsing fails and as a result the authentication times out. Removing one of the claims before the merge happens fixes this problem and authentication is possible. Worth noting that there is nothing logged about this error, its simply times out.

Checking why AWS insists on sending the email_verified claim even when I set the scope to openid only

#13

Thank you so much for the details @nahojkap . I recently came across a similar issue with AWS Cognito that lead to a timeout. It looked like email claim was to blame, but your findings shed some additional light. This is a bug on our side, I will be looking into it.

Would you also be opening an issue against Cognito regarding the different types for email_verified ? To be clear, this is supposed to be boolean so "email_verified": true that comes in the ID Token is the correct version.

#14

Will be raising an issue with AWS, will update here when I know more. Let me know if you need anything else from me otherwise.

#15

Also @ikakavas (and not had time to check if there is an issue reported about this already) the AWS Cognito logout pages require some custom URL parameters (client_id and logout_uri) and while I can specify these in the op.endsession_endpoint config, the LogoutRequest class ignores the fact the URI passed already contains a ? for the query string and simply appends a ? and the generated query string.

Cognito will in this case report missing parameter. Changing the URL manually fixes it but now running into some other mysterious error in Cognito but still digging into what that can be.

#16

Already tracking this in https://github.com/elastic/elasticsearch/issues/48409