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

[Alistair Young <alistair@smo.uhi.ac.uk>]

The new SAML2 spec seems very interesting. Lots of hard work involved  
there I think so thanks to all for producing such a comprehensive  
package. Also, thanks to Tom for clarifying a destination site first  
profile. Tom mentions the introduction problem, where it's not easy to  
find out where the user's source site and Assertion Service is located.
wrt this I'd be grateful for your opinions on a tentative solution that  
we're playing with, on the Guanxi project.
We're building a SAML framework, based on Shibboleth and custom  
implementations for eLearning, allowing students at one institute to  
access resources on another institution's Virtual Learning Environment  
(VLE).
SAML allows for privacy but also, in eLearning, student assessment is  
critical, so there must be a way for the destination site to track the  
progress of the user. This could be done pseudonymously using an  
artifact or it could just know the user's source site ID. This way, the  
introduction is done by the user, suffixing their source site ID with  
their domain, i.e. 1324@uhi.ac.uk
I suppose that 1324@uhi.ac.uk is still a pseudonymous artifact that can  
be used for tracking in the VLE and for creating an account for the  
user in the VLE.
As the federation is all built on pre-arranged trust networks, the  
domain suffix will kick off a process of assertions as soon as the user  
tries to login to the VLE.
Obviously, the user should never enter their password at the remote VLE  
but what do people feel about entering the domain qualified user ID and  
using SAML2's authentication request structure to get the user  
authenticated at their source site?
thanks,
Alistair



On 12 Oct 2004, at 03:45, Tom Scavo wrote:

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