RE: [security-services] SubjectType and multiple NameIdentifier,SubjectConfirmation, or AssertionSpecifier elements

Title: e2open stationary

Gilbert - 

Thank 
you for excellent clarification. I think lines 357-362 of core-19 are valuable 
if we change it slightly as follows:

--

If a <Subject> element contains more than 
one subject specification the issuer is asserting that the statement is true for 
all of the subjects specified. For example if both a <NameIdentifier> and 
a <SubjectConfirmation> element are present the issuer is asserting that 
the statement is true of both subject 
specifications.

The 
definition of a <Subject> element that intentionally identifies more than 
one principal is deprecated.

--

 

I hesitate to use the word "Alias" instead of "Subject 
Specifications", but in effect that's what it is.

 

Jahan

 

---------------------------
Jahan Moreh
Chief Security 
Architect
Sigaba Corp.

cell: 
310.890.9391
tel: 310.286.3070

  
-----Original Message-----
From: Gilbert Pilz 
  [mailto:]
Sent: Monday, October 15, 2001 
  11:25 PM
To: oasis sstc
Subject: [security-services] 
  SubjectType and multiple NameIdentifier, SubjectConfirmation, or 
  AssertionSpecifier elements

  

  
On the focus 
  subgroup concall of October 9th I was assigned an action item to "write up 
  background semantics and background assumptions on relationships btwn 
  NameIdentifier(s) and subjectConfirmation(s) within Subject 
  elements".

  
Summary

  
Lines 364-371 of 
  Core-19 provide the schema for the <Subject> element as 
  follows:

  
<element 
  name="Subject" type="saml:SubjectType"/>

  
<complexType 
  name="SubjectType">

  
<choice 
  maxOccurs="unbounded">

  
<element 
  ref="saml:NameIdentifier"/>

  
<element 
  ref="saml:SubjectConfirmation"/>

  
<element 
  ref="saml:AssertionSpecifier"/>

  
</choice>

  
</complexType>

  
From this schema we 
  can see that a single <Subject> may have an arbitrary number of 
  <NameIdentifier>’s, <SubjectConfirmation>’s, and 
  <AssertionSpecifier>’s. The question is; what does it mean when a 
  <Subject> contains more than one of these sub-elements (i.e. (two 
  <NameIdentifier>’s) or (one <NameIdentifier> and one 
  <SubjectConfirmation>) etc.)? Lines 357-362 of Core-19 state 
  that:

  
If 
  a <Subject> element contains more than one subject specification the 
  issuer is asserting that the statement is true for all of the subjects 
  specified. For example if both a <NameIdentifier> and a 
  <SubjectConfirmation> element are present the issuer is asserting that 
  the statement is true of both parties.

  
The 
  definition of a <Subject> element that intentionally identifies more 
  than one principal is deprecated.

  
Although the “both 
  parties” wording is a bit confusing (implying, as it does, that there are 
  two parties), nevertheless it 
  seems clear that what is meant is that all the “subject specifications” refer 
  to a single global principal that is identified in a number of different 
  ways.

  
Hypothetical 
  Use Case

  
One use case that 
  could motivate these semantics is single sign-on into a federated domain of 
  legacy applications that identify principals in different ways. For example, 
  say I have built a SAML authentication layer on top of two sets of 
  applications, Set A and Set B. To the applications in “Set A” I am known as 
  “/…/dev.e2open.cell/users/gpilz” and to 
  “Set B” I am known as “C=US, 
  ST=California, L=Belmont, O=E2open, OU=Dev, CN=”. 
  Given that there is only one Authentication Authority for this federated 
  domain the question is “Does the Authentication Authority generate two 
  separate Authn Assertions, one for Set A and one for Set B, each of which 
  contains a single subject specifier, or do I generate a single Authn Assertion 
  that contains multiple specifiers that can be consumed by either Set A or Set 
  B”? Core-19 allows for the later but does not preclude the 
  former.

  
The main idea here 
  is that PEPs and other relying parties would selectively ignore those subject 
  specifiers that didn’t make sense to them.

  
Other 
  References

  
The F2F#3 whiteboard 
  design (http://www.oasis-open.org/committees/security/minutes/SSTC-F2F-3-Notes-Hodges-WhiteboardTranscription.pdf) outlines the contents of a “Subject” 
  in four different places. Although there is a slight variation in the contents 
  in some of these outlines (“holder of key” and “assertion ID” are present in 
  some versions and missing in others), every outline presents “Subject” as a 
  union of either a “[security 
  domain, name]”, “bearer”, “holder of key”, or “assertion ID”. Also notable is 
  that there are no “*” or “+” adornments indicating that there can be more than 
  one of any of these elements. Applied to Core-19 schema this would mean that a 
  <Subject> could contain either a singe<NameIdentifier>, a single 
  <SubjectConfirmation>, or a single 
  <AssertionSpecifier>.

  
Critique

  
Although the 
  hypothetical use case outlined above is certainly plausible, there are a 
  number of problems with the current design. For instance, suppose a PEP in an 
  application in Set A submits an <AuthorizationQuery> containing a 
  multi-specified <Subject> against a global PDP and receives back a 
  <Response> that contains a <Subject> with a single specifier that 
  it doesn’t understand? The same question applies to <AttributeQuery>’s 
  as well. In addition to this, what happens when a PDP receives an 
  <AuthorizationQuery> containing a multi-specified <Subject> and 
  its internal policy database contains conflicting policies for one or more of 
  the specifiers?

  
The Core-19 design 
  optimizes for the hypothetical use case at the expense of creating a bunch of 
  very sticky problems. The hypothetical use case is completely supported by an 
  Authentication Authority that creates multiple Authentication Assertions each 
  of which contains a single <Subject> with a single specifier. PEP’s and 
  other relying parties are free to ignore Authn Assertions containing 
  <Subject>’s that they do not understand, but the possibility of posing 
  potentially ambiguous queries (Did he mean “/…/dev.e2open.cell/users/gpilz” or 
  “C=US, ST=California, L=Belmont, O=E2open, 
  OU=Dev, CN=”?) is removed.

  
Proposal

  
I propose that lines 
  357 through 362 of Core-19 should be removed and the schema for 
  <Subject> should be changed to read:

  
<element 
  name="Subject" type="saml:SubjectType"/>

  
<complexType 
  name="SubjectType">

  
<choice>

  
<element 
  ref="saml:NameIdentifier"/>

  
<element 
  ref="saml:SubjectConfirmation"/>

  
<element 
  ref="saml:AssertionSpecifier"/>

  
</choice>

  
</complexType>

  
 

  
    
    

      
        

      
        
 

        
Gilbert W. 
        Pilz Jr.
Security Architect
DIR: 650.226.1765

        
CELL: 
        831.239.3736


        
 

      
        
 

      
        
 

        
E2open
1075 
        Old County Road
Belmont, CA.  94002
www.e2open.com

        
TEL: 
        650.769.3700

        
FAX: 
        650.591.2501