This is not a replacement for the actual documentation and you cannot cut and paste your way to a working system. The examples are not usable without taking into consideration your local needs and requirements.

The Adobe Creative Cloud service (helpfully called "Adobe SSO" in their documentation and also referred to as "Adobe Experience" and "Adobe Target"), is used to offer access to the Adobe suite of software products.   Many organisations are now being encouraged to use their SAML integration.

Their documentation for Shibboleth IdP can be found at https://helpx.adobe.com/enterprise/kb/configure-shibboleth-with-adobe-sso.html.  However, it  recommends changing much of the default NameID configuration, which would be unacceptable to an already operational IdP, and also configuring and releasing additional attributes using non-standard names which isn't required.

The Adobe service is provided via a SAML IdP/SP Proxy (Okta), it is the Okta SP that you are integrating with.


Identity Provider Metadata

The Service Provider does not consume an Identity Provider Metadata file and it must be configured using the Adobe Admin Console - https://adminconsole.adobe.com/enterprise

Service Provider Metadata

The Service Provider provides metadata to be consumed by your Identity Provider is not semantically correct.   This is evident in the Adobe documentation where it suggests a number of modifications.  Issues with the SP metadata are as follows;


<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor entityID="https://www.okta.com/saml2/service-provider/xxxxxxxxxxxxxxxxxxxx" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://adbe-yyyyyyyyyyyyyyyyyyyyyyyy-yyyy-prd.okta.com/auth/saml20/accauthlinktest" index="0" isDefault="true"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Profile Requirements

Example Shibboleth Configuration

Refer to the RelyingPartyConfiguration topic and be cognizant that creating overrides for every service is generally an inefficient use of the software. Consider identifying common requirements across services and create overrides tied to multiple services that share those requirements, or that reference profile configuration beans containing common settings.

	<!-- Container for any overrides you want to add. -->

	<util:list id="shibboleth.RelyingPartyOverrides">

		<!-- other overrides... -->

		<!-- SPs that dont support encryption of data to them. -->
      <bean parent="RelyingPartyByName" c:relyingPartyIds="https://www.okta.com/saml2/service-provider/xxxxxxxxxxxxxxxxxxxx">
          <property name="profileConfigurations">
              <list>
                  <bean parent="SAML2.SSO" p:encryptAssertions="false" />
              </list>
          </property>
      </bean>


	</util:list>

Account Provisioning

Account provisioning is via the Adobe Admin Console - https://adminconsole.adobe.com/enterprise.  Other methods exist such as via an API - https://adobe-apiplatform.github.io/umapi-documentation/en/UM_Authentication.html

NameID Requirements

The SP requires a NameID either in the format of urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress  or in another format, cf. "User Login Setting" when configuring the SP in the admin console mentioned above.

Other more stable identifiers and attributes could be used over and above email address, such as pairwise-id / subject-id attribute, eduPersonPrincipalName, uid or sAMAccountName, that would require a different configuration to that listed in the examples here.  This will link into what can be configured in the Account Provisioning above and the User Login Setting in the Adobe Admin Console.

Example Shibboleth Configuration

Refer to the NameIDGenerationConfiguration topic for a full treatment of NameID features.

	<!-- SAML 2 NameID Generation -->
	<util:list id="shibboleth.SAML2NameIDGenerators">

		<ref bean="shibboleth.SAML2TransientGenerator" />

		<!--
		<ref bean="shibboleth.SAML2PersistentGenerator" />
		-->

		<!--
		Add custom support for email-based NameID, assumes you've released
		the source attribute (mail) to any SPs expecting to get it.
		-->
		<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
			p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
			p:attributeSourceIds="#{ {'mail'} }"/>

	</util:list>

Attribute Requirements

In addition to the mail attribute and NameID the Adobe documentation suggests that attributes with the name FirstName, LastName and Email are required.   However, the SP does support the follow standard attributes with NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" out of the box:

Example Shibboleth Configuration

The following is an example attribute-filter configuration

    <!-- Adobe Cloud SP -->
    <AttributeFilterPolicy id="AdobeCloudSP">
        <PolicyRequirementRule xsi:type="Requester" value="https://www.okta.com/saml2/service-provider/xxxxxxxxxxxxxxxxxxxx" />
        <AttributeRule attributeID="mail">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="givenName">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="sn">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
     </AttributeFilterPolicy>

Note an example attribute-resolver configuration is not provided here, but configuration might be required.   This should be a fairly simple attribute to configure given it will in most cases map to the equivalent LDAP attribute.