The Virtual Organization Concept
for Authorization Management
in Federated Clouds
Dr. Craig A. Lee
The Aerospace Corporation
Prof. David Chadwick
The University of Kent
OpenStack Design Summit
Hong Kong, November 8, 2013
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
Disaster Response Using Federated Clouds
NGA/NCOIC GeoInt Community Cloud Prototype (GCC) demonstrated
the 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.
Stakeholder Cloud #1
Stakeholder Cloud #2
Stakeholder Cloud #3
On-Demand Federated Cloud
Cloud
3
Port-au-Prince, Haiti
First Responders
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
How to Address These Requirements?
(from the perspective of a cloud service provider)
•
•
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 CSP
2. Federated Identification
One or more trusted external entities assert the identity attributes of users
3a. Authorization
CSP authorizes users based on their validated identity attributes or
3b. Federated Authorization
A trusted entity makes authorization decisions for the CSP
6
Trust - an Indispensable Component of FIM
•
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
7
Problem: IdPs Won’t Assert Attributes that CSPs Need
8
•
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)
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
Worldwide LHC Computing Grid routinely runs over 200 VOs
(Dashboard website: http://dashb-earth.cern.ch)
10
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
•
•
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
Cloud B
Cloud C
List
Upload
Download
Keystone
Keystone
Keystone
Swift
Swift
Swift
Haiti VO
Haiti VO Admin
13
VOMS w/ VOMS Admin
The VOMS manages info for multiple VOs
• Members
• Roles
• Participating Sites
Adding a VO Auth Stage to the
Keystone Command Pipeline
Request
Response
Token
Auth
VO
Auth
Admin
Token
Auth
XML
Body
•
Members
VO
Admin
VO Admin
Roles
Sites
VO Admin
VOMS Admin
•
Keystone
Service
JSON
Body
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
VOMS
14
Integrating VO Management into Keystone
•
Introduce an internal attribute mapping service
Attribute
Mapping
User 1
IDP 1Fe
Domain, project, roles
Id Atts
Keystone
IDP 2
User 2
A Federation
Some VO
15
OpenStack
Service
Attribute Mapping in Keystone
•
•
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
Extending Keystone to be a VO Manager
•
Create a Mapping API
Another VO
Domain, project, roles
Id Atts
External Mapping API
Attribute
Mapping
Domain, project, roles
Id Atts
Keystone
•
17
Alternatively, Attribute Mapping could become a standalone OpenStack service
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
GCC Example:
User Authentication using Keystone with external VOMS
Cloud A
Cloud B
UserA
Keystone
VO
Client
Swift
Swift VO Client
UserB
Role A Account:
Service Catalogs and
AUTH_TOKENs
for all VO sites
Keystone
Keystone
Swift
Authn as
RoleA
Container
ACL: UserA
…
Container
ACL: RoleA
VO.Haiti
UserA: RoleA
Site: Clouds A, B
…
VO.Haiti Admin
VOMS w/ Admin
19
Container
ACL: RoleA
…
Container
ACL: UserB
GCC Example: VO Container Access
Cloud A
UserA
ACL: UserA
Keystone
Container
ACL: RoleA
Local Admin
21
UserB
Role A Account:
Service Catalogs and
AUTH_TOKENs
for all VO sites
Swift
…
List, Upload,
Download
Swift VO Client
Keystone
VO
Client
Container
Cloud B
Keystone
VO.Haiti
UserA: RoleA
Site: Clouds A, B
…
VO.Haiti Admin
VOMS w/ Admin
Swift
Container
ACL: RoleA
…
Container
ACL: UserB
Local Admin
GCC Example:
Using VO Roles to Manage Container Access
VO Members
Participating Site
VO Roles
Medical
Staff
Civic
Engineer
First
Responder
Access
Control
Lists
Read:
Write:
Data
Containers
Data containers
could be made
available directly,
or replicated
Medical
Data
Local
Admin
Read:
Building
Write: Plans, Maps
Read:
Write:
End User
Data
22
Using VOs to Manage Access to
Arbitrary App-Level Services
VOMS
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
Application
Service
Owner
AUTH_URL
Site A
http://myclouda:5000/v2.0
Site B
http://mycloudb:5000/v2.0
2: Register &
Administer
Endpoint
App User
AUTH_TOKEN
Service Catalog
• App Svc Endpoint
1: Instantiate
App Service
VOMS Admin
5: VO Membership
Verified
4: Verify VO
Membership
Keystone
8: Authz User
Service Catalog
----App Service Endpoint
w/ reqd. VO Roles/Attrs
-----
9: User Authz’d
VO_PEP.py
App-level Service
Virtual Machine Image
Hypervisor
Hardware Server
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
•
•
•
•
•
25
•
•
– 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
Current Implementations and Future Work
•
•
University of Kent has Attribute Mapping in Keystone as described here
•
European Grid Infrastructure (EGI) has initial OpenStack VO
Aerospace Corp has external VOMS called from Keystone pipeline as
described here
– 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.