By Frank Boshoff, September 26, 2017
University of Toronto’s Information Technology Services (ITS) is replacing the Repository of Student Information (ROSI) mainframe with a distributed Linux cluster to reduce operational costs and improve capacity (the system’s capacity target is 15,000 students registering concurrently, instead of the several hundred that can currently be accommodated). Although reduced operational costs and improved capacity are beneficial enough to support a sound business case, there are other advantages provided by the new architecture that promise even bigger benefits.
ROSI is the Repository of Student Information – it is the system of record – and is therefore considered “the single version of truth”. For example, if a student wants to review their official standing with the University, they access ROSI. If an administrator needs to review a student’s GPA to confirm compliance with an enrolment control, they access ROSI. Such interactions happen via an on-line screen of some sort – a Browser for the student, a 3270 terminal emulator (the infamous “green screen”) for the administrator.
But what if a Division needs to process a group of students for, say, practicum assignments? Or a Department needs to capture supplemental information from applicants and once all applicants have submitted the information, update ROSI? Such processes have been supported on the mainframe using bulk data uploads or downloads, in other words, batch processing.
There are two problems with batch downloads:
Some departments have assumed the risk of storing copies of ROSI data, refreshing them frequently to avoid Batch Problem #2. A few have located their copies within the EIS data centre to enhance the security and minimize Batch Problem #1.
The new ROSI architecture addresses these problems and others.
The new ROSI provides for Web API access to ROSI information by Divisional applications. Security is addressed by using two industry standards:
Using these standards, Divisional applications can access student data in real-time, which addresses Batch Problem #2. To use those standards, however, the applications must be Web-based, authenticate users via UTORid and, when necessary, eToken.
eToken is already integrated with the University’s Shibboleth Identity Provider, and OAuth 2.0 and OIDC will be integrated by the end of the 1st quarter of 2018. Applications that use Shibboleth for user authentication will automatically have access to OAuth 2.0 and OIDC capabilities. OIDC also enables
secure mobile applications (one of the main reasons OIDC was created), which will become increasingly important as UofT staff (or possibly their robots) adopt mobile work habits.
What this means is that Divisional applications can be modified to access ROSI in real-time, avoiding the risk of stale data and reducing the risk of student data security breaches.
The new ROSI has a Web-based user interface and is accessed using the Browser installed on your workstation. Administrators no longer need to use a 3270 emulator. The login credential will be your eToken and its password, which will be mapped to your ROSI ID (which now becomes a “ROSI persona” rather than a credential). If you happen to have more than one ROSI ID, upon login you’ll be able to select the one you need to use.
As the new ROSI platform is being built, more information will be disseminated to administrative staff so that Divisional IT plans can take advantage of the new integration capabilities available in 2018 and beyond.