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] | [Elist Home]


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



> -----Original Message-----
> From: Kremp, Juergen [mailto:juergen.kremp@sap.com]
> Sent: Tuesday, December 03, 2002 2:41 AM
> To: 'saml-dev@lists.oasis-open.org'
> Subject: RE: [saml-dev] Is a separate "ArtifactReceiver" required?
> 
> Dear Rob, Dear experts,
> 
> my point is the question whether the URL carrying the SAML-Artifact can be
> send ***directly*** to the protected resource without the usage of an
> "ArtifactReceiverServlet" as separate web-application.

[Rob] Now I see what you want to accomplish.

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

> 
> If we have a Servlet Container that is capable of inspecting each (!)
> incoming URL and recognize the SAMLart-Parameter, then this step can be
> omitted. The TARGET Parameter is not needed because the target is directly
> called. With "odd" I mean the duplication of the TARGET (as parameter and
> implicit in the address).
> 
> 
> Juergen Kremp
> SAP AG
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: http://lists.oasis-open.org/ob/adm.pl


Rob Philpott 
RSA Security Inc. 
The Most Trusted Name in e-Security 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com 



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


Powered by eList eXpress LLC