RE: [saml-dev] Is a separate "ArtifactReceiver" required?

["Kremp, Juergen" <juergen.kremp@sap.com>]

>> 
>> Does the specification disallow this???
>> MUST I have a separate servlet to receive the artifact and redirect the
>> user-browser???
>> 

>[Rob] This is NOT currently permitted by the existing B/A Profile, which
>does require that the TARGET= parameter is supplied when redirecting the
>user from the asserting party site to the relying party site. 

The specification says that the TARGET parameter is required. Accepted but not entirely understood WHY this is mandatory.

Does the spec say anything about the technical realization of the artifact receiver on the destination site?
It is allowed that each and every resource is an "artifact receiver" (because the web container technically does the job?).

I think it is possible, because the spec only says that in step 6 (Responding to the User's Request):
"No mormative form is mandated for the HTTP response". 

This especially means that the reception of a "redirect" (from a separate ArtifactReceiver to the Resource) is not mandated.

However, to "fulfill" the words of the spec even such a "direct request" must carry the TARGET parameter, which then leads to funny URL's like this one:

http://host/application/calculator?TARGET=http://host/application/calculator&SAMLart=12353625363457236457

(/application/calculator is the business application!).


>> The intention is to increase the performance, because the usage of an
>> ArtifactReceiverServlet requires an additional redirection step at the
>> user browser site.
>> For a "single-click" application this is not worth worrying, but there are
>> other scenarios in which many resources are retrieved and each performance
>> penalty in form of a redirection causes notable delays for end-users.

>[Rob] I'm not sure I understand the use case in the last sentence here.  The
>B/A Profile is intended to send you to the relying party site with an
>assertion handle which the RP site can use to obtain a Web SSO assertion.
>The RP site should then locally authenticate you using info from the Web SSO
>assertion.  Once you are authenticated at the RP site, the assumption is
>that subsequent visits to that site could be done directly without
>revisiting the asserting party site.

>If you are talking about building an artifact for EVERY resource access at
>the RP site, then the performance impact of a browser redirect is the least
>of your worries.  Having every application at the RP site expecting to get
>an artifact and calling back to get an assertion to process on every  RP
>site resource access is far more expensive than the redirect. 

>So why would you want to use an artifact on every resource access at the
>replying party site?

We expect scenarios with heavy interaction between two Web sites. For example, consider a Portal web site which allows single-sign on access to an affiliated Web mail provider: each time, a portal user clicks on "check my inbox", the URL of the mail provider is called again and displayed in a new
frame. Of course, the mail provider might have means to re-identify the user without needing SAML, for example by some kind of cookie on the browser. But how should the portal site know about this fact and that it does not have to initiate a SAML authentication during the lifetime of the session at
the mail provider. So most probably the portal site would have no other chance than each time someone clicks on "check my inbox" issuing an assertion, regardless if the mail provider site needs it or not. 
Having this scenario in mind, an interesting question is how to make the first steps in a SAML authentication more lightweight in order not to waste to many resources when the target site decides to prefer a local authentication method (e.g. cookie) in the later steps of a SAML authentication."




Juergen