Abstract
SAML plays an import role in authentication and authorization scenarios. People have paid much attention to its security, and find that major SAML applications have critical vulnerabilities, including XML signature wrapping (XSW) vulnerabilities and SAML assertion eavesdropping vulnerabilities. The countermeasures now available cannot address these two types of problems simultaneously, and always require a large change of the server modules.
In this paper, we propose to break this stalemate by presenting a fresh approach to SAML. A key cause of XSW and SAML assertion eavesdropping is that SAML assertions can be verified independently of the environment related to them. So we present an improved version of SAML (environment-bound SAML) that provides SAML assertions with the ability to defeat XSW and SAML assertion eavesdropping by binding SAML assertions to environment, and keeps tiny deployment overhead. To ensure the integrity of the binding relationship, we present the Master-Slave signature (MSS) scheme to replace the original signature scheme. We implement our scheme in OpenSAML, and provide a performance evaluation of this implementation.
Keywords
1 Introduction
The Security Assertion Markup Language (SAML) [1] is an XML-based framework for exchanging user authentication, authorization and attribute information. SAML allows business entities to make assertions about the identity, entitlements and attributes of a subject. SAML is widely deployed. SAML assertions are usually used as the identity token in web Single Sign-On (SSO) scenario, or as the authorization grant in OAuth 2.0 scenario.
The security of SAML has a major impact on these web services. Based on previous analysis, major SAML applications have critical vulnerabilities. The most harmful vulnerabilities are XML signature wrapping (XSW) and SAML assertion eavesdropping. An SAML signature is looked as a node of an XML tree, which is presented by the Signature element. A new class of vulnerabilities named XSW utilizes the features of the SAML signature to break the security of SAML. By using XSW, an attacker can inject forged elements without invalidating the SAML signature. The XSW details are described in Sect. 2.1. In SAML application scenarios, it is inevitable that SAML assertions are transferred between different roles. So the security of SAML assertions is subject to the application environment. SAML applications are always built upon the existing web infrastructures, including principal agents (typically browsers), networks, and servers. Many prevalent vulnerabilities of these infrastructures can be exploited to weaken the security of SAML assertions. The details about SAML assertion eavesdropping vulnerabilities are described in Sect. 2.2.
Some countermeasures have been presented to mitigate the effects of XSW and SAML assertion eavesdropping. J. Somorovsky et al. [2] presented two countermeasures against XSW. S. Sun et al. [3] suggested seven recommendations that can mitigate the effects of OAuth 2.0 eavesdropping vulnerabilities. SAML assertions can be used as token in OAuth 2.0. So their recommendations are suited to SAML. But these countermeasures have their own drawbacks, which limit their practical use. We summarize the drawbacks as following:
-
Limited Capacity: None of countermeasures described above can address XSW and SAML assertion eavesdropping simultaneously. And it is hard to combine the existing countermeasures to resolve the two issues altogether. Because each countermeasure requires a big change for the logic process, the result of combining several countermeasure simply is usually that the original business logic in the service is affected.
-
Poor Universality: None of countermeasures described above is a universal measure. Any one of the countermeasures described above is only designed for a specific application scenario. So a countermeasure suited to a server maybe not suit others.
-
Heavy Deployment Overhead for Servers: Each countermeasure described above requires SAML servers to modify more than one module. It means wide-scale code changes. These changes introduce unwanted complications to SAML servers, and increase the overhead of deploying the countermeasures.
1.1 Contribution
We present a improved version of SAML, which provides SAML assertions efficient immunity against XSW and SAML assertion eavesdropping simultaneously. A key cause of XSW and SAML assertion eavesdropping is that SAML assertions can be verified independently of the environment related to them. So, in our scheme, SAML assertions are bound to environment (including the generation environment and the application environment). Unlike the existing countermeasures, the modifications of our scheme are limited to the SAML module. So all SAML servers can deploy our scheme with tiny overhead. In our scheme, when SAML assertions are generated, the SAML assertion issuer server binds SAML assertions to the generation environment (SAML assertions - generation environment binding) to prevent SAML assertions from tampering via XSW. When SAML assertions are used, the principal binds SAML assertions to the application environment (SAML assertions - application environment binding), to prevent SAML assertions from eavesdropping. Our scheme ensures that SAML assertions are only valid in the environment with which the SAML assertions are bound. So we name our new scheme as environment-bound SAML assertion scheme. To ensure the integrity of binding relationship, we propose a new sequential aggregate signature scheme to replace the original SAML signing scheme. By using the new sequential aggregate signature scheme, we modify the SAML signature process from only SAML assertion issuer server signing to SAML assertion issuer server co-signing with principal. The SAML assertion issuer server signs SAML assertion firstly to ensure the integrity of “SAML assertions - generation environment” binding relationship. Subsequently, the principal adds his signature onto issuer’s signature to ensure the integrity of “SAML assertions - application environment” binding relationship. Because there are only two signers in the new signature scheme, and the sequence of signing is fixed, we name this new sequential aggregate signature as Master-Slave signature (the first signer is the master user, and the second signer is the slave user). The Master-Slave signature is a restricted version of sequential aggregate signature.
We also give the implementation procedure of environment-bound SAML assertion scheme in detail, and analyse its security. At last, to demonstrate the feasibility of the environment-bound SAML assertion scheme, we evaluate the performance of a demo program which is based on OpenSAML. Comparing with existing countermeasures, the environment-bound SAML assertion scheme can provide SAML assertions effective immunity against XSW and SAML assertion eavesdropping simultaneously, keeping a tiny deployment overhead. And it is suitable to all application scenarios.
2 Related Work
XSW and SAML assertion eavesdropping pose a direct threat to SAML. In this section, we introduce some related works about these vulnerabilities and the corresponding countermeasures.
2.1 XML Signature Wrapping (XSW)
M. Mcintosh and P. Austel [4] and M. Jensen et al. [5] presented the XML signature wrapping (XSW) attacks. The cause of XSW attack is that different module of a application has different view on the same XML document. The security module of the application only performs security check on the signature part of the XML message. But the logic processing module of the application focuses on different parts of the same message. If an attacker modifies the XML message structure by injecting some forged elements keeping the XML signature valid, the security module may verify the signature successfully while the logic processing module processes the forged elements. Hence, by using XSW, an attacker can circumvent the security check and inject arbitrary content.
XSW on SAML. J. Somorovsky et al. [2] described the XSW attack on SAML. The simplest attack is the XML signature exclusion attack. Some servers’ security modules have poor implementation. If these security modules do not find the signature element, they skip the verification step directly. The attacker can simply insert arbitrary elements and remove the signature element. The other attack is the refined XSW attack. Figure 1 are two refined XSW attack examples. As shown in Fig. 1(a), the attacker injects a different ID element into the original assertion. Because the SAML 2.0 schema allows to have multiple assertions in a SAML document, the modification doesn’t invalidate the SAML assertions. But the logic processing module reads the forged \(<\) assertion \(>\) element. What Fig. 1(b) describes is similar with Fig. 1(a) but inserting the forged element into different place.
Countermeasures for XSW. J. Somorovsky et al. [2] presented two countermeasures against XSW. The SAML consumer server is regarded as an aggregation of a security module and a logic processing module. The first countermeasure is “Only process what is hashed”. The security module acts as a filter and only forwards the hashed parts of a SAML assertion to the logic processing module. The second countermeasure is “Mark signed elements”. The security module marks the signed parts of a SAML assertion. And then the security module forwards the marked SAML assertion to the logic processing module. The logic module only processes the trusted parts of a SAML assertion. But these countermeasures only address the XSW problems. They do not consider the eavesdropping issues. Both “Only process what is hashed” countermeasure and “Mark signed elements” countermeasure require the SAML application servers to modify the logic processing module. They all involve a large deployment overhead for SAML application servers.
2.2 SAML Assertion Eavesdropping
S. Sun et al. [3] analysed eavesdropping vulnerabilities of OAuth 2.0, and suggested some recommendations that can mitigate the effects of these vulnerabilities. SAML assertions can be used as token in OAuth 2.0 [6]. So their analyses and recommendations are suited to SAML.
SAML Assertion Eavesdropping in OAuth 2.0. OAuth 2.0 protocol [7] is an open and standardized web resource authorization protocol. Due to poor implementation, some OAuth 2.0 web applications are not indeed secure in practice. S. Sun et al. [3] uncovered several critical vulnerabilities that allowed an attacker to gain access to the victim’s resource or impersonate a victim. As described in Fig. 2, an attacker can eavesdrop on SAML assertions by sniffing on the unencrypted communication. According to the OAuth 2.0 specification, SSL/TLS should be used to provide end-to-end protection between any two parties. However, SSL/TLS imposes management and performance overhead and introduces undesired side-effects. So many service providers only use SSL/TLS for a few pages, such as login pages. An attacker can eavesdrop on SAML assertions via the communications without SSL/TLS protection. Due to poor implementation, some pages of SAML assertion consumer server have XSS vulnerability. An attacker can inject a malicious script into any page with XSS vulnerability to enforce the principal log again and send SAML assertions to him. Moreover, any vulnerabilities found in the principal agents (typically the browsers) also lead to security breaches. The security of browsers faces the challenge of the browser extension mechanism [8, 9]. If an attacker controlled the principal agent, he would obtain any data through the principal agent, including SAML assertions.
Countermeasures for SAML Assertion Eavesdropping. S. Sun et al. [3] suggested recommendations that allow to mitigate discovered vulnerabilities. The SAML assertion consumer server should (1) provide explicit authorization flow registration, (2) support redirect URIs whitelist, (3) support token fresh mechanism, (4) enforce single-use of token, (5) void saving token to cookie, (6) support explicit user consent, and (7) support explicit user authentication. But these countermeasures only address the SAML assertion eavesdropping problems in OAuth 2.0 scenario. None of them is universal measure. The countermeasure (1) requires SAML assertion consumer servers support a registration option. And this option could protect only half of servers from token theft. For the countermeasure (2), most of SAML assertion consumer servers prefer “Domain-based redirect URI validation” to “Whitelist-based redirect URI validation”. Sometimes, the tokens need to be kept for a long time, and may be used for many times. So the countermeasure (3) and (4) are not suitable for some scenarios. Many servers save the session data to cookie. Hence, the countermeasure (5) is hard to be accepted by these servers. Because some servers support “Automatic authorization granting”, the countermeasure (6) and (7) cannot be applied in these servers.
3 Threat Model
In this section, we define the threat model for environment-bound SAML assertion scheme, including the attacker type and the attacker capability. There are three types of attackers in our threat model. Their capabilities describes as following:
Server attacker: The server attacker can exploit the vulnerabilities of server web pages, such as XSS, to setup malicious web pages. As Fig. 2 described, the malicious pages enforce the principal agent to execute the scripts implanted by the attacker. The scripts usually send the SAML assertions of the victim principal to the attacker. The attacker injects forged elements into the original assertions by using XSW, and then he submits the modified assertions to the SAML assertion consumer server. Or he replays the stolen assertions directly.
Agent attacker: The principal agent attacker can exploit the vulnerabilities of principal agents (such as browsers) to eavesdrop, such as man-in-the-browser malware [10]. As Fig. 2 described, SAML assertions are often forwarded by the principal agents. They must be cached in the memory of the principal agents. If the attacker controlled the principal agents, he would analyse agent caches to obtain SAML assertions. Similar to the server attacker, the agent attacker can submit the modified assertions or replay the stolen assertions.
Network attacker: The network attacker can sniff network traffic between different parties to steal SAML assertions. As Fig. 2 described, the attacker can sniff SAML assertions from the unencrypted channels. Moreover, we also assume that the attacker is able to “pry open” SSL/TLS sessions and extract the sensitive data by exploiting the bugs of SSL/TLS [11]. After obtaining SAML assertions, the attacker can handle them just like what the server attacker and the agent attacker does.
In short, our threat model gives attackers the ability to exploit XSW vulnerability and SAML assertion eavesdropping vulnerability. By combining these two vulnerabilities, a attacker can gain unauthorized access to the victim’s resource or impersonate victim principal.
4 Environment-Bound SAML Assertions
In this section, we describe the environment-bound SAML assertion scheme in detail. To provide SAML assertions efficient immunity against XSW and SAML assertion eavesdropping simultaneously, SAML assertions are bound to environment by using the Master-Slave signature scheme. Figure 3 describes the environment-bound SAML assertion scheme. Firstly, we present the Master-Slave signature in detail. And then we demonstrate how to bind SAML assertions to environment by using Master-Slave signature scheme.
4.1 Master-Slave Signature
The key point for the environment-bound SAML assertion scheme is that SAML assertions are bound with a specified environment. So the security of binding relationship is the prerequisite and the foundation of the environment-bound SAML assertion scheme. To ensure the integrity of binding relationship, we present the Master-Slave signature (MSS) scheme. By using MSS, we modify the SAML signature process [1, 12, 13] from only SAML assertion issuer server signing to SAML assertion issuer server co-signing with principal. The signature of the SAML assertion issuer server ensures the integrity of “SAML assertions - generation environment” binding relationship. And the signature of the principal ensures “SAML assertions - application environment” binding relationship.
Definition of MSS. G. Neven [14] proposed a sequential aggregate signed data (SASD) scheme. The SASD scheme is based on families of trapdoor permutations except that it doesn’t require the permutations to be certified. But this scheme is not a strong sequential aggregate signature scheme. The signing sequence can be changed without invalidating the signature. The MSS scheme is derived from SASD. We give the definition of MSS as following:
Definition 1
The Master-Slave signature (MSS) is a restricted version of sequential aggregate signature. There are only two signer in the MSS scheme: the master signer and the slave signer. It allows these two signers to sign different messages while aggregating into a single signature. And the sequence of signing is fixed. The master signer creates the initial signature, and the slave signer generates the aggregate signature subsequently. Any change to signing sequence would invalidate the signature.
MSS Details. The MSS scheme is a tuple of four algorithms (KeyGen, MasterSign, SlaveSign, Verify). And it defines three roles: the master user, the slave user, and the verifier. The master user uses MasterSign algorithm to create the initial signature. The slave user uses SlaveSign algorithm to generate the aggregate signature. The verifier uses Verify algorithm to verify the final Master-Slave signature. This is consistent with environment-bound SAML assertion scheme. The SAML assertion issuer server is the master user. The principal corresponds to the slave user. The SAML assertion consumer server plays a role as the verifier.
We present our Master-Slave aggregate signature scheme arising from any family of claw-free trapdoor permutations. So it can be easily instantiated with RSA, which is the default signing algorithm of SAML. We first introduce some prerequisites. Let \(k, l \in \mathbb {N}\) be security parameters. \(l\) is system-wide parameter. \(k\) is chosen by each user as long as \(k > l\). Let \(\varPi \) be a family of claw-free trapdoor permutations. For each permutation \(\pi \) in \(\varPi \), there exists an abelian group \(\mathbb {G}_\pi \subseteq D_\pi \). Let \(enc_\pi :\{0,1\}^* \rightarrow \{0,1\}^* \times \mathbb {G}_\pi \) be a encoding algorithm which divides a message \(M\) into a shorter message \(m\) and an element \(\mu \in \mathbb {G}_\pi \). Let \(dec_\pi :\{0,1\}^* \times \mathbb {G}_\pi \rightarrow \{0,1\}^*\) be the corresponding decoding algorithm. The decoding algorithm must be injective: \(dec_\pi (m,\mu ) = dec_\pi (m^\prime ,\mu ^\prime ) \Rightarrow (m,\mu ) = (m^\prime ,\mu ^\prime )\). Let \(H_\pi :\{0,1\}^* \rightarrow D_\pi \), \(H^\prime :\{0,1\}^* \rightarrow \{0,1\}^l\), \(H^{\prime \prime }:\{0,1\}^* \times \{0,1\}^* \rightarrow \{0,1\}^l\) and \(G_\pi :\{0,1\}^l \rightarrow \mathbb {G}_\pi \) be public hash functions modeled as random oracle.
KeyGen. For a particular user, the KeyGen algorithm uniformly selects a pair of claw-free trapdoor permutation \((\pi , \rho , \pi ^\prime ) \leftarrow \varPi \). Here \(\pi \) is the permutation \(Evaluate(pk, \cdot )\), and \(\pi ^\prime \) is the inverse permutation \(Invert(sk, \cdot )\). The KeyGen algorithm return \(pk\) as the public key and \(sk\) as the private key.
MasterSign. For the master user, given the private key \(sk_m\) of the master user and a message \(M_m \in \{0,1\}^*\), the MasterSign algorithm computes
where \(h_m \in D_\pi \). The MasterSign algorithm returns \(\sigma _m\) as the master signature.
SlaveSign. The slave signing algorithm is given a tuple of six parameters \((sk_s, pk_m, pk_s, M_m, M_s, \sigma _m)\): the private key \(sk_s\) of the slave user; the public key \(pk_m\) of the master user; the public key \(pk_s\) of the slave user; the message \(M_m\) signed by the master user; the message \(M_s\) to be signed by the slave user; the master signature \(\sigma _m\). Firstly, the slave signing algorithm checks the validity of the master signature. The slave signing algorithm computes
If \(h_m \ne Evaluate(pk_m, \sigma _m)\), the algorithm return \(\bot \). Secondly, the slave signing algorithm computes
Thirdly, the algorithm encodes the string \((M^\prime \parallel \sigma _m)\) by running
\(m\) is a shorter string than \((M^\prime \parallel \sigma _m)\). \(\mu \) is an element of \(\mathbb {G}_\pi \). Fourthly, the algorithm computes
Lastly, the SlaveSign algorithm returns a slave signature \(\sigma _s \leftarrow (m, \chi , h_s)\).
Verify. The verification algorithm is given a tuple of five parameters \((pk_m, \) \(pk_s, M_m, M_s, \sigma _s)\): the public key \(pk_m\) of the master user; the public key \(pk_s\) of the slave user; the message \(M_m\) signed by the master user; the message \(M_s\) signed by the slave user; the slave signature \(\sigma _s\). Firstly, the verification algorithm parses \(\sigma _s\) as \((m, \chi , h_s)\) and checks the validity of parameters. If \(| \mathbb {G}_\pi | < 2^l\), the algorithm returns \(0\) to indicate rejection. Secondly, the verification algorithm computes
Thirdly, the master signature is reconstructed from \((m,\mu )\) by running
Lastly, the verification algorithm computes \(h_m \leftarrow H_\pi (M_m)\). If \(M^\prime \) is equal with \(H^{\prime \prime }(M_m, M_s)\), \(h_s\) is equal with \(H^\prime ((pk_m,pk_s) \parallel M^\prime \parallel \sigma _m)\), and \(h_m\) is equal with \(Evaluate(pk_m, \sigma _m)\), then the algorithm return \(1\) to indicate that the slave signature \(\sigma _s\) is valid. Otherwise it returns \(0\).
4.2 Binding SAML Assertions to Environment
The environment-bound SAML assertion scheme ensures that SAML assertions are only valid in special environment. In this section, we present how the SAML assertion issuer server binds SAML assertions to the generation environment, how the principal binds SAML assertions to the application environment, and how the SAML assertion consumer server verifies the SAML assertions.
Binding SAML Assertions to Generation Environment. The SAML assertion issuer server is responsible to generate SAML assertions and bind SAML assertions to generation environment by using the MSS scheme. The generation environment information includes: (1) the issuer information – who initializes SAML assertions, and (2) the objective principal information – who can use SAML assertions. The issuer information has been included in SAML assertions [1]. To prevent SAML assertions from a attacker tampering via XSW, the SAML assertion issuer server must indicates which principal can use SAML assertions. The SAML assertion issuer server adds the public key of the objective principal into each SAML assertion. The public key information is placed in the \(<\) Advice \(>\) element. The \(<\) Advice \(>\) element is a sub-element of the \(<\) Assertion \(>\) element. The integrity of \(<\) Advice \(>\) element is protected by the \(<\) Signature \(>\) element that envelops a master signature (by using MasterSign algorithm of MSS). Figure 4(a) is an example of a HTTP response message with a environment-bound SAML assertion. An X.509 certification, which includes the public key of the principal, is placed in \(<\) Advice \(>\) element.
Binding SAML Assertions to Application Environment. The principal is responsible to bind SAML assertions to the application environment before forwarding them to the SAML assertion consumer server. To resist SAML assertion eavesdropping, the principal creates a new XML element, called \(<\) EbAssertion \(>\) element, which envelops the application environment information and the original SAML assertion. Figure 4(b) defines the \(<\) EbAssertion \(>\) element and its complex type (EbAssertionType). The EbAssertionType type specifies the basic information of the application environment, including the following elements and attributes:
-
\(<\)SessionID\(>\) The identifier for session between the principal and the SAML assertion consumer server.
-
\(<\)CookiesHash\(>\) The hash value of cookies. The default case is that hash value comes from total cookies by using SHA1 [15] algorithm. But the SAML assertion consumer server can negotiate with the principal to decide how to get hash value. The hash value is encoded by Base64 [16].
-
\(<\)PrincipalURI\(>\) The unique URI for the principal.
-
\(<\)ServiceURI\(>\) The unique URI for the SAML assertion consumer server.
-
\(<\)Assertion\(>\) The original SAML assertion received from the SAML assertion issuer.
-
\(<\)Version\(>\) The version of the enveloped assertion.
-
\(<\)ID\(>\) The identifier for this environment-bound SAML assertion.
-
\(<\)IssueInstant\(>\) The time instant of issue in UTC.
And then the principal signs the \(<\) EbAssertion \(>\) element by using SlaveSign algorithm of MSS. Only the principal indicated by the SAML assertion issuer server can generate a valid MSS signature, because the other principals including attackers do not have the private key which can match the public key in the \(<\) Advice \(>\) element of SAML assertions. The principal removes the original signature and places his final signature in the \(<\) ds:Signature \(>\) element of \(<\) Assertion \(>\). Lastly, he forwards the valid environment-bound SAML assertions to the SAML assertion consumer server.
Verifying SAML Assertions. The SAML assertion consumer server is responsible to verify environment-bound SAML assertions. The environment-bound SAML assertion scheme only substitutes the Verify algorithm of MSS for the original verification algorithm. The verification process describes in Fig. 5. Firstly, the verification algorithm uses the SAML assertion issuer’s public key together with the public key in the \(<\) Advice \(>\) element (namely, the principal’s public key is extracted from “SAML assertions - generation environment” binding relationship), to verify the slave signature. Secondly, the verification algorithm checks the validity of “SAML assertions - application environment” binding relationship. The current application environment information is input to the verification algorithm. And then the verification algorithm compares the current application environment information with the application environment information bound to SAML assertions. It returns the check result to the logic processing module of the SAML assertion consumer server. The check result is reliable enough. The logic processing module need to do nothing more.
5 Security Analysis
In this section, we demonstrate how the environment-bound SAML assertion scheme can be used to improve the security of SAML applications.
The security of MSS has a direct impact on the environment-bound SAML assertions scheme. It can be proved in the random oracle model. If a MSS adversary \(\mathcal {A}\) broke our MSS scheme with AdvMSS \(_\mathcal {A}\), we could construct an algorithm \(\mathcal {B}\) to break the SASD scheme [14] with the same probability. As space is limited, the detailed proof is not described here.
The major adversary types have been described in Sect. 3. We explain how the environment-bound SAML assertion scheme can be used to harden SAML applications against adversaries.
Against server attacker. The server attacker exploits the vulnerabilities of server’s web pages to steal victim’s SAML assertions. The stolen SAML assertions have been bound to the generation environment and the application environment. We assume that the attacker does not know the private key of the SAML assertion issuer server and the victim principal. So the attacker cannot break the existing binding relationship. Due to “SAML assertions - generation environment” binding relationship and the co-signature, the server attacker cannot forge valid SAML assertions or inject forged elements into the stolen SAML assertions keeping signature valid. Because SAML assertions have been bound to application environment, the attacker cannot replay the stolen SAML assertions. If the stolen SAML assertions are replayed simply, MSS verification algorithm would return failed. The MSS verification algorithm checks whether the application environment information (\(<\) SessionID \(>\), \(<\) CookiesHash \(>\) and so on) is changed. If verification algorithm indicated the signature was invalid, the SAML assertion consumer server would terminate the process and drop assertions.
Against agent attacker. The agent attacker exploits the vulnerabilities of principal agent to steal SAML assertions. In environment-bound SAML assertion scheme, the principal is required to bind SAML assertions to the application environment. Once the application environment is changed, the corresponding SAML assertions become invalid. The agent attacker can steal three kinds of SAML assertions: the semi-manufactured SAML assertions (the assertions are only bound to the generation environment), the valid SAML assertions (the assertions are bound not only to the generation environment but also to the application environment, and the corresponding application environment is unchanged), and invalid SAML assertions (the assertions are invalid due to the changes in the corresponding application environment – for example, the session was close). Because the agent attacker does not know the private key of the victim principal, he is not able to bind the semi-manufactured SAML assertions to the application environment just as what the legal principal does. It means that the agent attacker cannot validate the semi-manufactured SAML assertions, no matter whether the semi-manufactured SAML assertions are tampered by using XSW or not. Similar to the server attacker, even if the agent attacker stole a valid SAML assertion or a invalid SAML assertion, he would not circumvent the environment information check of the MSS verification algorithm.
Against network attacker. The network attacker sniffs network traffic between different parties. The network attacker can steal two kinds of SAML assertions: the semi-manufactured SAML assertions (when the attacker sniffs network traffic between the SAML assertion issuer server and the principal), and the valid SAML assertions (when the attacker sniffs network traffic between the principal and the SAML assertion consumer server). Due to missing the victim principal’s private key, the network attacker is not able to validate a semi-manufactured SAML assertion. Due to “SAML assertion - application environment” binding relationship and the co-signature, both tampering attack via XSW and replay attack have no impact on the environment-bound SAML assertions. The network attacker cannot use the stolen SAML assertions to gain access to unauthorized resource or to impersonate victim principal.
6 Implementation and Performance Evaluation
In order to demonstrate the feasibility of the environment-bound SAML assertion scheme, we implemented our scheme and evaluated its performance.
6.1 Implementation
We re-developed the OpenSAML. OpenSAML is a set of open source libraries. The OpenSAML libraries support developers working with SAML. The current version, OpenSAML 2, supports SAML 1.0, 1.1, and 2.0 specification. OpenSAML has been applied widely by many projects, such as: Shibboleth, Globus Toolkit, gLite, JBoss, Apache WSS4J, and so on.
We modified the original signing and verification algorithm into the Master-Slave signature algorithm. We instantiate the Master-Slave signature algorithm by using the default algorithm of XML signature as following:
-
1.
using RSA private key encryption as \(Invert()\);
-
2.
using RSA public key decryption as \(Evaluate()\);
-
3.
using SHA1 as \(H_\pi ()\), \(H^\prime ()\), \(H^{\prime \prime }\), and \(G_\pi ()\) (SHA2 or SHA3 could be used to replace SHA1. But we suggested using SHA1 to be compatible with existing systems).
And then, we added support for environment-bound functions to OpenSAML. We implemented “generation environment bound” functions during the generation phase of SAML assertions. And we implemented “application environment bound” functions during the use phase of SAML assertions.
We chose Linux (version 3.2.0) as our development platform. We used OpenSAML version 2.5.2 as the development base line. It was the prerequisite to OpenSAML that we compiled and installed XMLTooling (version 1.5.2) library and XML-Security-C (version 1.6.1-5+deb7u2) library into the development platform. All modifications for the environment-bound SAML assertions scheme required an additional 2,878 lines added (across 27 files) to the OpenSAML source code.
6.2 Performance Evaluation
In order to demonstrate the performance impact of using environment-bound SAML assertions in SAML servers, we evaluated the performance of our scheme in SAMLSign program which was released together with OpenSAML. All experiments ran on Debian (version 7.0) Linux system with a 3.4 GHz Core i7-2600 CPU and 4 GB of RAM.
We analysed the slowdown in processing speed. The test results were gathered with Linux “time” command, which was able to show the total run time and the CPU time of a specified progress. Because there was no principal signing process in the original OpenSAML, we defined that the run time of the principal signing process in original OpenSAML was equal to \(0\). These tests considered two cases: (1) both the SAML assertion issuer and the principal signing assertions by using 1024 bit RSA keys; (2) both the SAML assertion issuer and the principal signing assertions by using 2048 bit RSA keys.
We analysed time performance with 1024 bits RSA keys firstly. The results of the run time tests were shown in Fig. 6(a). The run time of the issuer signing process was up \(8.4\,\%\) from the original. The run time of the signature verification process was up \(9.0\,\%\). But the test environment has a significant impact on the test results (The impact came from the concurrent processes in the system). The CPU time was more accurate than the total run time to reflect the slowdown in processing speed. The data described in Fig. 6(b) showed the CPU time comparison, when the 1024 bits RSA keys were used. The CPU time of the issuer signing process was up \(3.5\,\%\) from the original. The run time of the signature verification process was up \(3.6\,\%\).
We repeated time tests with 2048 bits RSA keys subsequently. Figure 6(c) showed the total run time comparison. The run time of the issuer signing process was up \(7.6\,\%\) from the original. The run time of the signature verification process was up \(10.8\,\%\). Figure 6(d) showed the CPU time comparison. The CPU time of the issuer signing process was up \(5.2\,\%\) from the original. The run time of the signature verification process was up \(6.8\,\%\).
7 Conclusion
In this paper we presented the environment-bound SAML assertion scheme as a new approach to enhance the security of SAML assertions. We described how to bind SAML assertions to the environment, and explained why it was able to protect SAML assertions against XSW and SAML assertion eavesdropping. To finish binding task, we introduced the Master-Slave signature, which was well suited for environment-bound SAML assertion scheme. At the end of this page, we demonstrated the feasibility of the environment-bound SAML assertion scheme by the experiment data and result.
We see the environment-bound SAML assertion scheme as a first step to enhance the security of SAML-based protocols and applications.
References
Cahill, C.P., Hughes, J., Lockhart, H., et al.: Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 (2005)
Somorovsky, J., Mayer, A., Schwenk, J., Kampmann, M., Jensen, M.: On breaking SAML: be whoever you want to be. In: Proceedings of the 21st USENIX Security Symposium, Bellevue, WA, USA, August 2012, pp. 397–412 (2012)
Sun, S.T., Beznosov, K.: The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems. In: Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS’12), Raleigh, NC, USA, October 2012, pp. 378–390 (2012)
Mcintosh, M., Austel, P.: XML signature element wrapping attacks and countermeasures. In: Proceedings of the 2005 Workshop on Secure Web Services (SWS’05), Alexandria, VA, USA, November 2005, pp. 20–27. ACM press (2005)
Jensen, M., Liao, L., Schwenk, J.: The curse of namespaces in the domain of xml signature. In: Damiani, E., Proctor, S., Singhal, A. (eds.) Proceedings of the 2009 Workshop on Secure Web Services (SWS’09), Hyatt Regency, Chicago, USA, November 2009, pp. 29–36. ACM Press (2009)
Campbell, B., Mortimore, C., Jones, M.B.: SAML 2.0 profile for OAuth 2.0 client authentication and authorization grants (draft-ietf-oauth-saml2-bearer-16), March 2013
Hardt, D.: The OAuth 2.0 authorization framework, October 2012
Chia, P.H., Yamamoto, Y., Asokan, N.: Is this app safe? a large scale study on application permissions and risk signals. In: Proceedings of the 21st International Conference on World Wide Web (WWW’12), Lyon, France, April 2012, pp. 311–320 (2012)
Bandhakavi, S., King, S.T., Madhusudan, P., Winslett, M.: VEX: vetting browser extensions for security vulnerabilities. In: Proceedings of the 19th USENIX Security Symposium, Washington, DC, USA, August 2010, pp. 339–354 (2010)
Mushtag, A.: Man in the Browser: Inside the Zeus Trojan, February 2010
Duong, T., Rizzo, J.: Beast, September 2011
Cahill, C.P., Hughes, J., Metz, R., et al.: Profile for the OASIS Security Assertion Markup Language (SAML) V2.0 (2005)
Cahill, C.P., Hughes, J., Beach, M., et al.: Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 (2005)
Neven, G.: Efficient sequential aggregate signed data. IEEE Trans. Inf. Theor. 57(3), 1803–1815 (2011)
Reagle: Schema for XML signatures (2001)
Josefsson, S.: The Base16, Base32, and Base64 Data Encodings, October 2006
Acknowledgements
This work was partially supported by a National Key Basic Research Project of China (2011CB302400), the “Strategic Priority Research Program” of the Chinese Academy of Sciences, Grant No. XDA06010701, and No. XX17201200048 of State Grid Corporation of China. We would like to thank all anonymous reviewers for helping us make this paper better.
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2014 Springer International Publishing Switzerland
About this paper
Cite this paper
Chen, K., Lin, D., Yan, L., Sun, X. (2014). Environment-Bound SAML Assertions: A Fresh Approach to Enhance the Security of SAML Assertions. In: Lin, D., Xu, S., Yung, M. (eds) Information Security and Cryptology. Inscrypt 2013. Lecture Notes in Computer Science(), vol 8567. Springer, Cham. https://doi.org/10.1007/978-3-319-12087-4_23
Download citation
DOI: https://doi.org/10.1007/978-3-319-12087-4_23
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-12086-7
Online ISBN: 978-3-319-12087-4
eBook Packages: Computer ScienceComputer Science (R0)