Title: Message
Roger,
I would say yes to Question #1 -- however there are a couple types of
SubjectConfirmation methods.
So for
Question #2, you are correct -- in that the user does not have to confirm itself
in the same way as you described in your motivation section. Rather, they use a
"bearer" method -- which, but simply, means that they just need to bear (or
possess) the assertion. But it's a little bit more than that (and spelled out in
Profiles), you also need to match up some attribute within SubjectConfirmation,
such as Recipient, NotOnOrAfter, and InResponseTo. All of these are meant to
enhance the security around the bearer method for Web SSO.
So
there is a risk, but the attacker would need to steal the assertion within
the timeframe alloted for the request to complete by the SP (InResponseTo) and
the IDP (NotOnOrAfter). However if you have access to the data over the wire
between the user and the IDP or on the user's browser, you may as well steal
passwords, etc...
Tom.
-----Original Message-----
From: Costello, Roger
L. [mailto:]
Sent: Tuesday, June 06, 2006 8:40
AM
To:
Subject: [saml-dev]
Seeking clarity on the SubjectConfirmation element
Hi Folks,
I am seeking your confirmation that I
understand the SubjectConfirmation element. Below I have written
up my understanding of it.
Understanding the SubjectConfirmation Element
Motivation
First I provide the motivation for why an
element such as SubjectConfirmation is needed. Consider this
scenario:
A Bad Guy steals (intercepts) an
assertion that is sent by an Identity Provider (IdP). The Bad Guy
presents himself and the stolen assertion to a Service Provider (SP).
How will the SP determine that the presenter is not the real subject of
the assertion? Answer: before the IdP sends out the assertion,
he embeds a SubjectConfirmation element into the assertion. The
SubjectConfirmation element contains a digital version of a lock. The SP
asks the presenter (the Bad Guy) for the key to the lock. Since the Bad
Guy doesn't have the key the SP knows that there is something fishy with the
presenter.
So, the motivation for the
SubjectConfirmation element is to provide a way for the SP to determine if the
presenter is the real subject of the assertion.
Recap
The SubjectConfirmation element contains
information about how the presenter of the assertion must confirm that he is
the subject identified in the assertion. For example, the
SubjectConfirmation element may contain a ds:KeyInfo element, which means that
the presenter can confirm he is the subject of the assertion by giving a
secret key.
Questions
Question #1: do I correctly understand
the purpose of the SubjectConfirmation element?
Question #2: does it make sense to use
the SubjectConfirmation element in a WebBrowserSSO profile? I think that
it doesn't make sense because the whole point of this profile is to avoid
making the presenter reauthenticate, and the presence of the
SubjectConfirmation element implies that the SP should reauthenticate the
presenter, correct? On the other hand, isn't it risky for the SP to not
reauthenticate? Suppose that the presenter has a stolen assertion as I
describe above; the SP would be taking a big risk by not reauthenticating the
presenter, correct?
/Roger
