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

["Cahill, Conor P" <conor.p.cahill@intel.com>]

Title: RE: [saml-dev] HTTP error response code

 

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. 

I'm not sure I would say that the presenter "is the real subject" as in most cases the sender isn't actually the subject but is in fact some piece of software acting on the subject's behalf (for SSO, the browser isn't generally the subject, although it is sending the message).

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. 

Note that you can also have a Subject Confirmation without a NameID (in which case the confirmation is still something that the sender must meet in order to present the assertion to the recipient). 

Questions

Question #1: do I correctly understand the purpose of the SubjectConfirmation element? 

Pretty close. 

 

Question #2: does it make sense to use the SubjectConfirmation element in a WebBrowserSSO profile? 

Yes.  And it must be Bearer (meaining that an entity must present this assertion within the rest of the conditions)

   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?   

Subject confirmation does *NOT* mean that the SP should reauthenticate.  It's just a condition that must be met before the assertion is accepted.  In the case of Browser SSO, the confirmation is explicitly "...:Bearer".   I think you're saying that without a confirmation you would get the same behaviour of Bearer -- but that isn't documented and we like to be explicit about things used in security situations.

 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? 

If the SP just sent to user to the IdP for authentication and the assertion is being presented within the conditions of the assertion (such as the validity period, the audience, etc.) it is well within the risks to accept it.

 

In any case, if you decide to reauthenticate and you accept a password, you're just asking the user to give you their bearer token that they keep in their head -- it just as likely could have been stolen by the bad guy with much worse consequences as there's no other <conditions> to rely on in that case.

 

Conor