Single sign-on SSO for Amazon OpenSearch Service utilizing SAML and Keycloak

A regular use case for patrons is to combine current identification suppliers (IdPs) with Amazon OpenSearch Service. OpenSearch Service presents built-in assist for single sign-on (SSO) authentication for OpenSearch Dashboards, and makes use of SAML protocol. The SAML authentication for OpenSearch Service helps you to combine your current third-party IdPs, akin to Okta, Ping Identification, OneLogin, Auth0, ADFS, Azure Energetic Listing, and Keycloak, with OpenSearch Service dashboards.

On this submit, we stroll you thru how one can configure service provider-initiated authentication for OpenSearch Dashboards by utilizing OpenSearch Service and Keycloak. We additionally talk about how one can arrange customers, teams, and roles in Keycloak and configure their entry to OpenSearch Dashboards.

Resolution overview

The next diagram illustrates the SAML authentication move for this resolution.

The sign-in move consists of the next steps.

1. The person opens a browser to navigate to the OpenSearch Dashboards endpoint of OpenSearch Service in a digital non-public cloud (VPC), for instance https://vpc-abc123.us-east-1.es.amazonaws.com/_dashboards.
2. The service supplier (OpenSearch Service) makes use of the details about the IdP (Keycloak) to generate a SAML authentication request. The service supplier redirects SAML authentication requests again to the browser.
3. The browser relays the SAML authentication request to Keycloak. Keycloak parses the SAML authentication request and asks for the person to insert their login and password to authenticate.
4. After a profitable authentication, Keycloak generates a SAML authentication response that features authenticated person particulars from Keycloak and sends the encoded SAML response to the browser.
5. The browser relays the SAML response to OpenSearch Service Assertion Client Service (ACS) URL.
6. OpenSearch Service validates the SAML response. If the validation checks are handed, the person is redirected to the entrance web page of OpenSearch Dashboards. The authorization is carried out in accordance with the roles mapped to the person.

Stipulations

To finish this walkthrough, you need to have the next arrange:

• An OpenSearch Service area operating OpenSearch or Elasticsearch model 6.7 or later with fine-grained entry management enabled inside a VPC.
• Keycloak put in and configured. On this submit, we created the IdP in the identical VPC of the OpenSearch area. There is no such thing as a want for a direct connection between the IdP and the service supplier, so you may have the IdP in a distinct community as nicely.
• A correctly configured safety group for OpenSearch Service and Keycloak IdP server to obtain inbound site visitors from customers.
• A browser with community connectivity to each Keycloak and OpenSearch Dashboards.

Allow SAML authentication for OpenSearch Service

Step one is to allow SAML authentication for OpenSearch Service. Full the next steps:

1. On the OpenSearch Service console, open the main points web page to your OpenSearch Service area.
2. On the Safety configuration tab, select Edit.
3. Choose Allow SAML authentication.

Enabling this feature mechanically populates completely different IdP URLs, which is required to configure SAML assist within the Keycloak IdP. Notice down the values below Service supplier entity ID and SP-initiated SSO URL. The OpenSearch Dashboards login move may be configured both as service provider-initiated or IdP-initiated. The service provider-initiated login move is initiated by OpenSearch Service, and the IdP-initiated login move is initiated by the IdP (for instance, Keycloak). On this submit, we use a service provider-initiated login move.

Configure Keycloak as IdP

Throughout the SAML authentication course of, when the person is authenticated, the browser receives a SAML assertion token from Keycloak and forwards it to OpenSearch Service. The OpenSearch Service area authorizes the person with backend roles in accordance with the attributes offered within the token.

To configure Keycloak as IdP, full the next steps:

1. Log in to the Keycloak IdP admin console with admin person privileges (for instance, https://:8081/admin/).
2. Select Create Realm.
3. For Realm title, enter a reputation (for instance, Amazon_OpenSearch) and select Create.

For managing OpenSearch Service particular roles, customers, and teams, you first create a separate shopper realm that gives a logical area to handle objects.

4. Within the navigation pane, select your realm, then select Purchasers.
5. Select Create shopper.
6. Within the Normal Settings window, for Consumer kind, select SAML
7. For Consumer ID, use the service supplier entity ID you copied earlier, then select Subsequent
   
8. Below Login settings, enter the service provider-initiated SSO URL copied from earlier (for instance, https://vpc-abc123.us-east-1.es.amazonaws.com/_dashboards/_opendistro/_security/saml/acs) and select Save.
9. On the shopper settings tab, below Signature and Encryption, activate Signal Assertions and maintain all different choices as default, then select Save.
   
10. On the Keys tab, below Signing keys config, flip Consumer signature required off.

Configure Keycloak customers, roles, and teams

After you will have configured the Keycloak IdP shopper for OpenSearch Service, you may create roles, teams, and customers on the IdP facet. For this submit, we create two roles, two teams, and two customers, as listed within the following desk.

Full the next steps:

1. Within the navigation pane to your realm, select Realm roles.
2. Select Create position.
3. For Function title, enter a reputation (for this submit, super_user_role) and select Save.
4. Repeat these steps to create a second position, readonly_user_role.

Now let’s create teams, assign the roles to the teams, and map the customers to the teams.

5. Below your realm, select Teams within the navigation pane.
6. Select Create group.
7. For Identify, enter a bunch title (for instance, super_user_group) and select Save.
8. Repeat these steps to create a second group, readonly_user_group.

When the brand new teams are created, they are going to be listed on the Teams web page.

9. On the main points web page for every group, on the Function mapping tab, select Assign position.
10. For the group super_user_group, choose the position super_user_role and select Assign.

11. Repeat these steps to assign the position readonly_user_role to the group readonly_user_group.

The final step is to create customers and assign them to teams in order that they mechanically inherit group privileges. For this submit, we create two customers, super_user_1 and readonly_user_1, with dashboard admin and dashboard read-only privileges, respectively.

12. Below your realm, select Customers within the navigation pane.
13. Select Create new person.
14. Below Normal, configure the person particulars, together with person title, first title, final title, and e-mail, then select Create.

15. Set a short lived password on the Credentials tab after you create the person.
16. Select Add person and repeat these steps so as to add your second person, readonly_user_1.
17. To affix a person to a particular group, select Be part of Group on the Teams tab of the respective person.

18. Choose the group the person is becoming a member of and select Be part of. For instance, the person super_user_1 is becoming a member of the group super_user_group.

19. Repeat these steps for the person readonly_user_1 to affix the group readonly_user_group.

Subsequent, you may take away the default position mapping for the customers since you already assigned the roles to their respective teams.

20. On the Function Mapping tab, choose the default position.
21. Unassign the default position for the person by selecting Unassign after which Take away.
22. Repeat these steps for the opposite person.

23. Select Consumer scopes within the navigation pane.
24. Within the Identify column, select role_list.

25. On the Mappers tab, select position listing.

26. Activate Single Function Attribute and select Save.

Obtain SAML metadata from Keycloak

The configuration of Keycloak is now full, so you may obtain the SAML metadata file from Keycloak. The SAML metadata is in XML format and is required to configure SAML within the OpenSearch Service area.

1. Below your realm, select Realm settings within the navigation pane.
2. On the Normal tab, select SAML 2.0 Determine Supplier Metadata below Endpoints.

This can generate an IdP metadata file in one other window. This XML file accommodates data on the supplier, akin to a TLS certificates, SSO endpoints, and the IdP entity ID.

3. Obtain this XML file regionally so you may add this file on the OpenSearch Service console in later steps.

Combine OpenSearch Service SAML with Keycloak

To combine OpenSearch Service with the Keycloak IDP, you should add the IdP metadata XML file on the OpenSearch Service console.

1. On the OpenSearch Service console, navigate to your area.
2. Select Safety configuration, then select Edit.
3. Below Metadata from IdP, select Import from XML file to import the file and auto-populate the IdP entity ID.

Alternatively, you may copy and paste the contents of the entity ID property from the metadata file.

4. For SAML grasp backend position, enter super_user_role.

Which means that a person with this position is supplied supervisor person privileges to the cluster, however can solely use permissions inside OpenSearch Dashboards.

5. Increase the Further settings part
6. For Roles key, enter an attribute from the assertion (in our case, Function) and select Save Modifications.

Take a look at the OpenSearch Dashboards SAML authentication with Keycloak

You’re now prepared to check the SAML integration with Keycloak as an IdP.

1. Select the OpenSearch Dashboards URL supplied on OpenSearch Service console.

It’s going to mechanically redirect you to the Keycloak sign-in web page for authentication.

2. Enter the admin person title (super_user_1) and password and select Signal In.

Upon profitable authentication, it can redirect you to the house web page of OpenSearch Dashboards. In the event you encounter points at this step, seek advice from SAML troubleshooting for widespread points.

Internally, the safety plugin maps the backend position super_user_role to the reserved safety roles all_access and security_manager. Due to this fact, Keycloak customers with the backend position super_user_role are approved with the privileges of the supervisor person within the area. To grant read-only dashboard entry to person readonly_user_1, log in to OpenSearch Dashboards because the person super_user_1. Then map the position readonly_user_role as a backend position for the reserved safety position opensearch_dashboards_read_only.

When establishing entry management for the cluster, it’s essential to rigorously handle the permissions granted to customers, adhering to the precept of least privilege. By having each super_user_role with administrative capabilities and read-only readonly_user_role, you may strike a steadiness. This strategy permits a small variety of trusted customers to have full administrative entry inside OpenSearch Dashboards, whereas additionally enabling read-only entry for different stakeholders who require visibility however don’t want extra entry.

On the time of writing, when you specify the particulars within the Keycloak metadata XML, if you signal out from OpenSearch Dashboards, it can name Keycloak straight and attempt to signal the person out. This doesn’t work at present with a few of the variations of OpenSearch Service, as a result of Keycloak expects the sign-out request to be signed with a certificates that OpenSearch Service doesn’t at present assist. In the event you take away from the metadata XML file, OpenSearch Service will use its personal inside sign-out mechanism and signal the person out on the OpenSearch Service facet. No calls might be made to Keycloak for signing out.

Clear up

In the event you don’t need to proceed utilizing the answer, delete the assets you created:

• OpenSearch Service area
• VPN and Keycloak occasion

Conclusion

On this submit, you realized how one can configure Keycloak as an IdP to entry OpenSearch Dashboards utilizing SAML. To be taught extra about OpenSearch Service and SAML integration, seek advice from SAML authentication for OpenSearch Dashboards. Keep tuned for a sequence of posts specializing in SAML integrations with OpenSearch Service and Amazon OpenSearch Serverless.

Concerning the Creator

Sajeev is a Senior Cloud Engineer (Large Knowledge & Analytics) and a Topic Matter Skilled for Amazon OpenSearch Service. He works carefully with AWS clients to offer them architectural and engineering help and steering. He dives deep into large knowledge applied sciences and streaming options and leads onsite and on-line classes for patrons to design the most effective options for his or her use instances.