[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] preserving query parameters in AssertionConsumerServiceURL
Scott, apologies for the delayed
follow-up, it's one of those weeks...
Thanks for your response, but I
still need convincing of what can or cannot be done with
AssertionConsumerServiceURL.
> I can't speak for what the standard
intended, but I think this is bad practice and our implementation wouldn't allow
it.
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?
Saml-core-2.0-os line 2061 reads: "AssertionConsumerServiceURL [Optional] Specifies by value the
location to which the <Response>
message MUST be returned to the
requester."
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.
> We do direct comparisons against the
metadata, so using a query string that would vary would break
it.
I think my service provider
does the same (applying a level of authentication to the
AssertionConsumerServiceURL to make sure it matches a predefined list).
This
is consistent with the standard. Saml-core-2.0-os line 2063 reads: " 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."
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.
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.
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.
> I think you should be putting that information into RelayState.
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:
"If a SAML request message is accompanied by RelayState data, then the SAML responder MUST return its SAML protocol response using a binding that also supports a RelayState mechanism, and it MUST place the exact data it received with the request into the corresponding RelayState parameter in the response."
I'll check with our Service Provider if they
actually support that feature.
Checking the trace I have I think they use
Tivoli FIM
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.
Thanks for your help
______________________________
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: 03 April
2009 18:12
To: Schmidlin, Franck; saml-dev@lists.oasis-open.org
Subject:
RE: [saml-dev] preserving query parameters in
AssertionConsumerServiceURL
> However, the decoded SAMLResponse is
sent to
> /ufs/user/framedResponse.jsp?app=ABC without the necessary
esessionid
> parameter.
The URL you sent had some kind of embedded
ampersand URL-encoded into it, it probably tripped a bug in some
fashion.
> I am trying to argue with the Assertion providers that this
violates
> the SAML standard, but I have failed to back this up with
appropriate
> references.
>
> Could you help me argue my point
that the AssertionConsumerServiceURL
value
> should be used as it by
the assertion provider, without modification?
I can't speak for what the
standard intended, but I think this is bad practice and our implementation
wouldn't allow it. We do direct comparisons against the metadata, so using a
query string that would vary would break it.
I think you should be
putting that information into RelayState.
--
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
Northgate Managed Services Limited
(NI). Registered in
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]