Technical Overview of InAcademia

What is InAcademia?

InAcademia is an online REST API-based service that assists online retailers and service providers in validating whether a user is entitled to an academic offer or discount for purchase of goods and services, or for registration to access membership benefits or restricted content. InAcademia draws on the authoritative systems of record that are used by the institution itself for managing access to its internal services like the user’s email, learning and exam platform(s) or e.g. a HR application or an active directory system, or for accessing premium content such as academic journals.

Provided the student is registered with a participating eduGAIN Identity Provider, the InAcademia Service provides merchants with a quick, easy, reliable and secure way to verify academic affiliation (whether a user is a student, a member of staff or faculty), thereby removing outdated, slow, costly and manual validation processes.

How does InAcademia work?

InAcademia leverages an authoritative and trusted authentication and authorisation infrastructure, called eduGAIN, used by thousands of institutions across Europe and beyond to enable their students and staff to access internal and external service. This infrastructure is called eduGAIN, and is the higher education federation for identity, authentication and authorisation. Validation is requested in real time, and can be relied upon because it refers directly to the role, or affiliation, that the academic institution has assigned to the user according to strict criteria.

The workflow starts when a merchant’s OpenID Connect RP initiates an authentication request using the authorization code flow towards the InAcademia OP’s endpoint, which acts as a proxy that initiates a SAML authentication request to the user’s home institution’s identity provider (IdP), where users are assigned roles which are expressed as ‘affiliation attributes’. When the user authenticates, their IdP releases a set of attributes to InAcademia’s internal SAML SP, that includes the user’s designated affiliation, which InAcademia’, compares to the attribute value requested by the merchant (either student, a member of staff or faculty) and then returns a privacy-preserving confirmation (or denial) of whether that user is affiliated with that institution. This process uses the same authentication procedure that users follow when accessing academic services at its home institution. The InAcademia Service is designed as a ‘token translation service’, translating complex SAML2 attribute values and authentication responses received from academic identity provider software to a simple boolean value for consumption by the merchant’s OIDC RP, vastly simplifying the academic/student validation process.

How is it used?

InAcademia can be easily and unobtrusively integrated with a merchant’s website to initiate a validation request at any appropriate point in the merchant’s registration or checkout workflows. For in-scope institutions InAcademia can replace friction-led procedures, such as asking students to send scans or originals of their identity documents for verification, and mitigates the significant challenges presented by reliance upon academic email domains as proof of academic validation, including the fact that even if an institution has issued an email account to the user, it will not provide any assurance of the user’s role at that institution.

What types of user attributes can InAcademia validate?

The supported attribute types are:

StudentIs the end-user a student at its institution?
Faculty or StaffIs the end-user primarily an academic or professional member of its institution? This is articulated as such in response to the varying definitions of ‘faculty’ and ‘staff’ globally.
Employee Is the user an employee at its institution?
Member Does the end-user hold any of the above roles at its institution (i.e. either a student, faculty member, staff or employee)? Please note that in this case, InAcademia will not distinguish whether the user is a student, staff, faculty member or employee.

Where the institution releases the necessary attributes, InAcademia can also respond to additional claims, such as re-use detection and IdP Hint assertion.

To support GDPR compliance, InAcademia presents users with a consent screen, which allows the user to decide whether it consents to the information being passed to the requesting merchant. Denying consent results in failure of the validation, is signaled to the merchant and no ID Token is provided to the merchant.

The image below provides a schematic overview of the core components, protocols and flows involved. Note that the REST based API does not carry any personal information beyond a pseudonymised identifier that is utilised as part of the validation.

Authentication and attribute consumption is handled by the SAML Service Provider component of InAcademia, which is a SAML2 SP and a member of eduGAIN.

After receiving the attributes, InAcademia interprets the attributes and based on that creates the required response. InAcademia is stateless and can only respond with boolean values and simple claims.

Both identifiers for the requesting merchant as well as the identifier for the authenticating IdP are logged in a transaction database for a period of 28 days before being purged; this information is distilled in order to provide a statistics log from which invoicing reports can be generated.

More detail is available here: https://inacademia.org/inacademia-and-privacy/.

Skip to content