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

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