INDIGO AAI An overview and status update!

Transcription

1 RIA INDIGO DataCloud INDIGO AAI An overview and status update! Andrea Ceccanti (INFN) on behalf of the INDIGO AAI Task Force!

2 INDIGO Datacloud An H2020 project approved in January 2015 in the EINFRA call 11 M 30 Months (Apr > Sept. 2017) Who: 26 partners from 11 European countries What: develop an open source platform for computing and data targeted at multi-disciplinary scientific communities Where: provisioned over hybrid (public and private) e-infrastructures 2

3 INDIGO objectives Provide seamless access to data and computing provisioned over private, public or hybrid e- infrastuctures Leverage and extend current Cloud technologies, fill the gaps, provide tools and services to support scientists, software developers, resource providers and e-infrastructures for the efficient exploitation of computing, data and network technologies: Better software for better science 3

4 The INDIGO approach Based on Open Source solutions widely supported by big communities whenever possible exploit general solutions instead of specific tools/services increased sustainability ensure that the framework offered to final users, as well as to developers, will have a low learning curve ease of adoption and integration 4

5 Example use case scenario Computational Portal as a service 5

6 Example use case scenario Computational Portal as a service A scientific community has an application (or a set of them) that should be accessed through a portal, and: Requires a dynamically instantiated batch queue as a back-end Exhibits unpredictable workload Supports multiple access profiles Should be deployable through Cloud providers, with features such as redundancy and elasticity May require cloud-bursting to other infrastructures Should support access to external reference data and data local to the application, which must be accessible in a distributed way 6

7 The AAI problem Heterogeneous authentication/authorization mechanisms but we need common AAI ground, persistent identifiers, support for delegation, easy integration in services To be effective, security should not impact usability we need support for federated identities We need AAI solutions that allow our users to manage authentication and authorization on dynamically provisioned resources in a secure way Without being security experts! INDIGO-DataCloud RIA

8 INDIGO AAI: approach How can we have common AuthN and AuthZ primitives that just work across several distributed infrastructures? Which tools should we provide to our users so that they have complete control on how AuthN and AuthZ is configured and performed on the resources (assembled from distributed providers) they will use for their research? How do we avoid reinventing the wheel? How do we exploit what is already available, leverage existing standards and ensure that what we develop is sustainable? INDIGO-DataCloud RIA

9 INDIGO AAI: main challenges Authentication/Identity Supporting federated authn mechanism Persistent INDIGO identifier Offline access Authorization Orthogonal to AuthN Attribute-based Dynamic Consistent across heterogeneous infrastructure Delegation 9

10 INDIGO AAI architecture 10

11 Authentication Slide courtesy of Paul Millar 11

12 Identity layer challenges Support multiple AuthN mechanisms SAML, OpenID-Connect, X.509 Harmonise Identities One INDIGO identity linked to multiple user authn mechanisms Persistent INDIGO identity identifier Link group membership and other attributes to INDIGO identity similarly to what VOMS does with VO attributes and X.509 certificates, but in a way that is orthogonal to the AuthN mechanism used 12

13 Identity in INDIGO The INDIGO identity layer speaks OpenID-connect The INDIGO Identity and Access Management Service is an OIDC provider Authenticates users with supported AuthN mechanism SAML, X.509, OIDC Provides to RP access to identity information through standard OIDC interfaces Can be seen as a first credential translation step 13

14 Why OpenID connect Standard and widely adopted in industry Don t reinvent the wheel Reduced integration complexity in relying services Lots of things we need are covered and standardized Dynamic Registration of clients/relying parties Token revocation Discovery Session management Distributed/Aggregated claims Mobile-friendly 14

15 INDIGO AuthN flow Access service INDIGO Service Marcus wants to access some service at INDIGO service Home IdP Indigo IAM

16 INDIGO AuthN flow Access service INDIGO Service INDIGO Services sees that Marcus is not authenticated, and redirects him to INDIGO IAM for authentication Home IdP Indigo IAM

17 INDIGO AuthN flow INDIGO Service redirect to IAM for AuthN Home IdP Indigo IAM

18 INDIGO AuthN flow INDIGO Service redirect to IAM for AuthN IAM lets Marcus choose how he wants to authenticate Marcus chooses his Home IdP Home IdP Indigo IAM

19 INDIGO AuthN flow INDIGO Service redirect to home IdP for AuthN Home IdP Indigo IAM

20 INDIGO AuthN flow INDIGO Service Home IdP authenticates Marcus and sends back an AuthN assertion Home IdP Indigo IAM

21 INDIGO AuthN flow INDIGO Service IAM validates assertion. Marcus is now authenticated at IAM. Home IdP Indigo IAM

22 INDIGO AuthN flow INDIGO Service send back to IS OIDC authz code Home IdP Indigo IAM

23 INDIGO AuthN flow INDIGO Service exchange authz code for OIDC ID-token access token Home IdP Indigo IAM

24 INDIGO AuthN flow INDIGO Service IS validates ID-Token. Marcus is now authenticated at IS Home IdP Indigo IAM

25 INDIGO AuthN flow INDIGO Service IS requests additional profile information about Marcus from IAM user info endpoint Home IdP Indigo IAM

26 IAM Status Implementation based on the Mitre OpenID connect server reference implementation Java-Spring-Server Certified open source OIDC server implementation Actively maintained also used as the base of the Shibboleth IdP OIDC implementation Main OIDC functionality covered Token issuing and management, Client registration/discovery, Scope management Simple and usable management web application provided 26

27 IAM Authentication status OAuth client/token/consent management Local username/password authentication External SAML IdP authentication Identity orthogonal to AuthN Group information available via OIDC External OIDC IdP authentication Certificate authentication AuthN mechanism exposed via OIDC done done done done done in progress in progress in progress 27

28 IAM Authentication status OAuth client/token/consent management Local username/password authentication External SAML IdP ETA: authentication June release Identity orthogonal to AuthN Group information available via OIDC External OIDC IdP authentication Certificate authentication AuthN mechanism exposed via OIDC done done done done done in progress in progress in progress 27

29 Authorization Slide courtesy of Paul Millar 28

30 Authorization challenges Consistency Provide solutions to dynamically define, propagate, compose and enforce authorization policies on resources at various levels of the infrastructure Scalability in a scalable way Manageability supporting cross-organizational user, group and privilege management as well as enrollment and registration flows Integration in a way that produces minimal integration friction in services 29

31 Authorization challenges Consistency Provide solutions to dynamically define, propagate, compose and enforce authorization policies on resources at various levels of the infrastructure Scalability in a scalable way Manageability supporting cross-organizational user, group and privilege management as well as enrollment and registration flows Integration in a way that produces minimal integration friction in services 30

32 AuthZ in INDIGO: OAuth 2 A standard framework for delegated authorization to access HTTP protected resources Decouples AuthZ from AuthN Natural solution for delegated authorization in HTTP services 31

33 Authorization in INDIGO INDIGO services are HTTP APIs protected by an OAuth Authorization Service In order to access resources, a client needs an access token OAuth scopes used to target the token to specific APIs/ services provide hints for finer grained authz Identity layer provides other attributes as base for AuthZ decisions 32

34 Scope-based authorization Each service registers the supported scopes when it registers at the authorization server (AS) The AS maintains policies that determine which client is authorized to request a given scope The request for a given scope is authorized by the user through the OAuth consent mechanism but is possible to define trusted, whitelisted client services for which user consent is not requested Authorization is enforced at the target service considering scopes and other relevant information 33

35 Scope-based authorization Indigo IAM Registered Scopes js:submit_job js:cancel_job ss:read ss:write Access SG Job Scheduler SG Science Gateway Storage Service

36 Scope-based authorization Indigo IAM Registered Scopes js:submit_job js:cancel_job ss:read ss:write Redirect for AuthN & consent Job Scheduler SG Science Gateway Storage Service

37 Scope-based authorization Indigo IAM Authorization requested Scientific Gateway would like to: Registered Scopes js:submit_job js:cancel_job ss:read ss:write Redirect for AuthN & consent know your identity submit jobs on JS on your behalf read files from SS on your behalf write files on SS on your behalf Cancel Accept SG Science Gateway Storage Service

38 Scope-based authorization Indigo IAM Registered Scopes js:submit_job js:cancel_job ss:read ss:write Returned id token & access token Job Scheduler SG Science Gateway Storage Service

39 Scope-based authorization Indigo IAM Registered Scopes js:submit_job js:cancel_job ss:read ss:write Submit job Job Scheduler SG Science Gateway Storage Service

40 Scope-based authorization Indigo IAM Registered Scopes js:submit_job js:cancel_job ss:read ss:write Submit job Job Scheduler Job scheduling is authorized by the js:submit_job scope SG Science Gateway Storage Service

41 Scope-based authorization Indigo IAM Registered Scopes js:submit_job js:cancel_job ss:read ss:write Job Scheduler Read job output data SG Science Gateway Storage Service

42 Scope-based authorization Indigo IAM Registered Scopes js:submit_job js:cancel_job ss:read ss:write Job Scheduler Read job output data Data access is authorized by the ss:read scope SG Science Gateway Storage Service

43 Fine-grained authorization OAuth scope-based AuthZ provides a first coarse grained authorization step Finer-grained authorization can be implemented at services on top of this step taking into account User identity attributes Service authorization policies Collaboration/VO policies Consistent authorization across services is enabled by callouts to the Argus authorization service 40

44 Fine-grained authorization Indigo IAM Authz! Service Collaboration Policies Policy distribution Read job output data Storage service SG Science Gateway AuthZ Callout Authz! Service Local Policies

45 Authorization status OAuth2 authorization First level of access control; Mitre OAuth2 implementation already provides most of what is needed for INDIGO use cases Some development now focused on filling the gaps e.g., providing the concept of service groups, in order to simplify OAuth scope management Fine-grained attribute-based authorization services on attributes provided by the OIDC identity layer; really service-dependent Consistency across services via callout to Argus is the scope of the second year of the project 42

46 Delegation 43

47 OAuth delegation 44

48 OAuth chained delegation? 45

49 OAuth token exchange OAuth flow to implement chained delegation among services! Under standardization Supports impersonation and delegation 46

50 IAM OAuth token exchange MitreID connect already has some non-standard form of chained delegation, which however does not (in its current form) solve our use cases i.e. delegate offline access to identity information across services Plan is to extend MitreID connect implementation with a subset of the OAuth token exchange standard i.e., the minimum functionality needed to support our use cases! ETA: June 47

51 The Token Translation Service What about integration with services that do not speak OpenIDconnect? The INDIGO Token Translation Service (TTS) maps INDIGO identity & attributes to external service credentials provides an extensible plugin-based architecture, and will initially support translations to ssh keypair S3 keys X.509 certificate 48

52 Timeline Architectural and design deliverables done See for all INDIGO deliverables! Development activities ongoing! First official INDIGO release expected end of July, 2016 but we will start make available services as soon as they are ready enough to be tested 49

53 Thanks! Questions?! 50