Federated Access to i2b2 using Shibboleth Authentication

i2b2Shib was created to allow end users at collaborating institutions access to a single i2b2 instance without the need to create new usernames and passwords for the users.

i2b2Shib leverages Shibboleth to allow federated access to an i2b2 webclient.  When the user accesses i2b2Shib, the user is redirected through Shibboleth to their home institution where they are able to login with their local institutional credential.

Upon successful authentication, the user is sent back to the i2b2Shib application. The application then automatically provisions the user into i2b2 and grants access to the demo data project. The application then launches the i2b2 webclient passing in the SubjectUniqueId as the username and the Shibboleth Session ID as the password.

When the session ends, the server automatically de-activates the i2b2 account to prevent access to i2b2 from outside the i2b2Shib webclient.

i2b2Shib Process

Shibboleth Process

  • User goes to i2b2Shib application URL
  • Shibboleth SP redirects to WAYF
  • User Selects Home Institution
  • User redirected to Institution IDP
  • User logs into IDP
  • User redirected back to i2b2Shib

i2b2 SHIB Process

  • If User does not exit
    • User provisioned into i2b2
  • Username Set to UniqueID
  • Password set to SessionID
  • Account activated
  • User autologged into i2b2 Webclient

On End Session

  • Account De-activated

Screenshot showing UserID and Name from Shibboleth Attribute Release

What is Shibboleth?

Shibboleth Infrastructure allows users to authenticate at their local institution, with their local credentials, and securely access resources.  Through a set of attribute release policies, the remote application can be given access to a number of identity attributes which can be used for provisioning a user in an application.


What is InCommon?

InCommon has created a Federation of Higher Education Institutions, Government Agencies, and Corporate Entities with a mission to create a common trust fabric to enable access to protected online resources.  The federation currently has almost 300 participants including over 200 higher education institutions.  Through the Shibboleth infrastructure and the trust network of the InCommon Federation, we can securely authenticate the users from these organizations.

InCommon Federation

Barriers to Implementation

One major barrier when implementing a Shibboleth application is that each IdP has to have an attribute release policy to allow the IdP to send the SubjectUniqueId to the SP. In the case of InCommon, one would have to coordinate with 200+ organizations to have an application work with all the organizations.

There is an external Shibboleth plugin, uApprove from SWITCH, that allows the end user to consent to the release of attributes. 


Authentication is the process whereby a relying party can trust at a defined level of assurance (LOA) that an authentication credential truly belongs to the certified physical person presenting that credential.

Authorization, in turn, is the process whereby a relying party determines whether an authenticated physical person has the necessary personal attributes to conduct specific activities.