CA Single Sign-On and LDAP/AD integration

CA Single Sign-On and LDAP/AD integration

CA Single Sign-On and LDAP/AD integration Legal notice Copyright 2017 LAVASTORM ANALYTICS, INC. ALL RIGHTS RESERVED. THIS DOCUMENT OR PARTS HEREOF MAY NOT BE REPRODUCED OR DISTRIBUTED IN ANY FORM WITHOUT THE WRITTEN PERMISSION OF LAVASTORM ANALYTICS, INC. Apache Hive, Hive are trademarks of The Apache Software Foundation. Apache Spark, Spark, Apache, and the Spark logo are trademarks of The Apache Software Foundation. Microsoft and SharePoint are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. MongoDB and Mongo are registered trademarks of MongoDB, Inc Qlik, Qlik Tech, QlikView and the Qlik Tech logos are trademarks or registered trademarks of Qlik Tech International AB. Salesforce, SALESFORCE.COM and others are trademarks of salesforce.com, inc. and are used here with permission. Tableau and Tableau logo are registered trademarks of Tableau Software, Inc. TIBCO Enterprise Runtime for R are either registered trademarks or trademarks of TIBCO Software Inc. and/or its subsidiaries in the United States and/or other countries. The names of actual companies and products mentioned herein may be trademarks or registered trademarks of their respective owners. Disclaimer No representation, warranty or understanding is made or given by this document or the information contained within it, and no representation is made that the information contained in this document is complete, up to date or accurate. In no event shall LAVASTORM ANALYTICS, INC. be liable for damages or losses of any kind in connection with, or arising from its use, whether or not LAVASTORM ANALYTICS, INC. was made aware of the possibility of such damage or loss. i

CA Single Sign-On and LDAP/AD integration Contact us If you encounter any technical issues, we recommend that you visit the Dataverse Forums at https://help.lavastorm.com/. If your query has not been discussed previously in the forums, you can create a new topic and receive answers from our Dataverse experts. Alternatively, you can log a ticket by emailing support at help@lavastorm.com. Our product is constantly evolving and input from you is highly valued. If you have any suggestions, please contact the product team at product@lavastorm.com. Tip: We recommend that you check our website for the latest documentation as minor updates or improvements may be made to the Help between releases. Note: The images in this help are used purely for illustrative purposes and may display licensedependent functionality. ii

CA Single Sign-On and LDAP/AD integration Table of contents 1. Introduction 1 2. Deployment architecture 2 3. CA Single Sign-On integration restrictions 5 4. SSO and LDAP/AD integration options 6 Local users only - no SSO, no LDAP/AD integration 6 LDAP/AD user authentication, no SSO 6 SSO, no LDAP/AD integration 6 SSO, Dataverse backed by LDAP/AD 7 Timeout options 7 iii

CA Single Sign-On and LDAP/AD integration: 1. Introduction 1. Introduction This document provides an overview of: The deployment architecture of SSO support in this release, see Deployment architecture on page 2. The restrictions of SSO integration with Dataverse, see CA Single Sign-On integration restrictions on page 5. The supported Dataverse integration options with SSO and LDAP/AD, see SSO and LDAP/AD integration options on page 6. 1

CA Single Sign-On and LDAP/AD integration: 2. Deployment architecture 2. Deployment architecture The following points outline the recommended deployment architecture when integrating Dataverse with CA Single Sign-On: Dataverse should be deployed on a machine that sits behind a firewall, which will control access to the application. A SiteMinder Access Gateway (or SiteMinder Secure Proxy Server if using an older version of SiteMinder) should be deployed in a DMZ, and firewall settings should restrict access to Dataverse to the Gateway only. During the installation of Dataverse, there is an option to enable SSO deployment selecting this option performs the necessary setup to allow Dataverse to consume the SM_USER header. It is recommended that you enable HTTPS access to Dataverse (see the topic "Enabling HTTPS" in the integrated product help for more information). After installation, an administrator should sign in to Dataverse (via direct access to the box Dataverse is installed on), to further configure user account creation options, see SSO and LDAP/AD integration options on page 6. 2

CA Single Sign-On and LDAP/AD integration: 2. Deployment architecture The following diagram shows the supported deployment architecture of Dataverse integration with CA Single Sign-On: 3

CA Single Sign-On and LDAP/AD integration: 2. Deployment architecture The following steps describe the authentication sequence as pictured in the diagram: 1. User requests access to Dataverse access is via the Gateway, e.g. https://dataversegateway.com. 2. The Gateway checks for a user session based on any active cookies stored in the user's browser. 3. Assuming there is no active session, then the Gateway challenges the user for their credentials (a login form is displayed to the user). 4. The user enters their credentials and submits the form back to the Gateway. 5. The Gateway then sends through an authentication request to the SiteMinder Policy Server. 6. SiteMinder Policy Server communicates with the Policy Store to authenticate the user. Depending on the SiteMinder setup, it may be backed by a user directory, such as Active Directory. 7. On completion of the authentication request, the Policy Server communicates back to the Access Gateway: a. At this point, if the user is not authenticated, then the Gateway should prevent access to Dataverse. b. If the user is authenticated, continue to step 8. 8. Assuming the user has been authenticated, the Access Gateway then requests the Dataverse Webapplication, in doing this it passes the SM_USER header, which the Dataverse application consumes, and depending on the configuration within Dataverse, Dataverse will check to see if the user defined by the SM_USER header exists in Dataverse: a. If the user does not exist, Dataverse will create the user on demand and allow or deny access. b. If LDAP/AD integration is configured and the user does not exist in Dataverse, Dataverse will look up the user in LDAP/AD, then create the user on demand and allow access. If the user cannot be found in LDAP/AD, access is denied. 9. Assuming the user exists, then access to Dataverse is granted. 10. Access to the Dataverse application is served to the user. 4

CA Single Sign-On and LDAP/AD integration: 3. CA Single Sign-On integration restrictions 3. CA Single Sign-On integration restrictions Applications can be integrated into CA Single Sign-On in a number of ways. The current release of Dataverse only supports integration as described in Deployment architecture on page 2, i.e. access to Dataverse is controlled via a reverse proxy method, either: Integrated to the SiteMinder Access Gateway. Integrated to the SiteMinder Secure Proxy Server (component available in older SiteMinder versions, pre Access Gateway). Note: The current release of Dataverse has been developed and tested against CA Single Sign-On v12.6 using the SiteMinder Access Gateway method. Other types of integrations that are generally available to integrate applications with CA Single Sign-On, which the current release of Dataverse will not support are as follows: Direct install of a SiteMinder WebAgent onto the Tomcat web container that is deployed as part of the Dataverse Server install. Use of the SiteMinder SDK within Dataverse, to directly integrate to a customer's SiteMinder Policy Server. 5

CA Single Sign-On and LDAP/AD integration: 4. SSO and LDAP/AD integration options 4. SSO and LDAP/AD integration options As described in Deployment architecture on page 2 step 8, there are a number of configuration options within Dataverse which define how users are created and how users are authenticated. These options are described in more detail in this section: Local users only - no SSO, no LDAP/AD integration If SSO deployment was not enabled as part of the installation process, and LDAP/AD integration has not been configured, then only locally created Dataverse users will be allowed access to the system. LDAP/AD user authentication, no SSO If SSO deployment was not enabled as part of the installation process, Dataverse can be configured to authenticate users against an LDAP or AD system. Users attempting to sign in with their LDAP or AD credentials must exist in Dataverse, which can be configured to: Automatically synchronize users and groups every x days. LDAP/AD synchronizations can also be initiated manually via the UI. Create users on demand when a user who does not already exist in Dataverse signs in, their details are retrieved from LDAP/AD and then created in Dataverse. There is also the option to configure Dataverse to synchronize user details on every login. SSO, no LDAP/AD integration During installation, if SSO deployment is enabled, then the following logout options can also be configured (these can be updated post install by editing the cust.prop file): Logout button: If the Disable Logout option is not selected, the logout button will be displayed for SSO users, and when clicked will end the Dataverse session and take the user to a pre-configured URL. If the Disable Logout option is selected, the logout button will not be displayed for SSO users. In this scenario, it is expected that logout will be handled via the customer portal/gateway, and that the Dataverse lock timeout setting would be aligned with the portal/gateway session timeout. Logout URL redirect: When the Disable Logout option is not selected (i.e. the logout button is enabled), then during installation there is also the option to enter a URL that users will be redirected to when they log out of Dataverse. For example, this could be a URL on the portal/gateway that invalidates the SiteMinder session and directs them to the login page. 6

CA Single Sign-On and LDAP/AD integration: 4. SSO and LDAP/AD integration options After installation users need to be created in Dataverse, in one of the following ways: Dataverse is configured to create users on demand: If the user does not already exist when the login request comes through, then Dataverse creates the user and assigns a default role (which is set via the UI). Admin users can manually create users in Dataverse, either via the UI or API: In this scenario, if a user logs in and they do not exist, Dataverse will return an invalid response which should be handled by the calling portal/gateway. SSO, Dataverse backed by LDAP/AD Dataverse can be configured to perform user authentication via SSO (see SSO, no LDAP/AD integration on the previous page), and also have the users backed by an LDAP/AD user directory. This creates the following scenario: 1. Users log in via the Gateway. 2. Users can be created in Dataverse in one of the following ways: a. On demand - if the user does not exist in Dataverse, but the user is found in LDAP/AD then they are created based on their LDAP/AD details. Optionally, Dataverse can be configured to always synchronize the user details on every login. b. Via a manual or automated sync of LDAP/AD users. Timeout options Dataverse implements the following two timeout options: Session timeout - When a user has been inactive for a configured period of time, the user is logged out and their session is ended. In this case, the user is presented with a session timeout screen, where they can sign back in to the Dataverse Directory page. Lock timeout - For use when Dataverse is integrated with SSO, to align with the gateway timeout. When a user has been inactive for a configured period of time, the user is locked out and presented with a lock screen, but their session remains active. This prevents the exposure of data within the application, but allows the user to sign back in to resume their work from where they left off, if their gateway session is still valid. 7

2017 LAVASTORM ANALYTICS, INC. www.lavastorm.com Contact support: help@lavastorm.com Document ID: DV-SSO-S1 Date of publication: Tuesday, July 4, 2017