Adobe SSO

[Boyd, Todd M.]

You can truly validate that it is being sent if you turn on debugging for the assertions. You will see the SAML response in its entirety--you can even see it before encryption takes place if you turn on debugging for encryption.

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Jann Malenkoff <jannmalenkoff at gmail.com>
Sent: Thursday, August 2, 2018 9:30:33 AM
To: Shib Users
Subject: Re: Adobe SSO

Thank you Peter!

The following appears in the logs -- can I assume that it is being sent?

2018-08-02 07:24:43,513 - DEBUG [net.shibboleth.idp.saml.profile.impl.ExtractSubjectFromRequest:144] - [48DD30BAA780B9437CF580FB2FC1F123] - [] - Profile Action ExtractSubjectFromRequest: No Subject NameID/NameIdentifier in message needs inbound processing
2018-08-02 07:24:58,422 - DEBUG [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:124] - [48DD30BAA780B9437CF580FB2FC1F123] - [] - Configuration specifies the following formats: [urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress]
2018-08-02 07:24:58,422 - DEBUG [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:145] - [48DD30BAA780B9437CF580FB2FC1F123] - [] - Filtered non-metadata-supported formats from configured formats, leaving: [urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress]

On Thu, Aug 2, 2018 at 5:13 AM, Peter Schober <peter.schober at univie.ac.at<mailto:peter.schober at univie.ac.at>> wrote:
* Jann Malenkoff <jannmalenkoff at gmail.com<mailto:jannmalenkoff at gmail.com>> [2018-08-02 09:24]:
> We have the following configure -- but for the life of me can't figure out
> why the NameID is not sent --- can anyone spot anything obvious we missed?
>
> RELYING-PARTY.XML
> p:nameIDFormatPrecedence="#{{'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'}}"

If you control a local copy of the SP's metadata (as you do) you don't
need to override the NameIDFormat here. The IDP uses what's listed
first in metadata.

> ADOBE METADATA IMPORTED
> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
> entityID="https://www.okta.com/saml2/service-provider/">

Hardly "ADOBE METADATA", btw.

>           <md:KeyDescriptor use="signing">

Assuming the metadata you sent was complete that means your IDP will
not even interop with that SP due to a lack of a key usable for
encryption -- unless you have globally set idp.encryption.optional in
your conf/idp.properties.

But encrypting NameIDs defaults to off for many many years now, so the
only thing this should affect (if the IDP completes SSO at all) are
the attributes you send along (FirstName, LastName, Email).
Which is not what this question of yours is about.

> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>

Having that in the metadata will suffice.

> SAML-NAMEID.XML
> <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>
> p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
>             p:attributeSourceIds="#{ {'Email'} }" />

I'd add p:omitQualifiers="true" there for good measure but otherwise
that looks OK.

> ATRIBUTE-FILTER.XML
>
> <AttributeFilterPolicy id="https://www.okta.com/saml2/service-provider/">
>         <PolicyRequirementRule xsi:type="Requester" value="https://www.okta.com/saml2/service-provider/"/>
[...]
>         <AttributeRule attributeID="Email">
>             <PermitValueRule xsi:type="ANY" />
>         </AttributeRule>
>     </AttributeFilterPolicy>

OK.

> ATTRIBUTE-RESOLVER.XML
> <resolver:AttributeDefinition id="Email" xsi:type="ad:Simple" sourceAttributeID="mail">
>     <resolver:Dependency ref="myLDAP" />
>     <resolver:AttributeEncoder xsi:type="enc:SAML2String" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
> name="Email" encodeType="false" />
> </resolver:AttributeDefinition>

Unless the SP positively requires that nameformat (and you've verfied
that empirically, which you only can once you got it working with the
nonsensical format, and then work back from that) just leave the
default as per conf/attribute-resolver-full.xml, for of these
attributes.

TL;DR: Nothing really sticks out. You can always up the log level and
watch what gets set as NameID and what not, and why.

-peter
--
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<mailto:users-unsubscribe at shibboleth.net>