Overview

The Adobe Admin Console allows a system administrator to configure domains which are used for login via Federated ID for Single Sign-On (SSO). Once the domain is verified, the directory containing the domain is 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.

Prerequisites

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

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

Note:

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

Configure single sign-on using Shibboleth

To configure single sign-on for your domain, do the following:

  1. Sign in to the Admin Console and start with creating a Federated ID directory, selecting Other SAML Providers as the identity provider. Copy the values for ACS URL and Entity ID from the Add SAML Profile screen.
  2. Configure Shibboleth specifying the ACS URL and Entity ID, and download the Shibboleth metadata file.
  3. Return to the Adobe Admin Console and upload the Shibboleth metadata file in the Add SAML Profile screen and click Done.

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:

    %{idp.home}/metadata/

  2. Update the file to ensure the correct information is passed back to Adobe.

    Replace the following lines in the file:

    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>

    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>

    With:

    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>

    Also, replace:

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

    With:

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

  3. 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.
    -->
    <AttributeFilterPolicyGroup>
    	<AttributeFilterPolicy>
    		<PolicyRequirementRule xsi:type="Requester" value="https://www.okta.com/saml2/service-provider/spiml66pl3iZi7tuI0x7" />
    		<AttributeRule attributeID="NameID">
    			<PermitValueRule xsi:type="ANY" />
    		</AttributeRule>
    		<AttributeRule attributeID="FirstName">
    			<PermitValueRule xsi:type="ANY" />
    		</AttributeRule>
    		<AttributeRule attributeID="LastName">
    			<PermitValueRule xsi:type="ANY" />
    		</AttributeRule>
    		<AttributeRule attributeID="Email">
    			<PermitValueRule xsi:type="ANY" />
    		</AttributeRule>
    	</AttributeFilterPolicy>
    </AttributeFilterPolicyGroup>
  4. 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"
                          xsi:type="FileBackedHTTPMetadataProvider"
                          backingFile="%{idp.home}/metadata/localCopyFromXYZHTTP.xml"
                          metadataURL="http://WHATEVER"> 
            
            <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true">
                <PublicKey>
                    MIIBI.....
                </PublicKey>
            </MetadataFilter>
            <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P30D"/>
            <MetadataFilter xsi:type="EntityRoleWhiteList">
                <RetainedRole>md:SPSSODescriptor</RetainedRole>
            </MetadataFilter>
        </MetadataProvider>
        -->   
    
        <!--
        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:

%{idp.home}/conf/attribute-resolver.xml

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"
       xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
      </resolver:AttributeDefinition>
      <resolver:AttributeDefinition xsi:type="ad:Simple" id="Email"
        sourceAttributeID="mail">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="Email" />
      </resolver:AttributeDefinition>
      <resolver:AttributeDefinition xsi:type="ad:Simple" id="FirstName"
        sourceAttributeID="givenName">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="FirstName" />
     </resolver:AttributeDefinition>
     <resolver:AttributeDefinition xsi:type="ad:Simple" id="LastName"
        sourceAttributeID="sn">
     <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:

%{idp.home}/conf/relying-party.xml

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

<bean parent="RelyingPartyByName" c:relyingPartyIds="[entityId">
	<property name="profileConfigurations">
		<list>
			<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" />
		</list>
	</property>
</bean>

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

Replace:

encryptAssertions="conditional"

With:

encryptAssertions=”never"

3. saml-nameid.xml

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

%{idp.home}/conf/saml-nameid.xml

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

        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
            p:attributeSourceIds="#{ {'Email'} }" />

Upload IdP metadata file to Adobe Admin Console

To update the Shibboleth metadata file:

  1. Return to the Adobe Admin Console.

  2. Upload the Shibboleth metadata file to the Add SAML profile screen.

    After configuring Shibboleth, the metadata file (idp-metadata.xml) is available at the following location on your Shibboleth server:

    <shibboleth>/metadata

  3. Click Done.

For more details, see how to create directories on the Admin Console.

Test Single Sign-on

Check the user access for a user who you have defined in your own identity management system and in the Adobe Admin Console, by logging in to the Adobe website or the Creative Cloud desktop app.

If you encounter problems, 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.

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