Session duration in SURFconext: a balance between usability and security

Sessions

Staying logged in has everything to do with sessions. By allocating a unique code to a web browser/visitor, the web server will know which browser will return once the visitor has registered during the first visit. The period during which the browser identifies itself to the web server using this code is called the session duration. The session duration is determined on the basis of five factors:

1. Firstly the required security level. Banks, for example, choose for sessions of users logged in to perform bank transactions to be cancelled after just 5 minutes of inactivity.
2. However, it is not necessary to every application to only allow short sessions lasting just a few minutes. This often depends on the type of data being processed and the application being used. One type of data or kind of application is considered more sensitive than the other.
3. User experience also plays a part in determining the session duration. Users are used to staying logged in for some applications so that the application can start again quickly without having to log in again, as with Google’s Gmail, for example. The application may decide to change the session code after a certain period, so that the same code is not used for the entire period.
4. The web browser can also affect the session duration. As well as a duration in terms of time, the validity of a cookie can also be linked to opening and closing the web browser. These are also known as ‘session cookies’. These cookies are erased when the web browser is closed so the user is not recognised when the browser is reopened.
5. Lastly, when determining the session duration, the device used must also be taken into consideration. If someone is using a public computer, it is advisable for the session to be ended once the web browser is closed to ensure the next user starts from scratch rather than continuing where the previous user left off. In the case of mobile devices, which today include finger scanners to enable users to unlock their device, you can perhaps assume that this will always be the same person.

SURFconext authentication infrastructure

The SURFconext authentication infrastructure does not concern just one session; three different sessions must be taken into account.

(I) First of all, (using their web browser) the user accesses the service (SP). At this point, the service’s web server will redirect the user to SURFconext.

(II) SURFconext will subsequently redirect the user, possibly via the WAYF service, to the institution’s login page (IdP).

(III) On the IdP, the user will login and following successful login the session will start. Via SURFconext the user is directed back to the service. In both cases, a session is also started at these contact times.

The web browser has therefore had contact with three web servers, the SP, SURFconext and the IdP, all three of which have started a session of their own, independently of one another.

An SP will retain full control as long as the session on that SP remains active. As soon as the SP session ends or the user logs out of the SP, SURFconext and the IdP become significant again. If the user accesses the service again, the service will redirect the user to SURFconext. At this point SURFconext can still recognise the user from the session started by SURFconext itself, so that this is immediately redirected to the IdP, where the user can then be recognised from the session started by the IdP. The user will then automatically be redirected back to the SP and logged in without having to enter their user name and password on the IdP.

You should note that there is therefore no point in allowing a shorter session for the SP than for the IdP. If the SP session ends before the IdP session has ended, the user will still automatically be logged in next time the SP is accessed. So in effect, the IdP determines the session duration. As long as the session on the IdP has not ended, the user can continue to log in to all services linked to the IdP via SURFconext without having to log in to the IdP every time. The IdP determines the Single Sign On.

The SP has a means of reading and using or reusing the IdP session duration via SAML and there is a mechanism which the SP can use to force a login on the IdP, allowing a different session duration to the one set for the IdP. The role of SURFconext is fairly limited as regards session duration. SURFconext always forwards authentication requests to the IdP and only remembers the institution’s IdP to which the user is directed for a certain period.

Recommendation with respect to SP session duration

The use of session cookies is recommended for services linked to SURFconext to at least ensure that all sessions end simultaneously at the time when the browser is closed. We also recommend that linked SPs maintain the same session duration as the IdP so that the IdP continues to control the security level of the linked services.

When and why do I need to log in again?

These are the consequences of one of the three different sessions ending:

1. If only the IdP session ends, work on the SP can continue. It is only if the SP session ends or a new SP is accessed that SURFconext will redirect the browser to the IdP and the IdP will prompt the user to log in again.
2. Work on the SP can also continue if only the SURFconext session ends. If the session on the SP ends or a new SP is opened, SURFconext will again display a WAYF for the user to select the appropriate institution. Once the institution has been selected, login on the IdP will be automatic.
3. If only the SP session ends, then when the user returns to the SP or opens a new SP, login will be automatic via the existing sessions of SURFconext and the IdP, this is called Single Sign On.

The user will therefore only need to log in again if the IdP session has ended. If the SURFconext session has ended a WAYF will again be displayed prompting the user to select an institution.

More information

Technical information for the administrators of institution identity management systems and the administrators of the services using SURFconext can be found on the SURFconext wiki. You will find a detailed explanation of how this is achieved in SURFconext and exactly how it works. Answers are also given to questions such as ‘What are sessions and how long does a session last?’, ‘How do sessions work in the SURFconext authentication infrastructure?’ and ‘When and why do I have to log in again?’ This is a summary of the full article on wiki. Read the full article here.