IDP rely configuration - Adobe suggests a modification of default behaviour - any hints?

[Baron Fujimoto]

We just went through this here. AFAIK, they require an email address for both the NameID format and the released attribute - and that attribute must be named "Email". Adobe does not seem flexible on this. Perhaps you could use some non-email value for that attribute? They send email to users though, and if the Email attribute is their source for the recipient address, that functionality would presumably break if you did that.

Since they also have you replace the NameIDFormat in the metadata, you don't need to specify the preference in their relying party entry.

This thread from last year was also helpful  <http://shibboleth.1660669.n2.nabble.com/Adobe-SSO-tc7639936.html>.

FWIW, Adobe also has documentation for InCommon members that doesn't work. They essentially require you to manage their SP metadata in the InC aggregate using your Federation Manager account. But the x509 certificate they provide in their metadata does not meet InC's minimum key length. Furthermore, InC wants you to add a DNS TXT record for Domain Control Validation of the EntityID, but since Adobe is using okta.com for their EntityId's, we can't modify DNS for domains we don't control either so... we fell back on their non-InC Shibboleth config to get SSO working.

On Mon, Feb 11, 2019 at 04:07:08PM +0100, Dr. Guenther Schreiner wrote:
>During implementation of a Adobe contract, the software provider
>suggests
>(https://helpx.adobe.com/de/enterprise/kb/configure-shibboleth-with-adobe-sso.html)
>to modify the default configuration relying-party.xml to:
>        
><bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
>    <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" />
>            <ref bean="SAML2.ECP" />
>            <ref bean="SAML2.Logout" />
>            <ref bean="SAML2.AttributeQuery" />
>            <ref bean="SAML2.ArtifactResolution" />
>            <ref bean="Liberty.SSOS" />
>        </list>
>    </property>
></bean>
>
> This, of course, is not our intention to push the personal mail address
>to any SP.
>
> Is there a reasonable approach to limit this behaviour to the Adobe SP?
>
>Best regards,Guenther

>-- 
>For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
>To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum