As a system admin on the Admin Console, one of your first tasks is to define and set up an identity system against which your end users will be authenticated. As your organization purchases licenses for Adobe products and services, you will need to provision those licenses to your end users. And for this, you will need a way to authenticate these users.

Adobe provides you with the following identity types that you can use to authenticate your end users:

Adobe ID

Enterprise ID

Federated ID

If you want to have separate accounts owned and controlled by your organization for users in your domain, you must use either Enterprise ID or Federated ID (for Single- Sign-On) identity types.

This article provides the details required to set up the identity system that you will need if you plan to use Enterprise ID or Federated ID to authenticate your end users.

IdP

Adobe ID

Created, owned and managed by the end user. Adobe performs the authentication and the end user manages the identity. Users retain complete control over files and data associated with their ID. Users can purchase additional products and services from Adobe. Admins invite users to join the organization, and can remove them. However, users cannot be locked out from their Adobe ID accounts. The admin can't delete or take over the accounts. No setup is necessary before you can start using Adobe IDs.

The following are a few requirements and scenarios, where Adobe IDs are recommended:

If you want to enable users to create, own, and manage their identities.

If you want to allow users to purchase or sign up for other Adobe products and services.

If users are expected to use other Adobe services, which do not currently support Enterprise or Federated IDs.

If users already have Adobe IDs, and associated data such as files, fonts, or settings.

In educational setups, where students can retain their Adobe ID after they graduate.

If you have contractors and freelancers who do not use email addresses on domains you control.

If you have an Adobe teams contract, you will need to use this identity type

Enterprise ID

Created, owned, and managed by an organization. Adobe hosts the Enterprise ID and performs authentication, but the organization maintains the Enterprise ID. End users cannot sign up and create an Enterprise ID, nor can they sign up for additional products and services from Adobe using an Enterprise ID.

Admins create an Enterprise ID and issue it to a user. Admins can revoke access to products and services by taking over the account, or deleting the Enterprise ID to permanently block access to associated data.

The following are a few requirements and scenarios where Enterprise IDs are recommended:

If you need to maintain strict control over apps and services available to a user.

If you need emergency access to files and data associated with an ID.

If you need the ability to completely block or delete a user account.

Federated ID

Created and owned by an organization, and linked to the enterprise directory via federation. The organization manages credentials and processes Single Sign-On via a SAML2 Identity Provider (IdP).

The following are a few requirements and scenarios where Federated IDs are recommended:

If you want to provision users based on your organization's enterprise directory.

If you want to manage authentication of users.

If you need to maintain strict control over apps and services available to a user.

If you want to allow users to use the same email address to sign up for an Adobe ID.

ملاحظة:

The Identity Provider must be TLS 1.2 compliant.

Authentication domains

The portion of an email address after the @ symbol. To use a domain with Enterprise or Federated ID, you must first validate your ownership of that domain.

For example, if an organization owns multiple domains (geometrixx.com, support.geometrixx.com, contact.geometrixx.com) but their employees are authenticated against geometrixx.com. In this case, the organization will use the geometrixx.com domain to set up their identity on the Admin Console.

Personas responsible for this setup

System admin

Works with IdP directory managers and DNS managers to set up identity in the Admin Console. This document is targeted at System admins who will have access to the Admin Console. The persona is expected to work with the other personas who (usually) will not have access to the Admin Console.

DNS manager

Updates DNS tokens to validate domain ownership

Identity Provider (IdP) directory manager

Creates connectors in the IdP

Identity types using domains

User identities are verified against an authentication source. To use Enterprise ID or Federated ID, set up your own authentication source by adding a domain. For example, if your email address is john@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 validate 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.

If you have chosen to create an Enterprise ID identity type directory, you are done. Go ahead and set up your domains in the Admin Console.

If you have chosen to create a Federated ID identity type directory, Adobe will need to provision this directory before you can proceed with any more operations on it. However, you don't need to wait around while Adobe provisions the directory. You can go ahead and set up your domains in the Admin Console.

ملاحظة:

Provisioning Federated ID type directories typically takes up to 48 hours. You are notified by email when it is done.

Configure Single-Sign On (required for Federated ID directory)

After you receive the email from Adobe confirming that your directory is provisioned, configure the SAML settings for the directory.

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

TLS 1.2 enabled

Access to your DNS configuration for the domain claim process

The login URL of the IdP does not 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 can only log in to Adobe products 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. 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.

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

ملاحظة:

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.

Certificate tips:

PEM (base-64 encoded X.509) format

Named with a .cer filename 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)

ملاحظة:

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.

User Login Setting: Choose Email Address or Username to specify how users of this domain will identify themselves.

IDP Issuer: Enter the entity ID of the identity provider that issues the SAML request.

Your SAML assertion must reference this string exactly. Any difference in spelling, characters, or formatting results in an error.

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

Click Save.

Click Download Metadata.

The metadata file is downloaded to your local disk. 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 or 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.

If Federated ID is active, any changes to the configuration may cause the SSO logins to fail for end users. A changed configuration generates a new metadata file that needs to be reconfigured in the IdP.

After the SSO configuration with your Identity Provider is complete, sign in to the Admin Console and navigate to Settings > Identity.

Click Configure for the relevant directory.

In the Configure Directory screen, check I have completed the configuration with Identity Provider and click Complete.

Your directory is now configured for Single Sign-On.

If you have not already done so, you can add domains to the Admin Console. If you have already added domains to the Admin Console, you can link the required domains to this directory.

Set up domains

Your end users are authenticated against domains that you need to set up in the Admin Console.

To set up domains:

Add domains to the Admin Console

Prepare to validate domain ownership by adding a special DNS record

Validate the domains

Add domains

The domains that you add to the Admin Console do not need to be registered with the same IdP. However, when you link these domains to a directory, you need to link domains from different IdPs to different directories.

You cannot add a domain to the Admin Console if it has already been added to another organization's Admin Console. You can, however, request access to that domain.

In the Enter Domains screen, enter a list of up to 15 domains, and click Add Domains.

In the Add Domains screen, verify that the list of domains and click Add Domains.

Your domains are now added to the Admin Console. However, you still have to demonstrate ownership of these domains.

Demonstrate ownership of domain (using DNS tokens)

An organization must demonstrate their ownership of a domain. An organization can add as many domains to the Admin Console as required.

The Admin Console allows one organization to use a single DNS token to demonstrate ownership of all its domains. Also, the Admin Console does not require DNS validation for subdomains. This means that when you use the DNS token and demonstrate ownership of a domain, all subdomains of that domain are validated instantly as they are added to the Admin Console.

When you receive the DNS token, you need to work with your DNS manager to add a special DNS record for the domains that you have added.

To verify that you own the domain, you must add a TXT record with the generated DNS token. The exact instructions depend on your domain host, but follow the generic guidelines provided in Verify ownership of a domain.

You need to add information to your DNS servers to complete this step. Let your DNS manager know in advance so that this step can be completed in a timely manner.

Adobe periodically checks the DNS records for your domain. And, if they are correct, the domain is validated automatically. If you want to validate the domain immediately, you can sign into the Admin Console and validate it manually. See Domain validation.

Domain validation

The Admin Console attempts to validate domains you have added several times a day, so you need not take any action to validate a domain once the DNS records are properly configured.

Manually validate domains

If you need to validate your domain immediately, you can do this on the Admin Console. To manually validate your domains:

Links domains to directories

After you have set up your directories and domains in the Admin Console, you need to link the domains to the directories.

You can link multiple domains to the same directory. However, all the domains that you link to a single directory must share identical SSO settings.

تحذير:

You cannot link the same domain to multiple directories. Also, currently if you need to remove the linking between a domain and a directory, contact Adobe support. So, plan your domain-to-directory linking before you start the following procedure.

Sign in to the Admin Console and navigate to Settings > Identity.

Go to the Domains tab.

Click the check box to the left of the domain name and click Link to Directory.

If you want to link multiple domains to the same directory, multi-select the check boxes for these domains.

In the Link to directory screen, choose the directory from the dropdown and click Link.

Directory trusting

The ownership of a domain can only be claimed by a single organization. So consider the following scenario:

A company, Geometrixx, has multiple departments, each of which has their own unique Admin Console. Also, each department wants to use Federated user IDs, all using the geometrixx.com domain. In this case, the system administrator for each of these departments would want to claim this domain for authentication. The Admin Console prevents a domain from being added to more than one different organization's Admin Console. However, once added by a single department, other departments can request access to the directory to which that domain is linked on behalf of their organization's Admin Console.

Directory trusting allows a directory owner to trust other system admins (trustees). After this, trustee organizations in the Admin Console can add users to any domain within the trusted directory.

To summarize. If you plan to use Enterprise or Federated ID on your Admin Console, you must add the domain associated with your organization. If this domain was previously added by another organization, you have to request access to the directory containing that domain as a trustee.

To request access to a directory, see the steps in the Add domains procedure in Set up domains above.

تحذير:

As an owner of a directory, if you approve an access request for that directory, the trustee organization will have access to all domains linked to that directory, as well as any domains linked to that directory in the future. So planning the domain-to-directory linking is essential as you set up the identity system in your organization.

Domain trustee

Request access

If you request access to this domain, your name, email, and organization name is shared with the request to the system administrators of the owning organization.

The type of directory (Enterprise or Federated) depends on how it was set up by the owning organization. This means that you must use whichever directory type was chosen by the owning organization.

Since the domain has already been set up by the owner (see Demonstrate ownership of the domains in the Set up domains for details), as the trustee, you do not need to take any additional action. When the access request is accepted by the owner, your organization will have access to the directory and all it's domains, as configured by the owning organization.

Check request status

Sign in to the Admin Console and navigate to Settings > Identity.

Go to the Access Requests tab and check the status against each directory for which you have requested access.

You can also click the row item in the list of access requests and click Resend Request or Cancel Request.

If your request access to the directory is accepted by the owning organization, you receive an email notification. Your trust request disappears and instead the trusted directory and it's domains appear with the status Active (trusted) in your Directories and Domains listings.

Withdraw trustee status

As the trustee organization, if you no longer have a need to access the trusted directory, you may withdraw your trustee status at any time.

Sign in to the Admin Console and navigate to Settings > Identity.

In the Directories tab, click the shared directory to withdraw your access from.

In the directory details drawer, click Withdraw.

If you withdraw your access to a trusted directory, any Enterprise ID or Federated ID users that belong to domains in that directory (meaning that they log in using the domain credentials) are removed from your organization. Also, these users lose access to any software granted to them by your organization.

Domain owner

As a system administrator of an owning organization, you can choose to accept or reject the requests for access to the directories that you own.

When you get an email request for access to a directory you own, you can either choose to accept or reject the request from within the email itself. You can also go to the Access Requests tab to manage the claim requests.

Accept access requests

Sign in to the Admin Console and navigate to Settings > Identity.

Go to the Access Request tab.

To accept all the requests, click Accept All.

Or to accept requests for specific claims, click the check box to the left of each row and click Accept.

In the Accept Access Request screen, click Accept.

An email notification is sent to the System admins of the trustee organizations.

Reject request

You can also choose to reject the request for access to a directory that you own.

Sign in to the Admin Console and navigate to Settings > Identity.

Go to the Access Request tab.

Click the check box to the left of each row and click Reject.

In the Reject Access Request screen, enter a reason for the rejecting the request and click Reject.

The reason that you provide, is shared with the requesting organization via email. However, your email, name, and organizational information is withheld.

Revoke access

You can revoke the access of a trustee organization for which you have previously given access.

Sign in to the Admin Console and navigate to Settings > Identity.

Go to the Trustees tab.

Click the check box to the left of each row and click Revoke.

In the Revoke Trustee screen, click Revoke.

If you revoke the access of a trustee organization, users with Enterprise ID or Federated ID accounts on any domain in that directory are removed from the trustee's organization. Also, these users lose access to any software or services granted to them by the trustee's organization.

Manage encryption keys

While all data on Creative Cloud and Document Cloud is encrypted, you can choose to have Adobe generate dedicated encryption keys for accounts in a directory that you create.

Enable encryption key

Sign in to the Admin Console and navigate to Settings > Identity.

In the Directories tab, click the name of the directory for which you need to enable encryption.

Click Settings.

In the Dedicated Encryption Key section, click Enable.

In the Enable Dedicated Encryption Key dialog box, click Enable.

Revoke encryption key

You can choose to revoke the dedicated encryption key for a directory.

Sign in to the Admin Console and navigate to Settings > Identity.

In the Directories tab, click the name of the directory for which you need to revoke encryption.

In the Details screen, click Settings.

In the Dedicated Encryption Key section, click Revoke.

In the Revoke Dedicated Encryption Key dialog box, click Revoke.

Remove directories and domains

You can remove directory and domains from the Admin Console that are no longer in use.

Remove directories

ملاحظة:

You cannot remove a directory that has:

Active users

Linked domains

Trustees

Sign in to the Admin Console and navigate to Settings > Identity.

Go to the Directories tab.

Click the check box to the left of one or more directory names and click Delete.

In the Remove Directories screen, click Remove.

Remove domains

ملاحظة:

You cannot remove a domain if there are users with that domain in the Admin Console or if the domain is linked to one or more directories.

Sign in to the Admin Console and navigate to Settings > Identity.

Go to the Domains tab.

Click the check box to the left of one or more domain names and click Delete.