AAI WP 6 view Marco Fargetta marco Fargettact

AAI – WP 6 view Marco Fargetta (marco. Fargetta@ct. infn. it) INFN Catania

Different AAI for different users § WP 6 aims at developing application services for end users § They use applications and do not care about the execution platform § These could be different from service users/platform developers § E. g. , some applications need to deploy Paa. S services in advance and not at user request § Science Gateways and mobile applications should use the authentication that best fits their requirements § Access to remote facilities made with credentials provided by SG administrators § E. g. , robot certificate, token INDIGO-Data. Cloud 15/10/2021 2

2 ’. aut h. N Identity Provider Z th u. a ” 2 1. sign in User 6. get the results rack 3’/4’. t user SG Admin 15/10/2021 e. Token. Server Current AAI workflow in CSGF 3. create a proxy from an e. Token server with robot certificates 4. ex ec ute 5. ac ge t o tion ut pu t Local/ Grid/ Cloud 3

Current AAI workflow in CSGF § The SG portal drives both user authentication and authorisation § Authentication with SAML and authorisation using roles stored in a LDAP back-end § Tracking is needed to identify the user generating any interaction § EGI extension to include user names in robot proxies will simplify the tracking § The portal implements the user front-end and the abstraction layer for the applications § Not easy to integrate with mobile applications INDIGO-Data. Cloud 15/10/2021 4

Proposed improvements § Move the libraries for the infrastructure interaction into a separate service § The new service has to provide RESTful API’s for SGs and mobile applications § Integrate all the API’s of the Paa. S and Iaa. S components and add all further needed logic § Include other technologies to authenticate users on different e. Infrastructures § These should not require end-user explicit authentication § Extend the authorisation supporting different services § Role DB could be available in the Paa. S § Something like Microsoft Azure Active Directory Service § EGI LTo. S User Management Portal compatibility § Authorisation roles distributed inside SAML token (through AARC project) INDIGO-Data. Cloud 15/10/2021 5

Proposed architecture Community Identity Providers SGW INDIGO App n App 3 App 2 App 1 User Auth. Z WP 6 SGW 1 SGW n Auth. Z Could be the same API Frontend ? WP 5 WP 4 INDIGO-Data. Cloud IAM 15/10/2021 6

Proposed architecture § Communities are free to select any Auth. N/Auth. Z methods for their users § A reference implementation using SAML will be deployed by WP 6 in the general purpose SG § The Auth. Z service should contain the role(s) each user has in the SG § The SG is responsible to translate the roles to action in the infrastructure § Authentication to the e-infrastructure to be agreed with WP 4 and WP 5 INDIGO-Data. Cloud 15/10/2021 7

Conclusions § SG and mobile apps should not have any constraints concerning authentication; the “most open” possible § SG users can be different from Paa. S users INDIGO-Data. Cloud 15/10/2021 8

Thank you! Questions? INDIGO-Data. Cloud 15/10/2021 9