ABFAB and OpenStack(in the Cloud)

Transcription

1 ABFAB and OpenStack(in the Cloud) David W Chadwick University of Kent 1

2 Authentication in OpenStack Keystone User Trust Relationship Swift/Glance etc. 2

3 Federated Authnwith External IdPs External IdP User Trust Relationship Keystone 3

4 ABFAB SAML EAP Profile Picture courtesy of BeSTGRID University of Auckland, NZ 4

5 Trust -an Indispensable Component of FIM Trust in Authentication SPs must have a list of trusted authenticating authorities (IdPs, CAs etc.) SPs might have different mechanisms for this e.g. PKI to authenticate services and IdPs to authenticate end users Trust in Identification SPs must have a list of which trusted authorities are trusted to issue which identity attributes (types and values) Trust in Authorization SPs may want a set of locally understood authorization attributes so will need attribute mapping rules that map from externally issued identity attributes to local authz attributes SPs may want details of trusted external PDPs that will make authz decisions for them 5

6 Key Features of Protocol Independent FIM Modular Design Most functionality is provided by protocol independent code we added to Keystone Trusted IdPPolicy says which IdPsare trusted and which protocol each speaks Attribute Issuing Policy-says which IdPsare trusted to issue which identity attributes to users Attribute Mapping Policy -maps from IdPissued identity attributes into Keystone s internal roles, projects and domains Protocol plug-in modules handle the Protocol Specific Featuresof federated login IdP Request preparation idp Protocol negotiation (optional) IdP Response verification 6

7 FIM Protocol Module Output Federation wide Unique ID of end user e.g. Set of {Set of user identity attributes and name of IdP that asserted them} Caters for future attribute aggregation LoAcan be included as an identity attribute Validity time of asserted identity 7

8 Problem 1 User Access Rights Not all users from one IdPshould have the same access rights at an SP (e.g. OpenStack cloud) Different users from different IdPsmay have the same access rights at an SP Solution 1. Give different users different identity attributes By updating the IdP Solution 2. Create a Virtual Organisation (VO) where different users from different IdPsmay have the same identity attributes (or roles) Requires updating the IdPsor creating a VO service Solution 3. Add attribute mappings at the SP based on the user s unique federation ID and identity attributes Requires updating the SP 8

9 Problem 2 Updating the IdPAsserted Attributes IdPs will not assert the attributes that SPs need Organisational IdPstypically store user s attributes in corporate LDAP servers, and these are fixed for use by the organisation Its very difficult (almost impossible?) for SPs to get the specific attributes they need for authzto be added to corporate LDAP servers Federated Solution standardise a set of user identity attributes that all IdPswill issue and all SPs will consume e.g. EduPerson schema Grid Solution -the Virtual Organisation Management Service (VOMS) that allows a VO administrator to give tailored roles to VO users (from different organisations) Need attribute aggregation or VOMS to become an IdP 9

10 What About ABFAB Communities of Interest? A CoIis a group of SPs and IdPsthat have agreed to cooperate to provide access to a specific set of services only to those users within a particular community CoIscan be layered on top of the base Trust Router infrastructure to allow selected access to IdPsthat have joined a specific group 10

11 CoIsvs. VOs A set of IdPsand SPs that co-operate to provide access to a specific set of services only to those users within a particular community A set of users from different organisations that co-operate to share resources for a common purpose CoIis at the IdPlevel so it is unclear if a subset of an IdP susers are in the CoI CoIcannot be established without IdP involvement Explicit that only a subset of users from an organisation (IdP) are in the VO VO needs to be established without IdP involvement 11

12 VO Solutions for OpenStackCloud At least two different designs for this Have an external VO management system (VOMS) Modify Keystone pipeline to aggregate attributes from this Integrate VO management into Keystone Since Keystone already assigns roles/projects to users or groups, extend its capabilities to assign them to VO members, by mapping IdPasserted attributes into a Keystone groups (=VO roles) 12

13 External VOMS The Keystone project concept extended to VO projects Project names starting with "VO." are VO projects Keystone and Swift clients and servers modified to demonstrate the management of container access using VO roles List Upload Download Cloud A Cloud B Cloud C Keystone Keystone Keystone Swift Swift Swift VO 1 VO Admin VOMS w/ VOMS Admin 7 April Internet 2 Global Summit, Denver, CO The VOMS manages info for multiple VOs Members Roles Participating Sites

14 Adding a vo_authstage to the Keystone Command Pipeline Request Response Token Auth VO Auth Admin Token Auth XML Body JSON Body Keystone Service VO Members Admin VO Admin Roles Sites VO Admin VOMS Admin VOMS All OpenStackservices are designed with a configurable command pipeline Whenvo_authsees a project name with the VO. prefix, it consults the VOMS Verifies user s VO membership Returns member s VO role and other sites participating in this VO 14

15 KeyVOMS Architecture Diagram voms_admin KeyVOMS Client vo_admin KeyVOMS Client vo member KeyVOMS Client request reply authenticate vo credentials w/ service catalog validate validated KeyVOMS VO VO Foo Service Catalog Service Endpoint register Endpoint VO PEP Service eg. SWIFT KeyVOMS Client vo_site_admin VO Resource Provider 15

16 Integrating VO Management into Keystone Use the federation attribute mapping service to form VO roles/groups Attribute Mapping User 1 IDP 1 Fe Id Atts Keystone Groups Keystone IDP 2 User 2 A Federation Some VO OpenStack Service 16

17 Mapping Issue VO Administrator typically does not know what attributes or unique ID the IdPswill assert for each VO member Neither does the user unless it is a globally unique name like ABFAB Network Access Identifier - username@realm Solution VO Role Registration by Invitation 17

18 Invite Users to Register to a VO Role VO Administrator creates a Keystone group (VO role) and gives it permissions (domains, projects, roles) Sends group name and PIN to invited VO members VO member authenticates to Keystone via his/her IdP Asks to join group and provides PIN Keystone automatically creates a mapping rule from user s unique IdPasserted ID to group name 18

19 Any Questions 19