Reference Glossary
SAML
An XML-based open standard (OASIS, ratified 2005) for exchanging authentication and authorization data between an identity provider and a service provider, most often used for single sign-on.
Why it matters in a DAM
A DAM holds licensed photography, unreleased campaign creative, and sometimes contributor personal data, so it sits on the list of systems IT wants behind single sign-on rather than its own password. SAML is what lets a DAM trust an assertion from the company's identity provider (Okta, Azure AD, Google Workspace) instead of maintaining a separate user table, so when someone is deprovisioned centrally on their last day, their DAM access dies with it. Enterprise DAM RFPs routinely list SAML 2.0 support as a pass/fail requirement precisely because procurement and security teams won't approve a system that can't join the SSO fabric.
A worked example
Common mistake
Teams configure SAML for login but keep managing DAM roles and permissions manually inside the DAM itself, so a user removed from the identity provider still keeps whatever asset permissions were assigned to their DAM account until someone remembers to revoke them by hand.
SAML (Security Assertion Markup Language) is the OASIS standard, ratified as SAML 2.0 in March 2005, that defines how an identity provider passes an XML-encoded authentication assertion to a service provider so a user can log in without a separate password. In a DAM context, the DAM is the service provider: it trusts the company’s identity provider to confirm who someone is, and grants a session based on that assertion rather than checking credentials it stores itself.
SAML only proves identity — it says who logged in, and sometimes carries attributes like department or job title in the assertion. It does not, by itself, manage what that person can then do inside the DAM. That’s a separate configuration layer (role-based access control) that maps SAML attributes or group membership to DAM permissions. Confusing the two is the most common gap: SSO gets set up, but nobody wires the identity provider’s group changes into the DAM’s permission model, so access drifts out of sync with who’s actually still employed.
SAML is often paired with SCIM provisioning, which handles the account lifecycle (creating, updating, deactivating DAM accounts) that SAML doesn’t cover. A DAM can support SAML for login without supporting SCIM for provisioning, and vendors sell these as separate line items — worth checking explicitly rather than assuming ‘SSO support’ includes automated deprovisioning.
Frequently asked
What is SAML and why does it matter for a DAM?
SAML (Security Assertion Markup Language) is the OASIS standard, ratified as SAML 2.0 in 2005, for exchanging authentication data between an identity provider and a service provider. In a DAM it lets the platform trust a company's identity provider (Okta, Azure AD, Google Workspace) for login instead of managing its own password table, so access can be centrally controlled.
Does SAML also manage what a logged-in user can do inside the DAM?
No. SAML only proves who someone is at login; it does not manage permissions or asset access. That's handled by a separate layer, typically role-based access control, which maps SAML attributes or group membership to DAM permissions.
Why do enterprise DAM RFPs treat SAML 2.0 as a pass/fail requirement?
Because a DAM holds licensed photography, unreleased campaign creative, and sometimes contributor personal data, security and procurement teams generally won't approve a system that can't join the company's SSO fabric. SAML support signals the DAM can be centrally governed rather than maintaining its own separate login system.
What's the most common mistake teams make after configuring SAML?
They set up SAML for login but keep managing DAM roles and permissions manually inside the DAM itself. As a result, a user removed from the identity provider still retains whatever asset permissions were assigned to their DAM account until someone remembers to revoke them by hand.
Is SAML the same as SCIM provisioning?
No -- they solve different problems and are often sold as separate line items. SAML handles the moment of login (proving identity); SCIM handles the account lifecycle (creating, updating, and deactivating accounts), which SAML does not cover on its own.
Which identity providers typically connect to a DAM through SAML?
Common ones include Okta, Azure AD, Google Workspace, and OneLogin, with the DAM acting as the service provider that receives an XML assertion confirming the user's identity and attributes like department or role.
Sources
- SAML 2.0 is an XML-based protocol using assertions to pass authentication/authorization information between an Identity Provider and a Service Provider, ratified as an OASIS Standard in March 2005. checked 2026-08-07 — OASIS / SAML 2.0 Technical Overview