...
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 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 is it recommends changing many 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 provided by (Okta), it is the Okta SP that you are integrating with.
...
Service Provider Metadata
The Service Provider provided 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;
- 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 Supports signed responses, which is the Shibboleth default.
- Encryption is not supported and thus has to be disabled.
Example Shibboleth Configuration
| Tip |
|---|
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. |
...
. |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<!-- 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 is via the Adobe Admin Console - https://adminconsole.adobe.com/enterprise. However, other Other methods exist such as via an API -https://adobe-apiplatform.github.io/umapi-documentation/en/UM_Authentication.html
...
The SP requires a NameIdentifier in the format of urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress containing an emailAddress email address or other identifier used in "User Login Setting" when configuring the SP in the admin console mentioned above.
Is using another identifier a valid use of this NameID format?
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<!-- 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 configuration might be required. This should be a fairly simple attribute to configure give it will in most cases map to the equivalent LDAP attribute.
...