[Shib-Users] Rejecting replayed message ID

[James Bardin]

Hi,

Are there any conditions other than a straightforward replay, that can
trigger a replay error in a saml2 request?

A vendor using a SAML2 SP (probably java OpenSAML based) will
occasionally cause clients to get
"Error Message: Message did not meet security requirements", and the
corresponding "SecurityPolicyException: Rejecting replayed message ID
'EC0C9AB30A0A3CA900116902CE41BB72' from ..." in the logs. I haven't
yet gotten it to trigger on our test idp with logging at debug level.

Unfortunately, this is somewhat random, and we haven't been able to
reproduce it on demand. It can happen on both first authentication,
and when the client needs to re-authenticate. The message ID isn't a
replay, as it only shows up once in all the logs. The only other SAML2
SP we use is google, which doesn't have the problem, and the rest are
shibboleth.

--
James Bardin <jba...@bu.edu>
Systems Engineer
Boston University IS&T

[Cantor, Scott E.]

> Are there any conditions other than a straightforward replay, that can
> trigger a replay error in a saml2 request?

No, but the usual cause of *that* is the back button, which is why I trap that error message in order to customize the error page.

-- Scott

[James Bardin]

That's what I thought too, though I'm certain that this isn't direct
use of the back-button, but I think it's a similar situation.

I managed reproduce a case that looks like what users are reporting
(although this seems contrived). If I go to the SP protected url, and
get redirected to the IdP login, and for some reason don't finish the
auth process, then later with the same browser I again go to the that
SP, their server will hand me the same message ID. This surprised me,
because the apache mod_shib doesn't do this.

Could this could same situation happen if the shib session in the idp
timed out, and the SP attempted to re-authenticate an existing session
(is there such a thing as re-auth'ing a existing session)?

Thanks,

[Cantor, Scott E.]

>I managed reproduce a case that looks like what users are reporting
>(although this seems contrived). If I go to the SP protected url, and
>get redirected to the IdP login, and for some reason don't finish the
>auth process, then later with the same browser I again go to the that
>SP, their server will hand me the same message ID. This surprised me,
>because the apache mod_shib doesn't do this.

It's also incorrect, every SAML request has to have a unique ID.

It sounds like something users would likely do on occasion, though.

>Could this could same situation happen if the shib session in the idp
>timed out, and the SP attempted to re-authenticate an existing session
>(is there such a thing as re-auth'ing a existing session)?

SAML doesn't address sessions specifically, so there's no such concept,
but I don't follow what you're describing exactly. The issue of replay is
independent of the IdP, it's entirely up to the client replaying a message
ID, however that happens.

-- Scott

[James Bardin]

On Thu, Feb 3, 2011 at 7:42 PM, Cantor, Scott E. <cant...@osu.edu> wrote:
>>I managed reproduce a case that looks like what users are reporting
>>(although this seems contrived). If I go to the SP protected url, and
>>get redirected to the IdP login, and for some reason don't finish the
>>auth process, then later with the same browser I again go to the that
>>SP, their server will hand me the same message ID. This surprised me,
>>because the apache mod_shib doesn't do this.
>
> It's also incorrect, every SAML request has to have a unique ID.
>
> It sounds like something users would likely do on occasion, though.
>

Thanks Scott. I got access to the code generating the AuthnRequest,
and lo and behold, they were using the session ID from the webserver
as the ID for the AuthnRequest element. Thus all SAML requests for a
particular browser session will contain the same message ID. It works
once for initial SSO, but on the rare occasion the user hits our IdP
again, they will be flagged as a replay.

Working on a fix with them now.

Thanks again,

[Cantor, Scott E.]

> Thanks Scott. I got access to the code generating the AuthnRequest,
> and lo and behold, they were using the session ID from the webserver
> as the ID for the AuthnRequest element.

Shudder.

Glad you figured it out.

-- Scott