A: Customers on enterprise plans.
A: It includes login via enterprise identity management platforms such as Okta, Azure AD, OneLogin, etc.
A: It doesn't include social login (OIDC) and application-level login (OAuth). These logins are supported but are not related to this article.
A: Definitely. SAML SSO can be used for login only. It can also be used for JIT provisioning, where the identity management platform controls both the authentication (login), the user's creation, and the major user's permissions (this would be further specified in the next Q). The extended flavor is called SAML Provisioning (or SAML SSO with Provisioning).
In addition, you can choose to allow or disallow basic auth - that is the login with email and password as defined in Cloudinary databases (a mechanism that is available for all plans). The Master Admin of the account will keep having basic auth even when it is disabled, so it can still have access in case of SSO issues. 2FA is highly recommended for Master Admins.
A: The permissions that can be set are the user's Role, Sub-account/s, and User Groups. It's important to note that folder-level permissions, collection-level permissions, etc. cannot be set directly. They are indirectly controlled by the user group associations.
Note that the Cloudinary role dictates the relevance of other permissions:
- ML User is the only role that can have User Groups.
- Master Admin has access to all sub-account and all other permissions.
A: Yes, this is possible via the Provisioning API. You can have your SCIM list/create/update/delete users in Cloudinary.
A: It is only possible to enforce SSO for all users (except Master Admins) or allow basic auth for all within Cloudinary.
It is possible to achieve this by setting external users on your identity provider with the option for them to log in with basic auth.
A: External users might have their email already registered under another Cloudinary customer. In that case, the user will not be able to register their email to your account.
Here are some workarounds:
- Open a full account under your domain, something like firstname.lastname@example.org
- Enable the user's own email in your IdP, and map its SAML attribute to a unique email in Cloudinary. MS Azure systems can use the UPN as a unique user in Cloudinary. In that case, the user could access your account only through the IdP.
- Request the external user to maintain a new email address.
A: Yes. Most IdP platforms support such a URL. Please consult your SSO provider about IdP-initiated URL with a default/post-back SP. It is sometimes called a magic URL or user access URL.
- The authorization is controlled by the Identity Management platform. It will override the user’s permissions in every login. It means you can have mixed SSO and non-SSO login, but only a single mode of permissions.
- The user role is optional and the default is ML user. It means the role must be provisioned for the Master Admin and any other user with an elevated role.
- When SAML Provisioning is enabled, any login request must fully comply with the spec. All mandatory fields should exist in the assertion message, where attributes and values are case-sensitive.
- The SAML protocol supports only provisioning. Deprovisioning should be handled as a custom code using the Provisioning API. If SSO is enforced on the account, users will not be able to log in if access is removed from the identity provider.
- Additional considerations can be found here.
A: Full documentation: