Appendix D. Securing SAML assertions
In chapter 8, we introduced SAML assertions that can be used to communicate the findings of a security service. Since service endpoints depend on SAML assertions to identify users and make other security decisions, we should secure those assertions, too, in particular against the following threats:
- Forgery and tampering An attacker may submit a completely forged assertion. Or, he may tamper with the information in an assertion created by the security service. In use case #2 we described in section 8.2.2, the source endpoint can add an AttributeStatement (or alter it) in the assertion returned by the security service to make itself a member of the administrators group.
- Replaying An assertion can be captured and reused by an attacker. The attacker might replay the original message that has an assertion in it as is, or reuse the captured assertion as part of a different message.
- Privacy The user’s privacy may be violated if an assertion includes more details than a service endpoint really needs or if a MIM grabs the details in the assertion by eavesdropping.
In the next section, we will look at detecting forgery and tampering of SAML assertions.
D.1 Detecting forgery and tampering
To detect forgery and tampering, we can use the same techniques we discussed in chapter 7 to verify the integrity of messages. Any receiver of SAML assertions should only accept those assertions that are signed by their issuers. A SAML Assertion is like any other XML element; it can be signed by the issuer using the same signing mechanisms we described in chapter 7. A small technicality makes signing of SAML assertions slightly more complex than it should really be.
Recall that we need the ability to refer to an element in order to include its digest as part of SignedInfo. In chapter 7, we saw how we can refer to any element using its wsu:Id (or simply Id for elements defined by the XML-Signature and XML-Encryption specs) attribute value. As SAML Assertion elements already have an attribute named AssertionId that is declared as an identifier by the SAML schema, there’s now a dilemma when referring to an Assertion. Which identifier attribute’s value should we use to refer to a SAML Assertion?
Use of both wsu:Id and AssertionId attributes is not a good idea, as it can lead to confusion and inconsistency. Use of just wsu:Id is not possible, as the SAML schema requires an AssertionId on every Assertion. Use of just AssertionId is also not a clean solution, as the signature verifier will now need to look for three different attributes—wsu:Id, Id, and AssertionId, depending on what the referred element happens to be.
To get around this problem (and probably for other good reasons as well), the SAML profile for WS-Security defines a roundabout way of referring to SAML assertions from SignedInfo. Instead of referring to the assertion from within SignedInfo, the profile recommends a Reference to a SecurityTokenReference (STR) that in turn refers to the Assertion, as shown in figure D.1.
Figure D.1. Two levels of indirection are recommended when signing a SAML assertion. Signature refers to a SecuityTokenReference that in turn refers to the signed SAML assertion.
In this scheme, the SecurityTokenReference element identifies the Assertion by its AssertionId and creates for itself a wsu:Id that can be referred to from SignedInfo. Here is an example:
<wsse:SecurityTokenReference wsu:Id="MySAMLAssertion1Ref1">
<wsse:KeyIdentifier ValueType="...#SAMLAssertionID">
MySAMLAssertion1
</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
Note that the KeyIdentifier element in this example is defined in the WS-Security namespace rather than the SAML namespace. WS-Security establishes the notion of a KeyIdentifier as an opaque string that uniquely identifies a security token. The ValueType attribute indicates the type of token being identified. See figure D.1.
Listing D.1 is a sample signature that protects the integrity of a SAML Assertion.
Listing D.1. Example of a signature over a SAML assertion
From chapter 7, you will readily recognize the key elements in this code. The SignedInfo element contains a Reference 
to the SAML assertion that needs to be protected. As shown in figure D.1, this reference happens in an indirect way. The Reference in points to a SecurityTokenReference (STR) element C that in turn points to the SAML assertion 
we want to protect.
There is one key piece of this listing that you have not seen before—an STR dereference transform 
. Here is why it is needed here. As the Reference in SignedInfo points to an STR 
rather than the Assertion we want to protect, we need to employ an STR dereference transform to indicate that the DigestValue 
is computed after dereferencing the STR.
To summarize, you can use signatures to protect a SAML assertion, as it is just another XML element. Because standards say that you should refer to a SAML assertion via an STR, you will need to apply an STR dereference transform when computing the digest that goes into the signature’s SignedInfo element.
Next we will describe how we can protect SAML assertions against replay attacks, where the attackers capture and replay an assertion.
D.2 Defending against replay attacks
SAML assertions are susceptible to different kinds of replay attacks. A MIM may capture an assertion in whatever form it was transmitted and reuse it. He may replay the original message that has the captured assertion in it as is, or reuse the captured assertion as part of a different message. Note that an attacker can replay signed and encrypted assertions as well. He does not need the ability to decrypt the captured assertion or forge a signature.
A malicious service provider can capture an assertion submitted to it and resubmit the assertion to a different service without the subject’s permission.
There are a several strategies to defend against replay of SAML assertions, but all have limitations. In this section, we will present four strategies:
- Reduce the validity period of the assertion
- Restrict the audience for the assertion
- Confirm message origination
- Use AssertionId as nonce
We will also describe the limitations of each. You can combine some or all of these strategies in your implementations to get the best possible defense against replay attacks.
D.2.1 Strategy 1: Reduce validity period
In listing 8.2, you saw that a SAML assertion’s validity can be constrained by a time window. We can take advantage of this constraint and reduce the window of opportunity for replay attacks by narrowing the validity period of assertions to a short period of time.
This technique still cannot fully prevent replay attacks. A replay can still be made within the small validity period we set on each assertion. Furthermore, there are practical constraints that prevent us from reducing the validity period to a small value. For example, we have to account for the fact that the clocks of the assertion issuer and receiver may not be in exact sync; or we may have to support asynchronous services.
On the other hand, this is a simple strategy to use, and a good practice to always use.
D.2.2 Strategy 2: Restrict the audience for the assertion
The issuer of an assertion can explicitly identify the audience for an assertion. This would eliminate the possibility of assertions being replayed by an attacker or by a malicious service provider to services other than the one for which the assertion was originally issued.
Listing D.2 shows how the audience for an assertion is constrained.
Listing D.2. Example of AudienceRestrictionCondition
This example is self-explanatory. To restrict the audience for an assertion, we simply add an AudienceRestrictionCondition child to the Conditions element. An Audience element, consisting of a URI, identifies each of the parties who are expected to rely on this assertion. If an AudienceRestrictionCondition is set within an Assertion, any party that is not listed as an Audience should refuse to accept the Assertion.
Note that this strategy cannot prevent replay attacks against parties identified as the intended audience for the assertion. For attacks against everyone else, this strategy works well.
D.2.3. Strategy 3: Confirm message origination
SAML makes it possible for recipients of an assertion to figure out which parts of a message surely originate from the subject identified in an assertion. This facility is known as subject confirmation. It aids us in detecting replay attacks in which the attacker incorporates an assertion from a previously captured message into a different message.
A security service that issues SAML assertions can enable subject confirmation in two different ways. Table D.1 summarizes these and discusses the conditions under which each of them is most suitable.
Table D.1. Methods for confirming that an assertion’s subject is the one that created parts of a message or the entire message
|
Confirmation method name |
Description |
Key pair used in signature |
Suitable if |
|---|---|---|---|
| sender-vouches | The security service that issues the assertion signs those parts of the message that it can vouch for as originating from the Subject identified in the assertion. | Security service key pair | Security service is in a position to verify that it securely received a part of or the whole message directly from the Subject identified in the assertion |
| holder-of-key | The security Service that issues the assertion certifies a key as belonging to the assertion’s Subject. The subject in turn signs the parts of the message it is sending using the key certified by the security service. | Key pair of the subject identified in the assertion | Security service is not in the message path to sign the message itself |
SAML facilitates both of these confirmation methods using a SubjectConfirmation element that can be added to a Subject element in an assertion. We will discuss both these methods next, starting with the sender-vouches method.
Subject confirmation method 1: sender-vouches
If the security service that is issuing a SAML assertion is in a position to vouch for the integrity of an entire message or particular message parts, it can convey this information to the receiver by signing those parts and setting the SubjectConfirmation element as shown in listing D.3.
Listing D.3. Example of a subject with sender-vouches subject confirmation method
<Subject>
<NameIdentifier
NameQualifier="manning.com"
Format="...:SAML:1.1:nameid-format:emailAddress">
[email protected]
</NameIdentifier>
<SubjectConfirmation>
<ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
</ConfirmationMethod>
</SubjectConfirmation>
</Subject>
Note: Who is the sender in “sender-vouches”?
The word sender in sender-vouches may be confusing. In this context, sender actually refers to the sender of the SAML assertion—that is, a security service—and not the original sender of a message.
This subject confirmation method is applicable if the security service can somehow make sure that it securely received a part or whole of the message directly from the subject identified in the assertion it is issuing. For example, a subject may use a VPN or SSL/TLS to securely send a message to the security service. Or, a subject may sign the entire message or particular message parts using a key that can be verified by the security service as belonging to the subject.
But what if the security service is not in a position to vouch for the integrity of message contents? For example, the security service may not be in the message path. In such cases, the holder-of-key method is more suitable for subject confirmation.
Subject confirmation method 2: holder-of-key
A subject might obtain an assertion for later use out-of-band (like in Kerberos). In this case, the security service cannot vouch for the integrity of message contents, as it does not receive the message content from the subject. The security service can still facilitate the receiver’s task of identifying message parts that can be trusted to have originated from the subject named in a SAML assertion. The security service can do this simply by adding the subject’s key information to the assertion. Receivers can then trust any parts signed using the key in the assertion as originating from the subject named in the assertion.
Listing D.4 shows how this method of subject confirmation is conveyed in a SAML assertion.
Listing D.4. Example of a subject with holder-of-key subject confirmation method
<Subject>
<NameIdentifier
NameQualifier="manning.com"
Format="...:SAML:1.1:nameid-format:emailAddress">
[email protected]
</NameIdentifier>
<SubjectConfirmation>
<ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:holder-of-key
</ConfirmationMethod>
<ds:KeyInfo>
<ds:KeyValue>...</ds:KeyValue>
</ds:KeyInfo>
</SubjectConfirmation>
</Subject>
To make the job of a receiver easy when using the holder-of-key confirmation method, a sender can simply refer to the key specified by a SAML assertion’s SubjectConfirmation/KeyInfo instead of repeating the key information in its signatures. This way, the receiver is saved the additional task of determining which signatures in a message use the key specified by a SAML assertion. Listing D.5 shows this technique.
Listing D.5. Example of a signature whose KeyInfo points to a SAML assertion
<ds:Signature>
<ds:SignedInfo>
...
</ds:SignedInfo>
<ds:SignatureValue>
...
</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier
ValueType="...#SAMLAssertionID">
MySAMLAssertion1
</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
Confirming message origination prevents replay attacks in which the attacker reuses an assertion with a different message than the one in which it was originally used. This strategy is certainly a lot more powerful than the previous one, which could only defend against replays to services that were not listed as the audience for an assertion. Of course, the extra power comes at the cost of additional complexity. Strategies 1 and 2 were definitely much simpler to understand and use than this strategy.
The biggest limitation of this strategy is that it cannot defend against replays of the entire original message as is. In fact, it is very difficult to protect against replays of original messages as is. The next strategy strives to address this challenge.
D.2.4 Strategy 4: Use AssertionId as a nonce
The strategies we have described so far cannot avoid replays of a captured message as is. To avoid replay attacks of this kind, we need to include a nonce in the assertion. Recall from chapter 4 that a nonce is a number used once; that is, a number that will not be repeated. The service will need to remember the nonce values used in the last m minutes and reject any assertions with a repeating nonce value or with an issue instant that goes back more than m minutes.
Neither SAML nor WS-Security currently provides a standard way to communicate nonce values. In the case of an assertion issuer (security service) that does not cache and reuse SAML assertions even when contacted repeatedly with the same credentials, the AssertionId can effectively work as a nonce. But if the assertion issuer caches and issues the same assertion more than once, we cannot use this strategy.
Of course, none of these four strategies would guarantee protection against replay attacks unless we use signatures as discussed before to detect tampering of assertions. An attacker can simply change the timestamps, audience restrictions, and nonce values before resubmitting an assertion if the assertion is not protected against tampering by signatures.
To recap, we can use multiple strategies to prevent replay attacks. We have discussed four strategies here. While the last of these strategies, using AssertionId as a nonce, is the most watertight, it is not always applicable. In such cases, the remaining strategies can all be combined to reduce the opportunity for attackers. Strategy 1 of reducing the assertion’s validity period is always a best practice and helps even when strategy 4 is applicable by reducing the time window during which a repetition of nonce needs to be detected.
Let’s now consider the third and final security aspect we promised to discuss here.
D.3 Protecting confidentiality and privacy
SAML assertions contain information on subject identities, attributes, and privileges. Some or all of this information may need to be protected. In addition to clearly sensitive information such as bank account numbers, SAML assertions may carry often-shared identifiers or attributes such as email addresses that still need to be safeguarded from falling into the wrong hands, such as spam agencies.
There are two very different aspects to these concerns: confidentiality and privacy. Confidentiality is easier to tackle. We can use the encryption techniques discussed in chapter 6 to guarantee that sensitive information is not readable by third parties. Privacy, as we noted in chapter 1, is a lot tougher to guard.
A web service endpoint that should only be accessible to adults only needs assertions stating the age of a user. The security service need not reveal the real identity of the user. One way of attempting this is through the use of pseudonyms in assertions. Pseudonyms by themselves do not provide complete anonymity. This is because inferences can be made by correlating information from multiple assertions. We will not cover privacy protection in more detail here, as it is outside the scope of this book.