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.

SSO requirements

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.

Workflow overview

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.

  1. Claim a 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.

  2. Activate Federated ID.

  3. Add users and assign them to product configurations. See Manage users and Administrative Roles.

Configure SAML settings

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.

Note:

Okta is one of the many vendors you can choose to use as an Identity Provider.

  1. Click Configuration required. The domain details page opens.

    Click Configuration required
  2. 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.

    Certificate tips:

    • PEM (base-64 encoded X.509) format
    • Must be named with a .cer file extension (not .pem or .cert)
    • Unencrypted
    • SHA-1
    • 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)

    Note:

    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.   

    Identity Configuration panel
  3. IDP Issuer: Enter the entity ID of the identity provider that issues the SAML request. Note that your SAML assertion must reference this string exactly. Any difference in spelling, characters or formatting results in an error.

  4. IDP Login URL: Enter the IDP login URL / SSO address. This URL is where users are redirected after authentication.

  5. 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.
  6. User Login Setting: Choose Email Address or Username to specify how users of this domain will identify themselves.

  7. Click Save.

  8. 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.

    Ensure that the Identity Provider passes the following attributes (case-sensitive): FirstName, LastName, Email. 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.

  9. Review the settings and click Activate Federated ID. To go back and modify SAML settings, click Edit Configuration.

    Note:

    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.

    Click Activate Federated ID

    Note:

    Activating the domain cannot be undone. You can withdraw the request before activation, but not after you've activated it.

Configuring SSO does not automatically create users or confer software entitlements. Once you've successfully configured SSO, proceed to add users and product configurations. For more information, see Manage users and Administrative Roles.

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:

  • 'Email'
  • 'FirstName'
  • 'LastName'

These should match the entries set up via the Admin Console.

Configure SSO for InCommon Federation Members

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Twitter™ and Facebook posts are not covered under the terms of Creative Commons.

Legal Notices   |   Online Privacy Policy