RE: [saml-dev] preserving query parameters in AssertionConsumerServiceURL

["Scott Cantor" <cantor.2@osu.edu>]

Mihaylov, Dimitar wrote on 2009-04-08:
> I don't think it is completely pointless because if I'm not mistaken the
> RelayState is limited to 80 characters and you might have significantly
> longer URLs.

Which is why you store them locally and use a state token. Which you should
anyway because the resource URL isn't the IdP's business to know. It's
actually bad to reveal it because people might get the terrible idea to set
policy at an IdP based on it.
 
> So you might come to a situation that the RelayState cannot
> contain your original URL as it is. In such cases you have to store it
> locally and generate some handle and put this handle in the RelayState.

Right. You always should.

> This will increase the risk of potential Denial of Service (DoS) attacks
> because even without any authentication you store something in a session
> or in a database, etc.

No, I don't think so. You store it in a cookie. I would add that signing
requests can be a fairly major DoS issue, unlike using RelayState.
 
> So back to the question if the AuthnRequest is
> signed and the IdP verifies the signature why not take the ACSURL as it
> is and send the Reponse to it?

Like I said, haven't thought about it and signing requests is just not that
common for our use cases. Seems possible. Perhaps others can indicate if
their IdP will allow for that behavior. The big advantage though is *not*
what you're talking about, it's the ability to forego pre-registration of
the URLs. That's a big win, potentially. Just not sure it's worth opening up
SPs to trivial CPU consumption attacks.
 
-- Scott