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.
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 12
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.
The Web Browser SSO profile is arguably the most important use case of SAML. The Web Browser SSO Profile includes the following basic steps:
There are two SAML profiles defined to provide Web browser SSO:
Figure 13 is a basic activity diagram that illustrates the Browser/Artifact profile:Figure 13
The sequence of events is as follows:
There are several key things that happen in this profile that should be examined in more detail.
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):
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.
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.
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 14
The steps involved in this transaction are:
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.
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.