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=gpilz@e2open.com”.
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=gpilz@e2open.com”?) 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 gpilz@e2open.com
|
|
E2open 1075
Old County Road Belmont, CA. 94002 www.e2open.com
TEL:
650.769.3700
FAX:
650.591.2501 |