Saml backend role - azure AD

Hi Greetings.

I am trying to enable SAML auth for my Kibana login.

I have an Azure AD application created along with a role say “DevAdmin” and some users are also mapped to this role in Azure AD.

Now in Kibana “Roles”(all_access) I have added the above “DevAdmin” role to the “Backend Role”

I was ideally expecting all the users in “DevAdmin” mapped in AzureAD to be able to authenticate into Kibana.

But what is happening is now i am additionally needing to add the users also separately in the Kibana Role “Mapped Users” to make the login possible along with the user being present in the AzureAD group.

Can someone give me some pointers on why i am not able to just map in the “Backend Role” and get this auth moving.
Any help will be much appreciated.

Regards
Lokesh V

@lokeshv1989 when you authenticate with users that have “DevAdmin” role assigned, can you see that role listed under backend roles in “View roles and identities” section in kibana? (top right)

hi @Anthony
No, it is not showing any backend roles mapped.

image

I have added the role as backend role though, please see below,

@lokeshv1989 this indicates that the backend roles are not being received from AzureAD or extracted correctly from SAML response. Therefore any mapping after that point is irrelevant as there are no backend roles to map.

Does your entry in config.yml for roles_key match the claims section, see my example below:

hi @Anthony
where should i check config.yml, i am having AWS managed Kibana.
can you help me how to check this value from ‘dev tools’ in kibana.
Regards
Lokesh V

@lokeshv1989
The API docs are available here

You will need to enable the API access via elasticsearch.yml file, further details can be found here

In short, if you are using admin account (default admin:admin) you need to enabled the API access by adding below lines to elasticsearch.yml

opendistro_security.restapi.roles_enabled: ["all_access"]
opendistro_security.unsupported.restapi.allow_securityconfig_modification: true

Once that is updated on all nodes and nodes restarted, you can use below to get the current config using below:

GET _opendistro/_security/api/securityconfig

As it states in the docs PATCH and PUT is not recommended/supported. I had issues with PATCH, however PUT has worked for me in the past, you will need to specify full configuration for security with PUT. Similar to the original output of the response to GET query, just update the details where necessary.

hi @Anthony thanks for the reply.
roles_key in my cluster seems to be empty.
please see below screenshot.

image

@lokeshv1989 This might be the reason for no roles showing up. You can try to update the value to correct one and use PUT API.

hi @Anthony correct value means in my case should i put “MindTreeAdmin”(as shown in above screenshot) the backend role name to this field(roles_key)?
Regards
Lokesh V

@lokeshv1989 The name of the key used for roles, so in my example that claim was under “roles”, so yours is probably different. And in that claim the values will be received. so you might received 2 or 3 or more (like MindTreeAdmin, MindTreeReadOnly etc), but the roles_key is the actual name of the field returned in SAML response, not the value in it.

hi @Anthony
below is the screenshot of my AzureAD application screenshot,

in “Required Claim” i think nothing is there, should i create a claim?
Regards.

I can only speak for how I managed to get it working, (there maybe other/better ways to get this sorted) - in my case, yes I created a claim.

sure. why i asked the question is, in the screen there is something called “Additional claims” hence i got confused.

I should not count on this “Additonal claims” correct? instead create one claim under “Required claim”?

Regards.

I don’t remember such options, but sure why not try both, ultimately you want to see backend roles appearing in “View roles and identities” under backend-roles.

hi @Anthony
Finally this thing worked for us. Ur observation regarding claim id was spot on, just that instead of the claim title we used entire claim xml schema url in the roles_key field.
like “http://schemas.xmlsoap.org/xx/xxxx/xx/identity/claims/roles

Regards
Lokesh V