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:
> -----Original Message-----
> From: Kremp, Juergen [mailto:]
> Sent: Wednesday, December 04, 2002 1:03 PM
> To: Philpott, Robert; ''
> 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
