Understanding SAML 1.1 Assertions
Each party in the request-response communication must adhere to certain requirements. The requirements provide a predictable infrastructure so that the assertions and artifacts can be processed correctly.
- The artifact is a Base64-encoded string of 40 bytes. An artifact acts as a token that references an assertion on the source site, so the artifact holder—the Connect Secure device—can authenticate a user who has signed in to the source site and who now wants to access a resource protected by the system. The source site sends the artifact to the device in a redirect, after the user attempts to access a resource protected by the system. The artifact contains:
- TypeCode—A 2-byte hex code of 0x0001 that identifies the artifact type.
- SourceID—A Base64-encoded string of 20 bytes that determines the source site identity and location. You can use OpenSSL or similar Base64 encoding tool to generate the encoded string. The system maintains a table of SourceID values and the URL for the corresponding SAML responder. The system and the source site communicate this information in a back channel. On receiving the SAML artifact, the system decodes it and ensures that it is 20 bytes. It determines whether or not the SourceID belongs to a known source site, and, if it does, obtains the site location before sending a SAML request. The source site generates the SourceID by computing the SHA-1 hash of the source site’s own URL.
- AssertionHandle—A 20-byte random value that identifies an assertion stored or generated by the source site. At least 8 bytes of this value should be obtained from a cryptographically secure RNG or PRNG.
- The intersite transfer service is the identity provider URL on the source site (not the Connect Secure device). Your specification of this URL in the admin console enables the system to construct an authentication request to the source site, which holds the user’s credentials in cache. The request is similar to the following example:
GET http://<intersite transfer hostname and path>?TARGET=<Target>...<HTTP-Version><other HTTP 1.0 or 1.1 components>
In the preceding sample, <intersite transfer hostname and path> consists of the hostname, port number, and path components of the intersite transfer URL at the source and where Target=<Target> specifies the requested target resource at the destination (Connect Secure protected) site. This request might look like:
GET http://10.56.1.123:8002/xferSvc?TARGET=http://www.dest.com/sales.htm
- The intersite transfer service redirects the user’s browser to the assertion consumer service at the destination site—in this case, the Connect Secure device. The HTTP response from the source site intersite transfer service must be in the following format:
<HTTP-Version> 302 <Reason Phrase>
<other headers>
Location: http://<assertion consumer hostname and path>?<SAML
searchpart><other HTTP 1.0 or 1.1 components>
In the preceding sample, <assertion consumer hostname and path> provides the hostname, port number, and path components of an assertion consumer URL at the destination site and where <SAML searchpart>= …TARGET=<Target> …SAMLart=<SAML artifact>… consists of one target description, which must be included in the <SAML searchpart> component. At least one SAML artifact must be included in the SAML <SAML searchpart> component. The asserting party can include multiple SAML artifacts.

| Note: You can use status code 302 to indicate that the requested resource resides temporarily under a different URI. |
If <SAML searchpart> contains more than one artifact, all of the artifacts must share the same SourceID.
The redirect might look like:
HTTP/1.1 302 Found
Location: http://www.ive.com:5802/artifact?TARGET=/www.ive.com/&SAMLart=artifact
- The user's browser accesses the assertion consumer service, with a SAML artifact representing the user's authentication information attached to the URL.
The HTTP request must appear as follows:
GET http://<assertion consumer hostname and path>?<SAML searchpart> <HTTP-Version><other HTTP 1.0 or 1.1 request components>
In the preceding sample, <assertion consumer hostname and path> provides the hostname, port number, and path components of an assertion consumer URL at the destination site.
<SAML searchpart>= …TARGET=<Taret>…SAMLart=<SAML artifact> …
A single target description MUST be included in the <SAML searchpart> component. At least one SAML artifact MUST be included in the <SAML searchpart> component; multiple SAML artifacts MAY be included. If more than one artifact is carried within <SAML searchpart>, all the artifacts MUST have the same SourceID.
You should not expose the assertion consumer URL unless over SSL 3.0 or TLS 1.0. Otherwise, transmitted artifacts might be available in plain text to an attacker.
- The issuer value is typically the URL of the source site. You can specify the <ISSUER> variable, which will return the issuer value from the assertion.
- The username template is a reference to the SAML name identifier element, which allows the asserting party to provide a format for the username. The SAML specification allows for values in the following formats:
- You can prevent eavesdropping on the SAML artifact by synchronizing the clocks on the source and destination sites. The system provides an Allowed Clock Skew attribute that dictates the maximum time difference allowed between the system and the source site. The system rejects any assertions whose timing exceeds the allowed clock skew.
Related Topics