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:]
Sent: 03 April
2009 18:12
To: Schmidlin, Franck;
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 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
