Authentication Integration Worksheet
For any questions or assistance, please contact:
Authentication@CampusLabs.com
(716) 270-0000
Authentication Method
Please note that ALL campus community members will need to have access to your site. This includes students, faculty,
and staff. Make sure that the information you provide will allow all of these users to access the site.
Campus Labs only supports ONE campus authentication method at a time.
Important Note
Campus Labs requires that the selected authentication method must return a
unique, never-changing, and never-recycled Person Identifier for each user upon
a successful sign in. Please refer to our documentation on Choosing a Person
Identifier for guidance.
Complete ONLY ONE of the following sections
Shibboleth / SAML .................................................................................................................................................................. 2
Generic Pass-Through Authentication (GPT) .......................................................................................................................... 6
Central Authentication Service (CAS).................................................................................................................................... 12
Lightweight Directory Access Protocol (LDAP) ..................................................................................................................... 13
Shibboleth / SAML
CampusLabs supports native Shibboleth SP and SAML authentication and is a member of the InCommon Federation
(http://www.incommon.org).
Steps to implement a Shibboleth / SAML authentication:
1. Contact our Authentication Support Specialist (authentication@campuslabs.com) and indicate that you’d like to
setup Shibboleth authentication.
2. Answer the questions below so we can determine which configuration we will use.
3. We will work with you to get a site configured based on your answers to the questions.
4. Implement our metadata on your end and authorize the site we’ve created to connect to your authenticator.
5. Testing and troubleshooting
The standard attributes that we support are documented on the InCommon Federation’s website
(http://www.incommon.org/attributesummary.html). Please let us know if you are using something different.
Are you a member of the InCommon Federation (http://www.incommon.org/participants/)?
Yes –
What is your entity ID?
No –
Are you running a local Shibboleth Identity Provider (IdP)?
Yes –
Please provide the URL to your metadata or send your
metadata to the authentication specialist.
The URL to our metadata is: https://federation.campuslabs.com/Shibboleth.sso/Metadata
No –
Please provide information about your setup.
Campus Labs®
Authentication Integration Worksheet
8 February 2016
2
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
Training, Support, and Test Account Information
While a unique, permanent vendor account is not required, it can be helpful for assisting us with troubleshooting and
authentication-related support issues. If we are not issued a test account, we will be required to contact your campus IT
department for assistance.
User ID
Password
Single Log Out & Shibboleth Authentication Considerations
What is Single Log Out?
Single Log Out (SLO) is the process of reversing a Single Sign On (SSO) authentication session. SSO is often preferred by
campuses because it can reduce the number of times a user needs to provide credentials (username/password) to
campus web applications throughout the day.
A simple analogy:
Single Sign On (SSO) is like using your key fob to unlock all of your car doors at one time in order to keep them open at a
tailgate party so that you can easily get in to grab additional items throughout the day. Single Log Out (SLO) is the action
of locking your car with your key fob before heading to the game.
SSO is designed for convenience. SLO is designed for security. Sometimes these conflict. What if a neighbor accesses
your car while you are not looking? What if you need to get back into your car several times after you locked the doors?
Ultimate security would have you unlock and re-lock your car each time you access it for items.
Ultimate convenience would not enable the ability to lock the car.
What is Shibboleth?
Shibboleth is a popular authentication protocol that many campuses (especially InCommon federation participants) use
to apply security to web applications that are used by members of the campus community. Shibboleth is popular
because it is highly secure and easy to configure for both the campus and third party platforms, like Campus Labs.
However, there is one tradeoff for the security and simplicity of Shibboleth that can cause user experience issues in
specific use circumstances that are important to understand.
Limitations of Shibboleth Single Log Out
The Shibboleth protocol does not support Single Log Out by design.
The best and only way to log out of an authenticated session is to completely close the web browser when finished using
a web application, like Campus Labs, secured by Shibboleth.
Campus Labs®
Authentication Integration Worksheet
8 February 2016
3
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
Practical Implications of SLO Limitation
In scenarios where users are using their personal device and do not share their device with others this SLO limitation is
not particularly invasive since the user will likely perceive that the Campus Labs application only requires seemingly
periodic authentication, similar to Facebook or other web services that want to make it easy for users to quickly access
content.
However, in scenarios where multiple users will use the same device and browser in rapid succession (taking turns filling
out a survey, using the Location tracking kiosk screen, etc...), and where it is unlikely that the browser will be closed
after each log out attempt, users can unknowingly continue use of the application as a previous user who did not
successfully log out.
Remedies for the Shibboleth SLO Limitation
1. Users not sharing a device
If it is rare that multiple users will use a single device to participate in surveys or location tracking, then the simplest
remedy is to remind users to close the browser upon log out. The Campus Labs platform offers a configuration option
called a "Shibboleth log out URL" which allows a campus to define a URL that the system will direct the user to upon
clicking the "Log out" button in the application. The content of the webpage is at the discretion of the campus but
should contain a reminder to close the browser to complete the log out process.
* It is important to note that the presence of a Shibboleth log out URL does not guarantee a successful log out for each
user, it is simply a mechanism to remind users to close their browser.
2. Users sharing a device
If it is common for users to share a device, or the campus would like to use the location tracking features of the
application then a permanent change in authentication method to one that supports SLO is needed. The Campus Labs
platform supports the Central Authentication Services (CAS), Lightweight Directory Access Protocol (LDAP), and a
proprietary authentication method based on Security Assertion Markup Language (SAML) that we call Generic Pass
Through.
If you would like to employ either of these strategies please contact our support team by creating a help ticket.
Technical Summary of Issue
Adapted from The University of Texas at Austin
https://www.utexas.edu/its/help/shibboleth/2299
Campuses using a Shibboleth Identity Provider based on SAML 2.0 do not support single logout (SLO). SLO is the process
of reversing the single sign on (SSO) process by destroying all sessions that are created while using SSO. For the context
of this document, that would mean destroying the identity provider session and service provider sessions. Before
explaining this in more detail, there are a couple of important terms to know.
This document will refer to a service provider (SP) which is the host of the service or application, in this case the Campus
Labs platform that users are attempting to access and the identity provider (IdP) which hosts user authentication and
user attributes at the campus to be consumed by the SP.
Campus Labs®
Authentication Integration Worksheet
8 February 2016
4
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
For example, the university controls idp.its.campus.edu which is the IdP used to allow users to authenticate using
campus username/password credentials and gain access to an SP, like Campus Labs.
Understanding Shibboleth Single Sign-On Sessions
There are usually up to 3 sessions associated with Shibboleth IdP and SP integration: the IdP session, the SP session, and
the optional web application session for the service the SP is providing. The following is the most common
authentication flow for the creation of these sessions at a high level.
Whenever a user attempts to access an SP-protected application for the first time, they will not have an SP session or an
application session and are redirected to the IdP to see if they have a valid IdP session. When they make it to the IdP,
they also do not have an IdP session at this time and are prompted to provide credentials to authenticate.
Upon successful authentication, an IdP session is created and an associated IdP session cookie is placed in the user’s
browser. The user is redirected back to the SP where the IdP session is verified and an SP session is created and an SP
session cookie is placed in the user’s browser. Finally, the user is passed to the application itself where a web application
session may also be created.
Upon returning to the application, the optional web application session is checked and then the SP session is checked. If
either of these sessions are still valid, the user will not be redirected back to the IdP to re-authenticate. If neither of
these sessions are valid, the user will be sent back to the IdP where the IdP session is checked using the IdP session
cookie that was created upon initial authentication. If the user makes it back to the IdP with the IdP session cookie and
the IdP session is still valid, the user will not get prompted to provide credentials. The IdP session will be refreshed and
the user will be returned back to the SP and web application where new SP and web application sessions will be created.
If the user makes it back to the IdP without the IdP session cookie, or with an IdP session cookie but an invalid IdP
session, the user will be asked to authenticate.
The Complications of Single Logout and User Expectations
When a user clicks on a logout button in an SP’s application, they have a set of expectations. These expectations
combined with technical roadblocks currently keep SLO from being implemented.
When the logout button is clicked, the user’s web application session and SP session are ended, but the user is not
logged out of the IdP. Therefore, if the user were to revisit the web application, they would be automatically reauthenticated because they still have a valid IdP session cookie.
In theory one might, instead of just destroying the web application session and SP session, have the SP tell the IdP to
destroy its session as well. Unfortunately, the IdP does not know which SPs the user has sessions with, cannot inform
those SPs to destroy the user’s sessions, and cannot enforce that those SPs destroy the user’s session on the SP and web
application side. This creates a false sense of security for the user because they may believe that they have been logged
out of all systems. It also means that the user could go from SP to SP and get varying experiences after logging out of
one SP.
Campus Labs®
Authentication Integration Worksheet
8 February 2016
5
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
Generic Pass-Through Authentication (GPT)
Campus Labs supports authentication of users via secure HTTPS requests. Generic Pass-Through Authentication is a
custom authentication method based on security best practices that can be utilized in situations where the other
methods are insufficient or unavailable on campus. In this method, the campus is responsible for actually authenticating
the user, and upon successful authentication, redirecting the user to Campus Labs’ authentication server with a link that
contains their username and other desired attributes. One of the parameters on the URL is a hash of the data sent,
which is generated using a shared secret key known only to Campus Labs and the campus. Because the redirection is
done over SSL, the data in the link itself is protected, and upon receipt Campus Labs’ authentication server verifies the
contents of the hash using the shared secret – this verifies the data provided has not been tampered with and that the
link was generated by someone possessing the secret key.
Steps to implement a Generic Pass-Through (GPT) authentication:
1. Contact our Campus Labs Authentication Support Specialist and indicate that you’d like to setup GPT
authentication.
2. Campus Labs will create and configure a site and a shared key for you.
3. Create code that will generate the needed link to pass to Campus Labs.
4. Testing and troubleshooting
Required parameters:
realm
NOTE: realm should NOT be included in the pre-hash string
The URL of the product that you are connecting to*:
Data Manager (required)
Un-encoded URL:
https://schoolname.campuslabs.com/management/auth/
Baseline (formerly StudentVoice)
Un-encoded URL:
https://schoolname.campuslabs.com/app/views/home/default.aspx
Beacon
Un-encoded URL:
https://schoolname.campuslabs.com/beacon/
Campus Labs®
Authentication Integration Worksheet
8 February 2016
6
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
Course Evaluation - Students
Un-encoded URL:
https://schoolname.campuslabs.com/courseeval/
Course Evaluation - Faculty
Un-encoded URL:
https://schoolname.campuslabs.com/faculty/
Course Evaluation – Administrative Staff
Un-encoded URL:
https://schoolname.campuslabs.com/ce/
CollegiateLink**
Un-encoded URL:
https://schoolname.collegiatelink.net/externalauthentication/federationresult/
Compliance Assist
Un-encoded URL:
https://schoolname.compliance-assist.com/
* The realm parameter you use in your GPT code MUST be URL-encoded
**If you are using the Vanity URL feature with CollegiateLink, your realm URL will include
the encoded version of your Vanity URL instead of schoolname.collegiatelink.net.
userID
The unique identifier for the user who is authenticating.
time
The current time represented in milliseconds (UTC).
This should be a 13 digit timestamp.
Time must be synchronized with an international time server. (E.g.,
http://tycho.usno.navy.mil/cgi-bin/timer.pl)
NOTE: We can support time in seconds, but you will have to alert us so that we can make
an adjustment on our end.
Campus Labs®
Authentication Integration Worksheet
8 February 2016
7
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
random
A random series of alphanumeric characters
returnUrl
The URL user is redirected to upon login*
*Only for CollegiateLink product
hash
A 32-character MD5 hex representation of specific querystring values + the symmetric key.
In an example where no additional optional parameters are sent, the hash would be built
from the following string:
hash = “userID + time + random + returnUrl + symmetric key”
In an example where first name and last name are also being sent, the hash would be built
as such:
hash = “userID + time + random + returnUrl + firstname + lastname + symmetric key”
The order of the fields in the hash must match the order of the corresponding querystring
values. See more detailed examples below.
To verify your md5 hashing algorithm, running the string “hello” through an MD5 hash
should generate the following result string: “5d41402abc4b2a76b9719d911017c592”
Campus Labs®
Authentication Integration Worksheet
8 February 2016
8
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
Optional parameters:
firstName
User’s first name
lastName
User’s last name
campusEmail
User’s primary (campus) email address
affiliation
User’s primary affiliation with the campus (e.g.
Undergraduate, Graduate, Staff)
swipecardidentifier
User’s swipe card number. This can be used for tracking
attendance at events via swipe card readers.
Additional parameters:
Other parameters may be added to be automatically populated in the CollegiateLink profile and shown on system
reports. Common parameters include class year, major, school / college, part-time / full-time, etc.
Examples of a URL that your system would need to generate for authenticating a user into CollegiateLink using this
method would look like this:
Minimum Requirement:
https://federation.campuslabs.com/gpt?realm=https%3A%2F%2Fschoolname.campuslabs.com%2Fmanagement%2Faut
h%2F&userID=joeuser&time=1290238293223&random=23lkjhsxd82K&hash=280a1d8599f2054a291c3e83af1d5aaf
To generate the hash value:
userID – joeuser
time – 1290238293223
random – 23lkjhsxd82K
key – e1afc12960864755b8697638d17c0ee8bd9f8c47da4d4a0daf4f692f2517bffc
prehash –
joeuser1290238293223lkjhsxd82Ke1afc12960864755b8697638d17c0ee8bd9f8c47da4d4a0daf4f692f2517bffc
hash – 280a1d8599f2054a291c3e83af1d5aaf
Campus Labs®
Authentication Integration Worksheet
8 February 2016
9
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
Passing additional information:
https://federation.campuslabs.com/gpt?realm=https%3A%2F%2Fschoolname.collegiatelink.net%2Fexternalauthenticati
on%2Ffederationresult%2F&userID=joeuser&time=1290238293223&random=23lkjhsxd82K&returnUrl=/Organizations&
firstName=Joe&lastName=EndUser&campusEmail=juser%40schoolname.edu
&hash=77fee2706c33bc3fa8ce634f774d9da9
To generate the hash value:
userID – joeuser
time – 1290238293223
random – 23lkjhsxd82K
returnUrl – /Organizations
firstName – Joe
lastName – EndUser
campusEmail - juser@schoolname.edu
key – e1afc12960864755b8697638d17c0ee8bd9f8c47da4d4a0daf4f692f2517bffc
prehash –
joeuser1290238293223lkjhsxd82K/OrganizationsJoeEndUserjuser@schoolname.edue1afc12960864755b8697638d17c0
ee8bd9f8c47da4d4a0daf4f692f2517bffc
hash - 77fee2706c33bc3fa8ce634f774d9da9
Our system will not allow any requests that are 6 minutes in the past or future to be processed. This will prevent anyone
from reusing the URLs to authenticate. In addition, each subsequent request for any user produces a varying set of URL
parameters, thus thwarting brute force attacks.
Campus Labs supports GET and POST.
Your secret key is the last parameter in the string.
If all parameters are specified, you should concatenate as follows:
hash = MD5(userID + time + random + returnUrl + secret)
The single point of failure with this method of authentication is the exploitation of the symmetric key. It is important
to take proper precautions to ensure that the key is adequately protected.
Step by Step Example:
1. User goes to our product site.
2. User clicks the login link, which redirects the user to campus login page.
3. User enters credentials.
4. User is redirected back to us with a URL that resembles Example 1 above, upon successful authentication.
Campus Labs®
Authentication Integration Worksheet
8 February 2016
10
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
Complete the following information:
Authentication Server Information
URL
Please provide the link to the page that we can direct users to in order to log in.
Training, Support, and Test Account Information
While a unique, permanent vendor account is not required, it can be helpful for assisting us with troubleshooting and
authentication-related support issues. If we are not issued a test account, we will be required to contact your campus IT
department for assistance.
User ID
Password
Campus Labs®
Authentication Integration Worksheet
8 February 2016
11
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
Central Authentication Service (CAS)
CAS URLs
Please complete: (if not relevant, please denote writing “N/A”)
CAS Login Page: This is the page the user gets redirected to from the login page. The user enters the CAS login
credentials on this page.
CAS Logout URL: This is the URL that the user is redirected to when they log out.
URL
Parameters
CAS Login URL
CAS Logout URL
Our Service URL is: https://federation.campuslabs.com/auth/signin/
Training, Support, and Test Account Information
While a unique, permanent vendor account is not required, it can be helpful for assisting us with troubleshooting and
authentication-related support issues. If we are not issued a test account, we will be required to contact your campus IT
department for assistance.
User ID
Password
Campus Labs®
Authentication Integration Worksheet
8 February 2016
12
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
Lightweight Directory Access Protocol (LDAP)
Campus Labs Server CNAMES
The following CNAME must be able to connect to your system(s). Please configure any needed firewall exemptions.
Production Authentication Relay
ldap-sso.campuslabs.com
208.83.125.234
While not mandatory, it may be helpful for to also allow the following CNAMEs:
Development Environment 1
ldap-dev1.campuslabs.com
Development Environment 2
ldap-dev2.campuslabs.com
Multiple Campus LDAP servers
Please note that our products can be configured to connect to multiple LDAP sources (for example, students and staff
are in containers on different servers). If you opt for this configuration, the user will have to select their system from a
drop-down box before entering their username / password. Please enter all of the LDAP servers below, with a note for
what audience is being served by that server.
Configuration Options
An important consideration is whether or not the username that the user is entering should be used as their unique ID in
Campus Labs. It’s necessary for it to be unique and something that does not change. For that reason, email addresses
and usernames that might change over time are not ideal. We offer the ability to retrieve a different attribute than
what the user is entering to be used as their unique id. In this situation, the LDAP authentication process will be
configured to use a search account to connect to the server, a subtree-search will be performed starting at the desired
level, if a user is found, a bind will be performed with their entered credentials, and finally the alternative username
attribute will be retrieved.
Based on this decision, please complete either Option A (Direct Bind) or Option B (Search) below.
Authentication Server(s) Information – LDAPS (LDAP over SSL) is required
Server (Host name or IP)
Campus Labs®
Authentication Integration Worksheet
8 February 2016
Port
Description (if necessary)
13
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
Option A – Direct Bind
If we are capable of taking user provided credentials to use as a direct bind to your LDAP server AND the username
the user enters is intended to be their unique ID.
Please provide a sample user bind string and/or domain
information for binding. If there are multiple containers/UPN
formats to bind against, please list them all. They will be
attempted sequentially.
Examples:
uid=<username>,ou=people,dc=school,dc=edu
<username>@school.edu
Option B - Search
If we will use a search user to bind to your LDAP server and then utilize the user’s credentials to authenticate.
A. Search User Credentials
Provide a search user that has access to all containers that users are in.
Full DN
Password
B. Base Search Path
This value is the path to the container where the search will initiate. A sub-tree search is used, so all containers under
the specified base will be searched. This search will take longer based on how high up the search base is and how wide
and deep the sub-trees are.
This should be in the format: ou=People, o=school.edu, o=cp
Base DN
C. Unique Identifier
Please indicate the attribute that uniquely identifies a user. (i.e. saMAccountName, cn, uid etc)
Attribute
Campus Labs®
Authentication Integration Worksheet
8 February 2016
14
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)
Training, Support, and Test Account Information
While a unique, permanent vendor account is not required, it can be helpful for assisting us with troubleshooting and
authentication-related support issues. If we are not issued a test account, we will be required to contact your campus IT
department for assistance.
User ID
Password
Campus Labs®
Authentication Integration Worksheet
8 February 2016
15
developers.campuslabs.com
support@campuslabs.com
716.270.0000 (8am – 8pm ET)