Unsolicited SSO with AuthnRequestsSigned="true" SP metadata

Peter Schober peter.schober at univie.ac.at
Tue Nov 28 13:00:09 EST 2017


* Santu Ghosh <mon.snahasish at gmail.com> [2017-11-28 18:48]:
> Can anyone help me, what changes I have to do in my IDP side so that I can
> proceeded with my SP metadata (with WantAssertionsSigned="true") for
> Unsolicited SSO.

"WantAssertionsSigned" has nothing do to with anything here.
The rest I've already explained.

If the SP insists that all its SSO requests will be cryptographically
signed then the IDP can't allow unsigned requests, ergo no proprietary
"Shibboleth protocol" requests either as they have no povision for
being signed.

So this comes down to Trust Management (see the Shibboleth wiki
article of the same name) and who manages the metadata for that SP,
and how updates are communicated.
If the SP metadata is just a static XML file on disk of your IDP all
you need to do is remove AuthnRequestsSigned="true" from it and you're
done.
If you're getting this metadata from elsewhere (e.g. from the SP, from
a trusted third party, etc.) that moves the fix for the problem
elsewhere, too. Unless you're prepared to automatically change the
metadata on each refresh locally before you feed it to your IDP.

I'm not aware of a configuration in the IDP that would allow it to
ignore the SP's explicit request to reject unsigned authrequests
(since that would make it non-conformant) I wouldn't be surprised if
the IDP could in fact be configured to allow for that.

In practice you should probably just stop obsessing about "Unsolicited
SSO" (you've been at this for how many weeks now?) and simply use
SP-initiated SSO. SSO has to start somewhere, somehow, so it might as
well be a URL to the SP, not to the IDP. Problem solved, with no
ongoing maintenance nightmare.

-peter


More information about the users mailing list