AWS OpenSearch SAML 2.0 SSO Via Azure Active Directory

I’m checking the way to connect AWS services (e.g. grafana, Openserch, etc) to AAD (Azure Active Directory). While federation to grafana via AAD was a walk in the park thanks to the AAD gallery catalog. Federating to OpenSearch wasn’t that easy. In this article, I will explain how to Federate to AWS Opensearch via AAD in other words how to connect to AWS Opensearch with your AAD account.

Prerequisites:

• AWS account.
• An azure account with AAD tenant.

Creating AWS OpenSearch.

1. Search for Opensearch and click create a domain.
2. Fill in the domain name (please use a significant name).
3. At network choose Public access.
4. Mark the Prepare SAML authentication At SAML authentication for OpenSearch Dashboards/Kibana.
5. Finish and review.

Creating the federation

1. Go to your Azure tenant.
2. Click on Enterprise application.
3. Click on a new application.
4. Click on Create your own application.
5. Enter the application name when promoted (please use a significant name).
6. Click create.
7. At the new enterprise, application page click on Users and groups.
8. Add any users or groups that need to have access to the OpenSearch.
9. At the new enterprise, application page click on single sign-on.
10. At Basic SAML Configuration click edit.
11. To get the Identifier (Entity ID) Go back to AWS to you newly created Opensearch domain.
12. Go to Security configuration and click edit.
13. Scroll down to SAML authentication for OpenSearch Dashboards/Kibana, copy the Service provider entity ID and paste it back in Azure as the Identifier (Entity ID).
14. For the Reply URL copy and paste the IdP-initiated SSO URL.
15. Back to Azure on Attributes & Claims click edit.
16. Click add a group claim (it’s needed for configuration of backend roles in the OpenSearch services).
17. At SAML Signing Certificate download the Federation Metadata XML.
18. Back to AWS copy or upload the content on the XML file under the Metadata from IdP section.
19. At SAML master username — optional (its not optional trust me) write down the name of the user you want to be the first federated admin.
20. At SAML master backend role — optional (you shouldn’t leave it blank) write down the group name/id/any other way you choose to forward the claims (If you don’t know what to write here leave it blank and I will explain a little bit later how to troubleshoot and see what claim are forwarded to AWS).
21. Expand additional settings.
22. At Subject key — optional (well you know already) write: http://schemas.microsoft.com/identity/claims/displayname — if you want your username to look like “User”, Or write: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name — if you want your username to look like “User@blahh.nahh”. (make sure that the user you wrote in bullet number 19 is in a similar structure.)
23. At Roles key — optional (…) write: http://schemas.microsoft.com/ws/2008/06/identity/claims/groups — We specifies all those claims because OpenSearch is looking for specific claim names and he can’t find them so we give him a little hint where to search.
24. Click Save changes and wait until OpenSearch is deployed.
25. Back to Azure click on test and Test sign in — hopefully everything works as it should.

Troubleshooting

In case you can’t sign in or you don’t get the permissions you are expected to get. It’s a good time to bring out saml tracer and debug the hell out of this one.

Open your saml tracer and try to sign in to the application. look at the response you get from the application look for the <AttributeStatement> tag.

Go thru all the claims and check if everything is as expected (You are passing groups id/names).

Check the claim name and match it with the master user/role we had assigned before. The saml tracer is your best friend right now.