OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

There are two different issues being discussed here.

(1) The use of TARGET on the query string is mandated by the web browser
profiles. The source and destination site can agree on what this means
(including just ignoring it). As Scott suggests this may not be always
ideal, but I don't see it as breaking existing functionality or otherwise
getting in the way.

(2) There is a separate issue of "re-directing" users from the destination
site to the source site. This is typical when users access a resource first,
and, if I understand it correctly, Shiboleth and Liberty Alliance have
formalized such a flow. Some of the demonstrators at the Catalyst Demos
added this flow to the standard SAML 
Source --> Destination site flows. 

But there is no discussion of this flow in current web browser profile

So the question now becomes, do we want to add such a flow to SAML 1.1?
Or is it too broad an expansion of the scope of SAML 1.1?

To help decide that, let me outline the simplest such flow:
(1) User accesses resource at destination site 

No normative requirements here

(2) User is re-directed to an assertion creation URL at source site

   <HTTP-Version> 302 <Reason Phrase>
   <other headers>
   Location: http://assertion_creation_URL?..TARGET=xxxx...

(3) Assertion creation URL interacts with user if no user session available
or whatever

No normative requirements here.

(4) User is re-directed back to the destination site in the usual way
Follow Step 2 from existing profiles ( or

[Often the assertion creation URL and the inter-site transfer URL are
identical but it may aid the specification to separate the concepts]

Jehan, am I correct in that this was the flow used at the demo? I dont know
that there are any other requirements other than this flow.

- prateek

>>-----Original Message-----
>>From: Scott Cantor [mailto:cantor.2@osu.edu]
>>Sent: Wednesday, December 04, 2002 2:27 PM
>>To: jmoreh@sigaba.com; saml-dev@lists.oasis-open.org
>>Subject: RE: [saml-dev] Is a separate "ArtifactReceiver" required?
>>> Those who were involved at the Burton Catalyst Interop in 
>>> July remember that we (Sigaba) required  the source site to 
>>> pass the TARGET parameter back to the destination site. We 
>>> basically negotiated this with each of the other Interop 
>>> vendors. This was part of an unofficial "meta-data" 
>>> negotiation between all Interop vendors.
>>Doesn't the profile as currently written say that you MUST 
>>pass it? Why
>>would you have had to be explicit about it? I thought that 
>>was the issue
>>SAP had with the profile.
>>> The fact that the resulting URL is not bookmark-able is not 
>>> necessarily important here. What is important is that the 
>>> destination site needs the TARGET parameter to do its job.
>>My point is that the advantage of omitting a parameter like that is to
>>simplify or shorten the URL. The latter might be important, but the
>>former is entirely irrelevant in this case, so that eliminates one
>>reason to bother, IMHO.
>>> P.S. I have proposed that we add this meta-data to the 
>>> Metadata for SAML 1.0 Web Browser Profiles. Prateek and Jeff 
>>> are the authors of this document.
>>I think in general the question of the initial flow from the resource
>>side back to the source site (in either the artifact or POST case) is
>>important ground for SAML, as it was in Shib and Liberty. 
>>It's more than
>>just metadata on the side.
>>-- Scott
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC