How does SAML Service Provider understand identity after initial authentication (vs OIDC)?

0
votes

I'm looking to implement a plugin using OpenSAML for a 3rd party application that will enable the application to be treated as a SAML Service Provider, so that I can integrate it into AWS SSO.

The following image describes the SAML authentication process when the Service Provider (SP) and Identity Provider (IdP) use HTTP Artifact binding (taken from here):

SAML Authentication Flow

After the initial authentication, the SP returns the protected resource to the user. My question relates to how subsequent requests for protected resources are processed.

With OIDC, the browser would receive a token and this would be sent to the SP for subsequent requests. The SP can inspect the token and confirm its integrity (assuming it is signed) and validity, without needing to make further calls to the IdP to re-authenticate the end-user.

With SAML, how do I achieve the same effect? How do I not have to make repeated calls to the IdP to check identity?

I suppose I could use a session, but I don't understand how I might ensure that such information is not tampered with within the client (i.e. how does the SP not have to rely on information provided by the client?). Does SAML have some sort of concept of a token that is safe for the user to store (the HTTP Artifact binding explicitly restricts the user from seeing the response from the IdP)?

1
sessionsamlsaml-2.0openid-connectopensaml
_With OIDC, the browser would receive a token and this would be sent to the SP for subsequent requests. _ This is actually not true. – Bernhard Thalmayr
How so? For a typical integration of OIDC into auth/authz, once a user has authenticated, a JWT would typically be returned by some means (cookie or local storage, with consideration given to XSS / CSRF). Subsequent requests for a protected resource would then contain that JWT. A SP would check the validity of the token and serve up the protected resource if the JWT is valid. – John
depending on the OIDC flow (openid.net/specs/openid-connect-core-1_0.html), the browser may not see the ID Token (that's the standardised JWT), only the OIDC client may retrieve it. – Bernhard Thalmayr
Ah, yes, thanks, good point. – John

1 Answers

1
votes

What happens after the last step is not defined in the spec. You could say it's formally outside of SAML protocol. Even the last protocol-formalized step of SP supplying the resource is essentially a "do it yourself":

Section 3.4.5 (HTTP-Redirect binding):

Upon receiving the SAML response, the SAML requester returns an arbitrary HTTP response to the user agent

Section 3.5 (HTTP-POST binding):

Upon receiving the SAML response, the SAML requester returns an arbitrary HTTP response to the user agent

Section 3.6 (HTTP-Artifact binding):

[you can probably guess by now]

Most SPs will drop one or more cookies on the client during that last step. One of those cookies will contain a session ID or a more generic pointer that can be used to locate a session when sent back to SP. Subsequent resource "authorization" requests to SP will proceed by having the SP consult this server-side session. The session will usually hold the (authenticated) security context for this user/client.

For example, Shibboleth (built on top of OpenSAML) does so. The content of the cookie is up to the SP. It's arguable that token-based auth via e.g. local storage is more secure vs a cookie. There are pros/cons to both options and many factors specific to use case/context/technology stack impact the evaluation of risk and associated threat model.

Note: AWS SSO does not support the Artifact binding.