Store IdP in SP session before authentication?

[Lukas Hämmerle]

Thanks for the quick response.

On 30.10.18 17:05, Cantor, Scott wrote:
> On 10/30/18, 11:48 AM, "dev on behalf of Lukas Hämmerle"
> <dev-bounces at shibboleth.net on behalf of lukas.haemmerle at switch.ch>
> wrote:
> 
>> So, maybe Scott as one of the authors of the SAML specification
>> could shed some light on if the spec says something on this case.
> 
> The specification allows for some checks to happen if you want them
> to because the IdP has obligations around message IDs.
> 
> Some implementations store request state and some don't.

I just checked against an ADFS SP and it seems - like the Shibboleth SP
- ADFS also accepts the assertion from IdP B.


> Shibboleth doesn't. The main reason is that for it to provide any benefit you
> have to block unsolicited responses, and we've never actually
> provided that feature so it never made much sense to add more
> checking. 

We are glad that unsolicited responses are not blocked :-)


> There are security benefits to blocking them (it prevents
> the XSRF pattern that SAML is generally vulnerable to) but they're
> used so widely that I never saw much chance of people actually
> blocking them.
> 
> If SSP blocks them (or can block them at least), then there are
> advantages to what it's doing, but only if the blocking option were
> turned on. Otherwise you can generally circumvent whatever protection
> it's trying to add.

What do you mean by "whatever protection" in this case?
I'm not sure what SSP supports in this regard but it seems to block an
assertions by default if they come from an IdP that it did not expect.


Best Regards
Lukas


-- 
SWITCH
Lukas Hämmerle, Trust & Identity
GÉANT Project Task Leader of
eduGAIN Service Development - Research and Service Providers
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 05, direct +41 44 268 15 64
lukas.haemmerle at switch.ch, http://www.switch.ch