Short answer
SAML single sign-on lets users log in to the DAM with their corporate identity provider credentials. SAML 2.0, an OASIS standard, passes a signed assertion from the identity provider to the DAM, so staff use one corporate login. Enterprise buyers should require SAML 2.0 or an equivalent protocol for every internal user and test role mapping in the demo.
How SAML single sign-on works in a DAM
SAML single sign-on hands the login step to the organisation's identity provider, and the DAM trusts the signed assertion that comes back. SAML stands for Security Assertion Markup Language. The DAM acts as the service provider.
A typical login runs in four steps:
- The user opens the DAM, or a DAM tile in the company portal.
- The DAM redirects the user to the corporate identity provider.
- The identity provider checks the user's credentials and multi-factor rules, then returns a signed assertion.
- The DAM reads the user identifier and group attributes from the assertion and opens the session with the matching role.
SAML handles login only. User creation and removal need a provisioning method, such as just-in-time creation at first login or SCIM, an IETF standard for user provisioning.
Example of SAML single sign-on
Worked example: an employee in the EU brand team clicks the DAM link on the intranet. The identity provider confirms the employee's login and sends an assertion with the group Brand-EU-Editors.
The DAM maps that group to the Editor role in the EU workspace. When the employee leaves the company, IT disables the account in the identity provider. SCIM removes the DAM account the same day, so no orphaned licence or access remains.
SAML single sign-on in a DAM selection
SAML single sign-on belongs at checkpoint 2, Define, as a security requirement, and at checkpoint 5, Test, in the security review. The security requirements guide and the security review guide cover the full checklist.
Test these four behaviours in a demo or proof of concept:
- Log in through both service provider and identity provider initiated flows.
- Map two identity provider groups to two DAM roles and show the result.
- Deactivate a user in the identity provider and show the DAM account removed.
- Show how external agency users log in, and which login methods apply to them.
Confirm that SSO is included in the quoted tier. The requirements builder adds SSO and provisioning to the requirements list.
Common mistakes with SAML single sign-on
SAML single sign-on projects fail through four common mistakes.
- Enabling SSO without provisioning, so leavers keep DAM accounts.
- Leaving local admin accounts active with weak passwords outside SSO.
- Assuming SSO covers agencies and retailers who sit outside the corporate directory.
- Missing that SSO sits in a higher pricing tier than the one quoted.
Related terms: Data residency.
Frequently asked
Is SAML the same as SSO?
SAML is one protocol for single sign-on. SSO is the user experience of one corporate login across many applications. OpenID Connect is another common SSO protocol. A DAM requirement should name the protocols the identity provider supports.
Do external agency users need SSO?
External agency users sit outside the corporate identity provider, so they usually log in with DAM accounts, a guest directory or their own federated login. Define the method per user group, and require multi-factor login for every external user with download or upload rights.