Configuring SAML 2.0 based authentication with trusted Identity Provider

Article: 100049469
Last Published: 2022-10-10
Ratings: 1 0
Product(s): eDiscovery Platform

Description

Starting with release 9.5.2, eDiscovery Platform supports a new way for enterprise Single Sign-On (SSO) authentication with SAML 2.0 compliant Identity Provider (IdP).
With SAML protocol, an Identity Provider (IdP) authenticates users and provides the authenticated user identity information to a Service Provider (SP). The IdP authenticates the users once and then allows access to multiple applications and services without additional sign-ins. Most modern IdP also support multi-factor authentication (MFA). Support for SAML 2.0 is more commonly used to help enterprise users sign in to multiple applications using single login.
Note: For enhanced security, eDiscovery Platform Server forces the user to authenticate again from IDP by default. This behavior can be customized to not force a user to re-authenticate again for eDiscovery Platform Server if they have already authenticated with the IDP once.
The Service Provider does not directly interact with the Identity Provider as a browser carries out all the redirections. A user presents the authentication details directly with the trusted IDP, and those will never be shared with the Service Provider at any stage.
Note: eDiscovery Platform Server does not need to have direct access to the internet, to be able
to integrate with trusted IdP.

To set up SAML 2.0 based authentication with trusted Identity Provider (IDP):
The properties to enable SAML-based authentication are set using the Property Browser Support Feature. All property changes related to enterprise authentication should be made using the Property Browser. The Property Browser automatically updates the appliance each time you add a new property.
Perform the following steps to set up the SAML-based authentication:

  1. Register a new application in Identity Provider with the details about eDiscovery Platform Server
  2. Configure the required properties in eDiscovery Platform

Note: In a Distributed Architecture environment, all of these steps must be performed on each eDiscovery Platform server.

Step 1: Register a new application in Identity Provider with the details about eDiscovery Platform Server

eDiscovery Platform works with several Identify Providers, such as okta, Microsoft Azure, AWS, and so on. The following steps use the okta IdP; the steps to register a new application in Identity Provider vary based on the IdP you use.

  1. Sign in to the Identity Provider administrator portal.
  2. Register New Application. During the application registration, if asked, provide the following details:

A. Name of the App: Veritas eDiscovery Platform

B. Platform: Web based

C. Sign On Method: SAML 2.0

D. Single sign on URL OR ACS URL: https://<your-eDP-server-name-here>/esa/public/SamlSpAssertionConsumer

 Note: The URL specifies the location where the SAML assertion is sent by the IDP with a HTTP POST. This is often referred to as the SAML Assertion Consumer Service (ACS) URL of the application. This value is needed when you set the esa.saml.sp.acsUrl property as listed in Step 2.

E. Audience URI (SP Entity ID) or Issuer: https://<your-eDP-server-namehere>/

Note: It specifies the application-defined unique identifier that is the intended audience of the SAML assertion. This is most often the SP Entity ID of the application. This value is needed when you set the esa.saml.sp.entityid.issuer property as listed in Step 2.

F. Application username or User name in assertion’s subject Statement. It indicates the email address of the user.

Note: Ensure that the Response configuration is such that the “SAML Response” and the “Assertion in the response” must be signed using Signature Algorithm "RSA-SHA256".

Note: The user returned by SAML Assertion Response is mapped to an eDiscovery Platform user. The eDiscovery Platform user of type "Local" user is supported. Starting from version 10.1.4, the eDiscovery Platform user of the type "Enterprise" is also supported.

Note: eDiscovery Platform currently does not support automatic configuration for SAML using MetaData URL. All the configuration details need to be configured manually.

3. Once the application is registered, note down the following values of the registered application:

A. Identity Provider Single Sign-On URL value: The location where the SAML request will be sent to the IdP with a HTTP POST. This value is needed when you set the esa.saml.idp.ssoDestUrl property as listed in Step 2.

B. Identity Provider Issuer value: The unique identifier of the registered application in IDP, that is the intended source who sends the SAML assertion. This is most often the IDP Entity ID of the application. This value is needed when you set the esa.saml.idp.entityid.issuer property as listed in Step 2.

C. Download the certificate of your registered application, and save the cert file somewhere on your eDiscovery Platform server. If multiple formats of the certificate are presented for download by the IDP, then choose the Base64 Certificate format for download.

For example: D:\eDP\IDPCert\okat.cert

The path of IdP Cert file, located on eDiscovery Platform server.

This value is needed when you set the esa.saml.idp.certificateCerFile.Path property as listed in Step 2.

4. Assign permissions to all the required users who should be allowed to access eDiscovery Platform.

Note: A matching user account with the same user name must exist in the eDiscovery Platform server for the SSO to work.

Step 2: Configure the required properties in eDiscovery Platform

1. Using an account with System Management permissions, log onto the eDiscovery Platform web interface.

2. From the System > Support Features, select the Property Browser.

3. Using the Property Browser, configure the required set of properties to enable SAML 2.0 based authentication with trusted Identity Provider (IdP).

– Property: esa.saml.sp.acsUrl

Value: The value for this property must be the same as the value mentioned in step 2d above.

– Property: esa.saml.sp.entityid.issuer

Value: The value for this property must be the same as the value mentioned in step 2e above.

– Property Name: esa.saml.idp.ssoDestUrl

Value: The value for this property must be the same as the value mentioned in step 3a above.

– Property Name: esa.saml.idp.entityid.issuer

Value: The value for this property must be the same as the value mentioned in step 3b above.

– Property Name: esa.saml.idp.certificateCerFile.Path

Value: The value for this property must be the same as the value mentioned in step 3c above.

You might need to configure the following optional properties in specific scenarios:

– Property Name: esa.saml.sp.samlAuthRequest.forceAuthentication

Value: By default, the value is set to true, which indicates that the user should be forced to authenticate every time with IDP when they access the eDiscovery Platform web application.

If the value is set to false, the user will be asked to login only once with IDP to access all supported application including eDiscovery Platform.

For example, if the user has already authenticated with IDP once to access some application, and now when that user opens another tab in the same browser, and try to access eDiscovery Platform web application, the user will not be forced to log-in again with IdP, and will be signed in to eDiscovery Platform directly.

– Property Name: esa.saml.idp.samlResponse.useridAssertion.AttributeName

Value: IdP lets the SP know who the authenticated user is under the “subject” section of SAMLResponse XML data.

The value of the subject is generally in text format. In this case, it is not required to set the value of this property explicitly, as the default value is “subject”.

However, some IdP send the asserted user identity in non-text format; for example, in “transient” or “persistent” name-ID format. Such value cannot be used by eDiscovery Platform to map that user with eDiscovery Platform user. In such a case, IdP can be configured to return additional information about the authenticated user using “attribute statements”. Under such a scenario, the value of this property should be set with the exact “AttributeName” string, using which eDiscovery Platform matching username value is being sent by the IdP. Contact Veritas Support for more help.

Note: Once these properties are set, the eDiscovery Platform services must be restarted to take effect.

4. Enable SAML authentication by setting esa.saml.enabled to true.

By default, the value is set to false which sets SAML disabled by default.

Note: Before you set the value to true to enable SAML authentication, ensure that all properties listed in the step 3 are set. Also, eDiscovery Platform server must be configured to be accessed via HTTPS protocol.

Integration with dynamic groups of SaaS identification management platform

Starting with eDiscovery Platform 10.1.2, SAML 2.0 based authentication has following enhancements:    

  • eDiscovery Platform supports auto user creation. By default, this feature is disabled for security reasons. If enabled and configured, the feature can create new user, assign the configured or default roles and cases, based on the group or department user belong to as per the identity provider. 
  • You can configure eDiscovery Platform to map the user by matching the email address of the user, instead of username. To enable this, set the following property: esa.saml.idp.email.login.support to true 

Steps to configure SAML to integrate with dynamic groups of SaaS identification management platform:

Step 1: Configure the SAML assertion attributes and claims settings of the registered app in identity provider to return the following:

  • Additional Claim Name: “FullName”, Value to Return:  Display name of the user
  • Additional Claim Name: “Email”, Value to Return: Email Address of the user
  • Additional Claim Name: “UserId”, Value to Return:  User Id by which this user is known in IdP, for example this could be ObjectID of User (or Employee ID)
  • Additional Claim Name: “MemberOfGroup”, Value to Return:  This value should return the group or department name that the user belongs to (and using which user has access to registered app).

Note: The first three values will be used to create local new user in eDiscovery Platform. While the “Member of Group” value is used later to determine the default role and cases which should be assigned to the new user.

Step 2: Configure the default role and cases for each group or department as per following templates:

Template Properties:

esa.saml.createUnknownUsers.config.<GroupID>.GroupOrDeptName: <name of Group or Department>

esa.saml.createUnknownUsers.config.<GroupID>.DefaultRole:  <Role Name>

esa.saml.createUnknownUsers.config.<GroupID>.DefaultCases:  <Comma separated case names>  (or special string "<all-cases>")

Example: If there is a group (or dynamic group) which has been assigned permission to registered app at IdP level.

Group 1: Fire Department, Object ID of Group in IdP:  d6a06a1b-428a-4235-a15d-dafd1a09fbfb

Note: The ObjectID of Group is important due to security reasons. Few IdPs (for example Azure) does not return the Display Name of the group. They instead return the ObjectID value of the Group to indicate the group.

In above case, the admin needs to set following properties (as per template shown earlier):  

  • esa.saml.createUnknownUsers.config.d6a06a1b-428a-4235-a15d-dafd1a09fbfb.GroupOrDeptName: FireDept
  • esa.saml.createUnknownUsers.config.d6a06a1b-428a-4235-a15d-dafd1a09fbfb.DefaultRole: Case User
  • esa.saml.createUnknownUsers.config.d6a06a1b-428a-4235-a15d-dafd1a09fbfb.DefaultCases: Case One, Case Two

Step 3:  Set the following property to enable the feature:

esa.saml.createAccountForUnknownUsers to true

After these settings, suppose that a new user joins an organization and belongs to Fire Department as per IdP. When the user attempts to login, eDiscovery Platform auto-creates a new local user and assigns role of “Case User” on following cases “Case One, Case Two” (as per above example).

Was this content helpful?