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] RE: Is a separate"ArtifactReceiver" required?


I would support adding a minimal extension
that supports flow from destination to source site. My
question is whether it needs to be anything more than:
(taken from

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

>>-----Original Message-----
>>From: Jahan Moreh [mailto:jmoreh@sigaba.com]
>>Sent: Friday, December 06, 2002 7:09 PM
>>To: Scott Cantor; saml-dev@lists.oasis-open.org;
>>Subject: RE: [saml-dev] RE: Is a separate "ArtifactReceiver" required?
>>Scott -
>>You characterization is accurate. Indeed, at the interop we 
>>were creating
>>the "shire" URL based on the TARGET. If we had a specific agreed-upon
>>parameter (like Shib's shire), we would not have to make individual
>>agreements with each interop vendor.
>>Like you, we advocate supporting this kind of flow in SAML 1.1.
>>Jahan Moreh
>>Chief Security Architect
>>> -----Original Message-----
>>> From: Scott Cantor [mailto:cantor.2@osu.edu]
>>> Sent: Friday, December 06, 2002 3:16 PM
>>> To: saml-dev@lists.oasis-open.org;
>>> security-services@lists.oasis-open.org
>>> Subject: [saml-dev] RE: Is a separate "ArtifactReceiver" required?
>>> FWIW:
>>> The Shibboleth flow uses two parameters, one called "target" and one
>>> called "shire".
>>> The shire parameter is the acceptance point at the target 
>>site which the
>>> source site would send the user back to once finished with local
>>> authentication.
>>> The target is the place the user wanted to go before being so rudely
>>> interrupted.
>>> It sounds like the Catalyst implementers were using the 
>>target to figure
>>> out what the shire-equivalent URL should be, and then were 
>>sending the
>>> user there without any further indication of where the user 
>>would then
>>> be sent. That obviously won't work as a general mechanism for
>>> "target-first" access.
>>> The POST profile specifically calls out the TARGET form 
>>element as being
>>> not the place where the assertion is posted but instead the 
>>resource the
>>> user should be sent to afterwards. This is consistent with 
>>Shib's usage
>>> (we copy the incoming target back out into the form verbatim).
>>> Also FWIW, we know of lots of important or useful 
>>extensions that we'd
>>> like to have available to provide more control, but have 
>>deferred that
>>> until we can approach it with some formalism, whether we 
>>adopt Liberty's
>>> approach, or perhaps contribute something to a SAML 1.1 
>>discussion (my
>>> preference at the moment).
>>> -- Scott
>>> ----------------------------------------------------------------
>>> To subscribe or unsubscribe from this elist use the subscription
>>> manager: <http://lists.oasis-open.org/ob/adm.pl>
>>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