InAcademia

To safely connect students to the various student discount platforms InAcademia was created. It is operated by GÉANT for our academic community.

Description

InAcademia is available as a SAML 2.0 Service Provider (SP) for eduID.at Identity Providers that also participate in Interfederation/eduGAIN. (All eduID.at IDPs should participate in Interfederation/eduGAIN.)
It also acts as an OpenID Connect Provider (OP) for any connected student discount platforms (or "merchants"), providing for easier integration of the student verification flow within mobile apps.

Due to its setup as a proxy InAcademia can also act as a "data firewall": First it only requests the minimum data to be released from IDPs. Then it also filters down any data recieved from the IDP (requested or not) to the abolute minimum before providing the basic piece(s) of information to the merchant: Whether the subject is a student (or an employee) of the institution or not. Depending on the "flow"/integration chosen by the merchant an opaque identifier for the subject may also be shared with the merchant, to support use cases that require the subject to be recognised across visits. But even the opaque identifier (if chosen) is dynamically generated and pseudonymised by InAcademia, based on data recieved from the SAML IDP.

None of the attributes received from federation IDPs are passed through to the merchant verbatim.
Nothing else about the subject (except for the expected affiliation and possibly an opaque identifier) is revealed to the merchant, not even if the SAML IDP was misconfigured and sent along all kinds of personal data (e.g. the person's name or email address).

Attribute requirements

The data requirements and data processing are well explained in the InAcademia Privacy Statement, a very readable and informative document.

Attribute release configuration

If your IDP supports services of the GÉANT Data Protection Code of Conduct category (all eduID.at IDPs should support that) and follows our current documentation and recommendations (e.g. attribute resolution, attribute release) there's nothing extra to do to enable access to student discount platforms via InAcademia.

If on the other hand your IDP is not yet following our documentation or is not up to date with it it may be best to change that and update your configuration to match our best practices documentation. That seems a better investment than trying to add ad-hoc configuration rules for yet another individual service.

If you insist on not following any of our documentation it's pointless to provide even more documentation specifically for those not following our documentation, but anyway:

The entityID of the InAcademia service is https://inacademia.org/metadata/inacademia-simple-validation.xml (which you could also have found out yourself, of course) and you'll at least have to release an affiliation and an identifier to the service. The appropriate identifier for such a service is the SAML Pairwise-ID, so release that if you have it. (If you don't maybe start by following our documentation on how to generate it and then on how to scalably release it, too.) Otherwise the SAML Subject-ID or even an eduPersonPrincipalName would also be acceptable (though less preferred) because InAcademia pseudonymises any data it hands over to connected merchants, anway.