Edsby’s integration architecture

Edsby has been designed from the ground up for fast, easy, efficient, bidirectional integration with a wide variety of data stores and services found in school districts. Unlike rudimentary data export approaches intended for basic student, teacher and class rostering, there are different types of advanced integrations offered by Edsby that enable powerful data capabilities, and are key to its powerful role-based permission and access control: Data Synchronization Integrations, Authentication Integrations, and Real-Time Data Integrations.

Data Synchronization Integrations

Unidirectional Data Synchronization Integrations

The most common form on integration is one in which Edsby acts in a dependent configuration with the various “system-of-record” platforms in the district. The most common one of these is with the Student Information System (SIS), which is typically the system of record for all students, teachers, classes, schools and enrollments.

All synchronization integrations are done using a fully automated bidirectional data synchronization engine designed specifically to provide a bridge between Edsby and district enterprise data management systems.

As such, Edsby is ideal for managing situations in which there are multiple systems-of-record in a single district. For example, it is often the case that the SIS contains information about all teachers, but has no information about non- teaching staff such as guidance, district curriculum specialists, etc. Those staff must be then loaded from an alternative source such as the Human Resources (HR) Information System. Similarly, disparate systems may be used for substitute management, state and federal test results, athletics, etc.

In all of these cases, Edsby may be configured to pull the relevant data from each system, and then synchronize the data to the appropriate location in Edsby.

Bidirectional Data Synchronization Integrations

While most data synchronization is from district data sources to Edsby, it is common for districts to want so synchronize data from Edsby back to a district data table. This may be operational data, such as statistics, but it may also be pedagogical data such as attendance, grades, or report cards.

Edsby has been built with a plug-in architecture for both import and export data communication. This allows Edsby to both query district data and use that to populate the appropriate content in Edsby, and well as querying Edsby and using that to populate the appropriate data stores in the district.

Edsby Data Query and Update Standards

Edsby currently supports the following standards for both import and export:

• Direct connections to dozens student information or management systems (SISes or SMSes)
• CSV
• Excel
• ODBC
• Direct SQL (MySQL, DATACOM, DB2)
• Direct SQL (Microsoft SQL Server)
• Web Services (SOAP, REST, JSON, AJAX)
• SIF (via CSV or XML)
• FirstClass Batch Admin
• Flat file
• Batch Image Libraries (school photo upload)

Edsby has been designed for extensible data access, and additional protocols are added regularly.

High Performance and Parallel Processing

Edsby may run multiple uploads (imports) and downloads (exports) in parallel with no interference between the tasks. In addition, a single Edsby site may run multiple connection instances (very useful in overcoming firewall/VPN/security issues). In all cases Edsby will process the Edsby synchronization in the most efficient parallel way, leading to typical synchronization times of a few minutes for most sites.

Full Compression and Encryption of All Data

All data transferred is both compressed as well as transmitted over an HTTPS connection. There are no plain-text data transmissions at any stage.

Full Reporting And Trace Files

Each and every synchronization run is tracked and logged, and the district IT administrator has full access to the transmission files for debugging and analysis.

Flexible Scheduling

Edsby has a flexible scheduling system, so that synchronizations may be scheduled to best coincide with requirements of the district.

External Authentication Integrations

The second major type of Edsby integration is the Authentication Integration. In almost all Edsby installations, it is highly desirable for users to use their existing district UserIDs and passwords in order to log in. In order for that to happen, the Edsby server supports the ability to enable External Authentication.

External Authentication

With External Authentication, Edsby takes the User ID and password entered by the users, but instead of checking that UserID and password against internal Edsby passwords, it sends the UserID and password over a secure link to the existing district identity management solution (e.g. Active Directory or LDAP) in order to authenticate the user. If the response from the identity management solution is positive, the user is able to log in. If it is negative, the user is given the response code from the identity management solution.

Single Sign On (SSO) Integrations

Edsby also supports a number of Single Sign On (SSO) integrations. With SSO, logins are handled in quite a different way. Broadly speaking, in an SSO scheme there is some third party server which handles all authentication. Once the user is logged in to that service, the browser is given a ticket, which is stored in the browser.

When a user clicks the appropriate link in the authenticated service, the ticket is passed to the Edsby server, the Edsby server talks to the authentication server, and if everything matches the user is authenticated into Edsby without having to enter an UserID or password at all.

While SSO schemes are powerful and convenient, they do have certain restrictions. The major restriction is that in almost all cases, the UserIDs on all linked services must match. Since some services do not allow any control over the UserID, this means that all services must use that UserID.

An excellent example of this is Google Apps for Education, which must use an email address as a user ID (e.g. billy.student@someschool.edu). In order to use SSO with Edsby, Edsby must use the same UserID format.

Edsby provides a seamless integration with Google Apps for Education and Office 365 + Azure »

oAuth SSO Server Integrations

In addition to the SSO client integrations described above, Edsby is also capable of acting as an oAuth Server. This means that should the district wish, other district services may perform oAuth authentications against Edsby, enabling SSO for those services.

The Importance of UserIDs in Authentication Integrations

Building successful authentication integrations is highly dependent on being able to configure a common UserID between the various constituent systems, including Edsby. This is because most identity management systems installed in a district require a very specific UserID. To make matters even more complex, these UserIDs are not necessarily the same across all identity management systems. To use one simple example, Active Directory and LDAP require X.400-stype addresses, while Google Apps requires an email address.

In order to address this requirement, Edsby has extensive support for the ability to do UserID namespace mapping (e.g. users enter an email address as the user ID, but Edsby uses the student number as the User ID for LDAP BIND).

All accounts in the proposed system will be created through synchronization with the various authoritative identity management systems in the district (e.g. SIS, HR, Active Directory, etc.). Edsby will internally convert this to a Globally Unique ID (GUID) that will identify each and every user on the system, and the GUID mapping table will be exported automatically for district use.

At login time, the entered user ID will be used to formulate the correct external authentication call, which may vary based on school, role, etc. Note that in addition, Edsby also supports single-sign-on technologies such as OAuth.

In order to make this work, the district must define at least one universal Unique Identifier (UID) per role. Typically this will be something like this:

Multiple External Authentication Integrations

Edsby also support multiple OUs, multiple AD/LDAP servers, and multiple role- based UserID formats. Our external authentication support is also multi- tenanted, so that if multiple schools are on the same Edsby server, each school could use their own custom external authentication setup. Conversely, it is also possible from a single school or district to use multiple OUs or multiple AD servers.

By way of example, the largest Edsby server currently has just over 300,000 user accounts, with complex rules-based authentication. Students and teachers authenticate against one Active Directory server with two different domains, and also with two different sets of user IDs. Parents authenticate against a second Active Directory server, and casual users authenticate against the internal Edsby password system. All of this is working seamlessly, handling hundreds of thousands of authentications per day.

Real-Time Data Integrations

Learning Tools Interoperability Integrations

Edsby has been certified to the following LTI standards:

• Learning Tools Interoperability V1.0
• Learning Tools Interoperability V1.3
• LTI Assignment & Grade Services 2.0
• LTI Deep Linking 2.0
• LTI Names and Role Provisioning Services 2.0
• LTI Advantage Complete

SIF Support

Edsby supports SIF via CSV and XML. It is also worth noting that the underlying Edsby data structures for Students, Courses, Parents, Schools and Timetables are all based directly on the SIF specifications.

OneRoster Support

Edsby supports OneRoster Consumer, Service Provider and Gradebook Passback.

Extended Edsby Import Capabilities

On the uplink side, Edsby can query multiple systems, synthesize the resultant data set into a single update, and then use that to populate the relevant data structures in Edsby.

This means that Edsby can easily be synchronized with (for example) UserIDs from an Identity Management System, teacher names from an HR database, pictures from a folder of JPEGs, passwords from FirstClass, and enrollment data from an SIS.

In addition, Edsby is extensible, so for example the Edsby Student Panorama form could be easily extended to provide access to data such as:

• Student Community Service Hours
• Standardized test results
• Student Locker Numbers, etc.

Edsby Export Capabilities

On the export side, any data collected in Edsby may be exported into an appropriate district data store. This includes:

• Gradebook data
• Parent contact information
• All grade data including details with grades, notes, etc.
• Usage data
• Attendance data
• Report card data

Export data may then be saved either as CSV files, stored in auxiliary SQL tables, or written directly back to the required enterprise database.

Attendance and Discipline Data

Edsby may be configured to import attendance data from a variety of sources, and this data will be displayed to students, teachers, parents and administrators as appropriate. In addition, the attendance data (if available) will be collated and used as part of the report card submission process.

 

Click here to set up a demo of Edsby