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