Final Showdown

 Comparison

We can clarify the differences between the SAML and AWS authentication schemes by building a table that lists the method, description, English description (what it really means), and then some benefits and drawbacks.

Method	Spec Description	English Description	Benefits	Drawbacks
urn:oasis:names:tc:SAML:2.0:cm:holder-of-key	The holder of a specified key is considered to be the subject of the assertion by the asserting party	“Verify this signed blob to reconfirm the subject”	Strong authentication by the receiver  of the subject.	Additional per-message signature verification processing. Requires additional trust processing for the public key;
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches	Indicates that no other information is available about the context of use of the assertion	“Just trust me”	Fast and simple, no additional signature processing; if you trust the sender no additional processing is required	No additional confirmation possible; may require out-of-band or additional authentication
urn:oasis:names:tc:SAML:2.0:cm:bear er	The subject of the assertion is the bearer of the assertion, subject to some optional constraints	“I am the subject”	Fast and simple, no additional signature processing	No additional confirmation possible; may require additional out-of-band or additional authentication
Amazon HMAC Authenticator	You calculate a keyed-hash message authentication code (HMAC-SHA) signature using your Secret Access Key	“Look-up the password for a specific user account and generated a message authentication code for the received message”	Fast and simple;	Additional per-message HMAC processing; authenticators are not guaranteed to be unique per user-id;  Non-standard code development required

 

As you can see, the mechanisms are quite different, especially between the AWS HMAC and the SAML confirmation methods. It may be useful to remember that of all four mechanisms, holder-of-key is the strongest because it ties the subject back to a specific private key. However, comparing AWS to SAML confirmation methods is a little bit like comparing apples and oranges because the confirmation method itself is independent of the outer digital signature (in the case of a signed WS-Security message) or the inner digital signature (in the case of a signed SAML assertion) that adds extra integrity checking and non-repudiation to the SAML structure. In many cases, when confirmation methods like sender-vouches and bearer are used, this is in the context of a signed assertion, so even though we may not be able to reconfirm the subject explicitly, trusting the issuer itself is enough to guarantee the authenticity of the subject for some security models.

Security in the Jungle

In this post, we’ll be looking at the security properties of the Amazon Web Services authentication scheme.

Amazon Web Services Authentication

Amazon requires a per-message authentication scheme for non-anonymous cloud service requests. This model is based on a hash-based message authentication code, or HMAC. When compared to SAML, this type of authentication scheme is much simpler in that there are no implicit distinctions between issuer and subject. Instead, we have the request itself which is authenticated using a keyed message authentication code, based on a shared secret password. Rather than process a confirmation method, the receiver of the message looks up the password for the user id included in the message and computes the keyed code over the message. If the codes come out the same, the receiver has a guarantee that the user has not altered the message and that the user has knowledge of the password.

In contrast to SAML holder-of-key, which relies on the strength of a public-key algorithm, the strength of the authenticator is based on the length of the password and the strength of the hash function. In most cases the resulting authenticate code is included in the HTTP header of the messages sent to the Amazon cloud services, although it can also be sent over as XML payload content.  This type of security mechanism is sometimes loosely called a signed request, but in reality a digital signature is based on a single private key, only known to one person. This is an important distinction between a mechanism like holder-of-key and the properties of the Amazon web services HMAC scheme. In the latter case, by definition two entities know the password: The sender and receiver. It is also more likely that with the AWS authentication scheme based on HMAC, multiple senders will share a password and user-id, so Amazon will know that an authenticated account is accessing their service but will not be able to distinguish between how many actual senders (as an account can be shared) are making requests, since they all bear the same user-id and shared secret.

This authentication scheme has the benefits of simplicity, which often translates into increased overall system security. It also has benefits for performance as compared to SAML holder-of-key, which requires a client-side RSA digital signature compared to HMAC, with performance roughly equivalent to a hashing operation and is many times faster.

Next: Final Comparison

"Are you the Key Master"

Be a Ghostbuster

In this post after previously looking at other confirmation methods, we’ll be looking at the details of the holder-of-key confirmation method. 

Holder-Of-Key

SAML has the option for a confirmation method called holder-of-key, which is represented by the attribute urn:oasis:names:tc:SAML:2.0:cm:holder-of-key to signify that the subject of the assertion is identified by being the holder of a specific private key. How this work? The holder-of-key confirmation is based on the properties of public-key cryptography. In this case, the original subject signs a small piece of arbitrary data and includes his or her public key with the signed blob. Then, if the receiver trusts the association between this public key and the subject name, they are guaranteed that the original subject is authenticated based on the fact that only they are holder of this private key. This of course is subject to the constraints implicit in the strength of the public-key algorithm chosen as well as the implicit guarantee that only one subject has access to the private key, which is a core assumption built around the public-key infrastructure model. Another assumption has to hold here as well, which is that the receiver has enough information to verify that the public key is trusted and actually associated with the name given to the subject.

This association can be an implicit, stored assumption by the receiver or based on an X.509 certificate model, which would also require the receiver to do additional trust processing. It is often said that this model is the "most secure" confirmation method. In one sense, this is correct because the authenticity of the subject rests on a digital signature created by the subject, over and above the claims of the issuer. Remember, subject re-confirmation is just that - reconfirmation of the issuer's original claim that the subject is authenticated. One might argue that if the holder-of-key data is trusted, the weakest link in the chain of authentication is the issuer's assertion regarding the subject - after all, the subject is effectively authenticated with her or her own digital signature. The obvious downside of this method is that the original subject must perform a digital signature and have access to a private key, which pulls in assumptions regarding entity key issuance, revocation and management, which may be an unnecessary trade-off for security and complexity.

Next: Looking at AWS

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).

Exporing SAML

The "Token Comments" post discussed the importance of token technology within an enterprises security model. Now let's examine SAML in more detail.

SAML Security

To understand how the various confirmation methods in a SAML token fit in a security model, we have to first understand some of the basic assumptions about SAML itself. SAML assertions are declarations of fact, or claims about a subject according to someone - typically a "source site" (to use the SAML v1.x language) or an identity provider (to use the SAML v2.0) language. A SAML assertion encompasses three types of statements about a subject - statements of authentication, statements of attributes and statements of authorization. For the latter, this statement of authorization are quickly being taken over by XACML. In fact, this type of assertion has been frozen as of SAML v2.0 with no future enhancements. Users who require authorization statements are encouraged to look at XACML, which offer enhanced capabilities for the expression of authorization statements.

Confirmation Methods

SAML uses a special element called the subjectconfirmation element that can be thought of as a special hint given to the receiver of a SAML assertion. This element allows the receiver to reconfirm that the request came from the entity associated with the subject. The underlying assumption here is that the system sending the assertion is not the same as the subject, but the system receiving the assertion has some sort of trust relation with the sender. The classic example in this case could be a business partner. In most cases you trust your business partner, so normally the receiver of the assertion should not need to reconfirm the authentication, but there may be cases where it is an especially high-value transaction or maybe they just don't trust the system sending the assertion and need extra assurance. SAML provides three ways to accomplish this re-confirmation, called confirmation methods which are holder-of-key, bearer, and sender-vouches. While these three options are theoretically different, we will see that in practice they collapse into just two cases: do nothing or verify a signature.

Next, we'll examine bearer and sender-vouches in more detail.

Token Comments: SAML and AWS Authentication

We are now at a point where Enterprises are beginning to use cloud-based services, such as Amazon Web Services, along with more traditional WS-* services and the confusion continues to grow around which tokens and token options are appropriate for various security models. A common area of confusion concerns SAML and the different confirmation methods: bearer, holder-of-key, and sender-vouches and how these compare to the security model used by Amazon Web Services, which is an hash-based message authentication code scheme. What is the difference between these security models? Which is more secure? How do the models differ?

For those just getting started in this area, let's provide a short primer and some links for further initiation. SAML stands for Security Assertion Markup Language. It is a XML-based standard which sends authentication and authorization information across security domains. Amazon Web Services (AWS) are available cloud services like storage (S3) or cpu power (EC2) which are accessed over HTTP using both REST and SOAP protocols.

Going right to the source:
OASIS
SAML
AWS

The practical aspect of this for an Enterprise Architect is that as cloud computing continues to grow, a dynamic enterprise perimeter is created which expands beyond the datacenter. It is dynamic as various outside services are added over time or even eventually incorporated on demand. Business may necessitate using various types of tokens. Decisions must be made on which methods fit the security model and how one can translate between one token and another when necessary.

Next: Exploring SAML