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

Get Attributes CSO workflow Unprotected content Protected content IdP 1 Login Page IdP 2 Login Page WAYF Logged In? Login Sucess? No Login Success? No Yes User self-identifies as “member of IdP 2” User self-identifies as “member of IdP 1”

User interface example  Engineering Pathway Engineering Pathway  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 address not here; obtained as attributes from IdP. Password not needed at all.

Next steps  Consult the CSO Roadmap for NSDL SitesCSO Roadmap for NSDL Sites  Non-NSDL BEN partners: contact Isovera to request setup  Contact us!  Rob Lane  Carol Kassel  Andrew Johnston  David Millman

Questions?