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.
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:
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.
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.
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).
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.