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 _`\<,_
(*)/ (*)
________________________________________________________________________