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: Re: Assertion id AND attributes in the same query

Title: Assertion id AND attributes in the same query
You are raising fundamental questions.  I suggested support for this in the very
SAML-beginning but it was termed "credential negotiation" and voted out as a non-goal.
IMHO there is no real negotiation going on, the content site indicates what it needs
and if the auth site (and the user) doesn't serve that need, the request is simply rejected.
I think this is needed to make SAML fully usable.  It is not that
costly either.  My two recently contributed documents actually fully address
this although they use different [home-brewed?] terminology.
URL-based opaque one-domain "references"

"Fat browser objects" 
----- Original Message -----
From: Tim Moses
Sent: Thursday, August 09, 2001 19:40
Subject: Assertion id AND attributes in the same query

Colleagues - The need to convey an assertion id and attributes in the same query arises in the following circumstances.

A browser contacts a content site and is redirected to an authentication site.  The content site has specific requirements for:

1. The authentication scheme between the browser and the authentication site (I'll call this "primary" authentication);

2. The authentication scheme between the browser and the content site upon its return to the content site (I'll call this "secondary" authentication, normally this would be a bearer token, but who knows?);

3. The space in which the subject's name should appear; and

4. User attributes.

So, the content site needs to communicate its requirements in these four areas to the authentication site, preferably, before primary authentication takes place.

There is currently no fully-specified way for the content site to communicate its needs to the authentication site.  What are the possible solutions?

1. The authentication site "just knows" what authentication schemes, namespaces and attributes the content site needs.

2. Each authentication site URL corresponds to a single authentication scheme.  Then the content site specifies the authentication scheme by redirecting the browser to the appropriate URL.

3. The authentication site returns assertions containing every authentication scheme, namespace and additional attribute, and the content site searches through them for the ones that suit its needs.

4. The authentication site returns its own choice of authentication assertion and the content site submits a further query for any additional, or alternative, assertions that it needs.

Solution 1 works because we don't.

Solution 2 addresses requirement 1, but not requirements 2, 3 and 4.

Solution 3 is unsatisfactory from an identity-theft/privacy point of view.

Solution 4 introduces more delay than is absolutely necessary.

We have, in both the "fat object" and "artifact" browser profiles, opportunities to solve these questions in a more satisfactory manner.

In the "fat object" profile, the "form" can contain the Assertion Queries.  In the "artifact" profile, the initial redirection by the content site to the authentication site can contain an artifact, in the redirection URL, corresponding to the Assertion Queries, using either of the push or pull communication models.  The thing that is new and surprising about this approach is that the artifact does not correspond to an "assertion", but to a "query".  There would then have to be a communication directly between the content and authentication sites in which the content site would request assertions that directly meet its needs.

This is what it looks like in both the "push" and "pull" models.

Push model

Browser                   Content site           Authentication site

1 <---- redirect(artifact1) ----
2 --------------------- redirect(artifact1)--------------->
3                               ---- query(artifact1) ---->
4 <----------------------- authenticate ------------------>
5                               <- assertions(artifact2) --
6 <-----------------------------------redirect(artifact2)--
7 -------redirect(artifact2)--->

Pull model

Browser                   Content site           Authentication site

1 <---- redirect(artifact1) ----
2 --------------------- redirect(artifact1) --------------->
3 <------------------------ authenticate ------------------>
4                              <- request query(artifact1) -
5                              ----- query(artifact2) ----->
7                              <-------- assertions --------
6 <-------------------- redirect(artifact2) ----------------
7 -----redirect(artifact2)---->
Line 3 of the push model and line 5 of the pull model involve a query with both an artifact (or assertion id) and the set of requested attributes.

Best regards.  Tim.

Tim Moses
Tel: 613.270.3183

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

Powered by eList eXpress LLC