University of Guelph
developing applications
with
D2L WebServices & SSO
Zdenek Nejedly1, Hugh Smith1, Matt Searle1,
Cindy Wells2, Bill Teesdale2,
Trevor Pemberton3, Kyle Mackie3
1Computing
& Communications Services
of Physics
3Teaching Support Services
2Department
Session Outline
• Transferring grades with D2L Web Services
–
–
–
–
Physics Quizroom environment
Synchronizing student grades (past & present)
Toolkit for rapid application development
Lessons learned
• Expanding the UofG Single Sign On
– SSO integration patterns
– SSO middleware
– SSO with Desire2Learn
• Take home message
Physics Quizroom
• About 2,400 students per semester
• Flexibility in scheduling study and exam time
• Students required to:
– pass pre-tests in D2L (on-line)
– write quizzes in the
Physics Quizroom (on-site)
- Successful pre-tests required
for admission to quizzes
- All marks to be in the D2L
Grade synchronization: past & present
• Large enrolments
requires an efficient process and
automation, e.g., swipe cards, grade synchronization
between D2L and Quizroom,…
• Grade synchronization:
– 2003: WebCT – via a smart http client
– 2006: Blackboard – via the BB Web Services
– 2009: Desire2Learn – via the D2L Web Services
Developing with D2L Web Services
• Desire2Learn Web Services - API for management of
– users
– courses
– grades
•
•
•
•
WS overhead, e.g., SOAP, WS-Security
Platform independent (examples for .Net and Java)
Our dev platform: JSE 1.6/JEE 1.5, NetBeans
Our run-time platform: Linux RedHat
Challenges
existing system
in production since 2003
supportability
performance
expectations
reliability
availability
internet communication
vendor’s API
defined protocol
reality
real-time bulk updates
production timelines
Challenges: performance
• Core requirement: avoid changes to legacy
systems, i.e., maintain the original interface (2003)
• Implication: process full gradebook during each
synchronization (10,000 values every 15 minutes)
• Reality (D2L WebServices API):
– Support for single update not the entire class at once
– References instead of actual values
– Single call requires 1-2 seconds to complete
– Concurrency limited
– Timeout and usage limits on the auth token
• Challenge: complete a 2-hour process in 15 mins
Solutions: performance
• Cache the grade values and let through only the
modified values
• Internal userids: cache the reference-value mapping
• Cached in local relational database (MySQL)
• WS Security – token manager tracking age & usage
• All encapsulated in the Software Development Toolkit
(if interested let us know)
• Additional monitoring and process control in the OS
Outcomes: Improved Performance
The total process time reduced
a) downloads: from 30-60 minutes to 5-10 minutes
b) uploads: from 1-2 hours to 1-2 minutes
Q?
D2L & SSO @UofGuelph
• 2nd year of SSO integration - majority of the campus
community now exposed to SSO
– students (via LMS – Desire2Learn)
– employees (via the Pay & Pension Link service)
• Technology: Sun Access Manager 7.1 (Oracle)
• Components:
– central SSO server
– individual Policy Agents
SSO integration patterns @UofGuelph
Agent directly on the
protected service
Session initiated by a
middleware
Agent on the proxy
Session initiated via
Shibboleth
SSO integration patterns @UofGuelph
Agent on the proxy
Agent directly on the
protected service
e.g., departmental webservers,
campus webhosting
Session initiated by a
middleware
Session initiated via
Shibboleth
SSO integration patterns @UofGuelph
Agent directly on the
protected service
Agent on the proxy
e.g., Oracle/financial
applications
Session initiated by a
middleware
Session initiated via
Shibboleth
SSO integration patterns @UofGuelph
Agent directly on the
protected service
Session initiated by a
middleware
e.g., E-Academy, D2L, Pay &
Pension
Agent on the proxy
Session initiated via
Shibboleth
SSO integration patterns @UofGuelph
Agent directly on the
protected service
Session initiated by a
middleware
Agent on the proxy
Session initiated via
Shibboleth
e.g., Drupal, library access
Bringing D2L to SSO
• CourseLink.uoguelph.ca – hosted by D2L off campus
• Integration choices:
– PA directly – subject to code review
– Reverse proxy – shared hosting challenges
– via Shibboleth – in progress, not yet available
• Solution: D2L Single Sign On API
• Guelph module designed in java on SSO middleware
D2L SSO – tech overview
• Logging into D2L with SSO (typical)
1. Authenticate (Sun Access Manager)
2. Middleware: request a unique token and set a cookie
3. Redirect the user to D2L with the token
• Signing out of D2L (UofGuelph specific)
1. Destroy D2L session (D2L hotfix)
2. Redirect to SSO middleware
3. Redirect to SSO logout or D2L (session cookie)
• Sessions initiated by SSO but managed by D2L
SSO middleware
•
•
•
•
•
•
Linux on VMware
Load-balanced cluster
SSO via reverse proxy
Multiple tomcat instances
Custom java apps (D2L, Pay&Pension)
Shared hosting platform for various SSO applications
D2L SSO challenges & solutions
• Single Logout
– D2L hotfix, custom code
– communication/user education
• Internet comm issues – add a quality assurance layer
• General SSO challenges for a mission-critical service
– expecting 100% browser compatibility
Take-home message
•
•
•
•
Cache objects when possible
Consider toolkits to simplify the WS API
Plan for Internet communication issues
Choose the specific approach to SSO case-by-case
Acknowledgements
• Richard Gorrie and the TSS LTCI team
• Mark Sloggett, Bosco Tsang & CCS Managed
Servers
• Leo Song and Dennis Xu & CCS Networking
and Security
• Kent Hoeg and the Management Team
• Desire2Learn and Sunwapta
• Funding provided by UofG CCS, TSS, and the
Physics Department
• Support of the UofG campus community
thank you