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.
DLP specific setup:
Required items prior to starting:
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.
keytool -importcert -file /path/to/singing/cert -keystore /path/to/dlp/samlkeystore.jks -alias signing_cert
samlkeystore.jks
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
Assertion Consumer Service: the URL where the assertion is validated.
See the below Sequence Diagrams for typical SAML authentication (Not specific to DLP)