User identities are verified against an authorization source. To use Enterprise ID or Federated ID, set up your own authorization source by adding a domain. For example, if your email address is email@example.com, example.com is your domain. Adding a domain permits the creation of Enterprise IDs or Federated IDs with email addresses on the domain. A domain can be used either with Enterprise IDs or Federated IDs, but not both. You can however add multiple domains.
An organization must demonstrate their control over a domain. An organization can also add multiple domains. However, a domain can be added only once. Known public and generic domains, such as gmail.com or yahoo.com cannot be added at all.
To know more about the Identity types, see Manage identity types.
To use Enterprise or Federated IDs, start by adding a domain. If your organization controls multiple domains, you can add all of them.
This process requires you to verify that you control the domain by adding a token to the DNS.
If you are setting up Enterprise IDs, click Add New Domain.
If you are setting up Federated IDs, click Next.
If another organization has already claimed the domain, you are prompted with the following message:
To request access to this domain, discontinue with the remaining steps in this procedure and follow the procedures detailed in Request access to a claimed domain.
If the domain is available, the Set Up Domain wizard opens. In this case, continue with the next step in this procedure.
To verify that you own the domain, add a TXT record with the generated DNS token, to the domain.
Copy the DNS token that appears on the Set Up Domain wizard in the Admin Console, and update your DNS record with the token. The exact instructions depend on your domain host, but follow the generic guidelines provided in Verify ownership of a domain.
This step requires adding information to your DNS servers.
The generated DNS token expires within 365 days so you must complete this procedure within that period. Let your network administrators know in advance so that this step can be completed within the specified time.
Activating the domain cannot be undone. You can withdraw the request before activation, but not after you've activated it.
When organizations configure and enable Single Sign-On (SSO), users in that organization are able to use their corporate credentials to access Adobe software. This enables users to use a single credential to access Adobe desktop apps, services, and mobile apps.
The Adobe Admin Console offers a method for enterprise users to authenticate using their existing corporate identity. Adobe Federated IDs enable integration with a Single Sign-On (SSO) identity management system. Single Sign-On is enabled using SAML, an industry-standard protocol that connects enterprise identity management systems to cloud service providers like Adobe.
SSO can securely exchange authentication information between two parties: the service provider (Adobe) and your Identity Provider (IdP). The service provider sends a request to your IdP, which attempts to authenticate the user. If authentication is successful, the IdP sends a response message to sign in the user.
To successfully set up SSO for Adobe software, IT Admins need the following:
- An understanding of SAML 2.0
- An Identity Provider (IdP) that supports SAML 2.0, and at a minimum must have:
- IDP Certificate
- IDP Login URL
- IDP Binding: HTTP-POST or HTTP-Redirect
- Assertion consumer service URL
- Access to your DNS configuration for the domain claim process
The login URL of the IdP doesn't need to be externally accessible for users to be able to access it for logging in. However, if it is only reachable within the organization's internal network, users will only be able to log in to Creative Cloud when they are connected to the organization's internal network either directly, via wifi or via VPN. It is not necessary for the login page to be accessible only via HTTPS, but it is recommended for security reasons.
Currently, Adobe does not support IdP-initiated SSO.
Adobe’s cloud services offer SSO using a SaaS SAML 2.0 connector provided by Okta, a leader in SSO services. Adobe has partnered with Okta to enable SSO, and use of Okta’s SAML connector is included in your Adobe enterprise license. The connector is used to communicate with your identity provider to provide authentication services. You are not required to use Okta as your identity provider service since Okta connects to many SAML 2.0 identity service providers. For more information, see SSO / Common questions.
If your organization wants to test SSO integration, it is recommended that you claim a test domain that you own, as long as your organization has an Identity Provider with identities set up in that test domain. This allows you to test the integration before you claim the main domains, until you feel comfortable with the domain claim and configuration process.
Configuring Federated IDs to enable SSO is a multi-step process. If you want to set up SSO on several domains, follow the below process for each domain.
- Initiate a domain claim for Federated IDs.
- Validate DNS token.
- Ensure that DNS check is successful.
After you've initiated a domain claim and the DNS check is successful, the status of the request changes to Validation Required.
An email is sent to you, when the request is approved.
If you already have an Identity Provider (IdP), you can easily set up your SSO configuration using the SaaS SAML 2.0 connector provided by Adobe's partner Okta. Okta is a leading vendor of user authentication systems, and Adobe has partnered with Okta to enable SSO. The use of Okta’s SAML connector is included in your Adobe enterprise license.
Okta is one of the many vendors you can choose to use as an Identity Provider.
IDP Certificate: To upload the certificate (.cer) that your IdP uses to sign the SAML response or assertion, click Upload.
If you don't have the certificate, contact your Identity Provider for instructions to download the certificate file. For example, if you're using Okta as your IdP, sign in to the Okta Administrator dashboard, and choose Security > Authentication > Inbound SAML and then click Download Okta Certificate.
- PEM (base-64 encoded X.509) format
- Named with a .cer filename extension (not .pem or .cert)
- Multi-line format (single line fails)
- Must last a minimum of three years (it saves the maintenance over that lifespan, and does not compromise security)
The Okta certificates used at Adobe's side of the Federated ID handshake are 20-year certificates. This is so that you can do certificate rotation on a schedule of your own choice, rather than being forced to do it by Adobe/Okta.
IDP Binding: Choose the method to transmit SAML protocol messages.
- Use HTTP-Post to transmit the authorization request via the browser using an XHTML form. The IdP also responds with a document containing an XHTML form.
- Use HTTP-Redirect to transmit the authorization request via the SAMLRequest string parameter in the URL query string of an HTTP GET request. The IdP responds with a SAMLResponse string parameter in the URL.
To save the SAML XML Metadata file, click Download Metadata. Use this file to configure your SAML integration with the Identity Provider. Your Identity Provider requires this file to enable Single Sign-On.
For generic SAML identity providers such as OpenAthens, Shibboleth, send the username (usually email address) as the NameID in format 'unspecified'. Also, send the following attributes (case-sensitive): FirstName, LastName, Email.
These attributes must match the entries set up via the Admin Console. If these attributes are not configured in the IDP to be sent over as part of the SAML 2.0 Connector configuration, the authentication will not work.
To go back and modify SAML settings, return to the Admin Console, and navigate to Settings > Identity. Click the domain name, and then click Edit SSO configuration.
If Federated ID is active, any changes to the configuration may cause the SSO to break. A changed configuration generates a new metadata file that needs to be reconfigured in the IdP.