On Mon, Mar 17, 2014 at 6:44 PM, Paul B. Henson <hen...@csupomona.edu>wrote:
> > From: Richard Frovarp > > Sent: Monday, March 17, 2014 2:19 PM > > > > But it isn't stop using an application (unless a timeout there forces a > > logout of CAS). It's actually logging out of the application, and the > > user desiring to remove their access to the system. What good is logging > > out of an application if the only step required to get back in is > > clicking the login button? > > Consider two scenarios: > > 1) You have a single sign-on session, access blackboard, and then log out > of blackboard, but retain your single sign-on session. You then click back > to blackboard, and are transparently logged back in. > > 2) You have a single sign-on session, but gained from accessing some other > application, you have had absolutely no interaction with blackboard at all. > You click on a blackboard link, and are transparently logged in. > > Is #1 surprising, but #2 is not? They are both inherent artifacts of > having a valid single sign-on session. > Imagine this scenario. You are logged into Blackboard, you click logout. You get up, another person sits down at that same machine with the same browser session. They click login. They are now you. Perhaps you even leave the room. Would you expect that person to become you after clicking logout? We had that happen on one of our systems that was of extremely low security concern, and was reported to us. In essence they could have generated a guest wireless pass as someone else. In fact the person that discovered it didn't even have access to the system in question at the time using their account. > > > A surprising SSO is you logging out of a website, me sitting down, > > clicking login, and then being you. That isn't the point of SSO. > > There are really two ways to look at "SSO". The first is that you simply > use the same username/password pair for every single service, even if you > have to authenticate separately to them. The second is that you > authenticate once, and then can access every service without authenticating > again. > There is SINGLE sign on (SSO) and SAME sign on. The second is same sign on. > > Which one are you trying to implement? Because if you are trying to > implement the latter, then having an application "logout" destroy your > single sign-on session is what would be surprising. > In my case both. I don't know about the original poster. Authentication to computer via the AD domain is a type of SSO that share a same sign on with CAS (which is also an SSO at time, and a same sign on at other times). In our case we don't even use AD for CAS, but rather go through an MIT Kerberos. > > Basically, in the context of a global single sign-on session providing > access to all applications, the concept of "logging out" of a particular > application is no longer valid. Either you are "logged in" to everything, > or you are "logged out" of everything. And it seems the proper solution > isn't to have any single application destroy the entire session, but rather > stop having "application" logouts, and instead have each individual > application logout page go to a central CAS page where a user can select to > destroy their session or not. > > > I certainly get your point, and it may work for your users. It's not going to work for everyone. Unless Google, Microsoft, or Facebook are doing it, it will be difficult for my users to follow that train of actions. But I'll readily admit that we're behind the curve when it comes to SSO, and we're largely using CAS for same sign on. The original problem was with single sign off triggered by session expiration. Where a session timeout from one application triggered an automatic logout of that application, which then triggered a logout of CAS, which then triggered a timeout of another system, in this case Blackboard. It is entirely unexpected for one timeout to trickle it's way through other active applications. However, Google does appear to have a single sign out when the logout button is clicked. The idea is to implement the system to fit the needs of your institution. Single sign off is certainly not one of them for us, and I suspect that many other schools would find the same, especially if session timeouts are going to trigger them. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
