DAM permissions, SSO & user provisioning: a practical guide

Why it matters

A DAM holds an organisation's approved brand assets, but also unreleased product images, embargoed campaigns, licensed stock with usage limits and photos of identifiable people. Access mistakes in a DAM therefore come in two kinds. If access is too broad, confidential or unlicensed material leaks. If it is too narrow, people cannot find approved assets and go back to shared drives and email, which defeats the purpose of the system.

Identity problems also build up over time. The NSA and CISA note that users who change roles tend to accumulate privileges when movers are not managed, which increases the impact of insider abuse or account takeover. They also stress that leavers' accounts must be terminated promptly R12. The same guidance argues that local accounts, created and managed inside each application, are hard to monitor and should be replaced by federated SSO wherever possible R12. A DAM that is used by marketing, agencies, regional teams and partners can easily gather hundreds of local accounts that nobody owns.

Permission design also interacts with the rest of the DAM. Folder trees are often built mainly to carry permissions (see folders vs metadata). Rights and embargo fields can only protect assets if a permission rule reads them (see rights & usage management). Access design is therefore part of the information model, not only an IT setting.

No independent, freely accessible study was found that measures the cost of poor access management in DAM specifically. Vendor figures exist but are not repeated here.

Core concepts

Two distinctions are worth keeping in mind. First, SSO and provisioning are different protocols. SAML and OIDC carry identity and attributes at login, while SCIM manages accounts and groups outside the login flow R6 R8. Second, DAM permissions and usage rights are different things. A permission says what a person may do in the system. A usage right says what the organisation may do with the asset outside it. Good designs let the second drive the first.

Recommended practices

1. Write an access model before configuring anything

List the user populations (internal creators, librarians, marketing users, regional teams, agencies, partners, the public), the actions that matter (view, preview, download original, download rendition, upload, edit metadata, approve, share externally, delete, administer) and the object scopes (brands, libraries, folders, collections, statuses). Then decide which combinations are allowed. A one-page matrix is usually enough.

OWASP recommends enumerating user types, resources and operations early and defining trust boundaries before implementation R13. Vendor guidance from the DAM sector says the same: design roles up front rather than managing access by exception, one request at a time R16. The matrix becomes your test plan and the basis for later access reviews. The choosing a DAM guide explains how to turn it into demo scenarios.

2. Use a small set of roles, granted through groups

Keep functional roles few and meaningful, for example Viewer, Downloader, Contributor, Librarian, Approver and Administrator. Assign roles to groups, and people to groups. NIST's RBAC model was built for exactly this: it lets organisations manage security at the level of their structure instead of user by user R2.

Separate what someone can do (role) from where they can do it (scope such as a brand, library or folder). Many DAMs model this directly. In the wiki, Cloudinary documents global roles alongside folder and collection roles, assigned to users, groups and API keys, and Brandfolder documents roles from Owner to Guest granted at organisation, library, collection or portal level and inherited downward . Neither example is a recommendation; they show the two dimensions.

Avoid creating a new role for every exception. When roles start to encode markets, products and embargo states, you are heading towards what NIST calls "role explosion" R1.

3. Use attributes for rules that cut across roles

Some restrictions depend on the asset rather than on the person: an embargo date, a licence that covers only certain markets, a confidential product launch, a model release limited to one campaign. NIST SP 800-162 describes attribute-based access control as a way to make these decisions from attributes of the user, the object and the environment, without pre-assigning access for every case R1. OWASP's authorization guidance also favours attribute- or relationship-based models over pure RBAC for fine-grained rules R13.

In a DAM, this means letting metadata drive access. Keepeek, for example, documents a mode that filters assets by matching asset metadata against user attributes, which can be combined with folder and status permissions . Three conditions make such rules safe:

• Authoritative attributes. User attributes (department, market, partner company) should come from an authoritative source, usually the IdP or HR system, not from a field users can edit themselves R1.
• Protected object attributes. NIST warns that object attributes must not be modifiable by the subject in order to manipulate the access decision R1. In a DAM, a contributor who can edit metadata should not be able to change the field that grants access. Make access-driving fields editable only by trusted roles.
• Restrictive defaults. A missing value should hide the asset rather than expose it. This is the deny-by-default principle R13, and it matches the "empty is not permission" rule in rights & usage management.

4. Connect the DAM to your identity provider with SSO

The UK NCSC advises using the organisation's identity provider as the single source of truth for SaaS applications, through standards such as SAML and OpenID Connect rather than password synchronisation R9. The NSA and CISA add that SSO reduces locally provisioned accounts and gives administrators central visibility and control R12.

Practical decisions when you set up SSO:

• Protocol. Most DAMs in the wiki document SAML 2.0, and several also document OIDC (see the SSO column of the comparison table). Either is fine if implemented correctly. The NSA/CISA guide notes that OIDC uses a direct channel between the application and the authentication server, which protects identity tokens, and it considers OIDC the more secure option R12.
• Stable user identifier. Match accounts on an identifier that never changes or gets reused. OpenID Connect states that only the combination of issuer and subject is a guaranteed unique identifier, and that claims such as email "MUST NOT be used as unique identifiers" R5. The NCSC similarly recommends binding accounts with consistent, unique attributes such as staff numbers R9. Email-based matching breaks when people change names or when addresses are reused.
• SSO-only enforcement. Once SSO works, disable password login for regular users, so that disabling a user at the IdP blocks DAM access too. Keep one or two documented break-glass administrator accounts in case the IdP fails, since an SSO outage blocks every connected system R12. In the wiki, Bynder documents an SSO-only flag on users, and Cloudinary documents that SAML can be enforced for all users except Master Admins .
• Cost and plan. Several solution pages note that SSO is limited to higher plans or sold as an option. Include it in the price you compare.
• MFA. If MFA is enforced at the IdP, every SSO login benefits from it. Local accounts that remain need their own MFA R10 R12.

5. Automate the lifecycle: JIT is a start, SCIM finishes the job

NIST SP 800-63C-4 describes three provisioning models for relying parties: pre-provisioning (accounts created before the first login), just-in-time provisioning (created at first login from assertion attributes) and ephemeral provisioning (no persistent account) R3. It also requires the IdP to use a provisioning API to deprovision accounts that have been terminated at the IdP, subject to the RP's retention rules R3.

This is the practical gap with JIT alone. JIT creates accounts and can refresh attributes at each login, but it only acts when the user signs in. A leaver simply stops signing in, so the DAM account, its groups, its personal collections and any API tokens it created stay in place until someone removes them by hand. The NCSC recommends automated tooling, "such as tools using SCIM", to apply the joiner-mover-leaver process when an organisation has an identity provider R9.

What SCIM gives you:

• Create, update and deactivate users through a standard REST interface, with a standard active flag whose usual meaning is "can sign in" versus "suspended" R7 R8.
• Groups and memberships as first-class resources. Membership changes are made on the Group resource, so the IdP can push group changes without touching each user R7.
• Discovery of what a given implementation supports (filtering, PATCH, bulk) through the /ServiceProviderConfig endpoint R8. This is useful when testing a vendor's claim.
• An enterprise extension for attributes such as department, cost centre and manager, which can feed attribute-based rules R7.

How it works in practice depends on the IdP. Microsoft's documentation, for example, describes provisioning scoped by app assignment or group membership, a soft-delete that sets active to false when a user leaves scope, a later hard delete, and a limitation: users in nested groups are not provisioned R15. Read your IdP's equivalent page before you design groups.

SCIM support in DAMs is uneven. In the wiki, Bynder documents SCIM with Okta and Microsoft Entra, which requires SSO, and Nuxeo documents a SCIM 2.0 package . Frontify documents SSO with JIT creation and IdP group mapping at each login, and states there is no SCIM . For most other platforms in the wiki, SCIM is marked Unknown or not documented, and some offer alternatives such as a provisioning API or directory sync. When SCIM is missing, agree a compensating process:

1. IdP-driven group mapping at every login, so that movers' access is recomputed when they next sign in.
2. A scheduled export of DAM users compared with the IdP or HR list, with disabling of accounts that no longer match.
3. A provisioning API called from your identity-governance tool, if the vendor offers one.
4. An inactivity rule that disables accounts unused for a set period.

6. Map IdP groups to DAM groups, and keep the mapping in one place

Decide where group membership is mastered. The usual answer is the IdP: people are added to groups such as dam-viewers-brandA or dam-approvers-emea there, and the DAM only maps those groups to its own roles and scopes.

• One mapping table, documented outside the DAM, listing each IdP group, the DAM group or role it maps to, its owner and its purpose.
• Recompute, don't append. When groups come from the IdP, the DAM should replace a user's memberships at each sync or login, not add to them. Otherwise movers keep their old access, which is the privilege accumulation the NSA and CISA warn about R12.
• Avoid manual group edits inside the DAM for IdP-mastered groups. They will be overwritten, or worse, silently diverge.
• Know who configures the mapping. Some vendors expose it in the admin UI; others configure it through their support team. In the wiki, Brandfolder documents a SAML teams attribute mapped to access by its support team from a customer spreadsheet . That affects how quickly you can change it.

7. Handle movers and leavers explicitly

The IDPro Body of Knowledge describes the workforce identity lifecycle in three processes: joiners get identities, accounts and group memberships; movers get updated access with attestation that it is still right; leavers have access removed from the central directory and from downstream systems R14. For a DAM, add the content side:

Prefer disable, then delete. Disabling preserves audit history and ownership links while blocking sign-in. Microsoft recommends that applications support both soft and hard deletes so that accidental disables can be reversed R15. Deletion of personal data then follows your retention policy R3.

8. Give external users narrow, time-limited access

Agencies, freelancers, retailers, press and partners often need DAM access. The options, from lightest to heaviest:

1. Share links to a collection or a set of renditions, with an expiry date and, where available, download limits or a watermark. Treat links as access grants: OWASP reminds implementers to apply authorization to static resources and files, not only to application pages R13.
2. Brand portals or public microsites for broad, read-only audiences.
3. Guest accounts with a dedicated external role, limited to specific libraries or collections.
4. Federation with the partner's IdP, or guest accounts in your own IdP, so that the partner's leavers are handled by an identity system rather than by your DAM admin R11 R15.

Whatever the method, give every external grant an owner and an end date. In the wiki, Nuxeo documents permission grants that can carry start and end dates, which is one way to make access expire by design . Check that a share never overrides an embargo or licence restriction on an asset in it.

9. Treat integrations as identities too

Every connector (PIM, CMS, e-commerce, creative tools, AI agents) acts with some identity. Give each integration a dedicated service account or client, with only the scopes it needs, owned by a named person, and rotate its credentials. Do not run integrations on a personal account: when that person leaves, the integration either breaks or keeps privileges nobody reviews. The NSA and CISA recommend that system and application accounts are created and granted privileges only through approved, documented change requests and monitored like human accounts R12.

In the wiki, Orange Logic documents that SSO users cannot use bearer authentication for the API, so a separate non-SSO API account is needed, and its documentation recommends one API account per use case . Cloudinary documents roles that can be assigned to API keys . For machine-to-machine access, the OAuth 2.0 client credentials grant is the usual pattern where a DAM supports it. The API integration patterns guide covers authentication flows in detail.

10. Separate and protect administrator access

Administrators can change every rule above. The NCSC recommends separate administrative identities from day-to-day accounts, least privilege for admins, MFA, and logging of admin activity R9 R10.

• Keep the number of full administrators small and named.
• Split administration where the DAM allows it: user and group admin, metadata schema admin, workflow admin, integration admin.
• Require MFA for every admin, including any break-glass account.
• Log and review permission changes, role changes and new API credentials.

11. Review access regularly and keep evidence

Access drifts. The NCSC recommends reviewing accounts regularly for unnecessary privileges R10. The NSA and CISA describe an access inventory that lets application and data owners periodically review and reconcile accounts and privileges R12. IDPro calls access certification "a critical and often underestimated component" of a mature IAM programme R14.

A workable DAM review cycle:

• Quarterly: administrators and API/service accounts; external accounts and active share links; members of approver groups.
• Twice a year: all IdP-to-DAM group mappings, with the owner of each group confirming its members.
• Continuously: accounts unused for more than a set period, users present in the DAM but not in the IdP, and local (non-SSO) accounts.

For evidence, the DAM should log at least logins, downloads, shares, permission and role changes, and API credential changes. OWASP recommends consistent, parseable authorization logs centralised for analysis R13. Check how long the DAM keeps these logs and whether you can export them. In the wiki, Sitecore Content Hub documents a security diagnostics tool to inspect effective permissions, and audit logs retained two years online and seven years offline for security events in production. Bynder documents an access-rights report .

12. Test permissions like any other feature

• Effective-permission tests. Log in as a test user from each population in the matrix and try each sensitive action, including API calls and direct file URLs.
• Conflict rules. Understand what happens when two grants overlap. Sitecore Content Hub, for instance, documents that permissions are positive only and that several group policies combine with Any or All . Other platforms allow explicit denies. Your matrix must follow the platform's logic.
• Lifecycle tests. Add, move and remove a test user in the IdP, then check the DAM within the expected sync time. Repeat after any change to mappings.
• Regression after changes. Re-run the tests after schema changes, new libraries, new integrations and vendor releases.

Common pitfalls

How DAM platforms support this

The wiki records each platform's identity features in the sso field and the security section of its overview page, and its permission model in the Rights & governance and Administration sections of its features page. The comparison table lists the documented SSO protocols side by side. The examples below were chosen because each illustrates a distinct practice in this guide. They are not a ranking, and other platforms may offer similar functions.

Patterns visible across the twenty solutions documented in the wiki at the time of research:

• SSO is widespread. Eighteen of twenty overview pages record SAML and/or OIDC. One documents SSO without stating the protocol, and one documents directory and Kerberos sign-on only.
• JIT is common, SCIM is not. Many pages document just-in-time creation at first login. Only two document SCIM. For the rest, SCIM is Unknown, not documented or explicitly absent.
• SSO is often plan-dependent. Several pages note SSO as an enterprise-tier feature or a paid option.

Questions to put to any vendor, in demos or RFPs:

• Which SSO protocols are supported, on which plans, and is SSO self-service or configured by your support team?
• Can password login be disabled for everyone except named emergency accounts?
• Is there SCIM 2.0? Which resources (Users, Groups), which operations (PATCH, filtering), and for which IdPs? If not, what replaces it for leavers?
• Which attribute is used to match a returning user? What happens when their email changes?
• Are IdP group memberships recomputed at each login or sync, or only added?
• Can permissions depend on asset metadata and user attributes? What happens when grants conflict?
• How are external users, share links and portals controlled, and can every grant expire?
• How are API clients and service accounts created, scoped and audited?
• What is logged, for how long, and how can it be exported?

Where a solution page says Unknown for SCIM or for the permission model, the vendor's public documentation did not cover it when the page was researched. Ask the vendor directly and record the answer.