[Shib-Users] Idp not posting saml response back to SP

[Roy, Nicholas S]

We are in the middle of an IdP upgrade to version 2.3.3, and this issue started showing up in our logs after the update.  It does appear to be related (as Scott's said) to invalid authentication on the part of a user attempting to log in.  My concern with this is that the entire stack trace gets logged in the IdP logs, which presents a pretty distinct path to a denial of service attack on the part of an attacker.  If you want to DoS the IdP service for someone, you just do a bunch of invalid authN attempts and fill up their disk with log files.  Would it be possible to handle this issue as a WARN and not log the entire stack trace?

Thanks,

Nick Roy

-----Original Message-----
From: shibboleth-users-request at internet2.edu [mailto:shibboleth-users-request at internet2.edu] On Behalf Of Daniel Appleby
Sent: Monday, November 08, 2010 9:23 PM
To: shibboleth-users at internet2.edu
Subject: RE: [Shib-Users] Idp not posting saml response back to SP

We were running 2.2.0 and rolled back to 2.1.5 and the problem has gone. :). Same config.

Looks like some sort of bug in 2.2.0.

Regards,
daniel

-----Original Message-----
From: shibboleth-users-request at internet2.edu [mailto:shibboleth-users-request at internet2.edu] On Behalf Of Viitanen Viljo
Sent: Tuesday, 9 November 2010 1:57 AM
To: cantor.2 at osu.edu; shibboleth-users at internet2.edu
Subject: RE: [Shib-Users] Idp not posting saml response back to SP

FYI: I've seen the exact same issue, with many browsers on different machines while testing IDP 2.2.0. With 2.1.5 there are no problems.

Viljo Viitanen
University of Jyväskylä

-----Original Message-----
From: Scott Cantor [mailto:cantor.2 at osu.edu]
Sent: Friday, November 05, 2010 4:13 AM
To: shibboleth-users at internet2.edu
Subject: RE: [Shib-Users] Idp not posting saml response back to SP

> ####### The idp should send a post response back here but instead 
> redirects to itself (/profile/SAML2/Redirect/SSO) without the SAML 
> Request that was sent above...hence the decode error...

If it's redirecting to itself, LiveHeaders will show that. So again, I suggest that until there's client evidence, we're guessing. The fact that the next thing the IdP logs is that request doesn't mean something isn't happening in between.

The alternative is that this is one of those weird "client just doesn't act right" cases. Have you tried different browsers, different machines, etc?
Disabled all plugins?

-- Scott