The Admin Console allows a system administrator to configure domains which are used for login via Federated ID for Single Sign-On (SSO). Once ownership of a domain is demonstrated using a DNS token, the domain can be configured to allow users to log in to Creative Cloud. Users can log in using email addresses within that domain via an Identity Provider (IdP). The process is provisioned either as a software service which runs within the company network and is accessible from the Internet or a cloud service hosted by a third party that allows for the verification of user login details via secure communication using the SAML protocol.

One such IdP is Shibboleth. To use Shibboleth, you need a server that is accessible from the Internet and has access to the directory services within the corporate network. This document describes the process to configure the Admin Console and a Shibboleth server to be able to log in to Adobe Creative Cloud applications and associated websites for Single Sign-On.

Access to the IdP is commonly achieved using a separate network configured with specific rules to allow only specific types of communication between servers and the internal and external network, referred to as a DMZ (demilitarized zone). The configuration of the operating system on this server and the topology of such a network is beyond the scope of this document.


Before configuring a domain for Single Sign-on using Shibboleth IDP, the following requirements must be met:

  • An approved domain for your Adobe organization account. The status of the domain in the Adobe Admin Console must be Configuration Required.
  • The latest version of Shibboleth is installed and configured.
  • All Active Directory accounts to be associated with a Creative Cloud for Enterprise account have an email address listed within Active Directory.


Steps to configure Shibboleth IDP with Adobe SSO described in this document have been tested with Version 3.

Configure Adobe Admin Console

To configure Shibboleth IdP on the Admin Console, follow the below steps:

  1. In the Admin Console, navigate to Settings > Identity. The Identity page lists the directories in your organization.

  2. Click Configure against the directory you want to set up. The Configure Directory wizard opens.

    Configure directory
  3. To upload the IdP certificate, click Upload and navigate to the certificate file:


  4. Then, set IdP Binding to Redirect and User Login Setting to Email address.

  5. Enter the following URL in the IDP Issuer field:

    https://<claimed domain server name:port>/idp/shibboleth

  6. Enter the following URL in the IDP Login URL field:

    https://<claimed domain server name:port>/idp/profile/SAML2/Redirect/SSO

  7. Click Complete Configuration.

  8. To download the SAML XML Metadata file, click Download Metadata.

    After downloading the metadata file, you need to update the file to ensure the correct information is passed back to Adobe.

    Replace the following lines in the file:





    Also, replace:

    <md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">


    <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

  9. Click Activate Domain.

    Your domain is now active.

Configure Shibboleth

After you have downloaded the SAML XML Metadata file from the Adobe Admin Console, follow the below steps to update the Shibboleth configuration files.

  1. Copy the downloaded metadata file to the following location and rename the file to adobe-sp-metadata.xml:


  2. Edit the attribute-filter.xml file.

    The Adobe service provider requires the user's first namelast name, and Email in the SAML response.

    Edit the %{idp.home}/conf/attribute-filter.xml file to include the FirstName, LastName, and Email attributes by inserting the AttributeFilterPolicy node as displayed below (lines 17 to 31):

    <?xml version="1.0" encoding="UTF-8"?>
        This file is an EXAMPLE policy file.  While the policy presented in this
        example file is illustrative of some simple cases, it relies on the names of
        non-existent example services and the example attributes demonstrated in the
        default attribute-resolver.xml file.
        Deployers should refer to the documentation for a complete list of components
        and their options.
    		<PolicyRequirementRule xsi:type="Requester" value="https://www.okta.com/saml2/service-provider/spiml66pl3iZi7tuI0x7" />
    		<AttributeRule attributeID="NameID">
    			<PermitValueRule xsi:type="ANY" />
    		<AttributeRule attributeID="FirstName">
    			<PermitValueRule xsi:type="ANY" />
    		<AttributeRule attributeID="LastName">
    			<PermitValueRule xsi:type="ANY" />
    		<AttributeRule attributeID="Email">
    			<PermitValueRule xsi:type="ANY" />
  3. Edit the metadata-providers.xml file.

    Update the %{idp.home}/conf/metadata-providers.xml with the location of the adobe-sp-metadata.xml metadata file (line 29 below) that you created in Step 1 above.

        <MetadataProvider id="HTTPMetadata"
            <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true">
            <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P30D"/>
            <MetadataFilter xsi:type="EntityRoleWhiteList">
        Example file metadata provider.  Use this if you want to load metadata
        from a local file.  You might use this if you have some local SPs
        which are not "federated" but you wish to offer a service to.
        If you do not provide a SignatureValidation filter, then you have the responsibility to
        ensure that the contents are trustworthy.
        <MetadataProvider id="LocalMetadata"  xsi:type="FilesystemMetadataProvider" metadataFile="%{idp.home}/metadata/adobe-sp-metadata.xml"/>

Troubleshoot your Shibboleth setup

If you are unable to successfully log in to adobe.com, check the following Shibboleth configuration files for any possible issues:

1. attribute-resolver.xml

The attribute filter file, which you updated while Configuring Shibboleth, defines the attributes that you need to provide to the Adobe service provider. However, you need to map these attributes to the appropriate attributes as defined in LDAP / Active Directory for your organization.

Edit the attribute-resolver.xml file at the following location:


For each of the following attributes, specify the source attribute ID as defined for your organization:

  • FirstName (line 1 below)
  • LastName (line 7 below)
  • Email (line 13 below)
<resolver:AttributeDefinition xsi:type="ad:Simple" id="NameID" sourceAttributeID="mail">
      <resolver:Dependency ref="myLDAP" />
      <resolver:AttributeEncoder xsi:type="SAML2StringNameID"
        nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
      <resolver:AttributeDefinition xsi:type="ad:Simple" id="Email"
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="Email" />
      <resolver:AttributeDefinition xsi:type="ad:Simple" id="FirstName"
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="FirstName" />
     <resolver:AttributeDefinition xsi:type="ad:Simple" id="LastName"
     <resolver:Dependency ref="myLDAP" />
    <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="LastName" /></resolver:AttributeDefinition>

2. relying-party.xml

Update the relying-party.xml at the following location to support the saml-nameid format as required by the Adobe service provider:


Update the p:nameIDFormatPrecedence attribute (line 7 below) to include emailAddress.

<bean parent="RelyingPartyByName" c:relyingPartyIds="[entityId">
	<property name="profileConfigurations">
			<bean parent="Shibboleth.SSO" p:postAuthenticationFlows="attribute-release" />
			<ref bean="SAML1.AttributeQuery" />
			<ref bean="SAML1.ArtifactResolution" />
			<bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" p:postAuthenticationFlows="attribute-release" p:encryptAssertions="false" />
			<ref bean="SAML2.ECP" />
			<ref bean="SAML2.Logout" />
			<ref bean="SAML2.AttributeQuery" />
			<ref bean="SAML2.ArtifactResolution" />
			<ref bean="Liberty.SSOS" />

Also. to turn off encryption of the assertions, in the section DefaultRelyingParty for each of the SAML2 types:





3. saml-nameid.xml

Update the saml-nameid.xml at the following location:


Update the p:attributeSourceIds attribute (line 3 below) to "#{ {'Email'} }".

        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:attributeSourceIds="#{ {'Email'} }" />

Test Single Sign-on

Create a test user with active directory. Create an entry on the Admin Console for this user and assign it a license. Then, test logging in to Adobe.com to confirm that the relevant software is listed for download.

If you encounter problems, please see our troubleshooting document.

If you still require assistance with your single sign-on configuration, navigate to Support in the Adobe Admin console, and open a ticket.

Този материал е лицензиран под лиценз Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported  Публикациите в Twitter™ и Facebook не попадат под клаузите на Creative Commons.

Правни бележки   |   Правила за онлайн поверителност