Date: Thu, 28 Mar 2024 19:49:24 +0000 (UTC) Message-ID: <1212465617.21.1711655364750@03e092142a88> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_20_523452661.1711655364750" ------=_Part_20_523452661.1711655364750 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Shibboleth 2 IdP does not support single logout in = any meaningful sense. A very limited, and usually more harmful than helpful= , feature is documented at IdPEnableSLO.
This document is NOT a recipe for implementing single l= ogout. It's a warning to those who think they understand it. They probably = do not understand it and need to think about it long and hard before they t= hink about trying to deploy something, whether it's Shibboleth or something= else. This is particularly because the logout problem in a federated envir= onment is nothing like enterprise logout, and with the increased amount of = outsourcing, there is no such thing as a non-federated enterprise anymore.<= /p>
First, some humor.
Since Shibboleth was developed, one of the most requested features has b= een Single Logout (SLO). Our lists are full of threads indicating that this= feature is not as easy as it seems. This document is an attempt to collect= and expound upon the difficulties of SLO.
The issues presented below are not a list of theoretical issues that may= occur. Some of the developers have experience with SLO implementations in = similar protocols and have experienced all or most of these issues. In addi= tion, the Shibboleth team has received reports from sites that have tested = the Hungarian SLO plugin and they have also encountered these= issues.
Before beginning to look at the issues surrounding SLO a brief descripti= on of how the majority of web applications track their sessions and the mes= sage flow within SAML 2 SLO is provided.
Most web-based applications store data about currently active users with= in memory and index this collection of data with a randomly generated numbe= r: a session ID. This session ID is normally stored in a browser cookie so = that each time the user returns the cookie is presented to the application = and the application can find the relevant, current, session data.
SAML 2 SLO may be initiated by either the identity provider (IdP) or ser= vice provider (SP). A SAML 2 SLO request contains: a NameID that indicates = the user to be logged out and, optionally, a session index that corresponds= to the optional attribute within the initial authentication statement. A S= AML 2 SLO response contains a status URI that indicates whether the logout = operation was successful.
The SLO message flow is as follows. Note, it is the responsibility of th= e SLO initiator to provide the user with information about whether SLO has = succeeded or failed.
SAML 2 defines two broad means of transporting these messages; through t= he browser via HTTP POST or Redirect, known as front-channel bindings, or v= ia direct IdP/SP SOAP messages, known as a back-channel binding.
In order for SLO to be successful a couple of requirements must be met f= rom a user experience side:
One of the first issues with SLO is communicating to the user what will = occur if they click "logout". Users have already been taught that doing thi= s will cause them to be logged out of the application that contained the lo= gout button/link they used. They assume that all other applications will re= main active. Therefore there must be some means to distinguish between appl= ication-level logout and SLO.
This issue is usually addressed by providing a consistent UI component a= cross all participating applications. MS Passport, Virginia Tech's Authport= al, and other systems, do this by placing a branded, distinct, image/button= in place of the application-level logout link/button. When a user visits a= site that participates in the SSO system the application displays a form o= f the UI component that indicates that the user may log in. When the user i= s logged in the UI component is changed to reflect this state.
This approach however suffers from two problems. First it requires educa= ting users about this UI component and what it is meant to convey. Second, = it requires all SPs display the same UI component. While the first issue ca= n be solved through an education effort the second problem is practically u= ntenable. Third-party SPs sell their services to many organisation and are = unlikely to coordinate a different UI component for each one. It's also exc= eedingly unlikely that all organisations and SPs would agree upon a single,= uniform, UI component.
Another UI issue occurs during SP-initiated SLO. In this case it is the = SPs responsibility to provide the final indication to the user about the su= ccess or failure of SLO. However, the amount of information that the SP get= s back from the IdP is very limited; a URI that either indicates complete s= uccess or one that indicates some failure in the process. In the case where= SLO fails the SP will have little information with which to tailor what it= displays to the user since it will not know the cause of the failure. In a= lmost all failure cases the sensible thing would be to tell the user to clo= se their browser. This provides a way to deal with this issue, but it's not= very elegant.
If a front-channel binding is used this problem can become worse. In the= event that a SP is not responsive the user will be presented with an HTTP = error. At this point neither the IdP nor the SP present information to the = user. Some SLO implementation attempt to solve this by the use of frames. I= f implemented properly this can help ameliorate the issue.
Accessibility comes up in two places during SLO. First is the aforementi= oned logout UI component. Most sites seems to use an image for this. This p= oses a problem for visually impaired individuals. The solution to this is p= retty simple; use a good, descriptive, alt tag for the image. Most sites do= not seem to do this.
As previously mentioned, the mechanism usually used to deal with the HTT= P errors, that can occur during the use of front-channel bindings, is frame= s. Most accessibility experts however find the use of frames to be unaccept= able because of the great difficulty (or impossibility) of presenting such = an interface to individuals with various impairments. Most web browsers mea= nt to assist these individuals can not render various types of frames.
One problem, that of conveying information to the user when an HTTP erro= r is encountered during the use of a front-channel binding, has already bee= n discussed. However, there is also a correlated technical problem. When th= e IdP is using a front-channel binding to send messages it is tossing compl= ete control to the SP (which it hopes will be there to catch it). If the SP= is not responsive the process breaks down and the remaining SPs will not r= eceive logout requests. So, in addition to not being able to tell the user = what has happened there are also SPs, with active sessions, that are unawar= e that a failed logout attempt has occurred.
The reason for the front-channel binding is so that the user's browser, = with its session cookie, show up at the application. One use case for singl= e logout, however, is an administrator forcing the cessation of another use= r's session (e.g. their account has been compromised, because the user is d= oing something bad, etc.). In this case it will be the administrator's brow= ser, and not the user's, that will visit the service providers thus prevent= ing the applications for accessing a session cookie and destroying it as th= e means to invalidate the session. The means for addressing this is provide= d later.
The use of the back-channel binding can mitigate almost all the issues p= resented so far (except the lack of failure information in the SLO response= during SP-initiated logout). However, like in the case with administrative= logout over a front-channel binding the user's session cookie is not avail= able to the application and so the same issues are present; inability to lo= ok up the user's session and destroy it.
Finally, there is the problem that only SAML 2 supports single logout. I= f any entity supporting only SAML 1 is participating in the SSO session the= y will be left out of the logout process. Attempting to explain to a user w= hich services support SLO and which do not is unlikely to be successful.
A final issue that people have raised with single logout is the question= of who may initiate logout. Some organisations have concerns about allowin= g third-party applications to initiate a logout. Most of these concerns are= rooted in the poor mechanisms currently used to communicate that the user = is participating in an SSO session and that "logging out" will destroy thei= r session on all applications.
An example case goes as follows. A student accesses the university's stu= dent information system, which participates in the SSO service. The student= goes to register for classes and is reviewing possible courses. During thi= s review process the student access some material from the library, which a= lso participates in the SSO session, to see if the associated class is what= they want. Because they have been taught to always logout of applications = they click the logout link in the library application. This link is actuall= y an SLO-enabled link and also destroys the session within the student info= rmation system.
So, some organisations wish to limit who can initiate a single logout to= a set of applications that are under their control. A question then arises= ; what do you do if the user has only logged in to application outside the = organisation's control? Users will either need to be taught that some appli= cations can only initiate logout in certain situations or that if certain a= pplications (third-party ones) are used they must close the browser instead= of using the logout mechanism. Either message is unlikely to be understood= by many users.
When presented with these issues many individuals offer a protocol where= only the initiating SP and the IdP communicate. The goal is to destroy the= SP's session and the IdP's session so that users would have to re-authenti= cate if they visit that SP again. This approach leaves all other SP session= s active and communicating to the user exactly what they have, and have not= , been logged out of is likely not possible. Therefore, this approach incre= ases the risk that a user might abandon a computer with active sessions and= allow an unintended, and possibly malicious, user access to those services= .
To put it tersely, any application that would attempt this approach is l= ooking out only for themselves at the cost of compromising the security for= every other application participating in the SSO system.
A web application developer should do one of two things to support singl= e logout when using Shibboleth. The easiest is to remove all application le= vel session management and rely solely on the Shibboleth SP's session manag= ement. In addition to gaining SLO support the modified application will imm= ediately gain new session related features as they are added to the Shibbol= eth product and eliminate any confusion that may occur if the application's= session's configuration differs from that of the Shibboleth SP configurati= on (e.g. different session timeouts).
Web applications that do not rely on the Shibboleth SP session managemen= t will need to index their sessions by means of the Shibboleth session ID, = provided by the SP in the Shib-Session-ID header. Then they must i= mplement a callback script, that will be invoked when the SP receives a log= out request, that will be destroy the user's session. Note, however, that t= he application MUST NOT assume that the incoming request b= ears the session cookie and the script must be designed with that in mind.<= /p>
In summary, the issues surrounding the use of SLO generally fall in to e= ither user experience issues or technical issues. Many user experience issu= es can be addressed if an organisation is willing to invest effort in educa= ting its users (which requires an ongoing effort in order to catch new indi= viduals). The user experience and correlated technical issue that occurs wh= en an HTTP error occurs during the the use of front-channel bindings can no= t be addressed if accessibility requirements are also to be met. As such, b= ack-channel bindings are most likely to be successful but usage requires we= b application to take the aforementioned prerequisite steps, work that many= developers have expressed an unwillingness to undertake. This will leave m= any organisations at an impasse, choosing between a solution with a high ri= sk of being insecure or forcing developers to make changes to applications = throughout the organisation.