Adobe SSO

Thu Aug 2 11:05:53 EDT 2018

Grrr -- I should have check that, apologies -- you are right.

Via SAML Trace --- it's not being sent.

<saml2:Subject> <saml2:SubjectConfirmation Method=
"urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData
Address="" InResponseTo="id2563797135943584976540087" NotOnOrAfter=
"2018-08-02T14:51:10.924Z" Recipient="
https://adbe-016336715ad681bc0a495e8a-36b2-prd.okta.com/auth/saml20/accauthlinktest
" /> </saml2:SubjectConfirmation> </saml2:Subject>

Any ideas where else to investigate? The Adobe help did not seem to know
what's next and taking us on a wild-goose chase.

On Thu, Aug 2, 2018 at 7:42 AM, Boyd, Todd M. <tmboyd1 at ccis.edu> wrote:

> 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>
>
> --
> 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/66bc9656/attachment.html>