Setting Up SSO SAML 2.0 With Azure AD
Introduction This article explains how to set up SAML 2.0 integration between Sisense and Azure AD. For more information about SSO in Sisense see Introduction to SSO SSO via SAML 2.0 By default, Sisense supports Forms Authentication only. Starting from the L2021.11 version, you can also enable support for Windows Authentication and MFA. For more details, contact the Sisense support team. Configuration on Azure side Log in to your Azure account. Expand the left-hand menu: Go to Azure Active Directory Select Enterprise applications: Under the All Applications section, select New application: Create your own application for ‘Integrate any other application you don’t find in the gallery’ purpose, name it Sisense: Under Overview > Assign users and groups, configure access permissions for your SSO integration. Once configured, go back to Overview and switch to Set up single sign-on: Select SAML type of the SSO: Edit Basic SAML Configuration with the following settings: Name Value Identifier (Entity ID) Sisense Reply URL (Assertion Consumer Service URL) https://my.sisense.com/api/v1/authentication/login_saml_callback/ * replace my.sisense.com with your Sisense URL Note Azure allows HTTPS format only for Reply URL. To configure HTTPS in Sisense, see Setting Up SSL for Sisense. If you configure the integration in the Sisense test environment without SSL, you can set HTTP reply URL directly in the manifest of the SAML application, reference. Once saved, go to Edit User Attributes and claims. 10. Use Add New Claim to add the following attributes 11. Optional. Add a New Group Claim as per screenshot: Your Azure AD needs to be synchronized with on-premise Microsoft Active Directory to use this claim. See more details in Configure group claims for applications with Azure Active Directory. 12. Return back to the Single Sign-On page and copy the following parameters: Azure AD additional info In the latest versions of Sisense, it is required to fill the Relay State field in, it is marked as optional at provider side: RelayState is a parameter that identifies a specified destination URL your users will access after signing in with SSO. In case of Sisense, it could be a path to the main page: “https://my.sisense.com/app/main#/home” Configuration on Sisense side Go to Admin tab > Single-Sign On. Select SAML, turn the toggle on. Use parameters from Step 12 above: Remote Login URL = Login URL Remote Logout URL = Logout URL Public X.509 Certificate = Content of Certificate (Base 64) file (you can open it with a text editor) 3. Configure claim names according to your config in Azure AD. If you created a group claim in Azure SAML app, choose Define by Group and enter memberOf as the Group Claim name.Setting Up SSO SAML 2.0 with Okta
Okta provides secure identity management and single sign-on to applications that you can add to your Okta account. From Okta, you and your users can log in to Okta and then access applications such as Sisense without having to log in to each application. Okta supports applications that support SAML 2.0, such as Sisense. This page describes how to add Sisense to Okta and configure SSO-support with SAML 2.0. Note: This page reflects a 3rd party’s application which may change. If the steps described here do not match what you see in your Okta account, you can use the generic Sisense SAML documentation, along with the IdP’s documentation. Adding Sisense to Okta To add Sisense to Okta: Log in to Okta. In the menu bar, click Applications -> Browse App Catalog. In the Search field enter Sisense and choose Sisense SAML app. Then click Add Integration. Put Sisense application URL in Base URL and press Done. Sisense is added to your Apps. After you configure SAML 2.0 for Sisense, you can click this application in Okta to launch your Sisense dashboard. Configuring SAML 2.0 for Sisense To configure SAML 2.0: Under the Applications tab, select Applications. In the Applications page, click Sisense. In the Sisense app menu bar, click the Sign On tab -> Edit. Okta’s setup instructions are expanded. Click More Details to get your SSO information which Sisense needs to configure SSO. From the Okta setup instructions, copy the Remote Login URL, Remote Logout URL, and Download Signing Certificate. In the Sisense Web Application, select Single Sign On under the Admin tab. In the Single Sign On page, activate SSO. In the Remote Login URL, Remote Logout URL, and Public X-509 Certificate fields, enter your Okta SSO details into the relevant fields described in Step 4 of this procedure. Click Save. The Okta users you assigned to the Sisense application can access Sisense through Okta without having to log in to Sisense directly.Setting Up SSO SAML 2.0 with OneLogin
OneLogin is a single sign-on service where its users only have to enter one set of credentials to access their web apps in the cloud and behind the firewall, including Sisense. OneLogin’s policy-driven password security and multi-factor authentication ensure that only authorized users get access to your dashboards. This page describes how to add Sisense to OneLogin and configure SSO-support with SAML 2.0. Note: This page reflects a 3rd party’s application which may change. If the steps described here do not match what you see in your OneLogin account, you can use the generic Sisense SAML documentation, along with the IdP’s documentation. Adding Sisense to OneLogin OneLogin provides access to online applications through their centralized portal. To access Sisense from OneLogin, you need to create a OneLogin app. Your users can then authenticate through OneLogin and then be redirected to the Sisense Web Application. This procedure explains how to add Sisense to your OneLogin account and then configure Sisense SSO with your OneLogin settings. To add Sisense to your OneLogin configuration: Create a sub-domain account at https://www.onelogin.com. This account is a subdomain for your account. For example, Sisense would be www.sisense.onelogin.com. In your OneLogin sub-domain account, and select Apps > Add Apps. In the Search field, enter SAML Test Connector (IdP w/ attr w/ sign response). As you begin typing, the relevant results are displayed, make sure that you select the correct result. You can keep this name for your app, or define a new name in the Display Name field. The name you enter is the name displayed to your Onelogin SSO users. Click Save. You are redirected to your app’s Settings page. Select the Users tab. In the Users tab, verify that your users are listed. If not, select Users > All Users. Click the relevant user’s name to add the application to their account. When you click their name, the user’s settings are displayed. In the Applications page, select + > New app. Select your new app from the list and click Continue > Save. Select APPS > Company Apps. From the list, select your app. Select the SSO tab to display your SSO settings. In the SSO tab, your SSO details that you need to provide Sisense are displayed. Copy the highlighted fields into the Sisense SSO page. You can access this page in the Sisense Web Application by selecting Admin > Single Sign On > Edit > Select Saml 2.0, then enter the following information: X.509 Certificate: Click View Details to see your certificate. Copy the certificate and paste into the Public X.509 Certificate area as shown in below. SAML 2.0 Endpoint (HTTP): Copy and paste this into the Remote Login URL field in the Sisense Single Sign page. SLO Endpoint (HTTP): Copy and paste this into the Remote Logout URL field in the Sisense Single Sign page. 16. In the Sisense Single Sign page, click Save. The OneLogin users you assigned to the Sisense application can access Sisense through OneLogin without having to log in to Sisense directly. Users who access any of the web pages on your Sisense server will be redirected to OneLogin for authentication.Setting Up SSO SAML 2.0 with Salesforce
This page describes how to add Sisense to Salesforce and configure SSO-support with SAML 2.0. Note: This page reflects a 3rd party’s application which may change. If the steps described here do not match what you see in your Salesforce account, you can use the generic Sisense SAML documentation, along with the IdP’s documentation. Login to your Salesforce account. Set up a domain to your Salesforce account https://help.salesforce.com/articleView?id=domain_name_setup.htm&type=0 Enable Salesforce as an Identity Provider https://help.salesforce.com/articleView?id=identity_provider_enable.htm&type=0 From Setup, enter Apps in the Quick Find box, then select Apps. In the Connected Apps pane, click the New button. Fill required fields with the following information: Connected App Name - choose any Contact number - choose any Choose Enable SAML Entity Id - Sisense ACS URL - https://yourSisensedomain.com/api/v1/authentication/login_saml_callback/ Change Idp certificate to the SelfSignedCertificate From Setup, Enter Connected Apps in the Quick Find box, then select Connected Apps. Select SisenseApplication. In the Manage Profiles panes - add users that will have access to the application In Custom Attributes - Add Attribute key User.email with $User.Email value Copy IdP-Initiated Login URL paste it to Sisense Remote Login URL Download Idp Certificate - paste it to Public X.509 Certificate in Sisense Use notepad to open certificate, save lines starting from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- On the Sisense SSO page add Remote Login URL and Certificate saved in the previous step Click Save. Users who access any of the web pages on your Sisense server will be redirected to Salesforce authenticationSetting Up SSO SAML 2.0 with Auth0
Auth0 is a service that abstracts how users authenticate to applications. From Auth0, you and your users can log in to Auth0 and then access applications such as Sisense without having to log in to each application. Auth0 supports applications that support SAML 2.0, such as Sisense. This page describes how to add Sisense to Auth0 and configure SSO-support with SAML 2.0 by creating an Auth0 app and connecting it to Sisense. Note: This page reflects a 3rd party’s application which may change. If the steps described here do not match what you see in your Auth0 account, you can use the generic Sisense SAML documentation, along with the IdP’s documentation. Connecting Sisense to Auth0 To connect Sisense to Auth0: Log in to your Auth0 account. Select Clients from the left menu. Click CREATE CLIENT. In the Name field, enter a name for your app and select Regular web applications. Click Create. In your app’s homepage, open the Addons tab and enable the SAML 2.0 Web app. The Addon: SAML2 Web App window is displayed. In the Application Callback URL field, enter http s :// domain_name /api/v1/authentication/login_saml_callback/ , replace domain_name with your domain. In Auth0, select Addons and then click SAML2. Replace "Settings" with: { "nameIdentifierProbes": [ "http://schemas.xmlsoap.org/ ws/2005/05/identity/claims/emailaddress" ] } Click Save. Close the Addon: SAML2 Web App window and then open the Settings tab. Click Show Advanced Settings. Open the Certificates tab and copy the Signing Certificate. In the Sisense Web Application, select the Admin>Single Sign On. In the Single Sign On page, enable SSO and click Edit. Paste the Signing Certificate you copied in Step 11 and paste it in the Public X.509 Certificate field. In Auth0, open the Endpoints tab, and copy the value of the SAML Protocol URL field. In the Sisense Web Application, paste the SAML protocol into the Remote Login URL field and click Save. Users who access any of the web pages on your Sisense server, will be redirected to Auth0 for authentication.SSO Role and Group management
Setting up SSO often comes with a need to set up Group and Role for a new user. Sisense provides two alternative solutions for Group and Role Management: Use Defaults: Every new user is assigned default roles. This is only relevant for new users and it doesn’t override existing roles or groups starting from L2021.3. Define by Group: Define users based on group roles. Select this option if you have defined what group a new user should be assigned to through a Group claim. The main different is that Define by Group option will validate user groups and assign role dynamically on every log in. This means that if user role or group was changed manually the next time user is authenticated the changes will be reverted, groups and role will be set to the same as in Identity Provider. Therefore you should either chose the strategy of assigning groups and roles manually (Use Defaults) or rely on Identity Provider groups completely (Define by Group) and set up the roles for groups leaving the rest to Sisense. Let's review this within the following example: We have a system where SSO is already set up and now we want to define the role and groups to our new users. First scenario is we want all new users to be Viewers and have New users group: Once the first user is created via SSO his role will be set to Viewer and user will be automatically included in New Users group. But what if we want to make this user a Designer or Admin and maybe remove the user from New users group? We can do that manually from the Users page as per usual. The next time user is authenticated via SSO his role and groups will remain untouched. But what if we want to bring groups user belongs to alongside? In that case we will need to switch to Define by Group: The first time user is created via SSO he will be added to the groups found in Groups claim and his role will be chosen by the highest Default Role: So we have a new user created and the highest Role for his groups is Designer, but what if we want to make this particular user an Admin? Even though we can still go to the User page and change the user Role and Groups this is not the way to achieve this. The next time user is authenticated via SSO his Groups will be validated against Groups in Identity Provider (via the Groups claim) and all our changes will be overwritten. So what is the recommended approach in this case? We can simply create a new group in our Identity Provider and Sisense and assign the Admin Default Role for this group. The next time user is authenticated via SSO the groups will be synced and highest role will be assigned - Admin role. Note, we can always disable the logic that validates user Role/Group on SSO authentication: In this case new user cannot not be created via SSO authentication which means we either need to create such user manually/using REST API or have our system available for existing users only.Setting Up SSO SAML 2.0 With ADFS
Topics covered: ADFS SAML - introduction Prerequisite configuration for ADFS 2.0 and ADFS 3.0 Adding Sisense as Service provider to ADFS Claim configuration for Sisense in ADFS NameID claim and transformation rule for the latest Sisense versions Claim configuration for previous Sisense versions Sending ADFS groups for the Sisense user. “MemberOf” property. Exporting ADFS certificate Configuring Sisense SSO SAML on Admin panel Troubleshooting ADFS Error on ADFS side #1 Issue: Sisense application redirects to the ADFS page with errors and not redirects to Sisense #2 Issue: User prompted for a username and password two times when access from an intranet. Error on Sisense side #3 Issue: After successful login into ADFS Sisense redirects to the login page #4 Issue: For a new user: after a successful login into ADFS Sisense redirects to the login page, but the user was created in the Sisense app. Next login through ADFS successful ADFS SAML - introduction ADFS is a standards-based service that allows the secure sharing of identity information between trusted business partners (known as a federation) across an extranet. When a user needs to access a Web application from one of its federation partners, the user's own organization is responsible for authenticating the user and providing identity information in the form of "claims" to the partner that hosts the Web application. The hosting partner uses its trust policy to map the incoming claims to claims that are understood by its Web application, which uses the claims to make authorization decisions. To find out more about ADFS please check: https://msdn.microsoft.com/en-us/library/bb897402.aspx 1. Prerequisite configuration for ADFS 2.0 and ADFS 3.0 For ADFS 2.0, you must install update KB2681584 (Update Rollup 2) or KB2790338 (Update Rollup 3) to provide RelayState support. ADFS 3.0 has RelayState support built in. In both cases RelayState still needs to be enabled. Use the following steps to enable the RelayState parameter on your ADFS servers: For ADFS 2.0, open the following file in Notepad: %systemroot%\inetpub\adfs\ls\web.config %systemroot%\inetpub\adfs\ls\web.config For ADFS 3.0, open the following file in Notepad: %systemroot%\ADFS\Microsoft.IdentityServer.Servicehost.exe.config %systemroot%\ADFS\Microsoft.IdentityServer.Servicehost.exe.config In the microsoft.identityServer.web section, add a line for useRelayStateForIdpInitiatedSignOn as follows, and save the change: <microsoft.identityServer.web> ... <useRelayStateForIdpInitiatedSignOn enabled="true" /> ... </microsoft.identityServer.web> <microsoft.identityServer.web> ... <useRelayStateForIdpInitiatedSignOn enabled="true" /> ... </microsoft.identityServer.web> For ADFS 2.0, run IISReset to restart IIS. For both platforms, restart the Active Directory Federation Services (adfssrv) service. If you're using ADFS 3.0 you only need to do the above on your ADFS 3.0 servers, not the WAP servers. 2. Adding Sisense as Service provider to ADFS 1. Open the AD FS 3.0 Management Console and select [Add Relying Party Trust] to start the Add Relying Party Trust Wizard. Click Start. 2. Select “Enter date about the relying party manually” and click [Next]. 3. Specify a display name of your choice and click [Next]. 4. Select "AD FS profile" and click [Next]. 5. Just click [Next] on the Configure Certificate Page 6. Select “Enable support for the SAML WebSSO protocol” and configure the URL to the SAML plugin URL as a Relying party SAML SSO service URL. This URL has the following format https://<Sisense domain>/api/v1/authentication/login_saml_callback/ Click [Next]. 7. Enter Sisense as a "Relying party trust identifier" and click [Add] to add it to the list. Click [Next]. 8. Select “I do not want to configure multi-factor..”. Click [Next]. 9. Select "Permit all users to access the relying party" and click [Next]. 10. Just click [Next] on the next page, tick "Open the Edit Claim Rules dialog" and click [Close]. 11. The Edit Claim Rules window opens. In the first tab, click [Add Rule]. 3. Claim configuration for Sisense in ADFS 3.1. NameID claim and transformation rule for the latest Sisense versions 12. Select "Send LDAP Attributes as Claims" and click [Next]. 13. Enter "User.email" as the name of the rule. Select "Active Directory" as the Attribute store. Select the "LDAP Attribute" containing "E-Mail-Addresses" and "E-Mail-Addresses" as "Outgoing Claim Type". Click [Finish]. 14. Click [Add rule]. 15. Select "Transform an Incoming Rule" as a "Claim rule template". Click [Next]. 16. Configure rule as per the table below: Parameter Value Claim rule name EmailToNameID Incoming claim type E-Mail Address Incoming name ID format Unspecified Outgoing claim type Name ID Outgoing name ID format Email Mode Pass through all claim values 17. Click [Finish]. 3.2. Claim configuration for previous Sisense versions For the Sisense Windows versions > 6.7 and < 8.2.1, or Sisense Linux version < L8.0.4, add two claim rules and two transformation rules 12. Select "Send LDAP Attributes as Claims" and click [Next]. 13. Enter a name of your choice for the rule. Select "Active Directory" as the Attribute store. Select the "LDAP Attribute" containing "E-Mail-Addresses" and "User.email" as "Outgoing Claim Type". Click [Finish]. Add a similar configuration in another rule specifying "nameID" as "Outgoing Claim Type". Result: 14. Add two more custom rules rule by clicking [Add Rule]. 15. Select "Send Claims Using Custom Rule". Click [Next]. 16. Specify "Step1" and "Step2" as claim rule names and enter the respective custom rule code. Create 2 rules called Step1 & Step2: Custom Rule for Step1: c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress"); Custom Rule for Step2: c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress"); Keep Rules for Step1 and Step2 in the correct order. Result: Using proxy handler for ADFS 3 (Sisense Windows < 6.7 version) 12. Select "Send LDAP Attributes as Claims" and click [Next]. 13. Enter a name of your choice for the rule. Select "Active Directory" as the Attribute store. Select the "LDAP Attribute" containing "E-Mail-Addresses" and "User.email" as "Outgoing Claim Type". Click [Finish]. Add a similar configuration in another rule specifying "nameID" as "Outgoing Claim Type". Result: 14. ADFS requires a different structure of the SAML Request than the one used by Sisense Windows < 6.7 versions. For this purpose, you can use a proxy handler. The handler will rebuild the SAML XML request per the ADFS requirements. ! Starting from Sisense > 6.7 ADFS can be configured without an additional handler, please check more details in For the Sisense Windows versions > 6.7 and < 8.2.1, or Sisense Linux version < L8.0.4, add two claim rules and two transformation rules. Download handler for Sisense < 6.7 Download handler for Sisense >= 6.7 You can modify the handler that builds a new SAML Request per your needs in order to keep the correct communication with your ADFS provider. Put the Handler to the different IIS Web Site (not Sisense), replace DestinationADFSUrl with your ADFS server address. Original SAML Workflow More details: https://documentation.sisense.com/sso-via-saml-2-0/ SAML Workflow with ADFS Handler 4. Sending ADFS groups for the Sisense user. “MemberOf” property. In addition, ADFS can be configured to send user groups in the memberOf property. When the user logs in through ADFS, if the user does not exist in Sisense, Sisense creates a new user. When Sisense creates a new user, Sisense analyzes the “memberOf” field to locate one or more groups related to the logged-in user. User will be created with the groups sent from the ADFS in case if these groups were previously created in Sisense. In ADFS, create Claim Rule (names or SIDS) : ADFS will send to Sisense the list of the user’s groups in the XML Response: 5. Exporting ADFS certificate The SAML response coming from ADFS is signed to ensure that the authentication is coming from the correct Identity Provider In the ADFS management console, click the Certificates folder and double-click on the Token Signing certificate. 2. Click the Details tab and the Button [Copy To File]. Export the certificate as Base-64 encoded X.509 (.CER) Open the exported file in a text editor and copy the content to use it in your Sisense application 6. Configuring Sisense SSO SAML on Admin panel Use the previously saved certificate. In the “Single Sign-On” tab on the “Sisense Admin” panel: - Select SAML mode, enable SSO toggle - Edit configuration and paste Public X.509 Certificate - For the Remote Login URL specify "https://<adfs domain>/adfs/ls/idpinitiatedsignon.aspx". If you use a custom handler, then specify the URL address of the handler. 3. Save configuration Troubleshooting ADFS In case if you can’t find some of the issues here, please check Sisense logs and ADFS logs and check additional information on microsoft.com help pages. Error on ADFS side: #1 Issue: Sisense application redirects to the ADFS page with errors and not redirects to Sisense Investigation: Check ADFS errors in the Windows event viewer. Error 1: Error 2: Error 3: Case: ADFS can’t parse XML Request / Issues with configurations / Wrong Assertion Consumer URL Solution: Error 1: Verify that you applied correct version of ADFS handler Error 2: Set correct Incoming rules for Sisense > version 6.7 Error 3: Verify that Assertion Consumer URL in ADFS config matches URL in Error. ADFS supports only https URL, make sure you are accessing Sisense from https. #2 Issue: User prompted for a username and password two times when access from an intranet. Hotfix from Microsoft: https://support.microsoft.com/en-us/help/3018886/you-are-prompted-for-a-username-and-password-two-times- when-you-access Case: If multi-factor authentication deployed on ADFS. Solution: If hotfix didn’t help, please remove lines in ADFSHandler for your Sisense version that sets authentication suggestions: xw.WriteStartElement("samlp", "RequestedAuthnContext", SAML_NS_PROTOCOL); xw.WriteAttributeString("Comparison", "minimum"); xw.WriteStartElement("saml", "AuthnContextClassRef", SAML_NS_ASSERTION); xw.WriteString("urn:federation:authentication:windows"); xw.WriteEndElement(); xw.WriteStartElement("saml", "AuthnContextClassRef", SAML_NS_ASSERTION); xw.WriteString("urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"); xw.WriteEndElement(); xw.WriteEndElement(); // RequestedAuthnContext Errors on Sisense side #3 Issue: After successful login into ADFS Sisense redirects to the login page Investigation: Check Sisense logs, search the logs which contain the word SAML. C:\ProgramData\Sisense\PrismWeb\Logs\nodejsLogs.log C:/Program%20Files/Sisense/PrismWeb/vnext/iisnode/index.html Case: Error message in logs: Error 1: [ERROR] [baseMongo]: [SAML authentication with incorrect credentials] Error 2: SAML authentication with incorrect credentials Error: SAML assertion expired Solution: Error 1: Verify that Public X.509 Certificate in SSO page in Sisense app matches certificate in ADFS. Error 2: Verify that both servers have synced clocks server Sisense and ADFS. #4 Issue: For a new user: after a successful login into ADFS Sisense redirects to the login page, but the user was created in Sisense app. Next login through ADFS successful Investigation: Verify Sisense logs Check Admin page with Rest API, version 0.9: Run the GET /branding API call: Copy the result you get, and remove all parameters which their values are “string” or wrong path, for example: Case: Sisense branding was saved with incorrect paths to the templates or any other sources Solution: After removing/fixing paths, paste it in the body of the POST /branding API call and run it:
