Making Single Sign-On, well, "Single"

Here's a common scenario:

Yep, that's the login screen.

A member of the UofM community, we'll call her "Alice," wakes up in the morning and checks email... That requires logging into the familiar blue UofM login screen. She types her username & password and is sent on her way to read her waiting messages.

A few minutes later Alice visits our website https://www.lib.umn.edu intent on looking over her list of checked out items and maybe registering for a workshop.  She still sees a "Sign in" link at the top despite logging into email just a moment earlier.

Alice clicks the "Sign in" link on our website, her browser window refreshes a couple of times and she's suddenly signed in. "Wait, I thought we had a single sign-on at this university. Why did I have to click "Sign in"? She didn't need to type her password again, at least.

"Hmm, I just signed in. Ok, whatever." *click*

If Alice had been required to sign in before ever visiting our website, this wouldn't be a problem.  We could have just redirected her browser a couple of times before landing on the Libraries' homepage, collect login credentials if needed, and she'd be all set, but since we want users to be able do almost everything on our site without logging in, it's more complicated.

"Finally...I thought this was supposed
to be single-sign-on."

I won't bore you with the technical details of the UofM's central authentication system to explain why the situation is this way, or how it differs from what we had a few years ago (I started to, and deleted it when it reached three paragraphs), but suffice it to say it's inconvenient for our users and that bugs me tremendously.

We can do better.

I mentioned it might be possible to just redirect the browser a few times before landing on the homepage and be logged in.  Well, that's certainly possible and it works well even. But when our web design team undertook the Libraries' site redesign last fall, one of the driving principles behind the work was that the new homepage must be fast. Not just fast, but the fastest of any CIC library. according to Google's PageSpeed Insights metrics.

Delaying the homepage load for up to two seconds for users on campus or even three to four seconds for users off of the campus networks while login status is verified is out of the question. So how can we guarantee users who have already logged in elsewhere in UofM services get logged in here without slowing down the experience?

Ok, now a little more technical.

In order to know whether or not Alice has logged into any UofM systems, our web server needs to  communicate with the central server and check her status. However, our server still has no idea that it's Alice looking at the screen. Our server generally isn't allowed to know Alice has logged into her email (that could enable all sorts of security problems between unrelated websites), so her browser has to briefly visit a URL the central login service to see if her earlier login is still valid. If it is, she is sent back to our website, validated for our server too (and if not, she'll get the login screen again). All told, the web browser will be redirected four to six times in this communication, and it takes a few seconds.

We don't want to do any of that in the web browser window where Alice is already viewing https://www.lib.umn.edu. After all, so much effort went into making it load quickly.  Instead, the Libraries' website will create a hidden window, invisible really, to load the URL communicating with the central login service. All those redirects take place out of sight, while Alice is presumably scrolling the page or scanning for the "My Account" link she came to find.

After a second or two, if the central login service responds that she has a valid session, our web server suddenly gains some knowledge about her: her name, her UofM Internet ID, library barcode number, among other things.  Armed with this data, the invisible window's landing place is on a URL which completes her login to the Libraries' website, updating some info about her in our database, and gathering some statistics for the Student Success Project, among others; all the same things occur now which would have occurred if she manually clicked the "Sign in" link.

Magic! Though less chaotic than pictured...

The last thing the hidden window accomplishes is to communicate what it knows about Alice back up to the screen she was viewing.  When that data has been received, the "Sign in" link disappears, and Alice's username (mine, pictured) fades in place of it, along with the relevant "My account" and "Sign out" links in a dropdown menu. It's now as if she'd been logged in all along, and she didn't need to do a thing. She'll remain logged in until her central credentials expire a couple of hours later.

What do we get out of this?

Since most of our website is accessible to the public, without requiring any authentication, you're probably wondering at this point why any of this matters. Why not just require users who need to be signed in to sign in, and not worry about those who don't need it right now.  Well, we can get much better statistics on E-Journal and Database usage, affinity strings, and generally valuable data from signed in users which is unavailable to us otherwise.

Plus, with the visual feedback of a user's Internet ID appearing on the screen, we hope it will send our site visitors the positive message that "we know who you are, and we can meet your needs here."

Wait, I don't see this on the site yet.

Right now, the auto-login feature is only available on our development website. We want to spend a little longer putting it through its paces since it has a lot of "moving parts". Hopefully we will be able to put it onto the live website early this spring.