Re: Assertion id AND attributes in the same query

Title: Assertion id AND attributes in the same query

Tim,

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"
 http://www.x-obi.com/OBI400/andersr-browser-bearer-objects.ppt

"Fat browser objects" 

  http://www.x-obi.com/OBI400/andersr-browser-artifact.ppt 

 

Regards

Anders

  
----- Original Message ----- 

  
From: 
  Tim 
  Moses 

  
To: 'OASIS Security Services 
  group' 

  
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