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?

Prateek -
Thanks for elucidating the concepts here. Indeed, we would strongly support
the addition of this flow to SAML 1.1. We believe this is a very real case,
especially when the assertion consumer and the assertion producer are not
closely coupled (i.e., under the administrative control of the same
organization). OK. Enough preaching.

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

We believe that it is very important to conceptually differentiate between
the Inter-site transfer URL and the assertion creation URL . In fact, during
the interop demo we learned that people did not really expect the intersite
transfer URL to be accessed directly from the "outside".

Furthermore, SAML 1.0 Bindings and Profiles document only specifies a
recommended, not a normative interface to the transfer service.  At the
interop, we found that most companies required different or extra parameters
to their transfer service.

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.
The question here is the preservation of the TARGET parameter. During the
interop demo we learned that most assertion producers were doing a substring
search on the input TARGET parameter or weren't using the input TARGET at
all to determine who to redirect to, but required a different parameter to
instruct them which destination URL to redirect to, and then set the output
TARGET value from a hardcoded string.

To keep track of the user's session, we tried to URLEncode a sessionID as a
directory component of the TARGET parameter we passed to the assertion
producer, but since many transfer services weren't expecting to have to pass
the TARGET parameter through unchanged, they needed to either retrofit this
capability, or we agreed to pass and receive the sessionID through some
other named parameter.

So it would be good for the assertion creation URL to have some way to
receive some parameters that it could then return, unchanged, to the
destination service.

Finally, we (Sigaba) would be very happy to write a proposal for adding this
flow to SAML 1.1 Web Browser profiles.


Jahan Moreh
Chief Security Architect

> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Thursday, December 05, 2002 1:10 PM
> To: 'Scott Cantor'; jmoreh@sigaba.com; saml-dev@lists.oasis-open.org;
> 'security-services@lists.oasis-open.org'
> Cc: 'Kremp, Juergen'
> Subject: 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
> binding.
> 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...
>    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 ( 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