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.
Schools using CAS will still need to add users to Coursedog manually, in bulk with a CSV, or via our API.
SAML schools have the additional option of creating users via SSO by following the steps outlined here.
See “Setting Up Users” to learn more.
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.