Coursedog

Submit a Ticket My Tickets
Welcome
Login  Sign up

Configuring Single Sign-On (SSO)

Table of Contents

Overview
Requirements

Important Notes
Before You Begin
Assets
SAML Configuration
CAS Configuration
User Experience (Testing your configuration)
Related Articles

Overview

  • Coursedog provides a seamless login experience for users through Single Sign-On (SSO). In short, SSO allows users that are authenticated via their Student Information System (SIS) – through a centralized authentication service – to rely on that already open session on their browser to get direct access to Coursedog with the click of a button. 

  • This eliminates the need for users to create and keep track of a new username and password. 

  • Coursedog integrates with your identity provider through SAML and CAS protocols. Identity providers include Okta, AWS, Ping Identity, Azure, Shibboleth, etc.

  • This page will guide you through the configuration as well as the end user experience.

Requirements

Coursedog offers identity management administrators the tools to set up SSO in a few easy steps, provided the following conditions are met: 

  • Your institution uses one of the following unique identifiers for employees and students:

    • Email address – We recommend this be used as the unique identifier for a user, with a 1:1 relationship of user to email (i.e. Users don't have multiple email addresses). 

    • Unique ID – A unique identifier such as an employee or student id (e.g. EMPLID, PIDM). 

  • Users outside of your authentication domain can be set to authenticate via username and password on the individual account level.

Important Notes

  • Coursedog does not support Identity Provider (IDP)-initiated authentication. This means that the authentication cannot start directly from your identity provider, and the user must access Coursedog to authenticate (i.e. Service Provider-initiated authentication).

  • Our out-of-the-box SSO implementation does not create user accounts; it will only authenticate against an existing record.

  • Coursedog SSO only supports authentication, not authorization, to validate a user. 

    • We cannot restrict roles based on SSO. 

    • Role assignments for users must be handled manually, through batch uploads, or through our APIs. 

    • SAML schools have the additional option of assigning roles via SSO by following the steps outlined here.

Before You Begin

  • Coursedog provides you with a non-production(staging) instance where you should test all SSO-related configuration changes before configuring production.

  • Don't lock yourself out! Please create a secondary Coursedog Super Admin account for yourself following the below recommendation. You might need this secondary account in case your SSO configuration is not correct.

    • Set “Roles” to “Super Admin”.

    • Ensure “Products” lists “Admin” and at least one other product.

    • Set the Login Method to “Password”. This means that the password you've configured for the user in Coursedog will be used at login time rather than the SSO process.

Assets

Step 1

Configure your system to accept Coursedog and allow redirects from both staging.coursedog.com and app.coursedog.com. Your institution’s IT team should be able to assist with this. 


SAML Metadata

Staging

Go here to see how you should configure your system to accept Coursedog Staging. 


Production

Go here to see how you should configure your system to accept Coursedog Production. 


CAS Coursedog Referrers

Your IT team should reference your internal documentation for how to configure your system to accept Coursedog Staging and Production.


Step 2

  • Log into the Coursedog admin console with the credentials provided to you by your Customer Success (CS) representative.

  • Navigate to the following path: Admin > Settings > Auth Settings (at the bottom of the screen).

Step 3

  • Select "SAML" or "CAS" from the drop down.

  • Once you make this selection, it will disable username and password authentication for existing users whose Login Method is set to “Default” in their profile.  You may want to notify teammates when you are in the configuration and testing process. We recommend setting it back to “password” until you have SSO configured for the environment.

  • You can review the established Login Method for users by navigating to any product’s Settings > Users > (Click User Name). 


Auth Settings


Viewing User Login Method

Step 4

What you do next depends on whether you are configuring for SAML or Cas; proceed to the directions outlined in the relevant sections below.

SAML Configuration

For a SAML configuration, navigate to Admin > Settings > Auth Settings and then follow the directions outlined under the below screenshot.

Coursedog Settings

Authentication Method | SAML Certificate | SAML Login URL | SAML Logout URL
Redirect | SAML Redirect URL
 | SAML Attribute Options


Authentication Method

Saml


SAML Certificate

  • Paste in the value for your ds:X509Certificate. This is typically found in your certificate file.

  • If OpenID and through AzureAD, please provide your tenant ID to your Customer Success representative. The Coursedog client ID is: b5587ee3-25e3-41b7-84a1-ee35fae192c8

  • Coursedog SAML implementation requires the usage of SHA-256 algorithm for certificate signature.   


Coursedog Metadata Example

See ds:X509Certificate below.

SAML Login URL

Input the URL that will take the user to your SAML Identity Provider's (IDP) login page, e.g. https://elbert.edu/sso/saml


SAML Logout URL

  • Only set this if you are using Single Logout (SLO).

  • Most schools leave this blank.


Redirect

  • Set to TRUE if not using SLO.

  • If TRUE, you must enter a value in the SAML Redirect URL.


SAML Redirect URL

  • This is where you redirect the user upon logout.

  • Typically this will be the same as the redirect page above (e.g. https://elbert.edu/sso/saml).

  • You MUST input something here if “Redirect” is set to “True”. 


SAML Attribute Options

  • This is how Coursedog associates users between the two systems. It is used to map the fields returned from the SAML response to our internal fields.

  • This is required for SSO to function. 


Attribute (SAML Field)

  • To obtain the correct value, look in a sample SAML response for an email address value. Typically it is found in the NameID.

  • Even if/when the user identity doesn't rely on NameID to match the authenticated user identity from the Identity Provider, this is a mandatory attribute to the SAML Assertion Response and authentication will not be possible if that attribute is missing. If that's the case on your Identity Provider Service, please refer to its documentation on how to map and share NameID properly.


AZURE/OFFICE 365 or ADFS SSO IMPLEMENTATIONS

  • For Azure/Office365 or ADFS SSO implementations, most partners utilize email to authenticate users.

  • If this is true for your institution, please reference this tutorial on Azure SSO claim customizations.

  • Please ensure that the ADFS server is using TLS 1.2.


SHIBBOLETH IMPLEMENTATIONS

For Shibboleth you will want to ensure the NameID is set to be “transient” as opposed to “persistent”. We also recommend using the URN for the Attribute field as well (see below). Typically we see most institutions use “mail”. We've noticed examples where the sample response contained NameID but produced an "unable to verify user identity" error. This can sometimes be resolved by changing the Attribute value in Coursedog to be NameID.


COURSEDOG AND URN

Coursedog evaluates the URN value as well, as shown below.

User Property (Coursedog Field)

  • Map the unique identifier value passed from your institution to a Coursedog field. 

  • The two options are a unique email address or InstitutionID.

  • If you select Institution ID here and plan to create users via SSO as well, check out the “Email or Institution ID Attribute” section of our Creating Users and Assigning Roles & Departments via SSO article to ensure Coursedog knows how to map InstitutionId to email. 


Identity Provider Settings

The below SAML Conditions will need to be updated on the Identity Provider side. 

  • SAML protocol requires the Identity Provider (Okta, ADFS, or any other) to point to the target Service Provider (Coursedog) as one of the valid entries inside the Conditions.AudienceRestrictions.Audience node in the SAML assertion. 

  • The correct value can be retrieved from the entityID in the Coursedog metadata.xml file. 

  • The images below show where to retrieve the data from, and how it must appear on your SAML Assertion Response.


This is a partial image on a valid SAML Assertion Response.

CAS Configuration

Authentication Method | CAS Server URL | Redirect (True/False)
CAS Redirect URL | CAS Protocol
 | CAS Attribute Options

For a CAS configuration, navigate to Admin > Settings > Auth Settings and then follow the directions outlined under the below screenshot.

Authentication Method

Cas


CAS Server URL

URL for your CAS server (e.g. https://elbert.edu/cas).

Redirect (True/False)

  • Set to TRUE if not using SLO.

  • If TRUE, you must enter a value in the CAS Redirect URL.


CAS Redirect URL

Where to send the user upon logout.


CAS Protocol

Coursedog supports versions 2 and 3 (default is 3.0).


CAS Attribute Options

  • This is how Coursedog associates users between the two systems. It is used to map the fields returned from the CAS response to our internal fields.

  • This is required for SSO to function. 


Attribute (School CAS Field)

To obtain the correct value, look in a sample SACASML response for an email address value. Typically it is found in the email.


User Property (Coursedog Field)

Typically defaults to email, but it can also be InstitutionID for V2. See example below:


User Experience (Testing your configuration)

Login | Additional Note | For Staging | For Production | Logout

Once you are confident with your configuration, it is time to begin testing. Make sure you have access to a user and your logs. 

Login

With SSO enabled, the user types their email address into the login page and – rather than being asked to provide a password – they are redirected to their institution’s login page.

We use the entered email address to determine which school they belong to and therefore where to redirect them. Once redirected, the user then logs in as usual on their standard institution login page.


Additional Note

If you don't want users to be asked to enter their email address BEFORE they are redirected to your institution's log-in page, provide them with a direct link to access Coursedog SSO.


For Staging

https://staging.coursedog.com/#/login/<myschool


For Production

https://app.coursedog.com/#/login/<myschool>



When users access the URL, they are redirected to the institution portal/login page rather than starting in Coursedog.

Logout

When users log out of Coursedog, we can invoke a SAML or CAS logout, or redirect them to a page of their choice. 

Related Articles

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.