Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

This is a template for an integration guide for a SAML-supporting application. Typically these are mostly made up of corrections and gap-filling to the usually inaccurate or incomplete SAML technical documentation provided by applications or vendors, along with examples of how to configure the IdP to support whatever special requirements may exist.

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 encourage 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 is recommends changing many the default NameID configuration, which would be unacceptable to an already operational IdP, and also configuring and releasing additional attributes using non-standard names.

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

If there are "unknowns" or open questions to highlight, use a blockquote, like this.


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. 

  • IdP Certificate - It does not support SAML encryption, but it does support SAML signing, therefore you must provided 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
  • 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")

Service Provider Metadata

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

  • It suggests you change AuthnRequestsSigned and WantAsssertionsSigned from true to false
  • It suggests you remove the NameIDFormat's 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 is not required.

Profile Requirements

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

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.

Describe ways to account for any special requirements noted above. Could include examples of relying-party.xml changes or additions, or other suggestions in rare situations.

Example relying-party.xml override 
	<!-- Container for any overrides you want to add. -->

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

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

		<!-- SPs that required signed assertions but don't indicate that in their metadata. -->
      <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

Account provisioning is via the Adobe Admin Console - https://adminconsole.adobe.com/enterprise.  However, 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 in the format of urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress containing an emailAddress or other identifier used in "User Login Setting" when configuring the SP

Is using another identifier a valid use of this NameID format?

Example Shibboleth Configuration

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

Example saml-nameid.xml changes 
	<!-- 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 RequirementsA

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

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

Example Shibboleth Configuration

The following is an example attibute-filter configuration

Example attribute-filter.xml changes 
    <!-- 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 will be required.   This should be a fairly simple attribute to configure give it will in most cases map to the equivalent LDAP attribute.

  • No labels