SAML Bindings and Profiles
The SAML 1.0 specification includes rules for binding SAMLP requests and responses to several communication protocols. Several Web SSO profiles are also defined by SAML 1.0. These are the Browser/Post and Browser/Artifact profiles.
SOAP Over HTTP Binding for SAML
Because SAMLP requests and responses are encoded in XML, their binding to SOAP is trivial: It amounts to the simple wrapping of SAMLP requests and responses into a SOAP envelope and body. The example below shows a SAMLP request and response transmitted over SOAP on HTTP. For this example, the namespace declarations have been omitted.
Figure 12SAMLP Request and Response Transmitted Over SOAP on HTTP
Security
HTTPS provides message integrity and confidentiality. Optionally, authentication can be added by using client authentication. The SOAP over HTTP binding for SAML makes use of these properties to make communication between the issuing and relying parties. The SAML binding requires that the channel provide integrity and confidentiality, and makes authentication optional depending upon system requirements.
Web Browser SSO Profiles of SAML
The Web Browser SSO profile is arguably the most important use case of SAML. The Web Browser SSO Profile includes the following basic steps:
- A user authenticates to a source site.
- The user accesses an Intersite Transfer URL at the source site.
- The destination site receives the user with SAML assertions.
- The user obtains access to the desired resource.
There are two SAML profiles defined to provide Web browser SSO:
Browser/Artifact: Using a small amount of data on a redirect query string, a Relying Party can access the assertion by directly communicating with the issuing authority.
Browser/POST: The entire assertion is transmitted to the Relying Party as a Form/POST.
Browser/Artifact Profile
Figure 13 is a basic activity diagram that illustrates the Browser/Artifact profile:
Figure 13Basic Activity of Browser/Artifact Profile
The sequence of events is as follows:
- The user authenticates to a source site using whatever authentication method the source site has in place.
- The user clicks a link to the source site's Intersite Transfer URL. Clicking this link causes the source site to generate an authentication assertion for the user.
- The user is redirected to the destination site's SAML Artifact Receiver URL. A SAML Artifact is included on the URL query string. The Target URL on the destination site the user wants to access is also included on the query string.
- The destination site determines source of the artifact and calls back to the source site to retrieve the SAML authentication assertion.
- The destination site validates the SAML authentication assertion and allows the user to access the desired resource.
There are several key things that happen in this profile that should be examined in more detail.
Intersite Transfer URL
The Intersite Transfer URL (Step 2 of the Browser/Artifact Profile section) is the resource at the source site that is responsible for generating a SAML assertion for the user. The format of the request to the Intersite Transfer URL is not defined by SAML 1.0. In practice, and in the Novell implementation, both the destination site ID and the destination target URL must be sent to on the query string. The destination site ID allows the Intersite Transfer service to know who it is generating the assertion for. Each different Relying Party site might have different rules for assertions that it accepts, so the Intersite Transfer service needs to take those into account when generating the assertion. Secondly, the Intersite Transfer service must know the actual Target URL the user wants to access on the destination site. After the Intersite Transfer service has generated and stored a SAML authentication assertion on behalf of the user, the user is redirected to the destination site. The user is not sent directly to the Target URL on the destination site, but rather, is sent to a special SAML Artifact Receiver URL at the destination site that is responsible for authenticating incoming SAML users. The redirect URL to the destination site's Artifact Receiver URL contains two pieces of information (as defined in SAML 1.0):
- SAMLArtifact: [TypeCode (2 bytes)] [Source ID (20 bytes)] [Assertion Handle (20 bytes)] Base 64-encoded.
- Target URL: A URL-encoded representation of the resource the user wants to access on the destination site.
Artifact Receiver URL
In Step 4 of the Browser/Artifact Profile section, the user is sent to the destination site's Artifact Receiver URL. The service running at this URL is responsible for authenticating incoming SAML users. The Artifact Receiver URL expects the SAMLArtifact and TargetURL query string parameters to be present on the incoming request or it fails. The Artifact Receiver URL first parses the SAMLArtifact to determine the ID of the assertion generator. Using that ID, the source site is able to determine what site issued the assertion associated with the incoming user. The source site is then able to send to that site a SAMLP Request for the assertion referenced by the received SAMLArtifact. The destination site can then validate the returned assertion. If the received assertion is valid, the destination site authenticates the user and redirects the user to the Target URL.
SAML Service URL
The service running at the Artifact Receiver URL must send the source site a SAMLP Request to obtain the Authentication assertion for the user (Step 4 of the Browser/Artifact Profile section). This implies that there is a SAML service running on the source site and listening for SAMLP Requests. This service is called the SAML Service and it is another URL running on the source site. This URL listens for incoming SOAP messages containing SAMLP Requests and attempts to fulfill them. In this example, the source site's SAML Service returns the assertion generated for the browser user by the Intersite Transfer service in Step 2 of the Browser/Artifact Profile section.
Browser POST Profile
The Browser POST profile is a simpler and somewhat less secure Web SSO. In this case, the SAML assertion is sent to the destination site in the form of an HTTP FORM POST. Figure 14 shows an activity diagram of the steps involved in this type of Web SSO:
Figure 14Activity Diagram of Web SSO Steps
The steps involved in this transaction are:
- The user authenticates to the source site.
- The user accesses the Intersite Transfer URL.
- The Intersite Transfer URL generates an assertion for the user and returns the assertion to the user in HTML form.
- The HTML form containing the assertion is POSTed to the destination site's POST receiver URL.
- The destination site redirects the user to the resource as indicated by the Target URL.
Intersite Transfer URL
The functionality of the Intersite Transfer URL is identical to the Browser/Artifact case, except that after the assertion is generated, rather than being stored waiting for retrieval by the destination site, it is Base 64-encoded and returned to the user in an HTML form. The Target URL is also returned in the same HTML form. The page can also contain Java script that automatically submits the form to the destination site POST Receiver URL.
Destination Site POST Receiver URL
The service running at this URL is nearly identical to that in the Browser/Artifact case. Instead of calling back to the source site SAML Service URL to obtain the assertion, the POST Receiver URL simply reads the assertion from the incoming request. The POST Receiver validates the assertion and re-directs the user to the Target URL.