Forbidden error when connnecting after setting up SAML on Elastic Cloud

Elastic Stack Elasticsearch
1

Hi all,

I am trying to setup SAML via Azure Active Directory on an Elastic Cloud cluster.

Before I go into the details about the error, I just wanted to say that I ve read pretty much anything I could find on the internet about SAML and Elasticsearch (like the Okta guide on Medium) as well as the Azure AD specific guide on elasticsearch website.

I m getting the following error after I authenticate on Azure

{"statusCode":403,"error":"Forbidden","message":"Forbidden"}

Here is my elasticsearch.yml config

xpack:
  security:
    authc:
      realms:
        saml:
          cloud-saml:
            order: 2
          attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
        attributes.groups: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
          idp.metadata.path: "https://login.microsoftonline.com/something/federationmetadata/2007-06/federationmetadata.xml?appid=something"
            idp.entity_id: "https://sts.windows.net/something/"
            sp.entity_id: "https://something.eu-central-1.aws.cloud.es.io:9243/"
            sp.acs: "https://something.eu-central-1.aws.cloud.es.io:9243/api/security/v1/saml"
            sp.logout: "https://something.eu-central-1.aws.cloud.es.io:9243/logout"

I enabled saml traces to get more info. Here is what I get in a gist:

  • Constructed SAML Authentication Request
  • Received SAML Message: ...
  • SAML Response: ... Number of unencrypted Assertions: 1 Number of encrypted Assertions: 0 ]
  • SAML Assertion: [ Response ID: ... Response issued at: 2020-05-25T11:10:59.087Z Issuer: ... Number of attribute statements: 1 Number of authentication statements: 1 ]
  • (Possibly decrypted) Assertion: ...
  • SAML Assertion Subject Confirmation is in response to: ...
  • SAML Assertion is only valid between: 2020-05-25T11:05:58.916Z and 2020-05-25T12:10:58.916Z
  • SAML Assertion Subject Confirmation is only valid before: 2020-05-25T12:10:58.916Z
  • SAML Assertion Subject Confirmation intended recipient is: ...
  • [instance-0000000006] SAML Signature [......] matches credentials ...
  • SAML AttributeStatement has [9] attributes and [0] encrypted attributes
  • SAML Assertion was intended for the following Service providers: ...
  • Parsed token...
  • The SAML Assertion contained the following attributes... (the data coming into these attributes is correct).

Initially I thought the problem was with the signing / encrypting of messages but that can't be it as we are well past that point in the logs as shown above. I dont see any actual error message (all of the above are DEBUGs and INFOs). So I think that maybe where I m wrong is the setup of attributes as part of the Azure AD application?

Any help to debug this further would be highly appreciated.

Thanks

2

I think my attributes.principal and groups are incorrect. But I ll wait for the pros to confirm

3

Καλησπέρα Γιάννη!

So, 403 means that you are authenticated but unauthorized to do what you want to do

As we describe in our docs, when you authenticate you don't have access to anything by default so you need to use role mappings to add one or more roles to the users logging in via SAML so that a) Can see Kibana and b) can see necessary data

You can start from there and create the necessary roles and role mappings that give your users access to the needed data. Follow the links from the doc I shared above and we would be happy to help if you get stuck or if you have any specific question down the line

4

Γειά σου συνονόματε!

So I think I know where the problem is but don't know how to fix it. I did add the roles and role mappings in ES similar to:

######## Role Mapping 1 - Operators #######
PUT /_security/role_mapping/saml-kibana-operators
{
  "roles": [
      "kibana_dashboard_user",
      "kibana_user",
      "Kibana_viewer",
      "reporting_user"
    ]
,
  "enabled": true,
  "rules": { "all" : [
      { "field": { "realm.name": "cloud-saml" } },
      { "field": { "groups": "OK_Kibana_Operators" } }
  ]},
  "metadata": { "version": 1 }
}
######## Role Mapping 2 - Admins #######
PUT /_security/role_mapping/saml-kibana-admins
{
   "enabled": true,
    "roles": [ "superuser" ],
    "rules": { "all" : [
        { "field": { "realm.name": "cloud-saml" } },
        { "field": { "groups": "OK_Kibana_Admins" } }
    ]},
    "metadata": { "version": 1 }
}

Equally I created the roles (groups) OK_Kibana_Operators and OK_Kibana_Admins in Azure Active Directory.

I think the problem lies with how the role SAML attribute is mapped. I checked the federation metadata and used the

http://schemas.microsoft.com/ws/2008/06/identity/claims/role

as found in there.

But it doesnt seem this is coming through. Example from logs:

[instance-0000000013] Parsed token [SamlToken{...}] to attributes [SamlAttributes(NameId(urn:oasis:names:tc:SAML:2.0:nameid-format:transient)=something)[something]{[http://schemas.microsoft.com/identity/claims/tenantid=[something], http://schemas.microsoft.com/identity/claims/objectidentifier=[something], http://schemas.microsoft.com/identity/claims/displayname=[yannis@mydomain.com], http://schemas.microsoft.com/identity/claims/identityprovider=[live.com], http://schemas.microsoft.com/claims/authnmethodsreferences=[http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password, http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/unspecified], http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname=[Yannis], http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname=[Psarras], http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress=[yannis@mydomain.com], http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name=[yannis_mydomain.com#EXT#@mydomain.onmicrosoft.com]]}]

I tried to follow the blog here (https://www.elastic.co/blog/saml-based-single-sign-on-with-elasticsearch-and-azure-active-directory) and tried to add the saml attribute manually but it doesnt let me add it (apparently its restricted).

P.S. Really helpful to have a blog there detailing most of the steps but I do feel it's quite outdated. If you try to follow it you will see what I mean. Just my 2c.

5

Yes, this does seem to be the issue here. I have no working knowledge of Azure AD but a simple search lead me to Configure group claims for applications by using Microsoft Entra ID | Microsoft Learn which seems to describe how to release Security Groups from your azure AD in the http://schemas.microsoft.com/ws/2008/06/identity/claims/role claim ( == SAML Attribute in our case) , hope this helps.

P.S. Really helpful to have a blog there detailing most of the steps but I do feel it's quite outdated. If you try to follow it you will see what I mean. Just my 2c.

Thanks for the feedback, we do appreciate this. Ping @forloop who wrote the original blog post to see if it would make sense to update some parts. Speaking of which, @forloop wrote another excellent guide recently in the forums that might help you too.

6

I got it!

It was not simple. Your link saved my bacon @ikakavas! I had to do what was detailed there and then map the group ID (this is important as this is what's being sent back).

Thank you!

7

Thanks for the ping, @ikakavas.

At the time of writing, you had to manually add the http://schemas.microsoft.com/ws/2008/06/identity/claims/role claim and map it to user.assignedroles. Now, Azure automatically adds this claim. I'll see if we can update the blog post to reflect this :+1:

8

Hey @forloop - Nice to see you here. Dont get me wrong - The blog post was super helpful and got me 90% of the way. No chance I would have made it otherwise.

In the end I had to do what's explained here: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims

and will automatically return the roles as claims (provided you check the necessary checkbox)

9

All good @Yannis_Psarras, glad you got it sorted :slightly_smiling_face:

10

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.