Evolution of AuthN and AuthZ for research collaboration

(Nikolaos Liampotis)

• Is there a technical definition for AARC BPA complaints?
• Adopting this proxy beta protection but it’s not just a proxy but it’s also a set of guidelines that you need to follow to be a BPA complaint… Apart from the technical part, there are also proxy-related guidelines, there are also assurance profiles that are based on RAF. There is also guidance for combining assurance in case of linked identities. Having a … that is based on proxy is one side of the story but it’s also important to follow this guidance in order to be able to…information between different implementations. What we’ve come up in AARC 2 provide an updated view that shows how this can work in the case where the … needs to access resources that offered by different infrastructures. We have the notion of the community AAI which allows presenters to use their credentials from social providers in order to access services that are operated by the community. Apart from those services that all need to be connected to a single community AAI proxy, there are also generic services. Generic services are not offered to a single community, they are targeting marketing communities, so these generic services might need to be connected to different community AIs…the use case when we have sensors or services … offered by generic infrastructures. Usually, the generic infrastructures are also protected by proxy, so again here we have e-infra SD proxies, which are connected to the community AI and maybe access to the infraservices behind me. The question is how compatible it is with the BPA 2017 version. If you can see on this picture, this is very much compatible with the AARC BPA 2017…and the end services and again some services, which are protected by proxy. It is an evolution rather than revolution…. also, if there are possibilities of an infra proxy. We have the user ID services. They only have the proxy and of course the authorization. It’s not just about having a proxy. These are some of the guide lines that are already published. Another achievement during the 2nd phase of the project was that we managed to …the BPA into the authorization layer, because in the first version of the BPA, authorization was just a … that didn’t provide much detail. Now we have identified the main authorization models that our BPA complaint architecture is supposed to support.

Centralized policy information point – pass on this info to the end services; take the decisions by themselves Centralized policy management and decision making – for services that rely on a proxy to give them the decision which is expressed in a form of capabilities Centralized policy management and decision making and enforcement – extension of the previous model; the proxy enforces the decision exactly at the user; the proxy can suspend the user

We haven’t finished everything, there are a lot of items which need to be finalized by the end of April.

· Expressing affiliation info - So we are kind of in the phase of finalizing the guidance for expressing affiliation information. This is the last bit of the usual information for which there is no standardized way of communicating this info to services. We generally try to make use of existing standards. For example, this working document on definition information is proposing the use of eduScope affiliation… via passion external affiliation. We can distinguish between 2 types of affiliations. We need 2 attributes that are able to convey this information to the services · Best practices for integrating OIDC/OAuth2 based services – the idea is to provide best practices for conveying the user information using claims, because we have the standard claims for the OIDC specification, but this cannot address the needs of servers because you have affiliation information, assurance information, group membership information, capabilities … standard claims to support this information · IdP Discovery/ Hinting – tries to solve the usability issue which is an effect of the proxy because the user goes to the service, then it might be related to the infra proxy, where they would need to select their community IdP, then they would go to their community IdP proxy where they would be asked to select their Home IdP; we want to provide some mechanism that allows end services to signal, to provide a hint on the IdP that the user will use, so the IdP discovery process is transparent to the user · (De)provisioning – we need a way to signal the provisioning of user … information · Accessing resources on behalf of users in multi-proxy environment – in an environment where there is a singe proxy there are different standard flows one can use, but in a multi-proxy environment this is more tricky because if we don’t want to end up with end services having to connect to a different service on a different proxies we need to extend the flow that allows the validating tokens that are issued by different operation servers

Q: Do you think there is something we’re still missing and needs to be included in the working documents for the remaining of the hard project A: AuthN

• infra proxy translates between the groups that are … and the groups that are understood by the protected info services; so AuthN is distributed to both the community and the infraproxy; depends on the AuthN model, there are different scenarios Q: Is there someone outside the EU that is working on different proxy implementations; the different solution you have; is there anything known outside of the EU, e.g. USA? A lot of people using key drop; we can’t give guidance; some guidance is necessary; there was document like this in the past but it’s out of date; Are there people who are working on giving software guidance? A: A map of the BPA that will be able to show the software solutions; a catalog of the software that can be used;

AARC BPA complaint which a lot of people are claiming, and a lot of people misunderstand; to be able to know how to be compatible with it is important.; we only have guidelines, no requirements; there are only few things that should be done; it shouldn’t be too complicated - certain things are optional, however things like group syntax and being able to stay in your own domain are important

• someone must certify this –> AEGIS is a group that does that; AEGIS is an official way AEGIS is collecting information, but it’s only available to AEGIS members Everybody can join if they run an infrastructure, and AEGIS might even like this; and then if they are BPA complaint, they tell them Notification sign - good idea? (seal of approval) AEGIS are working on lists for the community and which guidance is relevant for which community; –> They should start with the FAQ list –> careful about who should be BPA complaint; –> This could be the official point of reference (checklist), AEGIS; –> People usually pay for getting a seal; Q: Is there outside of big infrastructures in EU that because of the IOSC they need to do this with the proxy, someone outside of EU that has those models?

You would have people in WWLG which are both in the US and Europe and they would have to work together; there are separate infrastructures that need to exchange information –> What should be the way of expressing this? –> the translation is important; –> It is essentially the same scenario we have with the multiple proxies. –> Deprovisioning for non-lab credentials