Course Evaluation Software Integration & SSO: A Technical Buyer's Guide (SAML, SCIM, LTI 1.3, Roster Sync)

Most course evaluation procurements are won or lost on features and price, then quietly stall for a semester because nobody scoped the integration. The single-sign-on does not enforce, the roster feed is a nightly CSV that breaks on late enrolments, and the IT security team returns a 90-question assessment two weeks before go-live. This guide is the technical companion to a course-evaluation buyer's guide: it explains the four integration layers you actually have to connect, the questions your IT and information-security teams will ask, and how to specify all of it in the RFP so integration is a line item rather than a surprise.

It is deliberately vendor-neutral on the survey features (compare those separately) and focused on the plumbing: identity, roster, delivery, and export.

Answer first: the four layers to scope

A course evaluation platform touches your estate in four distinct places. Treat each as a separate requirement with a named owner:

1. Identity / SSO — how students and staff authenticate (SAML 2.0 or OpenID Connect against your IdP; SCIM for provisioning).
2. Roster / enrolment data — how the tool knows who is enrolled in which course with which instructor (SIS feed, API, LTI NRPS, or file transfer).
3. LMS delivery — how the evaluation reaches the student inside Moodle, Canvas, Blackboard or Brightspace (LTI 1.3 / LTI Advantage).
4. Reporting / export — how results leave the tool into dashboards, data warehouses and accreditation evidence (API, scheduled export, PDF/CSV).

If any one of these is unspecified at contract signature, it becomes an implementation risk. The rest of this guide takes them in turn.

Layer 1: Identity and single sign-on

Standards to require. In European higher education the identity provider is usually Shibboleth, Microsoft Entra ID (Azure AD), or Okta, often federated through a national federation and eduGAIN. Your evaluation tool should support SAML 2.0 and/or OpenID Connect (OIDC) as a Service Provider, so students sign in with their existing institutional account and no new password is created. Require SSO to be enforced, not merely available — a tool that allows local password fallback undermines your MFA and offboarding controls.

Provisioning and deprovisioning. SSO authenticates; it does not, by itself, create or remove accounts. For staff and administrator accounts, ask whether the tool supports SCIM 2.0 for automated provisioning and — critically — deprovisioning, so that when a staff member leaves, access is revoked centrally. Where SCIM is not available, document the manual offboarding process; an orphaned admin account with access to student comments is a data-protection incident waiting to happen.

Anonymity vs identity. A subtlety unique to course evaluation: you authenticate the student to check eligibility and prevent ballot-stuffing, but the response must remain anonymous to the instructor. Confirm in writing how the vendor separates the authentication identity from the stored response, and that instructors cannot re-identify respondents in small cohorts. This is both an ethics requirement and, under GDPR, a data-minimisation one.

Layer 2: Roster and enrolment data

This is where most projects underestimate the work. The tool needs an accurate map of courses, sections, instructors, and enrolled students — refreshed often enough to handle add/drop. Options, roughly in order of robustness:

• Direct SIS integration / API — a live or scheduled feed from Banner, SITS, or a local platform (in some markets an in-house academic system like Fénix or SIGARRA). Most reliable, most work to set up.
• LTI Names and Role Provisioning Service (NRPS) — when the evaluation runs as an LTI tool inside the LMS, NRPS 2.0 lets it pull the membership and roles of a course context directly from the LMS. Elegant, because the LMS already holds the roster; scope it against how cleanly your LMS course structure maps to your evaluation units.
• OneRoster — a 1EdTech rostering standard; more common in schools than universities but worth checking if your SIS supports it.
• Scheduled file transfer (SFTP CSV) — the fallback. Workable, but plan for the failure modes: late enrolments, cross-listed modules, team-taught courses split across instructors, and students in multiple sections.

Specify the refresh cadence and the handling of team-taught and cross-listed modules explicitly. A single averaged score for a module taught by three staff is often exactly the data a module leader cannot use.

Layer 3: LMS delivery via LTI

To collect responses where students already are, the evaluation is usually launched from the LMS. The modern standard is LTI 1.3 / LTI Advantage, built on the 1EdTech Security Framework (OIDC login, OAuth 2.0, signed JWTs). LTI Advantage bundles three services worth naming in your requirements:

• Names and Role Provisioning Service (NRPS) — roster and roles for the launched context (see Layer 2).
• Assignment and Grade Services (AGS) — a gradebook column; for evaluation this is typically used to surface a completion indicator, never a grade.
• Deep Linking — lets staff place the evaluation as a resource in the course.

Require LTI 1.3 specifically. LTI 1.1 relied on a shared secret and OAuth 1.0 signing and is deprecated; do not accept it as the primary integration for a new deployment. Confirm certification status (1EdTech maintains a certified-products register) rather than taking "LTI compatible" at face value.

Layer 4: Reporting and export

Evaluation data has to leave the tool: into instructor dashboards, into a data warehouse or BI layer for institutional research, and into accreditation evidence. Ask for a documented API and/or scheduled exports (CSV/JSON), the ability to export both quantitative results and analysed qualitative themes, and PDF report generation for committees. Confirm you can extract your data on exit — this is also a GDPR Article 28(3)(g) return-and-delete obligation and a guard against vendor lock-in.

Requirement → what to ask

Integration requirement	What to ask the vendor	Red flag
SSO	SAML 2.0 / OIDC support; can it be enforced?	Local password fallback only
Provisioning	SCIM 2.0 for staff/admin deprovisioning	Manual account removal, no SCIM
Roster	SIS API, LTI NRPS, or SFTP; refresh cadence	Only one-off CSV import
Team-taught modules	Per-instructor splitting of results	Single averaged module score
LMS delivery	LTI 1.3 / Advantage, 1EdTech certified	"LTI compatible" (unversioned), LTI 1.1
Export	API + scheduled export, data on exit	Screens-only, no bulk export
Anonymity	Auth identity separated from response	Instructor can re-identify small cohorts

The IT security review — plan for it early

Any credible institution will run an information-security assessment before go-live. In North America this is often the HECVAT (Higher Education Community Vendor Assessment Toolkit); in Europe expect an equivalent questionnaire mapped to ISO 27001 and your GDPR obligations. The questions cluster around:

• Hosting and data residency — where is the data stored and processed? For EU institutions, EU/EEA hosting avoids a Chapter V transfer analysis entirely.
• Certifications — ISO 27001, SOC 2 Type II, and an accessibility conformance statement (VPAT / EN 301 549) for the student-facing interface.
• Data flows and PII — a diagram of what personal data moves where, and the lawful basis (typically public task, not consent, for institutional evaluation).
• Access control and logging — SSO enforcement, MFA for admins, role-based access, and audit logs.
• Sub-processors and the DPA — the GDPR Article 28 data-processing agreement and the sub-processor chain.

The practical lesson: request the vendor's security package (pen-test summary, certifications, VPAT, DPA, sub-processor list) during evaluation, not after selection. It moves a multi-week blocker to the front of the timeline. Our GDPR Article 28 DPA and sub-processor checklist covers the contract side in detail.

Data flows and who owns what

Assign an owner to each connection before signing:

• IdP / SSO — identity or IT security team.
• SIS / roster feed — the SIS/registry team.
• LMS / LTI — the learning-technology team.
• Data warehouse / reporting — institutional research or BI.
• DPA and security review — data protection officer and InfoSec.

A RACI table with these owners, attached to the RFP, is the single most effective way to keep an integration on schedule.

When a lighter integration is the right call

Integration should be proportionate. If you are a small institution running a handful of evaluations, a fully SIS-wired deployment may be over-engineering. Honest guidance:

• Pilot with LTI + SSO only. Launch from the LMS, authenticate via your IdP, and pull the roster with NRPS. This gets you a working, secure deployment without a bespoke SIS integration.
• Defer the data-warehouse feed until the pilot proves the instrument. Scheduled CSV export is fine for a first cycle.
• A self-hosted open-source tool may need less external integration precisely because you control the environment — at the cost of running it yourself.

Match the integration depth to the deployment scale; do not buy a Banner integration for a two-department trial.

How Koji fits

Koji is built to slot into this architecture rather than replace it. It authenticates students through your existing SSO (SAML 2.0 / OIDC), can be launched inside the LMS via LTI 1.3, pulls roster and roles where NRPS is available, and exposes an API plus scheduled exports so results flow into your dashboards and accreditation evidence. Because the conversational AI interview is the differentiator, the integration surface is deliberately standards-based and thin. The same interview engine powers the main Koji platform at koji.so for user and customer research, so the identity and export patterns are battle-tested outside education too. Ask us for the security package — hosting, certifications, VPAT and DPA — as part of your evaluation, not after it.

Frequently asked questions

Do we need LTI, or is SSO enough? They solve different problems. SSO authenticates the user; LTI delivers the evaluation inside the LMS and (via NRPS) can supply the roster. Many institutions use both: SSO for identity, LTI 1.3 for in-LMS launch and membership.

Can the tool integrate with an in-house or national SIS? Via API or scheduled file transfer, yes — but institution-specific systems (such as Fénix or SIGARRA in Portugal, or a local SITS/Banner configuration) rarely have a turnkey connector. Scope the roster feed explicitly and name an owner.

Should we require LTI 1.1 or 1.3? Require LTI 1.3 / Advantage. LTI 1.1 uses a shared secret and OAuth 1.0 signing and is deprecated; it should not be the primary integration for a new deployment.

What is HECVAT and will European buyers use it? HECVAT is a higher-education vendor security-assessment toolkit from North America. European institutions may use it or an equivalent questionnaire mapped to ISO 27001 and GDPR. Either way, request the vendor's security package during evaluation.

How is student anonymity preserved if they sign in with SSO? Authentication confirms eligibility and prevents duplicate responses; a well-designed tool separates that identity from the stored response so instructors cannot re-identify respondents, especially in small cohorts. Confirm this in writing.

Related Resources

• Course Evaluation Vendor Due Diligence: the GDPR Article 28 DPA & Sub-Processor Checklist
• EU AI Act and Course Evaluation Software Compliance
• European Accessibility Act & Course Evaluation Software Compliance
• Course Evaluation Data Retention & Records Management for Audit Evidence
• Institution-Level Evaluation Reporting for Quality Audits
• Buyer's roundup: Course Evaluation Software with LMS & SIS Integration (2026)