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

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

Hi Scott, hi Franck,

AssertionConsumerServiceURL [Optional]
Specifies by value the location to which the <Response> message MUST be
returned to the
requester. The responder MUST ensure by some means that the value
specified is in fact associated
with the requester. [SAMLMeta] provides one possible mechanism; signing
the enclosing
<AuthnRequest> message is another. This attribute is mutually exclusive
with the
AssertionConsumerServiceIndex attribute and is typically accompanied by
the
ProtocolBinding attribute. 

I would interpret the part "signing the enclosing <AuthnRequest> message
is another" that if the AuthnRequest is signed no comparision with the
metadata is necessary? Is this correct? If yes then I do not see any
problem putting any URL as value - containing parameters, etc. What do
you think?

Regards,

Dimitar

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Wednesday, April 08, 2009 6:26 PM
To: 'Schmidlin, Franck'; saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] preserving query parameters in
AssertionConsumerServiceURL

> 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



---------------------------------------------------------------------
To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: saml-dev-help@lists.oasis-open.org