Re: [saml-dev] SAML 1.1 Technical Overview (11 May 2004)

[Tom Scavo <trscavo@gmail.com>]

Here's an alternative profile to section 4.3 that addresses the issues
mentioned below:

Browser/Artifact Profile, Destination-Site-First

1) The client accesses a secure resource at the destination site.

2) A security check causes the client to be redirected to the
authentication authority at the source site.*  A target parameter with
the URL of the secure resource is appended to the redirect URL.

3) The client requests the authentication authority as outlined in step 2.

4) The authentication authority challenges the user for credentials.

5) The user supplies the required credentials.

6) The authentication authority verifies the credentials, establishes
a security context at the source site, and redirects the client to the
inter-site transfer service along with the target URL.

7) The client requests the inter-site transfer service as outlined in step 6.

8) The inter-site transfer service redirects the client to the
assertion consumer service at the destination site.  The redirect URL
includes the target URL and the artifact.

9) The client requests the assertion consumer service as outlined in step 8.

10) The assertion consumer service requests an assertion from the
source site's artifact resulution service.

11) The artifact resolution service returns the required assertion(s).

12) The assertion consumer service creates a security context at the
destination site and redirects the client to the target resource.

13) The client requests the target resource (again).

14) The destination site performs a security check and returns the
resource to the client.

* This is the so-called "introduction problem"---in general, how does
the destination site know the principal's preferred source site?

Hope this helps,
Tom Scavo


On Mon, 11 Oct 2004 10:58:23 -0400, Eve L. Maler <eve.maler@sun.com> wrote:
> 
> Thanks very much for taking the time to send these comments.  We can try
> to correct errors at some point, though obviously this isn't quite as
> high-priority right now as completing the SAML V2.0 cycle.  I have
> copied John Hughes, the main author of the original document, and I'll
> consult with him on this.
> 
> Regarding the general issue of terminology in SAML V1.x vs. V2.0: In
> large part, when we worked on SAML V2.0 we chose to adopt terminology
> suggested by the Liberty spec contributions because of their better
> applicability to the problem space and growing acceptance by
> technologists in the field.  In the V1.1 Technical Overview we retained
> the previous terminology for obvious reasons -- to retain consistency
> with the matching older specs.
> 
> Thanks again,
> 
>        Eve
> 
> 
> 
> Tom Scavo wrote:
> 
> > This message records some notes regarding the following document:
> >
> > Technical Overview of the OASIS Security Assertion Markup Language
> > (SAML) V1.1 (11 May 2004)
> > http://www.oasis-open.org/committees/download.php/6837/sstc-saml-tech-overview-1.1-cd.pdf
> >
> > I apologize in advance for not sending these notes earlier in the process.
> >
> > - [lines 60--72]  In light of SAML 2.0, where "asserting party" and
> > "relying party" are referred to as "identity provider" and "service
> > provider", respectively, why introduce new terminology at this time?
> > (Perhaps this is simply a timing issue.)
> >
> > - [line 146]  Delete extraneous hyphen.
> >
> > - [line 161]  The SOAP 1.2 namespace URI is erroneously listed.  This
> > should be the SOAP 1.1 namespace URI (see line 184, e.g.).
> >
> > - [line 165]  Delete superfluous line.
> >
> > - [line 197]  Delimit line by XML comment markers.
> >
> > - [line 204]  Insert comma after "e.g.".
> >
> > - [line 205]  Should be "it's", not "its".
> >
> > - [line 228]  Deprecated identifier used.
> >
> > - [line 291]  Using SAML 2.0 terminology, the "Responder" and
> > "Artifact Receiver Service" are called the "Artifact Resolution
> > Service" and Assertion Consumer Service", respectively.
> >
> > - [line 312]  Replace "an HTTP GET of the form provided below" with
> > "an HTTP GET request (see URL below)"
> >
> > - [line 322]  Assuming line 307 is correct, line 322 should refer to
> > "step 6", not "step 7".  (Actually, this brings up an interesting
> > point.  It might be more efficient for the Inter-site Transfer Service
> > to generate the assertion, but it is certainly easier to let the
> > Artifact Resolution Service do this.  In any event, this is most
> > likely an implementation issue that should be avoided here.)
> >
> > - [line 327]  Delete the first occurrence of the word "back" and
> > change the second occurrence to "made".
> >
> > - [line 328]  Should be "establish", not "established".
> >
> > - [line 337]  Replace 'on JavaScript "auto-submit" action' with 'of a
> > JavaScript onload handler'.
> >
> > - [line 343]  The reference to "HTTP Form" in step 6 should be "HTML Form".
> >
> > - [line 357]  Replace "HTML FORM" with "HTML form".
> >
> > - [line 359]  Replace "HTML FORM will contain an input or submit
> > action" with "HTML form will contain a submit button and/or JavaScript
> > onload handler".
> >
> > - [line 361]  Replace 'an "auto-submit"' with 'a JavaScript onload handler'.
> >
> > - [line 363]  Replace "Assertion Consumer" with "Assertion Consumer Service".
> >
> > - [line 366]  Replace "is the returned" to "is then returned".
> >
> > - [line 369]  Insert a comma after "As previously described".
> >
> > - [line 372]  Replace "Replying" with "Relying".
> >
> > - [line 379]  Using SAML 2.0 terminology, the "Responder" and
> > "Artifact Receiver" are called the "Artifact Resolution Service" and
> > Assertion Consumer Service", respectively.  Also, what happened to the
> > Authentication Authority in this diagram?  (It is needed, I think.)
> >
> > - [line 385]  This line says the user is redirected to the Inter-site
> > Transfer Service yet the diagram indicates the redirect is to the
> > portal.  Which is it?  (Indeed, should the redirect be to the
> > Authentication Authority?)
> >
> > - [line 388]  I don't believe the "portal application" is responsible
> > for redirecting the user to the Inter-site Transfer Service.  This
> > should be the job of the Authentication Authority, shouldn't it (or
> > should this be an implementation issue)?
> >
> > - [lines 389--390]  How is the URL of the original resource preserved?
> >  Is there a TARGET parameter?  If so, what components at the source
> > site must handle a TARGET parameter?
> >
> > - [line 400]  Assuming line 391 is correct, line 400 should refer to
> > "step 6", not "step 7".
> >
> > General questions about section 4.3:  How does the destination site
> > know which source site to redirect to (the so called "introduction
> > problem")?  Does the destination site redirect to the portal or to the
> > Authentication Authority?  How is the TARGET communicated to the
> > source site?  (It seems the Authentication Authority should support a
> > TARGET parameter, rather than the portal.)
> >
> > Since this document is final, it's water under the bridge at this
> > point, but section 4.3 seems to raise more questions than it answers.
> > Perhaps this use case should be left to SAML 2.0?
> >
> > Hope this helps,
> > Tom Scavo
> >
> 
> --
> Eve Maler                                        +1 781 442 3190
> Sun Microsystems                            cell +1 781 354 9441
> Web Products, Technologies, and Standards    eve.maler @ sun.com
>