What is the purpose of a SAML Artifact?

Question

I've seen a bunch of flow chart on how it is passed around between Identity Provider (IdP), Service Provider (SP), and Browser via Redirects. However it seems unnecessary to me right now, so i know i'm missing something.

Can someone provide me a use case where a SAML Artifact is required (or very useful) compared to not using one?

Thank you.

Solution 1

Typically, the intent of the artifact binding is to reduce the flow of SAML messages through the browser itself. This could be due to browser restrictions (browsers that have limits on query string / POST payload size) or no support for JavaScript (for auto-submitted forms), or even to improve the security model of how the SAML messages are transported. By using artifacts, sensitive data carried through the SAML Assertion / Attribute Statement is not passed through the browser, so it can be hidden from the end user or attackers between your site and the end user. This confidential data would only be directly resolved between sites through a back channel lookup.

Section 3.6.2 of the SAML 2.0 Bindings specs summarizes it best:

The HTTP Artifact binding is intended for cases in which the SAML requester and responder need to communicate using an HTTP user agent as an intermediary, but the intermediary's limitations preclude or discourage the transmission of an entire message (or message exchange) through it. This may be for technical reasons or because of a reluctance to expose the message content to the intermediary (and if the use of encryption is not practical). Note that because of the need to subsequently resolve the artifact using another synchronous binding, such as SOAP, a direct communication path must exist between the SAML message sender and recipient in the reverse direction of the artifact's transmission (the receiver of the message and artifact must be able to send a request back to the artifact issuer). The artifact issuer must also maintain state while the artifact is pending, which has implications for load-balanced environments.

Solution 2

Expanding on Scott T's answer, the SAML Artifact Profile was designed to improve security. To prevent a user from modifying it's SAML Assertion mid-traffic (such as changing Username, roles, etc), SAML 2.0 suggests that developers sign assertions via XML signatures. XML Signatures though are extremely vulnerable to XML wrapping attacks because of issues in every languages existing XML parsers. Visit https://www.usenix.org/conference/usenixsecurity12/breaking-saml-be-whoever-you-want-be to see XML wrapping attacks in action against SAML Assertions.

The SAML Artifact Profile solves this issue by creating a one-time use "artifact" that is passed to the Service Provider by the user (via redirect or post) rather then the SAML Assertion. When the Service Provider receives the one-time use artifact, it sends a SAML Artifact Resolve Request (containing the artifact) to the Identity Provider's Artifact Resolution Service (ARS). The ARS then responses with a SAML Artifact Response (containing the user's SAML Assertion) thereby preventing the SAML Assertion from ever being modified by the user as it is directly received by the Service Provider over a back channel.

Solution 3

A SAML message is transmitted from one entity to another either by value or by reference. A reference to a SAML message is called an artifact. The receiver of an artifact resolves the reference by sending a request directly to the issuer of the artifact, who then responds with the actual message referenced by the artifact.

Refer SAML 2.0,

Without the artifact there is no way to get to the actual message.

Note that this is only required when using HTTP Artifact Binding. (As opposed to the more common HTTP POST Binding which simple sends the SAML message).

Solution 4

Another reason for using HTTP Artifact binding is that you can use SSL to ensure SAML message integrity and confidentiality. The SAML requester and responder do not need to sign, validate, encrypt, and decrypt the SAML message.

Solution 5

it may be considered out of interest nowadays but the artifact profile is also useful if you have a low bandwidth between the user agent and sp & idp servers and a better bandwith between sp & idp. The (heavy) assertion does not circulate from the idp to the ua and from the ua to the sp and it may show better performance in certain circonstances.

View more solutions

Comments

[rock3t]

Does anything in SAML exists which allows no-browser interactions? You capture username:password and then talk with IdP whit out browser?

[Scott T.]

SAML by itself is used primarily for browser SSO. It can be wrapped in WS-Trust (docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html) to provide what you're asking - but this is pretty heavyweight.

[Scott T.]

Alternatives to consider: OAuth 2.0 can be used for simple non-browser cases like password-based authentication (tools.ietf.org/html/rfc6749). Many identity security products and applications are building RESTful authentication APIs based on OAuth. One such example (disclaimer I'm an employee) is from Ping Identity: apidocs.pingidentity.com/pingone/platform/v1/api/…

[rock3t]

Thanks, Scott. OAuth is the path we'll mostly take. Quite intrigued about SAML wrapped in WS-Trust never heard of this approach. Any implementation blogs/how to's?

[Bhushan Karmarkar]

Hi - thanks for explaining. Can I delegate the artifact ID to some other application (under the same umbrella) and that application resolves the assertion with IDP by exchanging artifact ID? Of course this other application could be any app, and not the SP registered to IdP. Any thoughts?