Community Sign-On and BEN
Table of Contents
What is community sign-on? Benefits How it works (Shibboleth) Shibboleth components CSO workflow User interface examples Next steps
What is community sign on?
Single sign-on (SSO): a specialized form of software authentication that enables a user to authenticate once and gain access to the resources of multiple software systems (e.g., Web sites)
Community sign-on (CSO): an application of SSO to a specific community, such as NSDL
Benefits: Users
Single username and password: user has to sign in only once to gain access to the entire community
Single registration: user doesn’t need multiple registrations, multiple usernames, etc. – just one
Security: user’s personal information is kept in only one place. User access multiple Web sites but personal info not transmitted
Benefits: content providers
More members: implementing CSO effectively pre-approves all exsiting community users for your site (you can allow or restrict access as you choose)
Reduced friction: users less likely to abandon a site if additional registration not required
Scalability: set up CSO once and use same technology for additional partner sites
Simplified account administration: user updates his/her info at one site so your site need not maintain redundant (or out-of-date) information
Access control: permit or deny access to different parts of your site based on a member’s attributes
Remote access: users can access your site from any computer because access controlled by login, not by physical location of the user’s computer
Integration with other sites: integrate services, such as tools from other sites, within your site and allow user seamless access
Personalization: customize your site based on members’ attributes
How it works
CSO for NSDL uses Shibboleth, an Internet2 Middleware Initiative project that has created an architecture and open-source implementation for federated identity-based authentication and authorization infrastructure
In English: Shibboleth allows users from different institutions or groups to obtain access to protected content anywhere on the Web. Users log in locally and their privacy is maintained
Federated identity allows for information about users in one security domain to be provided to other organizations in a common federation (e.g., NSDL)
Origin of “Shibboleth” (Judges 12)
Shibboleth components
Federation: a group of organizations who join together to use Shibboleth software to share access to resources in a common way
Service provider (SP): Web site with protected content requiring a login
Identity provider (IdP): authenticates users and provides attributes to a given SP
“Where are you from?” page (WAYF): page requiring users to identify their IdP so that they can log in appropriately
Attributes: info about the user that gets released from the IdP to the SP, according to IdP policy
GetAttributes
CSO workflow
Unprotected content
Protected content
IdP 1 Login Page
IdP 2 Login Page
WAYFLogged
In?
Login Sucess?
No
No
Login Success
?
No
Yes
Yes
Yes
User self-identifies as “member of IdP 2”
User self-identifies as “member of IdP 1”
User interface example
1. Engineering Pathway2. BEN
User selects protected content
User interface example (SP)
User clicks this link
User interface example (WAYF)
User clicks this link
User interface example (IdP)
User logs in
User interface example: request for additional info
Note that name and email address not here; obtained as attributes from IdP. Password not needed at all.
Next steps
Consult the CSO Roadmap for NSDL Sites
Non-NSDL BEN partners: contact Isovera to request setup
Contact us! Rob Lane <[email protected]> Carol Kassel <[email protected]> Andrew Johnston <[email protected]> David Millman <[email protected]>
Questions?