Bridging Silos: A Demonstration of Federation Management Using the KeyVOMS Prototype

Transcription

1 Bridging Silos: A Demonstration of Federation Management Using the KeyVOMS Prototype Dr. Craig A. Lee Senior Scientist, Computers & Software Division The Aerospace Corporation Ground Systems Architecture Workshop, March 2, 2016 Related Presentations at: IEEE/NSF/Internet2 workshop on End-to-End Trust and Security for the Internet of Things, Washington DC, February 4, 2016 DoD OCIO/DISA CTO Cloud Computing TEM, Arlington VA, January 29, 2016 The Aerospace Corporation 2016

2 Many Agencies that Operate Satellite Systems Are Moving Their Ground Systems to Multi-Tenant, Multi-Mission Clouds Regional Data Center Data Center Data Center Data Center Regional Data Center 2

3 This Will Require Federation Many different cloud sites will be deployed by many different organizations using many different cloud software stacks Many different cloud "silos" will result! Stove-piped systems "fork-lifted" on to a cloud will still be stove-piped! Simply doing a fork-lift will result in Silos-as-a-Service Collaboration, data access, and interoperability problems will continue There must be a way to securely bridge systems and security domains Secure sharing of resources: data and services Secure sharing must be possible at any level in the system stack Cloud infrastructure services Middleware services Application/mission services Regardless of whether services are cloud-hosted or bare metal Federation Management 3

4 Cloud Federation vs. General Federation "Hybrid" and "Community" Clouds are part of the lexicon These are fundamentally instances of cloud federation Requires federated identity management, authorization, etc. Federation can be done at any level in the system stack: IaaS, PaaS, SaaS This can include arbitrary, app-level services! If everything is a service, some just happen to be "factory" services producing other services that the user actually wants It doesn t matter if a service is cloud-hosted or bare-metal When "done right", cloud federation is an instance of general federation Can securely manage collaborations and the sharing of resources across a wide spectrum of application and administrative domains This vastly expands the applicability and potential impact of what (cloud) federation could mean: Up to and including a global intercloud of things C. A. Lee, Cloud Federation Management and Beyond: Requirements, Relevant Standards, and Gaps, IEEE Cloud Computing, Jan-Feb,

5 Federations Can Be Categorized Along Three Properties Organization How the participants in a federation are organized, e.g., what is the communication topology Access How federation participants access the federation, i.e., communicate and interact with the other participants Scale Given the number of participating sites, users and services, what implementation approaches are feasible, e.g. centralized vs. distributed, and what properties may they have, e.g., knowable with certainty at any given point in time 5

6 A General Implementation Concept: Federation Agents A Federation Agent is the thing that is capable of managing a local user's interactions with a federation: Federated Identity Management & Authentication Resource Discovery Federated Credential Validation Authorization A Federation Agent (FA) can be either: Internal to the User's administrative domain, or External to the User's administrative domain FA FA What Federation Deployment Models are Possible? 6

7 Federation Deployment Models Based on the Notion of a Federation Agent Simple, Pair-wise Federation Centralized Third-Party FA FA FA FA P2P Federation FA Gateway Federation FA FA FA FA FA FA 7

8 Federation Deployment Models Interclouds The Internet of Things Skitter data depicting internet connectivity. CAIDA.org, used by permission.

9 What Does Federation Actually Require? The Basic AuthN/Z Process The AuthN/Z Challenge in a Distributed Environment 1 1 User A 2 IdP A IdP B 2 User B SP A SP B How can User A find (discover) SP B? How can SP B validate User A s credentials and make access decision? 9

10 Fundamental Federation Requirements and Relevant Existing Standards Federation Discovery WS-I, UDDI, LDAP, distributed hash tables Semantics Discovery and Interoperability RDF, OWL, SPARQL Membership, Governance and Trust Cloud Auditing Data Federation, SDNs, Open vswitch, WS-Federation, WS-Trust, reputation systems, FOAF relationships Federated Identity Management OpenID, OpenID Connect, SAML, WebID, PKI proxy certs Federated Resource Discovery Similar to federation discovery Discovery policy resource owners may want to limit who can find their services Federated Resource Access XACML, OAuth 10

11 What s Needed? What are the Gaps? Semantic Interoperability Semantic discovery -- many concepts from the semantic web work What Federation Model Should Be Exposed to the User? Many piece parts for federation management exist but there is no userfacing, coherent abstraction for how to manage or interact with a federation One possibility: the Virtual Organization (VO) concept A security and collaboration context not necessarily owned by one organization VOs members granted roles/attributes that define their authorizations Standard Federation Gateway or Agent Includes all functionality for interacting with a federation Including any Software-Defined Networks Cloud Federation Profiles Profile of how standards and tools are used for a desired federation model Modular trust components that comprise a federation For example, GaTech Res. Inst. Trustmarks in trustmark repositories Trust Federations Trust relationships and semantic interoperability established ahead of need 11

12 A Precedent: Virtual Organizations in a Global Trust Federation Global computing grids enabled by the Interoperable Global Trust Federation (IGTF), Routinely runs hundreds of Virtual Organizations UPDATE WITHthe NEW How to adapt VOSCREEN concept SHOT to an on-demand, service-oriented world? 12

13 Virtual Organization Abstract Concepts A VO is a security and collaboration context not exclusively associated with any one physical organization or site Participants agree upon VO structure, rules and processes A VO participant 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 VO participants 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 A VO Management System (VOMS): Maintains member identity attributes and authorization attributes Enables resource (service) discovery Enables validation of VO member authz credentials on service invocation 13

14 Virtual Organizations from Feet Fred P QP Sally Based on their VO authorizations, members can access different services. Joe Q Z X Y Z X Q Z Sam Y Z How can separate organizations share Svc Q data and Svc services? X Svc Z Svc P Svc Q Virtual Organization C Svc X Svc Y Svc Z SysAdmin Organization A IdP Participating Answer: create sites a register Virtual Organization their services that they is wish not owned to make by any available one organization. to this VO. SysAdmin Organization B IdP 14

15 A VO Management System: KeyVOMS A Centralized, Third-Party VOMS for Secure Discovery and Access across Sites OpenStack v3 re-purposed as a standalone, VO Management Service: KeyVOMS Domain used as a VO Service Catalog used for app-level services Endpoint Filtering used Inherits support for FIM, PKI, certificate caching, revocation lists, etc. New rule set enforces three pre-defined roles: voms_admin vo_admin vo_site_admin Modular VO Policy Enforcement Point built Based on WSGI A -based Virtual Organization Management System, Lee, Desai & Brethorst, 6 th 15 IEEE CloudCom, December, 2014.

16 The KeyVOMS Demo Scenario KeyVOMS VO VO myvo Foo Service Catalog Service Endpoint KeyVOMS Command Line Client Used to inspect and manage internal KeyVOMS and VO information VO PEP RSS Feed Servers VO PEP Map Data Servers KeyVOMS-enabled Browser App Used to access different VO services based on the user s VO authorization attributes VO PEP VO File Servers Services from different providers being made available to myvo 16

17 Current KeyVOMS Demo Services: Managing Access to RSS feeds Map data 17 Files

18 Physical Infrastructure of Today s KeyVOMS Demo Craig s laptop in Ballston KeyVOMS Mgmt Client KeyVOMS RSS Map Data RSS VO Files VO Files EC2 Servers from Aerospace s Corporate Amazon Account Server from Private Digital Network Services, an NCOIC member 18

19 Next Step: A -based, General Federation Agent A Centralized, Third-Party VOMS was an easy "target of opportunity Re-purposing a v3 enabled concepts to be demonstrated A centralized approach is inherently not scalable How can we build a distributed, general federation agent? has been under continuous development with important mods? Booting and Growing a VO Sites with Membership Granting Authority can vary from 1 to N in a federation Service Discovery Initial replication, exhaustive query, limited query, search engines, Credential Validation Local account, guest/role account, credential exchange, user mapping, A User Interface: OpenStack Horizon Drop-down menu for projects which may have VO/Domain attribute Simple approaches are being initially taken 19

20 Final Observations: Scaling-Up to an Internet of Things Scalability Service Discovery Federated Identity Management Credential Validation Establishing trust ahead of need Trust Frameworks Trust Federations Securing the Protocols Hardening VO protocols against spoofing, man-in-the-middle, denial of services attacks, etc. Networking Support Push some support for VO P2P protocols into the networks Software-defined networks, e.g., GENI slices IEEE P2302 work on signaling protocols and bearer networks Adoption 20

21 Thank you All trademarks, service marks, and trade names are the property of their respective owners. The Aerospace Corporation 2016