Single Sign-On common questions

Adobe offers the following identity types:

• Enterprise ID: Organization creates and owns account. The accounts are created on a claimed domain. Adobe manages credentials and processes sign-in.
• Federated ID: Organization creates and owns account, links with enterprise directory via federation, enterprise company, or school manages credentials and processes sign-in via Single Sign-On.
• Adobe ID: User creates and owns account. Adobe manages credentials and processes sign-in. Depending on the storage model, user or organization owns the account and assets.
  

Yes, you can have a mix of Enterprise IDs, Federated IDs, and Adobe IDs, but not within the same claimed domain.

Enterprise ID and Federated ID are exclusive at the domain level. Therefore, you can choose only one of them. You can use Adobe ID in conjunction with either Federated ID or Enterprise ID.

For example, if an Enterprise claims only one domain, the IT Administrator can choose either Enterprise ID or Federated ID. If an organization claims multiple domains within an Enterprise, the IT Administrator can use one domain with Adobe IDs and Enterprise IDs, and another domain with Adobe IDs and Federated IDs, and so on. That means, for each domain, you can either have Enterprise ID or Federated ID along with Adobe ID.

Management of Adobe licenses under Federated ID is faster, easier, and more secure.

• IT administrators control authentication and the user lifecycle.
• When you remove a user from the enterprise directory, the user no longer has privileges to access the desktop apps, services, or mobile apps.
• Federated IDs allow organizations to leverage user identity management systems already in place.
• Because your end-users use your organization's standard identity system, IT doesn't have to manage a separate password management process.

When signing in, your end users are redirected to your organization's standard – and familiar – Single Sign-On experience.

Yes. You can switch over from Enterprise to Federated IDs using the same domain. For details, see how to move domain across directories.

Yes, you can federate your enterprise directory and its login and authentication infrastructure with Adobe using your SAML 2.0 compliant identity provider.

No. When a domain is claimed for Federated IDs, nothing changes to existing Adobe IDs with email addresses in that domain. Existing Adobe IDs in the Admin Console are preserved.

Asset Migration is an automated process. When you initiate this process, all the supported content that is currently stored in your Adobe ID account is migrated to your Enterprise/Federated ID account. To learn more, see Automated Asset Migration.

Adobe’s Federated ID implementation supports authorization; authentication is handled by your Identity Provider (IdP).

As an enterprise organization, you can create a link between your authentication services (utilizing a corporate ID structure such as Active Directory) and Adobe's. This allows the enterprise organization to host the authentication. Adobe never stores passwords and IT administrators cannot reset passwords or edit user names for Federated IDs via the Adobe Admin Console.

Yes. You can add multiple users via any bulk operation or user-sync methods available. The different ways to add users are generally based on:

• Your user management strategy (Example: CSV Bulk upload, User Sync Tool)
• Your identity provider capabilities (Example: Azure Sync, Google Sync)

Review Adding multiple users Helpx to know more about the different user management techniques.

No. You must connect your Adobe Admin Console directory to your identity provider (Example: Microsoft Azure, Google, etc.) to sync IdP users. See Add Microsoft Azure Sync to your directory or Add Google sync to your federated directory for more details.

Or, review Adding multiple users Helpx to know more about the different user management techniques.

Adobe recommends that all enterprise admins switch their Adobe ID users to Federated IDs. You can migrate from Adobe IDs to Federated IDs using these steps.

Adobe uses the secure and widely adopted industry standard Security Assertion Markup Language (SAML), which means the implementation of SSO integrates easily with any identity provider that supports SAML 2.0.

Following is a list of some IdPs that are SAML 2.0 compliant:

• Okta
• Oracle Identity Federation
• Microsoft ADFS
• Microsoft Azure AD^#
• Google Federation^# 
• Ping Federate
• Salesforce IdP with externally signed certificate
• CA Federation
• ForgeRock OpenAM
• Shibboleth
• NetIQ Access Manager
• OneLogin
• Novell Access Manager

Yes, as long as it follows the SAML 2.0 protocol.

Yes and the identity provider must be SAML 2.0 compatible.

At a minimum, your SAML identity provider must have:

1. IDP Certificate
2. IDP Login URL
3. IDP Binding: HTTP-POST or HTTP-Redirect
4. The Assertion Consumer Service URL of the IDP and it must be able to accept SAML requests and RelayState.

Check with your identity provider if you have further questions.

No, breaking a 2048-bit certificate has never been done. And, the only people to have ever successfully cracked even a 768-bit certificate (the Lenstra group), estimated it would have taken them over 1000 years with the same hardware to crack even a 1024-bitcertificate (a feat roughly 32,000,000 times easier than cracking a 2048-bit certificate).

If you want to get the latest geeky data about estimates for cracking certificates of various lengths, go to this website. For a fun (accurate but marketing-oriented) picture of how secure these certificates are, go to this website (or its backing math website).

No, that limit is on the certificates used to encode the communication pipe between the browser and the server. Whereas these IdP certificates are used to sign (not encode) the data being passed through that encoded pipe. The browser never sees these certificates: they are only used between Adobe and the customer’s IdP.

You can get good, commercial-grade 2048-bit certificates for about $10/year of life. And, the certificates used by IdPs can be self-signed, which means they can be generated with open-source software for free.

No, because there are two other layers of strong encryption which check the IdP’s identity, that you'd have to crack before you could pose as the IdP. And, both of these other layers are not self-signed. Meaning, that you would have to crack not only the certificate that enforces the encryption but the certificate of the signer that generated that certificate.

For your premium support phone number and email address, see the Welcome email and PDF attachment that was sent to your account administrator.

The same URL endpoint may be used for multiple directories. However, the federation metadata will be managed separately for each IdP. So, the common IdP endpoint will need to handle requests whose content is different.

Yes, if the SAML integration of the directory uses username format and the user names on the Admin Console are identical to the persistent IDs provided. However, this would require that the persistent IDs must be available at the time users are sync’d into the Admin Console. This is not a common scenario and hence, in practice, persistent format for the NameID element would not be supported.

No. The NameID element value is used as the username on the Admin Console; the NameQualifier is ignored.

Yes. Adobe supports SHA256 certificates. For details, see Set up identity.

Yes. You will need to give the CA-signed certificates to Adobe customer support and we will upload it for them.

To proceed, sign in to the Admin Console, navigate to Support > Support Summary and click Create Case. For more, see how to create and manage support cases.

By default, Okta certificates are self-signed. By exception (and possibly for a fee) they can have the certificate signed by a public CA instead.