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

A typical use case for purchasers is to combine present identification suppliers (IdPs) with Amazon OpenSearch Service. OpenSearch Service provides built-in assist for single sign-on (SSO) authentication for OpenSearch Dashboards, and makes use of SAML protocol. The SAML authentication for OpenSearch Service allows you to combine your present third-party IdPs, similar to Okta, Ping Id, OneLogin, Auth0, ADFS, Azure Lively Listing, and Keycloak, with OpenSearch Service dashboards.

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

Answer overview

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

The sign-in movement consists of the next steps.

1. The consumer 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 consumer to insert their login and password to authenticate.
4. After a profitable authentication, Keycloak generates a SAML authentication response that features authenticated consumer particulars from Keycloak and sends the encoded SAML response to the browser.
5. The browser relays the SAML response to OpenSearch Service Assertion Shopper Service (ACS) URL.
6. OpenSearch Service validates the SAML response. If the validation checks are handed, the consumer is redirected to the entrance web page of OpenSearch Dashboards. The authorization is carried out based on the roles mapped to the consumer.

Conditions

To finish this walkthrough, it’s best to have the next arrange:

• An OpenSearch Service area working OpenSearch or Elasticsearch model 6.7 or later with fine-grained entry management enabled inside a VPC.
• Keycloak put in and configured. On this put up, 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 possibly can have the IdP in a distinct community as properly.
• A correctly configured safety group for OpenSearch Service and Keycloak IdP server to obtain inbound 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 totally different IdP URLs, which is required to configure SAML assist within the Keycloak IdP. Word down the values below Service supplier entity ID and SP-initiated SSO URL. The OpenSearch Dashboards login movement will be configured both as service provider-initiated or IdP-initiated. The service provider-initiated login movement is initiated by OpenSearch Service, and the IdP-initiated login movement is initiated by the IdP (for instance, Keycloak). On this put up, we use a service provider-initiated login movement.

Configure Keycloak as IdP

Throughout the SAML authentication course of, when the consumer is authenticated, the browser receives a SAML assertion token from Keycloak and forwards it to OpenSearch Service. The OpenSearch Service area authorizes the consumer with backend roles based on 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 consumer privileges (for instance, https://<Keycloak server>: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 consumer realm that gives a logical area to handle objects.

4. Within the navigation pane, select your realm, then select Purchasers.
5. Select Create consumer.
6. Within the Basic 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 consumer 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’ve gotten configured the Keycloak IdP consumer for OpenSearch Service, you possibly can create roles, teams, and customers on the IdP facet. For this put up, 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 put up, 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 so that they mechanically inherit group privileges. For this put up, 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 consumer.
14. Below Basic, configure the consumer particulars, together with consumer 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 consumer.
16. Select Add consumer and repeat these steps so as to add your second consumer, readonly_user_1.
17. To hitch a consumer to a particular group, select Be part of Group on the Teams tab of the respective consumer.

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

19. Repeat these steps for the consumer readonly_user_1 to hitch the group readonly_user_group.

Subsequent, you possibly can 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 consumer by selecting Unassign after which Take away.
22. Repeat these steps for the opposite consumer.

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

25. On the Mappers tab, select position checklist.

26. Activate Single Function Attribute and select Save.

Obtain SAML metadata from Keycloak

The configuration of Keycloak is now full, so you possibly can 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 Basic tab, select SAML 2.0 Determine Supplier Metadata below Endpoints.

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

3. Obtain this XML file domestically so you possibly can 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 could 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 possibly can 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 a consumer with this position is offered supervisor consumer privileges to the cluster, however can solely use permissions inside OpenSearch Dashboards.

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

Check 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 offered on OpenSearch Service console.

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

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

Upon profitable authentication, it would redirect you to the house web page of OpenSearch Dashboards. When you encounter points at this step, check with 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. Subsequently, Keycloak customers with the backend position super_user_role are approved with the privileges of the supervisor consumer within the area. To grant read-only dashboard entry to consumer readonly_user_1, log in to OpenSearch Dashboards because the consumer 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 possibly can strike a stability. This method 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, in case you specify the <SingleLogoutService /> particulars within the Keycloak metadata XML, whenever you signal out from OpenSearch Dashboards, it would name Keycloak instantly and attempt to signal the consumer out. This doesn’t work at present with among 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. When you take away <SingleLogoutService /> from the metadata XML file, OpenSearch Service will use its personal inner sign-out mechanism and signal the consumer out on the OpenSearch Service facet. No calls can be made to Keycloak for signing out.

Clear up

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

• OpenSearch Service area
• VPN and Keycloak occasion

Conclusion

On this put up, you realized easy methods to configure Keycloak as an IdP to entry OpenSearch Dashboards utilizing SAML. To be taught extra about OpenSearch Service and SAML integration, check with SAML authentication for OpenSearch Dashboards. Keep tuned for a collection of posts specializing in SAML integrations with OpenSearch Service and Amazon OpenSearch Serverless.

In regards to the Creator

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