The Virtual Organization Concept for Authorization Management

in Federated Clouds Dr. Craig A. Lee

The Aerospace Corporation

OpenStack Design SummitHong Kong, November 8, 2013

Prof. David ChadwickThe University of Kent

Introduction and Organization• Challenge: Securely manage resource sharing across a dynamic,

distributed IT environment– Secure sharing of data & services

• Some Use Case Drivers– Disaster Response– Global Earth Observation System of Systems (GEOSS)– Feature Film Production

• How to Address These Requirements:– Federated Identity Management (FIM), and– Virtual Organizations (VOs): a security and collaboration context not

exclusively associated with any one physical organization or site• Fundamental Technical Approach to FIM in OpenStack

– Protocol Independent Infrastructure – Plug in protocol specific modules

• Fundamental Technical Approach to VOs in OpenStack– Trusted Third-Party Authority Assigns VO attributes– Service Provider Assigns privileges to VO attributes

2

Port-au-Prince, Haiti

First RespondersStakeholder Cloud #1 Stakeholder Cloud #2 Stakeholder Cloud #3

CloudOn-Demand Federated Cloud

Disaster Response Using Federated Clouds

3

NGA/NCOIC GeoInt Community Cloud Prototype (GCC) demonstratedthe integration of cloud resources and geospatial information tools in response to a Haiti-like earthquake event. Participants: Aerospace,

NJVC, Boeing, Raytheon, Telos, Winthrop Mgmt, OGC.

Global Earth Observation Systems of Systems (GEOSS)

• Ten year plan to build out architecture with data management tools for full and open exchange of data, metadata and data products, recognizing national and international policies and legislation.• http://www.earthobservations.org

Cloud-based Feature Film Production• The Entertainment Technology Council has started a cloud working

group to determine how feature film production could use cloud computing

• ETC (www.etcenter.org) is a non-profit industry consortium hosted at the USC School of Cinema/Television to promote technology adoption for the entertainment industry

• Modern feature film production is rapidly becoming completely digital• Even films that are not "action films" can involve many digital effects

that are supplied by different post-production houses• Film producers could establish a VO to manage the production of a

specific film:• Various post-production houses would be allowed to join VO and given

specific authorization rights to read and modify specific data assets, i.e., "filmed footage”

• VO membership ended when post-production house finishes work• VO terminated when final film production is complete

• Use Federated Identity Management, in which• Trusted third parties assert the identity attributes of the users

– One of more of these may be unique identifiers (but not essential for group access to a resource)

Three Stages of FIM:1. Federated Authentication

One or more trusted external entities authenticate users for the CSP2. Federated Identification

One or more trusted external entities assert the identity attributes of users3a. Authorization

CSP authorizes users based on their validated identity attributes or3b. Federated Authorization

A trusted entity makes authorization decisions for the CSP

How to Address These Requirements?(from the perspective of a cloud service provider)

6

• Trust in Authentication– CSPs must have a list of trusted authenticating authorities (IdP, CAs etc.)– CSPs might have different mechanisms for this e.g. PKI to authenticate

services and IdPs to authenticate end users• Trust in Identification

– CSPs must have a list of which trusted authorities are trusted to issue which identity attributes (types and values)

• Trust in Authorization– CSPs may want a set of local attribute mapping rules that map from

externally issued identity attributes to locally understood authorization attributes

– CSPs may want details of trusted external PDPs that will make authz decisions for them

Trust - an Indispensable Component of FIM

7

• 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 CSPs to get the specific attributes they need for authz to be added to corporate LDAP servers

• Solution - the Virtual Organisation (VO)

Problem: IdPs Won’t Assert Attributes that CSPs Need

8

Federated Authorization Management with Virtual Organizations (VOs)• A VO is a security and collaboration context not exclusively associated with any

one physical organization or site– Participating partners agree upon structure, rules and processes– A VO partner can be a single person, a group or an entire organization

• A VO has members that are assigned roles and/or attributes– Membership roles or attributes grant specific capabilities within a given VO as

determined by each resource/service provider

• Partners participating in a VO contribute resources, i.e., data and services– They retain complete control over their own resources!– Access by VO members can be modified or revoked at any time by both the VO

administrator and the resource administrator

• VOs enable federated, community clouds by being the Trusted Third Parties who assert user identity attributes, and who may authenticate users as well

9

Intellectual Heritage:VOs Developed for Global Grids

10

Worldwide LHC Computing Grid routinely runs over 200 VOs (Dashboard website: http://dashb-earth.cern.ch)

VOs and Federations

• A federation can contain many VOs– E.g. a national federation could host multiple VOs– IdPs in the federation may authenticate users and VOs

provide the user’s attributes to the SP

• A VO can be a federation– All federation partners are partners in the VO. The VO

decides how authentication will take place and identifies the users to SPs

• A VO can span multiple federations– To realize this, interconnected federations are needed

first, such as eduGAIN. The federation IdPs will authenticate the users and the VO provides the identity attributes

Adding VOs to OpenStack

At least two different designs for this:

1. External VO Management System (VOMS)– Approach used in current, operational grids

2. Integrate VO management into Keystone– Since Keystone already assigns roles/projects to users

extend its capabilities to assign them to VO members

12

Example of External VO Management System:NGA/NCOIC GeoInt Community Cloud (GCC) Prototype

13

• The Keystone project concept extended to VO projects– Project names starting with "VO." are VO projects– VO projects could be denoted by internal Keystone attribute

• 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

Haiti VOHaiti VO Admin

Swift Swift Swift

ListUpload

Download

Keystone

Adding a VO Auth Stage to the Keystone Command Pipeline

• All OpenStack services are designed with a configurable command pipeline• When AO 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

TokenAuth

VOAuth

AdminTokenAuth

XMLBody

JSONBody

KeystoneService

VOMS Admin

VOMS

VO AdminVO Admin

VO Admin

Sites

Roles

Members

Fe

Integrating VO Management into Keystone• Introduce an internal attribute mapping service

15

IDP 1

IDP 2

User 1

User 2

Id Atts 1

Id Atts 2

OpenStackService

Some VO

Keystone

AttributeMapping

Domain, project, rolesId Atts

Domain,

project, rolesA Federation

• Set of APIs for creating many to many mapping rules from sets of identity attributes to sets of keystone authz attributes• Identity attributes mapped differently for different VO members

Attribute Mapping in Keystone

Extending Keystone to be a VO Manager• Create a Mapping API

• Alternatively, Attribute Mapping could become a stand-alone OpenStack service

17

Keystone

AttributeMapping

Domain, project, rolesId Atts

External Mapping API

Domain, project, rolesId Atts

Another VO

VO User Authentication

Multiple ways of addressing this:

1. Keystone uses its existing authentication methods (e.g. un/pw)

2. Use an external PKI to authenticate users and send certificate and signed message to Keystone

3. Use federated authentication with IdPs

VOMS w/ Admin

VO.HaitiUserA: RoleASite: Clouds A, B

…VO.Haiti Admin

ContainerACL: UserA

ContainerACL: RoleA

Swift

…

Cloud A

Keystone

Keystone VO Client

Swift VO Client

UserA

GCC Example:User Authentication using Keystone with external VOMS

19

Role A Account:Service Catalogs and

AUTH_TOKENsfor all VO sites

ContainerACL: RoleA

ContainerACL: UserB

Swift

…

Keystone

Cloud B

UserB

Authn asRoleA

Un/pw

ContainerACL: UserA

ContainerACL: RoleA

Swift

…

Cloud A

Keystone

Keystone VO Client

Swift VO Client

UserA

Role A Account:Service Catalogs and

AUTH_TOKENsfor all VO sites

ContainerACL: RoleA

ContainerACL: UserB

Swift

…

Keystone

Cloud B

UserB

GCC Example: VO Container Access

21

List, Upload,Download

Local Admin Local AdminVOMS w/ Admin

VO.HaitiUserA: RoleASite: Clouds A, B

…VO.Haiti Admin

GCC Example:Using VO Roles to Manage Container Access

22

VO Roles

CivicEngineer

FirstResponder

Participating SiteAccessControl

Lists

MedicalData

BuildingPlans, Maps

End UserData

Read:Write:

Read:Write:

Read:Write:

LocalAdmin

Data containers could be made

available directly, or replicated

DataContainers

MedicalStaff

VO Members

Application Service Owner

VOMS

VOMS Admin

App VO w/ App VO Admin

Member Role

Site A, User k Data Processor

Site A, User m Data Processor

Site B, User n End User

Site AUTH_URL

Site A http://myclouda:5000/v2.0

Site B http://mycloudb:5000/v2.0

App User

Hypervisor

Hardware Server

App-level ServiceVirtual Machine Image

VO_PEP.py

1: InstantiateApp Service 3: A

uthn Use

r

4: Verify VO Membership5: VO Membership

Verified

7: R

eq A

pp S

vc10

: App

Svc

Res

ults

6: Use

r Authn

’d

AUTH_TOKENService Catalog• App Svc

Endpoint

8: Authz User

9: User Authz’d

Using VOs to Manage Access to Arbitrary App-Level Services

Service Catalog --- ---

--- ---

2: Register &AdministerEndpoint

App Service Endpointw/ reqd. VO Roles/Attrs

Keystone

Important, but Ancillary, Issues• Many VO management and administrative issues must be

addressed– Creating and terminating a VO– Joining and leaving a VO– Who is the VO Admin, and the VOMS Admin

• Common understanding of VOs– VO resources, roles, attributes and trusted VOMS– Data publishing and discovery– Semantic interoperability

• Granularity of data/resource protection– Resource protection carries an overhead– There will be a granularity at which resource protection overhead

becomes excessive and intolerable• Trust Federations

– Human organizations where common agreements are made in advance of need

– Existing Example: International Grid Trust Federation, www.igtf.net– Possible Analogy: International Disaster Response Trust Federation

24

Key Design Issues for VOs in OpenStack• How to store the VO attributes

– As separate user entries with VO attributes (as per VOMS)– As a set of general mapping rules (as per attribute mappings)

• How to Integrate VOs with multiple clouds– Authenticating identity credentials from different Identity Providers– Aggregating IdP attributes with VO attributes

• External VOMS DB vs. Peer-to-Peer Keystone VO DBs – External VOMS easier to implement, quicker authz revocation process, but single

point of failure– P2P doesn’t rely on third party VOMS, not a single point of failure, but introduces

consistency issue, and authz revocation takes longer• Whether to check that user is a VO member or not

– Carries an overhead (esp. if external VOMS DB) so when to avoid it?• Ensure that VOs can be used by arbitrary application-level services

– Database access, RSS feeds, any kind of standard services, e.g., geospatial tools: Web Map Service, Web Feature Service, Web Coverage Service, …

• What should be at app-level vs. infra-level, i.e., what should be in Keystone• Who manages the VO

– VO admin (distributed) or VOMS admin (centralised)• Infrastructure-level federation vs. application-level federation• Scalability

25

Current Implementations and Future Work

• University of Kent has Attribute Mapping in Keystone as described here• Aerospace Corp has external VOMS called from Keystone pipeline as

described here• European Grid Infrastructure (EGI) has initial OpenStack VO

– BUT important implementation differences exist• Uses existing EGI non-cloud VO and PKI infrastructure

• Currently no FIM or role support– Must use existing, common PKI infrastructure– All VO members get access to all VO resources

– Additional capabilities will be built-out in near future

• Open Geospatial Consortium’s (OGC) “Open Mobility” testbed project– Specifically targeting cloud-based collaboration for standards-based geospatial

tools, e.g., Web Map Server, Web Feature Server– http://www.opengeospatial.org/projects/initiatives/ows-10

• Building rough consensus on an OpenStack VO design

Thank you!

Questions?

All trademarks, service marks, and trade names are the property of their respective owners.