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

["Mihaylov, Dimitar" <dimitar.mihaylov@sap.com>]

Hi Scott,

>> 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. 

Do you mean a single cookie or one for each request? In the first case
you will get problems with parallel requests because the cookie might be
overwritten before you get response from the IdP. In the second case I
think there will be problems with their cleanup. If they are not
reliably cleaned up you may lose some other cookies (even such as
jsessionid, etc.) because of the limitation of 20 cookies per server.

Regards,

Dimitar

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Wednesday, April 08, 2009 8:43 PM
To: Mihaylov, Dimitar
Cc: saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] preserving query parameters in
AssertionConsumerServiceURL

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