DLP SSO: First time setup of SAML authentication
search cancel

DLP SSO: First time setup of SAML authentication

book

Article ID: 276055

calendar_today

Updated On:

Products

Data Loss Prevention

Issue/Introduction

The purpose of this guide is to provide a basic implementation for SAML Authentication.  This document is Identity provider agnostic and provides generic steps.  Each Identity provider may require specific tweaks or fixes.  

Resolution

DLP specific setup:

Required items prior to starting:

  1. IdP Metadata
  2. IdP Signing certificate (public)

NOTE:

This guide assumes you want to use EmailAddress for the nameID and nameID format in the assertion.  this can be modified as needed on step 6.
This guide does not include custom user attributes.  If you need to use other user attributes, you need to uncomment the userAttributes property and fill in the required data on step 6.

    1. Download a copy of the IdP metadata.  This will be obtained from the identity provider

    2. Remove the default idp-metadata.xml from the enforce server and replace it with the downloaded metadata from the previous step.  Default paths below (minus the directory for the dlp version).  The file name is case sensitive and must match exactly
      • Linux: /opt/Symantec/DataLossPrevention/EnforceServer/[VERSION]/Protect/tomcat/webapps/ProtectManager/security/idp-metadata.xml
      • Windows: C:\Program Files\Symantec\DataLossPrevention\EnforceServer\[VERSION]\Protect\tomcat\webapps\ProtectManager\security\idp-metadata.xml

    3. Backup the current springSecurityContext.xml
      • Linux: /opt/Symantec/DataLossPrevention/EnforceServer/[VERSION]/Protect/tomcat/webapps/ProtectManager/WEB-INF/springSecurityContext.xml
      • Windows: C:\Program Files\Symantec\DataLossPrevention\EnforceServer\[VERSION]\Protect\tomcat\webapps\ProtectManager\WEB-INF\springSecurityContext.xml

    4. Replace the current springSecurityContext.xml with the the SAML specific springSecurityContext.xml.  Note the SAML springSecurityContext-SAML.xml file needs to be renamed to springSecurityContext.xml
      • Linux: /opt/Symantec/DataLossPrevention/EnforceServer/[VERSION]/Protect/tomcat/webapps/ProtectManager/security/template/springSecurityContext-SAML.xml
      • Windows: C:\Program Files\Symantec\DataLossPrevention\EnforceServer\[VERSION]\Protect\tomcat\webapps\ProtectManager\security\template\springSecurityContext-SAML.xml

    5. Import the Signing certificate into the DLP samlkeystore.jks
      • Command to import the certificate: keytool -importcert -file /path/to/singing/cert -keystore /path/to/dlp/samlkeystore.jks -alias signing_cert
      • Linux: /opt/Symantec/DataLossPrevention/EnforceServer/[VERSION]/Protect/tomcat/webapps/ProtectManager/security/
      • Windows: C:\Program Files\Symantec\DataLossPrevention\EnforceServer\[VERSION]\Protect\tomcat\webapps\ProtectManager\security\samlkeystore.jks

    6. Edit the springSecurityContext.xml
      • OPTIONAL: specify the NameID and format as required by your IdP.  The format must match exactly what is configured on the IdP
      • OPTIONAL: uncomment and update the "userAttributes" as required by your IdP
      • Update the "entityBaseURL" property to the expected URL or alias that will be used to access the Enforce console. I.e. https://FQDN.domain.tld/ProtectManager

    7. Restart the DLP Enforce Manager service "SymantecDLPManagerService"

    8. Log into the console with the administrator bypass url
      • https://FQDN.domain.tld/ProtectManager/admin/Logon

    9. Update each user with a Valid SAML mapping.
      •  System > Login Management > DLP Users > SAML Name mapping section
      • This is the data you expect your IdP to return in the SAML Response to DLP to validate a user (such as their email address or other user attributes). 
      • This is case sensitive
        • The most common SAML error is that there is a case mismatch or typo in this field.  If the SAML login fails, check the DLP localhost log for the value provided to DLP and compare to the value in this field.  Look for the entry "AuthNResponse" in the DLP localhost log. 

    10. Download a copy of the SP Metadata for your IdP.  
      1. System > Settings > General and navigate to the DLP User Authentication section.  Click the link to the right of the "SAML config file for your IdP"

    11. Provide the DLP metadata file to the IdP to create a valid IdP entry

    12. Once the IdP has been configured with the DLP metadata (also known as the sp metadata) you can attempt to login to the system using SAML. 

Additional Information

Definitions:

Service Provider (SP): Entity providing service.  In our case, this is the DLP Enforce console

Identity Provider (IdP): Entity proving authentication token which will be used by the SP to validate and authenticate user.  (Okta, PingSSO, Azure, ADFS, etc)

SAML Request: SP initiated SAML request to be sent by the SP, to the IdP via the user's browser.  This occurs when the SP redirects the browser to the IdP

SAML Response: IdP initiated SAML response sent by the IdP to the SP.  This contains the Assertions. (in SP initiated SAML, this will be in response to the SAML Request)

NameID: Required information within an assertion to Uniquely identify a user.  I.e. username, email address, or other identifier agreed upon between the IdP and SP.

NameID Format: Specifies the syntax/structure of the NameID value.  It provides a standardized method to express the type or format of the data contained in the nameID

Assertion: Generated by the IdP after a user successfully authenticates to the IdP service.  This is added to the SAML response.  This contains the following information

  1. User Attributes
  2. NameID
  3. Conditions under which the assertion is valid
  4. Digital signature

Assertion Consumer Service: the URL where the assertion is validated.

 

See the below Sequence Diagrams for typical SAML authentication (Not specific to DLP)