Page Comparison

...

• IdP Certificate - It does not support SAML encryption, but it does support SAML signingsignature validation, therefore you must provided provide your SAML signing certificate (you may only have one if you use it for both purposes)
• IdP Binding - set to Redirect
• User Login Setting - This will come down to your individual deployment.   Many may choose to use Email address or another attribute.
• IdP Issuer - is the entityID of your IdP
• IdP Login URL - this is your HTTP-Redirect binding (the Location shown in your IdP metadata under  SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect")

...

• It suggests you change AuthnRequestsSigned and WantAsssertionsSigned from true to false
• It suggests you remove the NameIDFormat's NameIDFormats that it doesn't support, and add the one that it does.
• It provides a signing key which only has 1024-bits, but never signs an AuthnRequest so KeyInfo a KeyDescriptor element is not required.

<?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

• Supports signed responses, which is the Shibboleth default.
• Encryption is not supported and thus has to be disabled.

...

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

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

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

		<!-- SPs that requireddont signedsupport assertionsencryption butof don'tdata indicate that in their metadatato them. -->
      <bean parent="RelyingPartyByName" c:relyingPartyIds="https://www.okta.com/saml2/service-provider/xxxxxxxxxxxxxxxxxxxx">
          <property name="profileConfigurations">
              <list>
                  <bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" p:encryptAssertions="false" />
              </list>
          </property>
      </bean>


	</util:list>

...

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 NameIdentifier NameID either in the format of urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress containing an email address or other identifier used in 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

...

	<!-- 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'} }" 
            <property name="activationCondition">
                <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidates="#{{'https://www.okta.com/saml2/service-provider/xxxxxxxxxxxxxxxxxxxx'}}" />
       

   </property>
        </bean>

	</util:list>

Attribute Requirements

In addition to the mail attribute and NameIdentifier.  The 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:

• givenName (urn:oid:2.5.4.42)
• sn (urn:oid:2.5.4.4)
• mail (urn:oid:0.9.2342.19200300.100.1.3)

...

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

...