[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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=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>
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC