unsolicited SSO question regarding AuthnRequestsSigned="true"

Tue Oct 22 12:04:04 EDT 2019

Les,

You won't be able to make unsolicited SSO requests on behalf of a vendor that requires AuthnRequestsSigned.  Yes, they are mutually exclusive, and for them to not be, you would need the SP's private key, which is a bad idea for all kinds of reasons.

Signed AuthnRequests only add value in a very limited number of use cases.  I don't know if you're working with one or not.

The ability to send a truly unsolicited assertion would be accomplished most naturally by removing that flag from their metadata.  It's the obverse but it still demonstrates the fact:

https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfiguration

Another way you can disable support for this feature for specific services is by modifying their SAML metadata to include AuthnRequestSigned="true" in the <SPSSODescriptor> element. Doing so causes the IdP to require requests from that SP to be signed, and since this protocol does not allow for signing, it will cause such requests to fail with an error.

The rest would all be true from my perspective.

Take care,

Nate.

--------

The Art of Access ®

Nate Klingenstein | Principal

https://www.signet.id/ 

-----Original message-----
From: Les LaCroix
Sent: Tuesday, October 22 2019, 9:46 am
To: Shib Users
Subject: unsolicited SSO question regarding AuthnRequestsSigned="true"

Hi,
 I have a vendor that requires unsolicited SSO.  Their metadata says 'AuthnRequestsSigned="true"'.  When I go to the unsolicited SSO link
 https://.../idp/profile/SAML2/Unsolicited/SSO?providerId=vendorID
 I get the error " SPSSODescriptor for entity ID ... indicates AuthnRequests must be signed, but inbound message was not signed".  I am watching my browser traffic and it's only interacting with the IdP.  The error is happening before the IdP sends any SAML back, and there is no explicit authnRequest SAML being sent.  Also, I am doing this in an incognito window, and it's happening before I go through a login flow.
 Since there isn't any interaction with the SP, does that mean that AuthnRequestsSigned="true" in SP metadata and unsolicited SSO are mutually exclusive?   I can imagine that the IdP is, in effect, responding to an implicit authN request made on behalf of the SP.  There is clearly no way an (implicit) request could be signed with the SP's (private) signing key.  Most of the conversations on this topic in the list archive essentially end up with "tell the vendor to fix their metadata."  Is there any place I can point the vendor to that says AuthnRequestsSigned must be "false" for unsolicited SSO so they will fix their metadata?
 On the other hand, there isn't any explicit authnRequest being sent.  In that case I kind of feel like the IdP should ignore the SP's AuthnRequestsSigned, and the metadata isn't wrong, per se.  It puts me in a much weaker position to ask them to change it.  Also, if they ever implemented SP-initiated SSO, AuthnRequestsSigned="true" seems like it might be a good idea.
 Is this a problem with the vendor's metadata?  A problem with the IdP?  Or just a problem with my understanding of SAML?  :-)   I can change my local copy of the metadata to say AuthnRequestsSigned="false", and that's what I'm doing while I try to convince them to change it at the source.  It's a problem lying in wait if we ever have to update their metadata, though.
 Thanks in advance, -Les
 p.s. I am seeing this with IdP 3.4.3, in case that matters.
 --------------------------------
Les LaCroix '79 | Strategic Technologist
Carleton College | 1 N. College St. | MS 3-ITS | Northfield, MN 55057
507.222.5455

-- 

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/20191022/f5d286eb/attachment.html>