1 / 26

The Virtual Organization Concept for Authorization Management in Federated Clouds

Dr. Craig A. Lee The Aerospace Corporation. The Virtual Organization Concept for Authorization Management in Federated Clouds . Prof. David Chadwick The University of Kent. OpenStack Design Summit Hong Kong, November 8, 2013.

gada
Download Presentation

The Virtual Organization Concept for Authorization Management in Federated Clouds

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Dr. Craig A. Lee The Aerospace Corporation The Virtual Organization Concept for Authorization Managementin Federated Clouds Prof. David Chadwick The University of Kent OpenStack Design Summit Hong Kong, November 8, 2013

  2. 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 Introduction and Organization

  3. 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 First Responders Stakeholder Cloud #3 Cloud On-Demand Federated Cloud Port-au-Prince, Haiti

  4. 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

  5. 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

  6. 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

  7. 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

  8. Problem: IdPsWon’t Assert Attributes that CSPs 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 CSPs to get the specific attributes they need for authz to be added to corporate LDAP servers • Solution - the Virtual Organisation (VO)

  9. 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 Federated Authorization Management with Virtual Organizations (VOs)

  10. Intellectual Heritage:VOs Developed for Global Grids Worldwide LHC Computing Grid routinely runs over 200 VOs (Dashboard website: http://dashb-earth.cern.ch)

  11. 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

  12. Adding VOs to OpenStack At least two different designs for this: • External VO Management System (VOMS) • Approach used in current, operational grids • Integrate VO management into Keystone • Since Keystone already assigns roles/projects to users extend its capabilities to assign them to VO members

  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 Example of External VO Management System:NGA/NCOIC GeoInt Community Cloud (GCC) Prototype Cloud A Cloud B Cloud C List Upload Download Keystone Keystone Keystone Swift Swift Swift Haiti VO Haiti VO Admin VOMS w/ VOMS Admin • The VOMS manages info for multiple VOs • Members • Roles • Participating Sites

  14. Adding aVO AuthStage to the Keystone Command Pipeline Request Keystone Service Token Auth VO Auth Admin Token Auth XML Body JSON Body Response VOMS Admin VO Admin VO Admin VO Admin Members Roles Sites VOMS • All OpenStack services are designed with a configurable command pipeline • WhenAO 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

  15. Integrating VO Management into Keystone • Introduce an internal attribute mapping service Attribute Mapping Fe User 1 IDP 1 Domain, project, roles Id Atts Keystone Id Atts 1 IDP 2 Id Atts 2 Domain, project, roles User 2 A Federation OpenStack Service Some VO

  16. 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

  17. Extending Keystone to be a VO Manager Another VO • Create a Mapping API • Alternatively, Attribute Mapping could become a stand-alone OpenStack service Domain, project, roles Id Atts External Mapping API Attribute Mapping Domain, project, roles Id Atts Keystone

  18. VO User Authentication Multiple ways of addressing this: • Keystone uses its existing authentication methods (e.g. un/pw) • Use an external PKI to authenticate users and send certificate and signed message to Keystone • Use federated authentication with IdPs

  19. GCC Example:User Authentication using Keystone with external VOMS Cloud A Cloud B UserA UserB Swift VO Client Keystone VO Client Role A Account: Service Catalogs and AUTH_TOKENs for all VO sites Un/pw Swift Keystone Keystone Swift Authn as RoleA VOMS w/ Admin VO.Haiti UserA: RoleA Site: Clouds A, B … … … Container ACL: RoleA Container ACL: UserB Container ACL: UserA Container ACL: RoleA VO.Haiti Admin

  20. GCC Example: VO Container Access Cloud A Cloud B List, Upload, Download UserA UserB Swift VO Client Keystone VO Client Role A Account: Service Catalogs and AUTH_TOKENs for all VO sites Swift Keystone Keystone Swift VOMS w/ Admin VO.Haiti UserA: RoleA Site: Clouds A, B … … … Container ACL: RoleA Container ACL: UserB Container ACL: UserA Container ACL: RoleA VO.Haiti Admin Local Admin Local Admin

  21. GCC Example:Using VO Roles to Manage Container Access VO Members Participating Site Access Control Lists VO Roles Data Containers Data containers could be made available directly, or replicated Medical Staff Medical Data Read: Write: Civic Engineer Building Plans, Maps Read: Local Admin Write: End User Data First Responder Read: Write:

  22. Using VOs to Manage Access to Arbitrary App-Level Services Application Service Owner App User VOMS • AUTH_TOKEN • Service Catalog • App Svc Endpoint App VO w/ App VO Admin 3: Authn User 2: Register & Administer Endpoint 1: Instantiate App Service 6: User Authn’d 10: App Svc Results 7: Req App Svc 4: Verify VO Membership 5: VO Membership Verified Keystone 8: Authz User App-level Service Virtual Machine Image Service Catalog --- --- --- --- VO_PEP.py 9: User Authz’d VOMS Admin App Service Endpoint w/ reqd. VO Roles/Attrs Hypervisor Hardware Server

  23. 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, attributesand 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

  26. Thank you!Questions? All trademarks, service marks, and trade names are the property of their respective owners.

More Related