University of Guelph developing applications
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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
2Department of Physics
3Teaching 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
Challenges
existing system
in production since 2003
supportability performance
expectations
reliability availability
internet communication defined protocol
reality
vendor’s API 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 Agent on the proxy
Session initiated by a Session initiated via
middleware ShibbolethSSO integration patterns @UofGuelph
Agent on the proxy
Agent directly on the
protected service
e.g., departmental webservers,
campus webhosting
Session initiated by a Session initiated via
middleware ShibbolethSSO integration patterns @UofGuelph
Agent directly on the
protected service
Agent on the proxy
e.g., Oracle/financial
applications
Session initiated by a Session initiated via
middleware ShibbolethSSO integration patterns @UofGuelph
Agent directly on the
protected service Agent on the proxy
Session initiated by a Session initiated via
middleware Shibboleth
e.g., E-Academy, D2L, Pay &
PensionSSO integration patterns @UofGuelph
Agent directly on the
protected service Agent on the proxy
Session initiated by a Session initiated via
middleware Shibboleth
e.g., Drupal, library accessBringing 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 youYou can also read
