Single-SIgn-On for UXI Dashboards on the Greenlake Cloud Platform
UXI is now available for new customers on the Greenlake Cloud Platform (GLP). Check out the article Getting Started with User Experience Insight on the HPE Greenlake Cloud Platform and the Frequently Asked Questions for information.
For new dashboards on Greenlake Cloud Platform, you will configure SSO within to the greenlake cloud platform and not directly in UXI. There are two excellent blog posts here which cover Aruba Central, the same process should be used for UXI.
One important piece of information you will need is the service ID. You can find this greenlake cloud by going to the UXI application in the Greenlake Cloud Platform service catalog and looking for “Service ID” on the right-hand side of the page.
Single-SIgn-On for Existing UXI Dashboards not on the Greenlake Cloud Platform
This article will take you through how to configure SSO on existing dashboards that are not yet on GLP. Please note that you will eventually need to configure SSO again in the Greenlake Cloud Platform when you migrate to the Greenlake Cloud Platform. Migration to the Greenlake Cloud Platform is now available. If you have not configured Single Sign On for your dashboard yet, we recommend not configuring SSO in your UXI dashboard and instead migrating your dashboard to Greenlake Cloud Platform.
You can configure Security Assertion Markup Language (SAML) based Single Sign-On (SSO) for accessing the User Experience Insight dashboard.
How it Works:
Note: By default, a maximum of 100 total users can access the dashboard. If you require more users, please contact your Aruba account representative.
With SAML SSO configured, every login attempt using your email domain will be sent to your SSO identity provider login page. Once approved by the identity provider, you will be able to view the dashboard.
Existing users will keep all the permissions they had before enabling SSO. (admin or read-only).
New users approved by the identity provider are created as read-only users on the dashboard for which SSO is configured.
If a user leaves your organization, the SAML SSO login should fail. It is still recommended to review dashboard users periodically under Settings → Team.
The recommended procedure to configure SAML SSO is:
1. Obtain the SAML configuration and metadata from your Identity Provider (Usually an SSO team in your organization or a 3rd party service provider). You may need to provide them with sample values for entity ID and Reply URL (ACS URL) until step 2 below is complete. For example:
Entity ID - urn:auth0:cape:sso-12345678
Reply URL (Assertion Consumer Service URL) - https://cape.auth0.com/login/callback?connection=sso-12345678
2. Configure the UXI dashboard with the login/logout URLs, domains, certificate and claims
3. Download the metadata from the UXI dashboard and update the identity provider with the correct Entity ID and Reply URL (ACS URL).
How to Configure SAML Single Sign-On.
Step 1: Go to Settings → Integrations and select Configure SSO.
Step 2: Enter Required Information for the Identity Provider (IdP).
• Sign In URL: The SAML single login URL, where your users are redirected to log in
• Sign Out URL (optional): The SAML single logout URL
• Email domain(s): A comma-separated list of domains authorized on your directory
• X509 Signing Certificate: The public key for your identity provider, encoded in PEM or CER (non-binary) format, used to verify the authenticity of the SAML response from your server.
Seep 3: Enter Mapping Information from the Identity Provider (IdP).
The identity provider must provide a mapping of the attributes of the user. The user_id , email , given_name and family_name attributes are required.
For example the attributes mapping from Azure AD might look like this
For example the attributes mapping from Okta might look like this
Usually you can leave the mapping settings tab to the default values. If your identity store doesn’t conform to the default mapping below, you should provide the correct mapping in the mapping settings tab such that the users can be created with the correct information on our system:
{
"user_id":
"http://schemas.xmlso...05/05/identity/claims/nameidentifier",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
],
"email": "http://schemas.xmlso...05/05/identity/claims/emailaddress",
"name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"given_name": [
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
],
"family_name": "http://schemas.xmls...05/05/identity/claims/surname"
}
Step 4: Download the SP XML Configuration File and Save the Connection Specific Configuration to the Identity Provider (IdP)
You will be able to download the configuration in a metadata XML file. This will include the post-back URL (ACS URL), The Entity ID and the certificate used to sign the requests.
Use this information to update the Identity Provider.
Step 5: Verify the Connection
Once the Identity Provider has been configured, you can test the connection by selecting Confirm.
If you click Confirm and you see this same page again, it means the test of SSO was not successful. The most likely cause is either
- The attributes and claims are not configured correctly on the identity provider.
- The identity provider was not updated with the Entity ID or ACS URL in the SP XML configuration file.
Note: If you select Revert, you will remove the SSO configuration. However, the next time you configure SSO there will be a new Entity ID and ACS URL and you will need to update the identity provider with this information.
Step 6: Enable the Connection
If the previous test was successful, you will be able to toggle to enable SSO. SSO is enabled if the toggle is to the right.
SSO Enabled
If you need to disable SSO in the future, simply select the toggle disable or enable again.
SSO Disabled
We have tested the following Identity Providers
Microsoft ADFS
Microsoft Azure AD
Ping Identity
Okta
Others may work but have not been tested.
Current limitations
Role based mapping to sensor groups is not supported
SCIM – System for Cross domain Identity Management is not supported.
If you have multiple dashboards, the dashboard you configure SSO on is the dashboard where read-only users will be created if approved by the identity provider. For any other account users will need to be added manually. An email domain can only be used for one dashboard.
If you are using the dashboard in China, the SSO configuration option is not available.
Examples
Configuring UXI with Azure AD
Configuring UXI with Duo and Okta