-
Notifications
You must be signed in to change notification settings - Fork 23
Session state in EB 4.0.0
This page describes all session state kept for users.
Note that while this has been determined using EngineBlock 4.0.0, it will likely also hold true for earlier and later versions.
Session identifier. This is the temporary token handed to a user and kept in a HTTP cookie (sent with every request) that grants the user access to his/her session.
Note that this name depends on the session.name setting and it's scope depends on session.cookie-domain.
It's lifetime depends on session configuration but by default this is a 'session cookie' meaning that the browser will delete it when it is closed.
Language to show the user interface in (defaults to en).
It's scope and lifetime depends on EngineBlock configuration, by default this is:
; Language Cookie settings
cookie.lang.domain = ".surfconext.nl"
; Cookie expiry time, specify the time in seconds, set empty to let the cookie get expired after the session
cookie.lang.expiry = 5184000 ; 60 days in secondsEntity ID of the Identity Provider that was previously selected and will be shown as 'suggested' in the Identity Provider discover screen.
It's scope is the current domain, it's lifetime is 3 months.
We store all received SAML2 Requests for the duration of the session to:
- Enable use of Discovery screen without replaying AuthnRequest.
- Look up original Service Provider after the user returns from the Identity Provider with a SAML2 Response.
We cache all received SAML2 Responses for the duration of the session and reuse these when a user from a Service Provider does a new AuthnRequest. EngineBlock recognises 2 ways to reuse a response:
- A user does a new AuthnRequest from the same Service Provider and that Service Provider is still allowed to access the same Identity Provider. In this case the same Response (from the IdP) is used to create a new Response (saving the round trip to the IdP).
- A user does a new AUthnRequest from a different SP. In this case EngineBlock will request the list of available IdPs and if the user has a cached response from one of these then the user will not be shown a Discovery screen but will be redirected to the IdP.
We store the response between asking for and having given the response.
Corto has a mechanism called "Processing" which is used for steps that require user input, storing the login flow state, asking for user input and upon getting the user input retrieving the login flow state and continuing to the next step or to sending the response to the SP.
Profile allows users to add a Group Provider via OAuth. The 'return_url' (where to return to) and the OAuth Request Token are persisted in session storage.
The 'collabPersonId' or federation identifier (urn:collab:person...) is determined during processing of the incoming Response, but required during the entire flow, as such it is persisted in the session storage.
Within a given session EB will should never give out a different Transient NameID for the same combination of SP and IdP.
We store various data for auditing:
- Last error feedback data
- Logging (used when an error occurs)
- Current ServiceProvider / Identity Provider (for logging, even before response validation)
- Response from Idp for Idp Debugging
EngineBlock uses the native PHP Session controls that means the settings described at "Session Configuration" on php.net are relevant.
By default this will mean that a session will live 24 minutes past it's last accessed date.