Jahan,
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
http://lists.oasis-open.org/archives/security-services/200212/msg00001.html)
------------------------------------------------
(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...
etc.
(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 (4.1.1.4 or 4.1.2.4)
[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:]
>>Sent: Friday, December 06, 2002 7:09 PM
>>To: Scott Cantor; ;
>>
>>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.
>>
>>Thanks,
>>Jahan
>>
>>----------------
>>Jahan Moreh
>>Chief Security Architect
>>310.286.3070
>>
>>> -----Original Message-----
>>> From: Scott Cantor [mailto:]
>>> Sent: Friday, December 06, 2002 3:16 PM
>>> To: ;
>>>
>>> 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>
>>
