Integrating SSO with mConnect

Posted on by Skooler

Introduction

Investing correctly into Learning management systems and accompanying tools are essential now more than ever as remote learning becomes more regularly practiced. Skooler’s mConnect application joins the collaborative aspects of Microsoft Teams with the Power of Moodle to boost your educational institution’s online learning strategies.

Within this article we will be exploring how an effective SSO strategy can further enhance the mConnect features that facilitate positive remote learning and teaching experiences. There are many different SSO options that can be used. The two main options we will be comparing further down in this blog article, are SAML vs OpenID Connect.

What is SSO?

Single sign-on, also known as SSO, is a common authentication method used by many organisations and federations, as part of their strategy to manage user identity and authorisation for their online services or platforms.

  • Authentication is the process of verifying a user’s identity, this usually involves entering login credentials, such as a username and password.
  • SSO allows users to enter a single set of login credentials for them to gain access to multiple services or applications.

Ultimately, single sign-on creates a seamless experience for the user, as they can use multiple services without having to create separate identities  and input login credentials for each different service or platform. mConnect uses SSO in the same way, by allowing users access to applications and resources from both Microsoft Teams and Moodle with a single login. Some examples of large organisations that use single sign-on include Google, Apple, and Facebook. As SSO uses one password to open multiple accounts and services, many cybersecurity specialists would recommend using SSO as part of a strategy that also includes MFA (Multifactor Authentication). For a more in-depth explanation of Single Sign On, please click here.

5 Benefits of integrating SSO with mConnect.

There are many benefits to utilising SSO with Skooler’s mConnect application that will help to further improve student’s and teacher’s experience whilst learning and teaching remotely.

  1. One Password: Many people find it stressful to have to manage and remember multiple passwords for several different accounts and platforms. Not having to remember so many passwords alleviates this pressure and as a result improves the users experience with the learning tools and applications being used. 
  2. Time Saving: Having students and teachers frequently enter login credentials every time they change platforms or applications to access different resources, eats into teaching time. By only needing to log in once at the start of each session, users can increase their speed when moving between resources and learning tools.
  3. Lesson Fluidity: Repeatedly having to re-enter credentials during a lesson can prevent learning emersion for students within the lesson. Streamlining access between Moodle and Microsoft Team’s interfaces improves the overall experience for the user, as it facilitates user fluidity when accessing information and resources via the platforms.
  4. Reduces IT Support Workloads: Multiple Passwords are more likely to be forgotten, resulting in password resets. As a singular password is less likely to be forgotten, calls to IT support desks and companies about passwords are reduced.
  5. Reduces Security Risks: Using SSO as part of a strategy with multifactor authentication improves identity protection as it reduces the number of entry points to be hacked. Additionally, effective SSO solutions can allow students and teachers to use their login credentials from a variety of devices and virtual private networks, or VPNs, with a lesser security risk.

Comparison of OpenID vs SAML

OpenID: OpenID Authentication is a Microsoft based service which allows you to use your Azure Active directory credentials to login to your organisation’s Moodle. When your institution approves certain privileges, using this service will create seamless access to the entire Office 365 feature set. This authentication method comes as part of a plugin set for Moodle, which enhances collaboration between Moodle and your Microsoft Office 365 via features such as, a block to instantly access other Microsoft services such as teams or Onedrive, a repository to access your Onedrive/Sharepoint for your uploads into Moodle, a filter which automatically converts hyperlinks with an embedded version, and a local plugin which contains the config to tie them all together.

  1. Requires an Azure AD
  2. Allows seamless access to the Office 365 feature set.
  3. Comes as a plugin set on Moodle; inclusive of a block, authentication method, repository to access your Onedrive/Sharepoint, a filter which automatically converts hyperlinks with an embedded version and a local plugin which ties them all together.

SAML: The SAML2 authentication method allows for users to access their federated resources seamlessly without needing to login each time. A single login allows for free movement between your federated resources and reduces multiple logins. Additionally, this method also allows you to link together multiple identity providers, gaining you multiple points of access to a single source. This is a useful feature if you are a training provider or are a large academy with multiple institutions accessing the same site from different active directories.

The SAML2 authentication method allows a range of different SSO providers to be supported by it, such as Azure, ADFS, Shibboleth and many more. SAML doesn’t limit which SSO providers can use it! If you still have the requirement of using the Office 365 integration with Moodle, but want to retain the benefits listed above, the Office 365 set doesn’t require you to authenticate with OpenID connect. You can still enjoy all the benefits of the Office 365 plugin set as listed in the above section, providing your accounts are synced correctly in Moodle after authentication.

  1. Allows access to federated resources outside of Moodle seamlessly.
  2. Can link multiple Identity providers.
  3. Can be used with Azure, ADFS and Shibboleth and many more SSO providers.
  4. You can still use the Office 365 integration in Moodle without needing to authenticate with OpenID Connect.

OpenID and SAML are only two examples of the many authentication methods that exist; there are many other SSO options available if required!

Why it was important for Overt’s customers to use SAML?

The majority of Overt Software’s community are members of the UK Access Management Federation, which is a federation of service and identity providers from across the UK. These providers work together to provide SSO to hundreds of services within the federation and utilises SAML in order facilitate easy access between its members. Many of our customers use SAML identity providers, such as Shibboleth, Azure, and ADFS, to authenticate into their online resources. These resources include services such as e-books, online booking tools, learning management systems and many more.

As a result, it is important for our customers to be able to integrate their Shibboleth / SAML identity providers with Skooler’s mConnect Application, so that they can retain SSO between their already existing UK Federation resources and mConnect. Using SAML allows our customer’s users to easily access mConnect when coming from their existing federation resources without needing to re-authenticate. Another benefit of using a one login system such as a SAML identity provider, is that users don’t have to remember multiple different credentials to multiple services. By using a Shibboleth / SAML Identity Provider, the user only has to use one username and password to get access to all of their resources.

A lot of our customers have also opted for Seamless SSO to be setup, which provides automatic logins for users connected to their institution’s domain. For institutions with this setup, users on-site never have to type in their login details after they have logged into their computers, providing seamless access into all of their resources that are connected via SAML, such as mConnect. This creates a seamless and worry-free experience for students and teachers alike! Freeing up time to focus on learning and teaching.

Whilst OpenID certainly has its benefits, it was preferential for our customers to utilise SAML to provide the Single Sign On experience. If they had chosen to use OpenID rather than SAML, then users would have had to login to both Shibboleth, in order to access their UK Federation resources, and Azure AD, to access mConnect and their OpenID resources.

Implementing Shibboleth/ SAML

While integrating Shibboleth with mConnect for our customers, Overt came across a small obstacle involving Shibboleth’s strict set of content security policies.

What is a content security policy (CSP)?

A CSP is a set of rules within the browser headers, that adds an extra layer of security to a website to protect and mitigate against various types of attacks. The types of attacks that it protects against includes cross site scripting, packet sniffing, and other code injection attacks. We use a lot of content security policies to protect our websites and Shibboleth against these attacks. This is an excellent feature that web browsers support that allow users to be safe when logging in via Shibboleth.

Complication:  The issue Overt faced when implementing Shibboleth with mConnect was a specific rule within Shibboleth’s strict set of CSPs, that restricts Shibboleth being shown in iFrames across domains that aren’t trusted. (An iFrame is a window that displays a resource documents inside an application or webpage.) This restriction is a good thing, as it means that Shibboleth can only be accessed directly via a trusted domain, and as a result, prevents untrusted third-party websites from loading Shibboleth and performing cross site scripting, such as key logging, against users attempting to login. The problem was that although Microsoft Teams is a widely trusted and secure website, Shibboleth could not load as an iFrame due to this policy.

As the content security policy is a ‘catch all’ type of policy, it doesn’t take into consideration websites that are indeed secure and have procedures in place to prevent nefarious scripts running on them. This is what was occurring for Microsoft Teams’ website, which has a magnitude of security measures in place to ensure that their website and users are protected, however, it could still not load shibboleth within an iFrame.

Resolution: Solving this problem is an extremely simple fix, as there is an option within the content security policy to specifically allow trusted websites to load Shibboleth in an iFrame. The resolution for this issue involves adding, https://teams.microsoft.com, to the trusted domains within the CSP. This fix allows Microsoft Teams to show Shibboleth in an iFrame on its application. You can see this fix being deployed in the video below. We’ve also attached below the two configuration lines (and optional comment lines) that you will need to add to the idp.properties file.

# X-Frame-Options value, set to DENY or SAMEORIGIN to block framing
idp.frameoptions = allow-from teams.microsoft.com
# Content-Security-Policy value, set to match X-Frame-Options default
idp.csp = frame-ancestors teams.microsoft.com