Store IdP in SP session before authentication?
Cantor, Scott
cantor.2 at osu.edu
Tue Oct 30 12:05:36 EDT 2018
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. 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. 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.
-- Scott
More information about the dev
mailing list