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

The problem you are trying to solve is different from the use case for which the Browser/Artifact profile was designed. There are 2 possible solutions:

1. Wait for a Liberty-enabled product. Liberty handles this use case directly. When you go directly to the mail provider site but haven't authenticated there, Liberty defines how to send you back to a portal (Identity Provider in Liberty-speak) to initiate the web SSO process.

2. Use a slight variation of the B/A Profile described by SAML. In this scenario, the mail provider has 2 available links, one for the normal mail application and a second for the standard B/A Profile Artifact Receiver. The processing would look like:

a. The user logs in to the portal and clicks the "check my inbox" link

b. They are redirected to the mail provider's mail application with NO URL arguments (e.g. http://mail.com/inbox.jsp)

c. Access to the mail application would be controlled by the presence of a local authentication cookie or something similar. On the first visit, there won't be one, so the mail provider site would detect this and redirect the user back to the portal's ISX service using a URL exactly as the ISX expects. The URL might look something like https://portal.com/isx?TARGET=http://mail.com/inbox.jsp

d. The portal's ISX would create an artifact and redirect the user back to the mail provider's artifact receiver as defined in the B/A Profile (e.g. https://mail.com/artifactreceiver.jsp?TARGET=http://mail.com/inbox.jsp&SAMLart=1234567890abcdefg

e. The artifact receiver at the mail provider requests the assertion from the portal over the SOAP Binding as defined by the B/A profile, uses the assertion to locally authenticate the user (creating a cookie), and then redirects the user to the TARGET URL (i.e. the original mail application inbox)

f. After this point if the user clicks on the "check my inbox" link at the portal, they get sent directly to the inbox application and are allowed access since they are authenticated.

g. Note that if the mail provider needs to support connections from multiple portals, the link from the portal to the mail provider's inbox application could also pass along a URL parameter telling the mail provider which portal to send the user back to for an artifact if they aren't already authenticated. But that's something you'd have to define for yourself.

Make sense?

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

> -----Original Message-----

> From: Kremp, Juergen [mailto:juergen.kremp@sap.com]

> Sent: Wednesday, December 04, 2002 1:03 PM

> To: Philpott, Robert; 'saml-dev@lists.oasis-open.org'

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

> >>

> >> 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/calculat

> or&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

saml-dev message