RE: [saml-dev] drfat-catalyst-interop-plan-02

["Philpott, Robert" <rphilpott@rsasecurity.com>]

Hi Bhavna,

> From: Bhavna Bhatnagar [mailto:bhavna.bhatnagar@sun.com]
> In the above I am assuming that the authentication authority is actually
> the
> Issuer per the Assertion schema. Currently we at Sun put the sourceID
> there . Is
> that acceptable by all ? or should we have a more understandable string
> there
> like dns-suffix sun.com.

While the authn authority is the issuer, SAML doesn't require that the
issuer be the same system as the SAML SOAP Binding Responder.  The SourceID
which is defined as part of the B/A Profile identifies the system to which
the samlp:Request should be sent via the SOAP responder.

In our environment, the Issuer (SAML Authority) and SAML SOAP Binding
Responder can be (and probably are) on different systems, so we don't expect
to use the same identifier for both Issuer and SourceID. Our SAML responder
may eventually handle SOAP binding requests and responses for multiple
authorities.  

That said, we will use an IDType Base64 string for the Issuer string. Thus
we don't rely on a more understandable string.  

I hope this works for the other vendors also and I hope that having
different identifiers for Issuer and SourceID will word for you.

> D. Unauthenticated users are re-directed to the portal for login.
> 
> In D above, I am not sure what is the expected behaviour. If we redirect
> to portal login, then after logging in, one would be displayed a content
> page
> with links to content hosted at distinct web sites, but I would think
> that the user would expect to be taken directly to
> the content application after a successful login upon redirection. Does
> anyone think alike  or if not can someone please clarify the expected
> flow ?

I think what was intended was just what is says - an authenticated user
hitting the content provider will get redirected to the portal for login.
However, the description should say more about what happens next. After
authenticating the user, the portal could have 2 choices.  

First, the portal could display the links page that refers to the ISX
(inter-site transfer) service.  The user would then have to click to get
back to the original content provider.  Of course the click really gets them
to the ISX with a TARGET= parameter and the ISX creates the artifact and
sends them to the remote artifact receiver URL.  That then gets them to the
content application once the assertion is retrived.  Obviously, getting the
links page and clicking on it isn't very user-friendly.

However, if the content provider redirects to the portal AND supplies a
TARGET= parameter on the redirect, the portal could authenticate the user
and transfer directly to the ISX service with the supplied TARGET=
parameter.  The user would then not have to see the links page.  As in the
normal case, the ISX would create the artifact and send the user back to the
remote SAML artifact receiver.  Once the assertion is retrieved, the user
will see the content provider page they wanted. 

The 2nd scenario is more user-friendly, but it requires a vendor's content
site to redirect to the portal with the TARGET= parameter.

Can other vendors do this?  I am planning for us to handle either method.  

Prateek, could we update the scenario to describe this or do we have to just
stick with the first method?