<div dir="ltr"><div>Thank you Peter!</div><div><br></div><div>The following appears in the logs -- can I assume that it is being sent?<br></div><div><br></div><div>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<br>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]<br>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]<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 2, 2018 at 5:13 AM, Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Jann Malenkoff <<a href="mailto:jannmalenkoff@gmail.com">jannmalenkoff@gmail.com</a>> [2018-08-02 09:24]:<br>
<span class="">> We have the following configure -- but for the life of me can't figure out<br>
> why the NameID is not sent --- can anyone spot anything obvious we missed?<br>
> <br>
> RELYING-PARTY.XML<br>
</span><span class="">> p:nameIDFormatPrecedence="#{{'<wbr>urn:oasis:names:tc:SAML:1.1:<wbr>nameid-format:emailAddress'}}"<br>
<br>
</span>If you control a local copy of the SP's metadata (as you do) you don't<br>
need to override the NameIDFormat here. The IDP uses what's listed<br>
first in metadata.<br>
<span class=""><br>
> ADOBE METADATA IMPORTED<br>
> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:<wbr>SAML:2.0:metadata"<br>
> entityID="<a href="https://www.okta.com/saml2/service-provider/" rel="noreferrer" target="_blank">https://www.okta.<wbr>com/saml2/service-provider/</a>"><br>
<br>
</span>Hardly "ADOBE METADATA", btw.<br>
<br>
>           <md:KeyDescriptor use="signing"><br>
<br>
Assuming the metadata you sent was complete that means your IDP will<br>
not even interop with that SP due to a lack of a key usable for<br>
encryption -- unless you have globally set idp.encryption.optional in<br>
your conf/idp.properties.<br>
<br>
But encrypting NameIDs defaults to off for many many years now, so the<br>
only thing this should affect (if the IDP completes SSO at all) are<br>
the attributes you send along (FirstName, LastName, Email).<br>
Which is not what this question of yours is about.<br>
<span class=""><br>
> <md:NameIDFormat>urn:oasis:<wbr>names:tc:SAML:1.1:nameid-<wbr>format:emailAddress</md:<wbr>NameIDFormat><br>
<br>
</span>Having that in the metadata will suffice.<br>
<span class=""><br>
> SAML-NAMEID.XML<br>
> <bean parent="shibboleth.<wbr>SAML2AttributeSourcedGenerator<wbr>"<br>
> <br>
> p:format="urn:oasis:names:tc:<wbr>SAML:1.1:nameid-format:<wbr>emailAddress"<br>
>             p:attributeSourceIds="#{ {'Email'} }" /><br>
<br>
</span>I'd add p:omitQualifiers="true" there for good measure but otherwise<br>
that looks OK.<br>
<span class=""><br>
> ATRIBUTE-FILTER.XML<br>
> <br>
> <AttributeFilterPolicy id="<a href="https://www.okta.com/saml2/service-provider/" rel="noreferrer" target="_blank">https://www.okta.com/<wbr>saml2/service-provider/</a>"><br>
>         <PolicyRequirementRule xsi:type="Requester" value="<a href="https://www.okta.com/saml2/service-provider/" rel="noreferrer" target="_blank">https://www.okta.com/<wbr>saml2/service-provider/</a>"/><br>
</span>[...]<br>
<span class="">>         <AttributeRule attributeID="Email"><br>
>             <PermitValueRule xsi:type="ANY" /><br>
>         </AttributeRule><br>
>     </AttributeFilterPolicy><br>
<br>
</span>OK.<br>
<span class=""><br>
> ATTRIBUTE-RESOLVER.XML<br>
> <resolver:AttributeDefinition id="Email" xsi:type="ad:Simple" sourceAttributeID="mail"><br>
>     <resolver:Dependency ref="myLDAP" /><br>
>     <resolver:AttributeEncoder xsi:type="enc:SAML2String" nameFormat="urn:oasis:names:<wbr>tc:SAML:2.0:attrname-format:<wbr>unspecified"<br>
> name="Email" encodeType="false" /><br>
> </resolver:<wbr>AttributeDefinition><br>
<br>
</span>Unless the SP positively requires that nameformat (and you've verfied<br>
that empirically, which you only can once you got it working with the<br>
nonsensical format, and then work back from that) just leave the<br>
default as per conf/attribute-resolver-full.<wbr>xml, for of these<br>
attributes.<br>
<br>
TL;DR: Nothing really sticks out. You can always up the log level and<br>
watch what gets set as NameID and what not, and why.<br>
<span class="HOEnZb"><font color="#888888"><br>
-peter<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/<wbr>confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</font></span></blockquote></div><br></div>