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 IdP should be externally accessible (ideally via HTTPS) and configured to use SP-initiated SSO.
NOTE: At present, 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, you need to follow the process for each domain.
a. Initiate a domain claim for Federated IDs.
b. Validate DNS token.
c. 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 Adobe approval required. You'll receive an email once 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: Click Browse and upload the certificate (.cer) that your IdP uses to sign the SAML response or assertion.
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
- Must be named with a .cer file 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 how 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.
Click Download Metadata to save the SAML XML Metadata file on your computer. Use this file to configure your SAML integration with the Identity Provider. Your Identity Provider requires this file to enable Single Sign-On.
Review the settings and click Activate Federated ID. To go back and modify SAML settings, click Edit Configuration.
Once 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.
Activating the domain cannot be undone. You can withdraw the request before activation, but not after you've activated it.
For generic SAML identity providers such as OpenAthens, Shibboleth, etc., send the username (usually email address) as the NameID in format 'unspecified'. Also send the following three attributes; names are case-sensitive:
These should match the entries set up via the Admin Console.
See this Help article.