Please consider the envrionment before printing
SAML implementations typically exchange sensitive user data via the browser. This considerably increases the attack surface of your Single Sign-On (SSO) solution.
Luckily, SAML offers an alternative mechanism called HTTP Artifact binding that allows protocol messages to be transported more securely.
This article will look at the drawbacks of using HTTP Redirect and HTTP POST bindings for transporting protocol messages. We will then discuss how HTTP Artifact Binding works and why it can make your SSO solution more secure.
Although SAML defines several binding types for exchanging messages between trusted providers, most SAML SSO solutions utilize HTTP Redirect and HTTP POST bindings. Both HTTP Redirect and HTTP POST are front-channel bindings, meaning that the protocol messages are exchanged via the browser. Exchanging protocol messages in the full view of the browser increases the attack surface of an SSO solution by opening it up to risks such as Cross-Site Scripting (XSS). Personally Identifiable Information (PII) is also exposed to the browser unless the SAML assertions are encrypted. As we have seen with other protocols, such as OAuth, the more data we move to the server-side, the more secure the protocol.
The upcoming browser changes to phase out third-party cookies may be a further driving force for moving protocol messages away from the browser. With these changes, the browser will not attach cookies to cross-domain requests. This will impact SSO implementations as they commonly rely on cookies to manage user sessions and correlate requests with responses. So, it may become necessary to adopt back-channel communication.
This is where HTTP Artifact binding comes in.
SAML HTTP Artifact binding sends protocol messages using a direct server-to-server connection between an Identity Provider (IdP) and a Service Provider (SP). The messages never pass via the browser, so HTTP Artifact is a back-channel binding type.
At a high level, HTTP Artifact binding uses a similar approach to OAuth Authorization Code Flow. Instead of exchanging the SAML protocol message via the browser, it sends a unique one-time-use reference to the message called an artifact. The receiver resolves the artifact by sending a request directly to the artifact issuer. This exchanges the artifact for the actual message using a direct server-to-server connection between the providers, away from the browser. The secure back-channel exchange occurs over a synchronous binding, such as SOAP. So, that is SAML over SOAP over HTTP.
HTTP Artifact binding removes all sensitive user data from the browser. Only the artifact is exchanged via the browser, and without the artifact, there is no way of accessing the SAML assertion. This mitigates a set of attack vectors where an attacker steals and modifies the protocol messages. However, requiring signed artifact resolution requests can further secure the SSO solution, as message signatures cryptographically bind requests to their issuer. This means that the provider attempting to resolve the artifact can be authenticated, preventing stolen artifacts from being exchanged by a malicious party. Therefore, the attack surface of an SSO solution is significantly reduced by keeping assertions away from the browser and requiring signed back-channel requests.
When using HTTP Artifact binding to exchange the SAML assertion in SP-initiated authentication, the following flow will take place:
The SAML HTTP Artifact binding introduces an endpoint called the Artifact Resolution Service (ARS). This endpoint handles back-channel artifact resolution requests. So, this is where the artifact is exchanged for the actual message.
The SAML artifact is a base 64 encoded structured data, which consists of the following components:
The artifact resolution request contains the typical SAML protocol message attributes, with an ID, lifetime data, and information about its origin and destination. However, it also includes the artifact that is being resolved.
The artifact resolution request is sent using SOAP over HTTP. At the most basic level, this means that the request is wrapped in a SOAP envelope and placed inside a SOAP body. This request is posted to the identity provider’s Artifact Resolution Service endpoint.
IdentityServer
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<saml2p:ArtifactResolve
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_5a3d22bf133b46c5ab5ff8d20d21d6e7"
Version="2.0"
IssueInstant="2021-02-08T19:42:07Z"
Destination="https://idp.local/saml/ars">
<saml2:Issuer>https://sp.local</saml2:Issuer>
<saml2p:Artifact>AAQAADFQVAa+qBUxf70R+iio9SYSaZR9lh9eb/Ch30mTAa+GtZhf/QAAAAA=</saml2p:Artifact>
</saml2p:ArtifactResolve>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>The SAML response containing the assertion is also returned as a SOAP message. However, it is also wrapped in an ArtifactResponse message.
The ArtifactResponse follows the typical SAML response structure, with an ID and information about the message's origin and destination. However, it represents the response to the ArtifactResolve request as opposed to the inner SAML response, which is the response to the original authentication request. As a result, it has its own issuer, status, and issue instant.
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<saml2p:ArtifactResponse
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_79a1ca0e-65ac-40ab-89ea-6997445625d7"
InResponseTo="_5a3d22bf133b46c5ab5ff8d20d21d6e7"
Version="2.0"
IssueInstant="2021-02-08T19:42:55Z">
<saml2:Issuer>https://idp.local</saml2:Issuer>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</saml2p:Status>
<saml2p:Response>
<!--full SAML Response & Assertion-->
</saml2p:Response>
</saml2p:ArtifactResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>HTTP Artifact Binding can be used to transport any SAML protocol message. Both Identity Provider and Service Provider can support Artifact Resolution Service endpoints. The mechanism is termed as Double Artifact Binding when both the request and response are exchanged using HTTP Artifact binding. Using Double Artifact binding, only the artifacts are exposed to the browser.
Unlike the SAML front-channel bindings, HTTP Redirect and HTTP POST, which perform SSO in the full view of the browser, the HTTP Artifact binding sends protocol messages using back-channel communication. Thus, keeping protocol messages away from the browser and considerably reducing the attack surface of an SSO solution.
Using HTTP Artifact binding for sending SAML assertions ensures that all sensitive user data is removed from the browser. However, there is no huge benefit for using HTTP Artifact binding to exchange other protocol messages, such as the authentication and logout requests. But due to the upcoming browser changes, there may be an increase in demand for HTTP Artifact binding for all SAML protocol message types.
Our SAML component now supports Double Artifact binding for SAML Service Provider and SAML Identity Provider implementations. This means that you can use HTTP Artifact binding for transporting all SAML protocol message types.
Check out our SAML component page for more information.
