OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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



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

> Why would this be bad practice? Do you mean that nobody else does, or
> there something inherently bad about having a variable query string in
> 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,
> not separate from it. So If my AssertionConsumerURL contains a query
> the responder MUST respond to that URL, including the query string.

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

> However, this should not affect the format of
> The responder should compare the incoming value against its metadata,
> 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
> the responder should respond to the full AssertionConsumerServiceURL,
> 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

> I realise I am tilting at windmills, but if there is a valid
> 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
> advantage of being explicitly described as doing what we need it to


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

It's not that different. Whatever you do that involves a cookie will
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
for that purpose, and XML IDs have specific syntax and uniqueness

-- Scott

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]