OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [saml-dev] Seeking clarity on the SubjectConfirmation element

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...
-----Original Message-----
From: Costello, Roger L. [mailto:costello@mitre.org]
Sent: Tuesday, June 06, 2006 8:40 AM
To: saml-dev@lists.oasis-open.org
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


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.


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.


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?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]