To implement SAML single sign-on, see Configure SAML single sign-on or Configure SAML single sign-on with Microsoft Entra ID.
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.
![]() |
NoteCurrently, 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 for a Deep Security user
account. 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.
See also SAML claims structure.
The following diagram depicts 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 Getting started with SAML single sign-on.