Confirming ones Assertions

In this post, we’ll be looking at the details of the sender-vouches and bearer confirmation methods. 

Sender Vouches

SAML has the option of a confirmation method called sender vouches, which is represented by the attribute urn:oasis:names:tc:SAML:2.0:cm:sender-vouches to signify that in fact there is no additional information available about the context of use of the assertion. In other words, despite your best efforts to reconfirm the subject's authentication status you have no additional information to go on. This is an example of what I called an authentication "no op" - the receiver can't use SAML based information for re-authentication, but may use this fact to challenge the user or system in a different, application specific way. The existence of this confirmation method simply means that the receiver has more work to do if they wish to reconfirm the identity of the subject. This may be a password challenge or 2-factor authentication challenge or some other out-of-band mechanism. In most cases, the receiver may just decide it is less work to trust the sender and accept the request.

Bearer

SAML has the option for a confirmation method called bearer, which is represented by the attribute urn:oasis:names:tc:SAML:2.0:cm:bearer to signify that the subject of the assertion is the bearer of the assertion. What does this mean exactly? You can think of this as an arrow pointing from the issuer of the assertion to the subject and then an arrow pointing directly back to the issuer from the subject. In simple terms the issuer and subject are the same entity. This is important because it is calling out a special case for the SAML model which (if you recall) made the assumption that the system sending the assertion is not the same as the subject. In this case we are saying that the issuer is the subject - taking this reasoning one step further it then becomes impossible for the receiver to reconfirm the subject because there is no subject. Once again, the receiver is forced to trust the issuer with no additional information. In practice, bearer assertions are generally short-lived and the typical example given is that the bearer of the assertion is the same as the issuer provided the assertion is processed in a specific, short-lived timeframe.. It is up to the consuming application once again to understand the meaning of this confirmation method for its specific security model.

Next: the holder-of-key confirmation method, which is arguably the most complex (and also arguably the most secure).