Yes, I see the distinction. However, I was trying to
point out that the requirement for the ConfirmationMethod already
invalidates that there is no relationship between artifact and assertion in
that the assertion must specify that an assertion was used.
[Prateek Mishra] In a very weak sense,
yes, the assertion indicates that it was acquired using the
"artifact" protocol but nothing else. There is still no way that the
assertion contents can be tied to a specific artifact
value.
If
you combine this with the beginning of section 5 of the bindings
spec:
"The <SubjectConfirmation> element SHOULD be used by the
Relying Party to confirm that the request or message came from the System
Entity that corresponds to the Subject in the statement. The
<ConfirmationMethod> indicates the specific method which the Relying
Party should use to make this judgment."
[Prateek
Mishra]
Ryan,
only those
elements that are required to be present ("MUST" in RFC2119-ese) can
be explicitly checked for. The specific issue of
SubjectConfirmationData in the artifact profile was discussed at some length
on the list and can be found in the archives. We decided NOT to require its
use for SAML artifact. I am willing to accept that
the issue could have been resolved in a different fashion. However, if you
look at the threat model and analysis, you will see that there is no need
for this information
I would simply say
that at this point the specification does not require the use of
SubjectConfirmationData for the artifact
protocol.
The only way to do this for "artifact-01" would be if the artifact
was present, presumably in the SubjectConfirmationData. If the intent
was to have the destination site confirm the assertion in another manner,
the ConfirmationMethod of artifact-01 would not have been
required.
[Prateek]
these are inferences or deductions. The
specification as written does not require use of
SubjectConfirmationData.
Ryan
Ryan,
you are
referring to ConfirmationMethod, which you correctly point out must be set
to the
"artifact" URI.
Bhavna
and Rob referred to SubjectConfirmationData, a different animal
(element) altogether. Their question
was
whether the SubjectConfirmationData should carry the corresponding
artifact value. I don't think it should
and we
do not include it as part of the assertion.
Part of
the confusion here stems from similar sounding names: notice
that the SubjectConfirmation element
has
sub-elements ConfirmationMethod and SubjectConfirmationData. The former is
required but not the latter.
-
prateek
Prateek,
Page 17 of the bindings spec. establishes a relationship between
the fact that an artifact was used and the assertion by requiring that
the ConfirmationMethod of the SSO assertion be
urn:oasis:names:tc:SAML:1.0:cm:artifact-01.
"The <saml:ConfirmationMethod> element of each assertion
MUST be set to
urn:oasis:names:tc:SAML:1.0:cm:artifact-01."
This isn't the same thing as a relationship between the specific
artifact and assertion, but I think it's strong enough to invalidate
that there is no relationship.
If this relationship isn't required, why is the
ConfirmationMethod specified?
Ryan
Folks,
this is an issue. We do not use confirmation data, nor
do we check for it in
the
artifact case.
Nowhere in the artifact browser profile description is
there a requirement that
ConfirmationData be used. Indeed, one key requirement in
developing the artifact
profile was that there be NO relationship between the
artifact and the assertion itself. By placing
the
artifact in the assertion (as conf data) this requirement is violated
(however weakly).
The
relationship between the artifact and the assertion is established via
bilateral authentication
between source and destination sites. There is no other
relationship required.
-
prateek
The Oblix SAML implementation also expects the artifact
confirmation data.
-- Charles
Yes, we at Sun need the
SubjectConfirmaData to be the associated attifact string. The
source site at our end checks that the
SubjectConformationData does
contain the artifact string sent
out originally in the query to the destination's soap responder.
Bhavna
"Philpott, Robert" wrote:
The specs aren't really clear on
this... Do folks expect to receive a ConfirmationData element
containing the artifact as part of the SubjectConfirmation when
using the Artifact-01 method?
I've seen a sample assertion that did
have it and one that didn't.
I assume you would want it so the
relying party could (if they so desire) verify the assertion
statements are associated with a particular artifact-based
request.
Thanks,
Rob
Philpott
RSA Security
Inc.
The Most Trusted Name
in e-Security
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:rphilpott@rsasecurity.com
--
________________________________________________________________________
Bhavna Bhatnagar Sun Microsystems Inc.
Identity Management group __o
Tel: 408-276-3591 _`\<,_
(*)/ (*)
________________________________________________________________________