Answers to a series of Frequently Asked Questions (FAQs) are provided below. If you have a question that is not mentioned in the list and you would like an answer, please let us know!

What is the difference between AAI and Federated Access? 

Federated Access is authentication across separate administrative domains by relying on shared technologies and policies  - i.e. users from one organisation accessing services from another. AAI encompasses both scalable Federated Access and access control, such as user management and authorisation. 

How can I let researchers authenticate to the services in my infrastructure with eduGAIN?

You will need to run a SAML Service Provider (this is typically the entry point to your AAI) and publish its metadata to a federation that is part of eduGAIN. See https://edugain.org/participants/how-to-use-edugain/ 

How can my researchers authenticate to services in eduGAIN?

You will need to publish a SAML Identity Provider into eduGAIN. Ensure that you are authoritative for each attribute that you issue about a user - see technical guidelines below for how to aggregate information from researchers’ home organisations and your own sources.

How can I use the European Open Science Cloud (EOSC)?

By this question you may mean “How can I log into the EOSC EU Node and get credits to use its services”. If that’s the case please see https://open-science-cloud.ec.europa.eu/support/frequently-asked-questions/user-credits. In short - your Identity Provider will need to 1) be trusted for authentication to EOSC e.g. via eduGAIN and 2) assert that you are a Faculty or Employee/Staff of your Home Organisation by using the eduPersonAffiliation attribute.
If you are acting as a proxy to users coming from a different home organisation that will be accessing EOSC using your own IdP you may want to propagate these values. Please see “AARC-G003 Attribute aggregation” for guidance on aggregation of scoped attributes https://aarc-community.org/guidelines/aarc-g003/

Alternatively you may mean “How can I enrol my AAI and research services as an EOSC Node?” and enable cross-node authentication and authorisation. At the moment a first stage enrolment of 13 communities are being enrolled and a second phase will start shortly. More information will be provided in the future. It is already a good idea to build your AAI keeping in mind its future interoperability needs, though, so try to support the AARC guidelines to get a head start.

Isn’t SAML considered "dead"?

Generally, yes. OIDC has surpassed SAML for granting access to services - particularly because it supports non-web and API use. SAML, however, is still necessary for the connection between SAML Home Organisations (i.e. those in eduGAIN) and AAIs. A new OIDC equivalent for scalable identity federation is under active development but is not yet widely adopted.

Should I require users to register for MFA?

Some Home Organisations in eduGAIN already assert whether an authentication was performed with MFA or not. Wherever possible this should be accepted as proof of MFA to avoid your researchers managing multiple MFA tokens. Other home organisations, however, do not. If you want to ensure that all researchers use MFA (perhaps you are required to for legal reasons or simply as a good security practice) you will need to also provide your own MFA registration workflow.

Why should my community implement an AAI?

When a research community sets up a common AAI, people can use their university or institute login to access services in the community. It makes working across institutions feel a lot less complicated, because you don’t have to ask for new logins or wait around for someone to approve your access. There’s also a level of trust that comes with it. If everyone is on the same system, you know the same rules and security standards apply everywhere and you can introduce things like two-factor authentication in a uniform way without every service having to figure it out on their own. For the people running services, it’s a big relief too. They don’t have to spend time and money building their own user management and login systems or maintaining separate user databases. They just connect to the shared infrastructure, and it grows naturally as new services join. On a bigger scale, this kind of common AAI ties the community into international infrastructures. It makes data and services more interoperable and that means research outputs stay accessible for the long term, and the whole ecosystem becomes more sustainable.

How do I convince my home organisation that federated AAI can be trusted?

Historically Identity Providers have been hesitant to release user attributes to services in eduGAIN if there are no bilateral agreements in place. There are various trust marks that have been set up to address this problem. Entities in eduGAIN can assert Sirtfi to declare their support of good practices in operational security and incident response. At the AAI level a similar trustmark has been established, Snctfi, that asserts that the AAI and all services behind it comply with a set of policies. Additionally, it is up to service (and AAIs) to ensure that they do not request more attributes than strictly necessary - the Research and Scholarship attribute bundle has been developed for this purpose https://refeds.org/category/research-and-scholarship

Which groups or mailing lists can I join to stay connected to other communities?

We strongly recommend following FIM4R (Federated Identity Management For Research) https://fim4r.org . This group has been active since 2012 and spanned multiple different projects that have come and gone. 

Is there a financial benefit to using an AARC compliant AAI and avoiding a common commercial AAI?

Although difficult to quantify, in many situations the long term costs may be reduced. Using a common commercial AAI solution (such as those provided by Google or Microsoft) can expose you to certain risks: 

  • Lack of open access: Research is often global and neutral, allowing researchers to collaborate despite wars or political perspectives. Relying on a commercial product may put this at risk due to lack of control over the network access or terms of use. In the event of incompatibility, a workaround may be costly or impossible - putting the research itself at risk.
  • Vendor lock-in: The cost to migrate from one AAI to another is substantial and frequently underestimated. One large scale research community took 6 years to migrate their 12,000 services from one AAI to its successor, incurring a significant cost to that community due to time spent configuring systems. The AAI and the unique identifiers it provides should be viewed as a valuable asset to a research community. Being exposed to vendor lock-in in an AAI is a significant risk - if prices are suddenly increased a research community will have to find the technical resources to migrate or pay the fee.
  • No labels