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

["Schmidlin, Franck" <Franck.Schmidlin@northgate-is.com>]

I can't resist a final point:

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

Regular Expression patterns spring to mind.
If AssertionConsumerService could be specified in pattern form, either
RegExp or something that can map to a RegExp, then the problem would be
solved.
But I assume that opens another can of worms of some sort :-)


______________________________
Franck Schmidlin
Transformation Technical Consultant - Integration
Technical Architect - Northgate Hub 

Northgate Public Services

Please consider the environment before printing this e-mail


-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: 08 April 2009 16:26
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



------------------------------------------------------------------------
------------
The Northgate IS Content Screening and Inspection system has scanned
this message for malicious and inappropriate content and none was found.
Please take care when opening attachments even when these are expected
and from known and trusted sources. 
------------------------------------------------------------------------
------------

------------------------------------------------------------------------
------------
The Northgate IS Content Screening and Inspection system has scanned
this message for malicious and inappropriate content and none was found.
Please take care when opening attachments even when these are expected
and from known and trusted sources. 
------------------------------------------------------------------------
------------
-----------------------------------------------------------------------------------------
This email is sent on behalf of Northgate Information Solutions Limited and its associated companies ("Northgate") and is strictly confidential and intended solely for the addressee(s).  
 
If you are not the intended recipient of this email you must: (i) not disclose, copy or distribute its contents to any other person nor use its contents in any way or you may be acting unlawfully;  (ii) contact Northgate immediately on +44 (0)1442 232424 quoting the name of the sender and the addressee then delete it from your system.
 
Northgate has taken reasonable precautions to ensure that no viruses are contained in this email, but does not accept any responsibility once this email has been transmitted.  You should scan attachments (if any) for viruses.
 
Northgate Information Solutions Limited. Registered in England no. 06442582  -  Northgate Information Solutions UK Limited. Registered in England no. 968498  -  NorthgateArinso UK Limited .Registered in England no. 1587537  -  Moorepay Limited.  Registered in England no. 891686  -  Northgate Land & Property Solutions Limited  -  Registered in England no. 2149536 Registered Office: Peoplebuilding 2, Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire HP2 4NW 
 
Northgate Managed Services Limited (NI).  Registered in Northern Ireland no. NI032979  -  LearnServe Limited (NI).  Registered in Northern Ireland no. NI043825
Registered Office: Hillview House, 61 Church Road, Newtownabbey, Co. Antrim, BT36 7LQ 

-----------------------------------------------------------------------------------------