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

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

> Why would this be bad practice? Do you mean that nobody else does, or is
> there something inherently bad about having a variable query string in the
> AssertionConsumerServiceURL?

It's inherently bad. The SAML profiles requires, or at least strongly
encourages, comparison of ACS URLs against metadata, and if the value is
different for each user, there's no way to successfully compare them.

> As far as I understand RFC3986, query parameters are part or a URL, they
are
> not separate from it. So If my AssertionConsumerURL contains a query
string,
> the responder MUST respond to that URL, including the query string.

This isn't about what one responds to but how the comparison is performed.

> However, this should not affect the format of AssertionConsumerServiceURL.
> The responder should compare the incoming value against its metadata, but
> using a smarter mechanism than a simple string comparison.

And what would that mechanism be?

> Once the incoming URL has been confirmed as associated with the requester,
> the responder should respond to the full AssertionConsumerServiceURL, and
> NOT to the URL held in metadata.

So I should somehow know to drop the query string before comparing them?
What if the actual URL has a query string I'm supposed to include in the
comparison? Which parameters do I include and which ones do I know to drop?

> I realise I am tilting at windmills, but if there is a valid operational
> reason as to why we can't have a variable query string in our
> AssertionConsumerServiceURL I really would like to know it.

Sorry, but I see no way it can work.

> Looking at saml-bindings-2.0-os, yes, you are right, RelayState has the
> advantage of being explicitly described as doing what we need it to do:

Right.

> Btw, they've apparently told my colleagues to use the ID/InResponseTo
> attributes to recover our SessionID, but that feels like a fudge to me.

It's not that different. Whatever you do that involves a cookie will amount
to the same kind of mechanism as using RelayState itself. The reason for
RelayState is that not everybody will want to generate IDs that are suitable
for that purpose, and XML IDs have specific syntax and uniqueness
requirements.

-- Scott