University of Guelph developing applications with D2L WebServices & SSO Zdenek Nejedly 1, Hugh Smith 1, Matt Searle 1, Cindy Wells 2, Bill Teesdale 2, Trevor Pemberton 3, Kyle Mackie 3 1 Computing & Communications Services 2 Department of Physics 3 Teaching Support Services
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
internet communication Challenges supportability expectations performance reliability availability vendor s API existing system in production since 2003 reality defined protocol 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 2 nd 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 Agent on the proxy Session initiated by a middleware 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 Agent on the proxy Session initiated by a middleware e.g., E-Academy, D2L, Pay & Pension Session initiated via Shibboleth
SSO integration patterns @UofGuelph Agent directly on the protected service Agent on the proxy Session initiated by a middleware 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