unsolicited SSO question regarding AuthnRequestsSigned="true"

[Les LaCroix]

>
> There is always an explicit request.


Quibble.  There is no SAML stanza "samlp:AuthnRequest" being received by
the IdP unless the IdP itself is generating it.  There certainly isn't
anything being provided by my browser like what would be redirected through
the browser for an SP-initiated session.

Your point is well taken, though.  Thanks for framing it in a way that will
make it easier to explain to the vendor.

-L

------------------------------
Les LaCroix '79 | Strategic Technologist
Carleton College | 1 N. College St. | MS 3-ITS | Northfield, MN 55057
507.222.5455


On Tue, Oct 22, 2019 at 11:03 AM Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 10/22/19, 11:46 AM, "users on behalf of Les LaCroix" <
> users-bounces at shibboleth.net on behalf of llacroix at carleton.edu> wrote:
>
> > Since there isn't any interaction with the SP, does that mean that
> AuthnRequestsSigned="true" in SP metadata and
> > unsolicited SSO are mutually exclusive?
>
> Yes.
>
> > 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?
>
> Not if common sense isn't sufficient.
>
> > On the other hand, there isn't any explicit authnRequest being sent.
>
> There is always an explicit request. Failure to enforce the flag would
> mean the flag meant nothing since any attacker would simply bypass the
> normal flow and issue an unsigned redirect to get around the policy the
> flag is trying to impose.
>
> > 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.
>
> If the metadata is unsigned, or doesn't have a proper sliding validity
> window, or isn't being resigned frequently, then it is inherently a problem
> to rely on it since it breaks the security model of the system, so the
> problem is largely moot in practice.
>
> -- Scott
>
>
> --
> 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/6fdac5a6/attachment.html>