Slide

What is InAcademia?

InAcademia is an online REST API-based service that assists online retailers and service providers to validate whether a user is entitled to an academic offer or discount either for purchase of goods and services, or for registration to access membership benefits or restricted content. It does this by way of an OpenID Connect proxy that asks the user to authenticate at its institution's identity provider (IdP), and then returns confirmation (or denial) of whether that user is affiliated with its academic institution. This means that users can validate their entitlement to discounts and services in a similar way as they would access any access-controlled service at its home institution.

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), provided the student is registered with a participating eduGAIN Identity Provider, thereby removing outdated, slow, costly and manual validation processes.

How does InAcademia work?

InAcademia leverages information from the higher education federation for identity, authentication and authorisation, eduGAIN, which provides an infrastructure used by thousands of institutions to enable their students and staff to authenticate with internal and external service providers. Validation is requested in real time, and the information is up-to-date as the affiliation of the user has been verified (by the academic institution).

InAcademia performs an auxiliary service, without forming part of the supply chain in fulfilling products or services, and prevents the need for students to send scans or originals of their identity documents for verification. Your student validation process will no longer rely on requesting and checking hard copies, scans or photographs of ID. Some merchants choose to verify users academic affiliation by requesting confirmation of access to academic email domains; however, this method does not provide any assurance of the user’s role at that institution.

Merchants can configure their workflow to initiate a validation request to the InAcademia service at any time during the registration or checkout process.

When a validation request is initiated at a merchant’s website it triggers an OIDC request at the InAcademia service endpoint. Using the SAML protocol, the user is then asked by InAcademia to prove affiliation with the academic community by entering their institution-specific credentials directly into their home institution’s systems. When the institution's IdP returns the authentication response, InAcademia evaluates whether the response matches the requested affiliation to be validated and sends back the validation result to the requesting merchant, in a privacy preserving format.

What types of user attributes can InAcademia validate?

The supported attribute types are:

Student = Is the end-user a student at the institution?

Faculty or Staff = Is the end-user a teacher/researcher (faculty) or a worker (other than teacher/researcher, staff) at the institution?

Employee = Is the user an employee at the institution?

Member = Is the end-user affiliated to the 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.

The response may also contain additional claims, should an institution be willing and able to provide the necessary attributes.

In all cases (all validation flows and claims) the user is presented with a consent screen, allowing 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 InAcademia Service is set up as a ‘token translation service’, translating SAML2 attribute values on one side to a boolean value for use with another protocol on the other side.

The image below provides a schematic overview of the core components, protocols and flows involved. Note that the REST based API only validates student or staff affiliation and therefore does not carry any personal information beyond a pseudonymised identifier. The service API is shielded with OpenID Connect, using either the authorization code flow or the implicit grant scheme, which requires a user to authenticate and consent before a response is passed back to InAcademia. For user authentication, InAcademia depends upon the Identity Providers available via eduGAIN, the pan-European interfederation for Research and Education, and, in some cases, the nationally federated identity providers not announced to eduGAIN.

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

After receiving the attributes, InAcademia interprets the attributes and based on that creates the required response. InAcademia can only respond with boolean values and simple claims. At no point is personally identifiable attribute information, as was received by the SAML backend of InAcademia, passed to the merchant.

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