Topics on this page
About SAML single sign-on (SSO)
This page applies to legacy accounts. Learn more
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 as a Service, 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 as a Service without an existing Deep Security as a Service account.
How does SAML single sign-on work in Deep Security as a Service?
Sections below detail how SAML single sign-on works in Deep Security as a Service.
Establish 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 as a Service) 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 as a Service 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.
Create Deep Security as a Service accounts from user identities
Once Deep Security as a Service and the identity provider have exchanged SAML metadata documents and established a trust relationship, Deep Security as a Service can access the user identities on the identity provider's directory server. However, before Deep Security as a Service 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 as a Service 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 as a Service console. There must be both a group and a role for each Deep Security as a Service 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 as a Service 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 as a Service role.
Learn more about the SAML claims structure required by Deep Security as a Service.
Below is a representation of this process:
Implement SAML single sign-on in Deep Security as a Service
Once trust has been established between Deep Security as a Service 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 as a Service can use SAML single sign-on to automatically make Deep Security as a Service 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.