Single Sign-On
Doug Randall, III
Presentation materials available at HYPERLINK “http://csdirect.iii.com/ppt/iug2007-j12-singlesignon.zip” http://csdirect.iii.com/ppt/iug2007-j12-singlesignon.zip [CSDirect username and password required]
Single Sign-On allows OPAC and WAM to participate in institutional single sign-on, users can sign in with institutional id just once. Uses institution’s central authentication [which OHSU doesn’t have]
If user has already signed onto participating system on campus, user never sees login screen for library access.
LDAP – same credentials for all systems but have to log into each one. Single sign-on requires only one login.
Makes multiple systems behave like one. Other systems know you’re signed on.
How does it work?
Starts with introducing a single sign-on service for institution, usually with a few key participating systems (web mail and portal usually first). If there’s no single sign-on initiative underway, there’s little the library can do.
Lots of different single sign-on systems, including homegrown ones.
Innovative uses Apache web server as common ground for integration. Uses a separate Apache server trusted by Millennium.
IT usually provides central server with access to usernames and passwords + software for distributed sign-on server. They also usually provide instructions and software for other systems to hook in.
Single sign-on not strongly driven by standards. There are several popular products plus some others.
III sets up Apache server and works with IT to implement.
How do we do it?
Be sure single sign-on initiative is in place on campus, and it’s the appropriate time for the library to join
Load and maintain common ID field in patron records
Talk to III sales consultant
Apache
Very popular and extensible
Each SSO method has a way to work with Apache
They’ve worked with:
Sun Access Manager
IBM Tivoli
CAS (Central Authentication Services)
Shibboleth
Pubcookie (U of Washington)
Arizona State University system: ASU local, ASU-Rite (PERL-based)
Michigan State University local system – Sentinal (CAS-derived)
These schools have used single sign-on for awhile:
Arizona State University
University of Washington
University of Scranton
Yale Law School
Getting going
Bringing in new server
To user, looks just like web OPAC but with different authentication
2 server names; one uses SSO; other one has native authentication if needed
Usually SSO gets name of existing catalog server. Staff users pointed to renamed server.
No authentication required for public pages. When accessing private pages: With LDAP, Millennium prompts for authentication, then looks up elsewhere.
Can still serve non-SSO users by accessing other server. They have to connect to other name [so we’d have to offer 2 links and differentiate between them].
Identifier doesn’t have to be a particular tag (e.g. unique ID) but it does have to be indexed.
Can have scope creep, e.g. updating patron data in real time, other kinds of integration with IT.
SSO vs. LDAP
Many institutions start with LDAP as stepping stone. These are separate products, not exchangeable.
For community borrowers, need to think about how to present alternative link to users.
Shibboleth
Primary focus – a “federated” authentication method
As an idealized implementation of a local SSO
Single sign-on across institutions. Visitors can use credentials from home.
Institutions have own Web Initial Sign-on
With Shibboleth, local university should never need to know anything about visitor as an individual in order to give visitor rights.
User clicks visitor link which goes to local university’s Shibboleth system
User chooses her university when asked
User transferred transparently to home system to authenticate
After sign-on, referred back to local with token that indicates she’s a student
Local system then grants rights appropriate for visiting student
Some institutions use Shibboleth as local SSO system. Framework allows that, but it shouldn’t be confused with interinstitutional authentication for which Shibboleth standard was designed.
Most of what web OPAC and WAM do are targeted to individual rather than group identity as communicated by Shibboleth.
Group identity more relevant for WAM -> group access rights.
Q & A
Only username (or common identifier) needs to be in patron record—NOT password. Millennium never even handles the password. Authentication done through campus single sign-on service.
Patron record expiration, other patron record stuff/functionality doesn’t change at all. SSO only deals with how you prove your association with your patron record.
Multiple patron records with same identifier: SSO considers this an error.
Just expanding SSO to include INNReach. Campuses that use Shibboleth locally would be able to authenticate to INNReach. But no Shibboleth authentication for INNReach now (i.e. INNReach system would refer back Shibboleth-style).
With SSO for INNReach, sign-on would be valid for INNReach too; wouldn’t be prompted again.
Self-check would work as before, using native authentication. LDAP would also continue to work as before.
Pverify screen – needs to be adjusted for LDAP (split screen—one side for campus credentials and other side for barcode). For SSO, don’t use pverify.
Single Sign-On – p. PAGE 3