What is Single Sign-On?

MENU
The online learning landscape has seen significant changes in the last few years, and one of the most major has been a shift in the role of the Learning Management System (LMS). LMS platforms used to be something of a ‘jack of all trades’ — attempting to provide every feature that an institution needed, all under one virtual roof.

But, as the web evolved, new platforms emerged which handled specific elements of online learning in innovative and specialized ways. Because of this the need for Single-Sign-On (SSO) was born. 
 
Authentication — the process of securely allowing a student or faculty member to log in to a web application — and Single Sign-On (SSO) — which allows users to access multiple online services through a common identity (such as their university username and password).

Below you'll find a list of the types of SSO used by MediaCore to seamlessly connect users to the various education tools being used by their university or organization: 
 
Active Directory is the central directory service which underpins Windows–based networks, used by the majority of institutions. All users on an institution’s network are contained in its Active Directory — along with group memberships, which can indicate whether a user is a student or a member of staff, and often which classes they belong to.

Using Active Directory for authentication to external web applications is effective, and as AD is used almost universally by universities, it offers a great, common means of implementing Single Sign-On. But, it’s also the authentication equivalent of tapping straight into the jugular, and usually requires the installation of a piece of ‘connector’ software on the AD server.

For this reason, a number of additional protocols and Identity Providers (IdPs) have surfaced. In many cases these act as secure ‘middle men’ between the central user directory and multiple external applications, without requiring a university to directly expose its AD.
 
Shibboleth is an IdP that’s specific to the education world and is used as the authentication mechanism in many of our university deployments here at MediaCore. Based around the SAML protocol (more on this a little later), Shibboleth was created by a consortium of academics and institutions to provide a common authentication framework for universities who increasingly wanted to make use of innovative web applications.
 
The InCommon Federation, incorporating a large number of leading institutions and tool providers who have implemented Shibboleth authentication, provides a common, secure means of sharing user data between a university's internal directory systems and external applications.
 
Learning Tools Interoperability (LTI)  is lightweight, seamless and education–specific. It’s also been specifically designed to make modern LMS platforms more extensible using external resources and tools. LTI is fairly unique; instead of acting as an IdP ‘middle man’ to a directory service such as AD, it passes through information directly from the LMS. When a user launches an LTI–enabled tool, the LMS uses LTI to pass along some key information — such as the user’s name and email address, the course that they’re launching the tool from, and their role within that course. The external tool then uses this information to authenticate the user, and assign permissions based on their role within the LMS course they’ve launched the tool from.

LTI is supported by all of the major LMS platforms (such as Moodle, Canvas, Blackboard and Sakai), and it's used extensively in MediaCore's own plugins for these platforms. When a user launches MediaCore from within Canvas, for instance, MediaCore uses LTI to deliver them into a media collection that specifically relates to that Canvas course — and also uses their role (e.g. instructor or student) to give them appropriate permissions within that course’s media collection. The recently released LTI 2.0 specification brings some great new functionality.
 
Security Assertion Markup Language (SAML) — is a common authentication protocol, allowing for the secure exchange of authentication data between different online platforms. SAML underpins many other services (including Shibboleth, which is largely based around SAML authentication requests), and can also be used by developers to integrate third–party tools with their own platforms and systems.

OAuth2, in a similar way to SAML, is another common authentication framework. OAuth2 is used extensively in the consumer technology world — when you click ‘log in with Facebook’, or ‘log in with Google’ within an application, it’s Facebook and Google’s OAuth2 implementations that makes this happen. OAuth2 also features in MediaCore’s APIs, allowing universities to integrate their own custom applications with our platform. MediaCore can act as either an OAuth2 client or an OAuth2 server, offering flexibility when institutions want to integrate the application into their own authentication workflows. OAuth2 also drives the Single Sign-on capabilities of MediaCore’s mobile video capture apps.
 
PingIdentity Recently, a number of companies and products have emerged which offer enterprise–grade authentication platforms, making it easy for organizations to work with multiple service providers — and crucially, also allowing application providers (such as MediaCore) to offer robust, enterprise–grade integration with complex systems such as Active Directory. Our partners at PingIdentity are leading the way in this universe — and their PingOne platform and ‘AD Connect’ software power MediaCore’s Active Directory integration, offering our institutions a secure, robust and seamless experience.
 
Google Apps for Education is increasingly being adopted by institutions across the world and is extensively used by MediaCore’s own global team for communication and collaboration. Thanks to OAuth2, Google Apps can also be used as a Single Sign On identity — universities can allow their users to log in to MediaCore using their GApps EDU credentials — or with a single click if they’re already signed into Google, or are using a Chromebook.

Groups and Organizational Units can also be synced across, allowing permissions to be set using an existing group structure.
 
Central Authentication Service (CAS) - is an enterprise level single-sign-on solution, that's purpose is to permit a user to access multiple applications while only needing to provide a username and password once. CAS provides a better user experience for universities or enterprises who have multiple sites to login to. CAS is not one specific implementation of a protocol, but rather a collection of many possible Authentication Mechanisms and SSO protocols. It is up to the specific institution to configure their CAS with the features that they want.
LAST UPDATED:

Jun. 01, 2015