University of Guelph. developing applications with D2L WebServices & SSO

Transcription

1 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

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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?

10 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

11 SSO integration Agent directly on the protected service Agent on the proxy Session initiated by a middleware Session initiated via Shibboleth

12 SSO integration 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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