ABFAB and OpenStack(in the Cloud)

19  Download (0)

Full text

(1)

ABFAB and OpenStack (in the Cloud)

David W Chadwick

University of Kent

(2)

Authentication in OpenStack

Trust

Relationship Keystone

(3)

Federated Authn with External IdPs

Trust

Relationship External IdP

(4)

ABFAB – SAML EAP Profile

Picture courtesy of BeSTGRID University of Auckland, NZ

(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

(6)

Key Features of Protocol Independent

FIM

• Modular Design

• Most functionality is provided by protocol independent code we added to Keystone

– Trusted IdP Policy – says which IdPs are trusted and which protocol each speaks

– Attribute Issuing Policy - says which IdPs are trusted to issue which identity attributes to users

– Attribute Mapping Policy - maps from IdP issued identity attributes into Keystone’s internal roles, projects and domains

• Protocol plug-in modules handle the Protocol Specific Features of federated login

– IdP Request preparation

– idP Protocol negotiation (optional) – IdP Response verification

(7)

FIM Protocol Module Output

• Federation wide Unique ID of end user e.g.

uid@idp

• Set of {Set of user identity attributes and

name of IdP that asserted them}

– Caters for future attribute aggregation

– LoA can be included as an identity attribute

(8)

Problem 1 – User Access Rights

• Not all users from one IdP should have the same access rights at an SP (e.g. OpenStack cloud)

• Different users from different IdPs may 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 IdPs may have the same identity attributes (or roles)

– Requires updating the IdPs or creating a VO service

• Solution 3. Add attribute mappings at the SP based on the user’s unique federation ID and identity attributes

(9)

Problem 2 – Updating the IdP Asserted

Attributes

• IdPs will not assert the attributes that SPs need

• Organisational IdPs typically 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 authz to be added to corporate LDAP servers

• Federated Solution – standardise a set of user identity attributes that all IdPs will 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)

(10)

What About ABFAB Communities of

Interest?

• A CoI is a group of SPs and IdPs that have

agreed to cooperate to provide access to a

specific set of services only to those users

within a particular community

• CoIs can be layered on top of the base Trust

Router infrastructure to allow selected access

to IdPs that have joined a specific group

(11)

CoIs vs. VOs

• A set of IdPs and SPs

• that co-operate to provide access to a specific set of services

• only to those users within a particular community

• CoI is at the IdP level so it is unclear if a subset of an

IdP’s users are in the CoI • CoI cannot be established

without IdP involvement

• A set of users

• from different organisations • that co-operate to share

resources

• for a common purpose

• Explicit that only a subset of users from an organisation (IdP) are in the VO

• VO needs to be established without IdP involvement

(12)

VO Solutions for OpenStack Cloud

• 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 IdP asserted

attributes into a Keystone groups (=VO roles)

(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 Cloud A Keystone Cloud C Cloud B Keystone

The VOMS manages info for multiple VOs • Members

• Roles

VO 1 VO Admin

Swift Swift Swift

List Upload Download

(14)

Adding a vo_auth Stage to the Keystone

Command Pipeline

• All OpenStack services are designed with a configurable command pipeline

• When vo_auth sees 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

Request Response Token Auth VO Auth Admin Token Auth XML Body JSON Body Keystone Service VOMS Admin VOMS VO AdminVO Admin VO Admin Sites Roles Members

(15)

vo member

KeyVOMS Client

KeyVOMS Architecture Diagram

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

(16)

Fe

Integrating VO Management into Keystone

• Use the federation attribute mapping service to form VO roles/groups

IDP 1 IDP 2 User 1 User 2 OpenStack Some VO Keystone Attribute Mapping Keystone Groups Id Atts A Federation

(17)

Mapping Issue

• VO Administrator typically does not know

what attributes or unique ID the IdPs will

assert for each VO member

• Neither does the user

– unless it is a globally unique name like ABFAB

Network Access Identifier - username@realm

(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 IdP asserted ID to group name

(19)

Figure

Updating...

References

Related subjects :