ABFAB and OpenStack (in the Cloud)

David W Chadwick

University of Kent

17 April 2014 Internet 2 Global Summit, Denver, CO

Authentication in OpenStack

2

Trust

Relationship

Swift/Glance etc.

Keystone

User

7 April 2014 Internet 2 Global Summit, Denver, CO

Federated Authn with External IdPs

3

Trust

Relationship

Keystone

External IdP

User

7 April 2014 Internet 2 Global Summit, Denver, CO

ABFAB – SAML EAP Profile

Picture courtesy

of BeSTGRID

University of

Auckland, NZ

47 April 2014 Internet 2 Global Summit, Denver, CO

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

57 April 2014 Internet 2 Global Summit, Denver, CO

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

67 April 2014 Internet 2 Global Summit, Denver, CO

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

• Validity time of asserted identity

77 April 2014 Internet 2 Global Summit, Denver, CO

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– Requires updating the SP

87 April 2014 Internet 2 Global Summit, Denver, CO

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)– Need attribute aggregation or VOMS to become an IdP

97 April 2014 Internet 2 Global Summit, Denver, CO

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

107 April 2014 Internet 2 Global Summit, Denver, CO

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

117 April 2014 Internet 2 Global Summit, Denver, CO

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)

127 April 2014 Internet 2 Global Summit, Denver, CO

External VOMS

13

• 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 CCloud B

Keystone

The VOMS manages info for multiple VOs

• Members

• Roles

• Participating SitesVOMS w/ VOMS Admin

VO 1

VO Admin

Swift Swift Swift

ListUpload

Download

Keystone

7 April 2014 Internet 2 Global Summit, Denver, CO

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

14

Request

Response

Token

Auth

VO

Auth

AdminTokenAuth

XMLBody

JSONBody

KeystoneService

VOMS Admin

VOMS

VO AdminVO Admin

VO Admin

Sites

Roles

Members

7 April 2014 Internet 2 Global Summit, Denver, CO

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 credentialsw/ service catalog

request reply

validatevalidated register

vo_admin

KeyVOMS Client

vo_site_admin

KeyVOMS Client

7 April 2014 Internet 2 Global Summit, Denver, CO 15

Fe

Integrating VO Management into Keystone

16

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

IDP 1

IDP 2

User 1

User 2

OpenStack

Service

Some VO

Keystone

Attribute

Mapping

Keystone GroupsId Atts

A Federation

7 April 2014 Internet 2 Global Summit, Denver, CO

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

• Solution – VO Role Registration by Invitation

177 April 2014 Internet 2 Global Summit, Denver, CO

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

187 April 2014 Internet 2 Global Summit, Denver, CO

Any Questions

197 April 2014 Internet 2 Global Summit, Denver, CO