SAML protected resource

Question

I am trying to protect a resource using SAML. There are three actors at play: identity provider (IDP, outside of my control), service provider (SP, I happen to be using spring-security-saml, but this question is not specific to that), and the protected resource (PR, some protected endpoint in a service outside of the SP).

There are two scenarios that I need to support:

1. The user attempts to access the PR for the first time, without any kind of session.
2. The user attempts to access the PR again, when they have previously accessed it.

There is ample guidance on how scenario 1 should work as it is the standard way to use SAML from what I've seen. Scenario 2 seems to be less standard though and I have yet to find any definitive documentation on how it should be handled.

In scenario 1, the flow seems to be standard:

• User attempts to access PR
• PR directs the user to the SP
• SP does the normal SAML assertions with the IDP then redirects the user to login with the IDP
• User successfully logs into IDP
• User is redirected back to SP with information about the user
• SP redirects back to PR (possibly with some kind of generated token to use in the future or additional information about the user)
• Information from PR is supplied to the user

It is scenario 2 that I am less clear on, my thinking is the following:

• User attempts to access PR with token provided in previous scenario
• PR checks the validity of the token with SP
• SP determines if token is valid (how is this done? There doesn't seem to be anything in the SAML standard for checking if a session is active)
• PR allows access to resource depending on response from SP

My questions are:

• Is my understanding of scenario 2 correct? Is this how SAML is intended to be used?
• How would I check the validity of the session with the IDP?
• Does the PR have to check the validity of the session on every request? Since SAML doesn't require an expiration (like OAuth access tokens) there doesn't seem to be any way to cache a user's session.

Answer 1

There can be two conditions for accessing the PR.

1. A valid application session created by PR with a specified time before it needs to be renewed.
2. A valid SAML token on which to base the application session.

The PR could take the view that as long as the SAML token is valid then the application session is valid. Or it could decide it wants to create a new session every 10mins, which means redirecting to the IdP to get a new SAML token on which to base the new application session. It depends on the resource being protected. In a sensitive resource, medical data perhaps, the session should be managed accordingly.

In terms of SAML token validity, the IdP issues the token for a set period of time using Response/Conditions/NotBefore and Response/Conditions/NotOnOrAfter which are shown in the examples. There is also Response/AuthnStatement/SessionNotOnOrAfter which can be used to check validity. This:

Gets or sets the time instant at which the session between the principal identified by the subject and the SAML authority issuing this statement must be considered ended

from here. This effectively limits the PR session as the IdP "disowns" the user after this time. e.g. a public walk-in access request for an hour's access to PR. NotOnOrAfter refers to the assertion while SessionNotOnOrAfter refers to the user. After SessionNotOnOrAfter the IdP might not authenticate the user depending on policy etc.

If the PR needs to renew the application session, it could ask the SP to validate the SAML token, which could involve working out whether NotOnOrAfter is in the past. If it is, then the SP would start the process with the IdP again to get a new SAML token. If an IdP is dealing with a sensitive PR, it may release attributes for a limited time, depending how access is granted at its end.