About SAML single sign-on (SSO)

To implement SAML single sign-on, see Configure SAML single sign-on or Configure SAML single sign-on with Azure Active Directory.

What are SAML and single sign-on?

Security Assertion Markup Language (or SAML) is an open authentication standard that allows for the secure exchange of user identity information from one party to another. SAML supports single sign-on, a technology that allows for a single user login to work across multiple applications and services. For Deep Security, implementing SAML single sign-on means that users signing in to your organization's portal would be able to seamlessly sign in to Deep Security without an existing Deep Security account.

How SAML single sign-on works in Deep Security

Establishing a trust relationship

In SAML single sign-on, a trust relationship is established between two parties: the identity provider and the service provider. The identity provider has the user identity information stored on a directory server. The service provider (which in this case is Deep Security) uses the identity provider's user identities for its own authentication and account creation.

The identity provider and the service provider establish trust by exchanging a SAML metadata document with one another.

At this time, Deep Security supports only the HTTP POST binding of the SAML 2.0 identity provider (IdP)-initiated login flow, and not the service provider (SP)-initiated login flow

Creating Deep Security accounts from user identities

Once Deep Security and the identity provider have exchanged SAML metadata documents and established a trust relationship, Deep Security can access the user identities on the identity provider's directory server. However, before Deep Security can actually create accounts from the user identities, account types need to be defined and instructions for transforming the data format need to be put in place. This is done using groups, roles and claims.

Groups and roles specify the tenant and access permissions that a Deep Security user account will have. Groups are created on the identity provider's directory server. The identity provider assigns user identities to one or more of the groups. Roles are created in the Deep Security Manager. There must be both a group and a role for each Deep Security account type, and their access permissions and tenant assignment must match.

Once there are matching groups and roles for each user type, the group data format needs to be transformed into a format Deep Security can understand. This is done by the identity provider with a claim. The claim contains instructions for transforming the group data format into the matching Deep Security role.

Learn more about the SAML claims structure required by Deep Security.

Below is a representation of this process:

Implement SAML single sign-on in Deep Security

Once trust has been established between Deep Security and an identity provider with a SAML metadata document exchange, matching groups and roles have been created, and a claim put in place to translate the group data into roles, Deep Security can use SAML single sign-on to automatically make Deep Security accounts for users signing in through your organization's portal.

For more information on implementing SAML single sign-on, see Configure SAML single sign-on.