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 University of Guelph developing applications with D2L WebServices & SSO

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 defined protocol internet communication existing system in production since 2003 expectations performance reliability availability vendor’s API real-time bulk updates production timelines reality supportability

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

Developing apps with the Toolklit Initialize the toolkit TokenManager.initialize(serviceUrl, login, passwd, timeout, reuseN); ToolBox toolBox = new ToolBox(serviceUrl); // or ToolBoxCached(..) Get the toolkit services GradesTools gradesTools = toolBox.getGradesTools(); Get the grades List values = gradesTools.getGradeValuesByGradeObject(courseId,strGradeId);

Outcomes: Improved Performance The total process time reduced a) downloads: from minutes to 5-10 minutes b) uploads: from 1-2 hours to 1-2 minutes Q?

D2L & 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 Agent directly on the protected service Agent on the proxy Session initiated by a middleware Session initiated via Shibboleth

Agent directly on the protected service e.g., departmental webservers, campus webhosting Agent on the proxy Session initiated by a middleware Session initiated via Shibboleth SSO integration

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

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

Agent directly on the protected service Agent on the proxy Session initiated by a middleware Session initiated via Shibboleth e.g., Drupal, library access SSO integration

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