Adobe SSO

[Jann Malenkoff]

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>
wrote:

> * Jann Malenkoff <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180802/3bb1f741/attachment.html>