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 <rl2226@columbia.edu> Carol Kassel <ckassel@columbia.edu> Andrew Johnston <andrew@columbia.edu> David Millman <dsm@columbia.edu>

Questions?