The first of the two profiles defined by version 1.0 of SAML uses a level of indirection in presenting its security evidence. The browser first obtains from the source site a small identifier called an artifactby SAML.
Artifacts are used so that SAML assertions may fit into an HTTP URL from a Web browser. Typically a browser would pass security information in a cookie. However, cookies cannot be used in cross-domain applications, so the URL may be used instead to pass security data. Browsers put a limit on the size of the URL length that they will support, and SAML assertions containing a large number of attributes may not fit into a URL. Note that the browser manufacturers, not the HTTP specification, impose a limit on the URL size. For example, Microsoft Internet Explorer imposes a limit of 2 KB on the HTTP URL size. We discuss the topic of session tracking on the Web in more detail in Chapter 6, “Principles of Securing Web Services.”
We will first describe the format for an artifact and then describe how it is used. SAML Artifact Structure
The artifact structure consists of a mandatory 2-byte field followed by optional addi- tional data and is defined as follows:
SAML_artifact := B64(TypeCode RemainingArtifact) TypeCode := Byte1Byte2
The B64 notation means that the artifact is base64 encoded. Base64 encoding trans- forms any binary representation to text by substituting ASCII text character groups for any non-ASCII characters, thus allowing you to treat binary encodings as text.
The TypeCode is defined as:
TypeCode := x0001
The RemainingArtifactfield is composed of a SourceIDfollowed by an AssertionHan- dlewhere:
SourceID := 20 byte sequence AssertionHandle := 20 byte sequence.
Copyright © OASIS Open (2001, 2002). All Rights Reserved
Thus, for this release of the SAML specification, the artifact is 42 bytes long. The SourceIDis to be used by the target to determine the identity of the source site. This encoding is not defined, but it is assumed that the target will store a table of source site identifiers keyed by SourceID. The source site identifier must be rich enough for the target to identify and contact the source site.
The source site uses the AssertionHandle to locate an assertion for a particular browser user. It is assumed that the source site will keep a table of assertions or suffi- cient information to construct a particular assertion keyed by AssertionHandles. The requirement is that, when a source site is presented with an artifact, it will be able to return the correct assertion to the requestor.
Using the SAML Artifact
Given that we now understand what an artifact is and how it may be used, we can trace how a browser can use the artifact protocol. The browser wishes to initiate a con- versation with some target. There are two ways that a secure, SSO connection can be initiated using the Browser Artifact Protocol.
1. The browser can try to access the target without an artifact, and the target will cause the Browser request to be redirected to a third-party authority, called the source site in the protocol.
2. The browser can access the source site on its own and request an artifact. In either case, the browser must authenticate itself with the source site. This may be done before the request is sent to the target or, in the first method, the target may force the authentication.
In the first case, the browser reaches the source site by redirection and requests an artifact by presenting information on the target to be accessed. If the browser is not authenticated to the source site, the browser is required to log in. This will be the only login request for this session with the source site and thus the rationale for the claim of SSO. The source site constructs an artifact and returns the artifact to the browser, Step 1 in Figure 5.2, and redirects the browser to the target.
In the second case, the browser accesses the source site, either having logged on pre- viously or at the time of access, and requests an artifact for a target.
The browser presents the artifact(s) to the target. Note that the browser may send more than one artifact. The target dereferences the artifact, determines the location of the source site, and makes a SAML request to the source site, sending the artifact(s) that it received from the browser. The target must use the SAML binding protocol in access- ing the source site. The request is a SAML request asking for one or more assertions that are associated with the artifact or artifacts sent.
The source site inspects the artifact(s) and creates or retrieves the proper assertion(s) and returns them to the target in a SAML response. The source site must return one assertion for each artifact in the request. The target may make additional requests on the source site, depending on what it is trying to accomplish. For example, the target may request a SAML authentication assertion, and then, after assuring itself of the authenticated user’s identity, it may make an attribute and/or authorization request. These requests may be made to the same source site if it handles both types of requests, or the requests may be sent to other SAML authorities. Once the target has the proper assertions, it may perform other security functions such as authorization. These will be carried out using the appropriate SAML methods.
There are a number of potential security threats to the browser artifact protocol that the specification describes and makes recommendations on how to mitigate. The threats described are:
Stolen artifact. If an attacker can obtain an artifact, then that attacker has a very good chance of impersonating the user. To counter this threat, the specification states that the exchange must have confidentiality and integrity protection. This can be accomplished by using SSL/TLS. If the bad guy defeats this, say, by com- promising the DNS and redirecting the browser to a malicious site, then a short validity time can be used to limit the time available to the attacker. For example,
the source site can check the time between the request from the target and the creation time of the corresponding artifact. The specification recommends that this time should be set to a few minutes. This, of course, means that the time clocks of the source site and the target must be synchronized. Given this con- straint, the time that an artifact is valid must be greater than this chosen delta time. The target may also set a valid time limit on the time span during which it will accept a valid assertion. Another, albeit weak, approach is to check the IP address of the browser if it is included in the assertion.
Attacks on the exchange. The stealing of the artifact being sent from the target to the source site by man-in-the-middle and replay attacks may compromise the exchange between the target and the source site. These attacks may be defeated by good distributed security practices such as encrypting messages using, say, SSL/TLS, mutual authentication, and signing the message.
Malicious target. Someone with bad intent may set up a malicious target. If so, that site could turn around and imitate the user. If this target is not one that has a relationship with the source site, mutual authentication will defeat this attack. Note that the target must establish trust with the authenticated source site. If the target has a relationship with the source site, the source site should check whether the request has come from the site to which it sent the artifact. Remem- ber, the target is named in the artifact.
Forged artifact. Some sites may try to create a bogus artifact. The algorithm that the source site uses to create the artifact should contain enough randomness to make constructing an artifact very difficult.
Exposure of the browser state. The artifact may be stolen from the browser and reused. The use of an artifact should be checked by the source site, and it should only allow the artifact to be used once. The specification recommends a short lifetime for an artifact. Thus, the exposure time of the artifact is limited to this short lifetime.
SAML POST
A second profile defined by the SAML specification uses the HTTP POST protocol to transmit assertions from the browser to the target. The POST method does not impose any size limits, so you are not forced to invent a method to keep the size of the security information small, as is done in the artifact profile described previously.
In the POST profile, the browser makes a request to the source site, passing the requested target the browser wishes to access. The source site constructs one or more SAML assertions and puts them in an HTTP form. The source site returns the form that contains the assertion(s) to the browser with a redirect to the target. The assertions must be digitally signed, and it is further recommended that the transfer between the browser and the source site and the browser and the target be protected by SSL/TLS or some other mechanism to ensure confidentiality. Further, the target must ensure that the assertion can be used only once. This may require the target to hold a lot of state for an indeterminate time.
This profile faces security threats similar to those faced by the artifact, with the dif- ference that an assertion is sent rather than an artifact.
In the next section, we will take a brief look at an endeavor named Shibboleth that is working on SAML-based solutions for some of the harder problems in distributed security.