D u k e S y s t e m s Building the GENI Federation With ABAC Jeff Chase Duke University Thanks: NSF TC CNS-0910653.

Slides:



Advertisements
Similar presentations
D u k e S y s t e m s Foundations of a Future Inter-Cloud Architecture Jeff Chase Duke University / RENCI.
Advertisements

CLARIN AAI, Web Services Security Requirements
D u k e S y s t e m s Some tutorial slides on ABAC Jeff Chase Duke University.
Sponsored by the National Science Foundation 1 Activities this trimester 0.5 revision of Operational Security Plan Independently (from GPO) developing.
SCENARIO Suppose the presenter wants the students to access a file Supply Credenti -als Grant Access Is it efficient? How can we make this negotiation.
Sponsored by the National Science Foundation Campus Policies for the GENI Clearinghouse and Portal Sarah Edwards, GPO March 20, 2013.
D u k e S y s t e m s Authorization Framework: Status Jeff Chase Duke University.
Information Sciences Institute Internet and Networked Systems Managing Security Policies for Federated Cyberinfrastructure Stephen Schwab, John Wroclawski.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification.
Sponsored by the National Science Foundation GENI Clearinghouse Panel GEC 12 Nov. 2, 2011 INSERT PROJECT REVIEW DATE.
DESIGNING A PUBLIC KEY INFRASTRUCTURE
Dorian Grid Identity Management and Federation Dialogue Workshop II Edinburgh, Scotland February 9-10, 2006 Stephen Langella Department.
Information Resources and Communications University of California, Office of the President UCTrust Implementation Experiences David Walker, UCOP Albert.
Unit Testing CS 414 – Software Engineering I Don Bagert Rose-Hulman Institute of Technology January 16, 2003.
Use Case Development Scott Shorter, Electrosoft Services January/February 2013.
Shibboleth Update a.k.a. “shibble-ware”
CS-550 (M.Soneru): Protection and Security - 2 [SaS] 1 Protection and Security - 2.
Shibboleth: New Functionality in Version 1 Steve Carmody July 9, 2003 Steve Carmody July 9, 2003.
D u k e S y s t e m s Accountability and Authorization GEC 12 Jeff Chase Duke University Thanks: NSF TC CNS
D u k e S y s t e m s Building the GENI Federation with ABAC: Going Deeper Jeff Chase Duke University Thanks: NSF TC CNS
External Identity and Authorization in GENI. Topics Federated identity and virtual organizations ABAC Creating and transporting attributes.
1 TAPAS Workshop Nicola Mezzetti - TAPAS Workshop Bologna Achieving Security and Privacy on the Grid Nicola Mezzetti.
Digital Object Architecture
RECALL THE MAIN COMPONENTS OF KIM Functional User Interfaces We just looked at these Reference Implementation We will talk about these later Service Interface.
D u k e S y s t e m s A Tale of Two Federations Jeff Chase Duke University.
AMPol-Q: Adaptive Middleware Policy to support QoS Raja Afandi, Jianqing Zhang, Carl A. Gunter Computer Science Department, University of Illinois Urbana-Champaign.
GEC5 Security Summary Stephen Schwab Cobham Analytical Services July 21, 2009.
Sponsored by the National Science Foundation GEC17 Developer Sessions: ABAC: Life after Speaks-For Marshall Brinn, GPO July 22, 2013.
D u k e S y s t e m s ABAC: An ORCA Perspective GEC 11 Jeff Chase Duke University Thanks: NSF TC CNS
Sponsored by the National Science Foundation GEC16 Plenary Session: GENI Solicitation 4 Tool Context Marshall Brinn, GPO March 20, 2013.
A Flexible Access Control Model for Web Services Elisa Bertino CERIAS and CS Department, Purdue University Joint work with Anna C. Squicciarini – University.
Sponsored by the National Science Foundation Enabling Trusted Federation Marshall Brinn, GENI Program Office October 1, 2014.
An XML based Security Assertion Markup Language
Access Control for Federation of Emulab-based Network Testbeds Ted Faber, John Wroclawski 28 July 2008
Sponsored by the National Science Foundation Towards Uniform Clearinghouse APIs GEC17 Developer Working Sessions July 23,
Technical Break-out group What are the biggest issues form past projects – need for education about standards and technologies to get everyone on the same.
Sponsored by the National Science Foundation GENI Security Architecture What’s Up Next? GENI Engineering Conference 7 Durham, NC Stephen Schwab SPARTA/Cobham.
Introduction to Trust Logic Jeff Chase Duke University This presentation contains easily recognizable copyrighted material. No offense is intended. Please.
The TAOS Authentication System: Reasoning Formally About Security Brad Karp UCL Computer Science CS GZ03 / M th November, 2008.
Module Coordinator Tan Szu Tak School of Information and Communication Technology, Politeknik Brunei Semester
Claims-Based Identity Solution Architect Briefing zoli.herczeg.ro Taken from David Chappel’s work at TechEd Berlin 2009.
Federations and Higher Education. Topics  Federations: What they may be and where they may fit The theory The practice: first instantiations –Ice9: Shibboleth.
“Trust me …” Policy and Practices in PKI David L. Wasley Fall 2006 PKI Workshop.
Sponsored by the National Science Foundation Introduction to GENI Architecture: Federated Trust Perspective Marshall Brinn, GPO GEC20: June 24, 2014.
D u k e S y s t e m s GENI Federation Basics Jeff Chase Duke University.
SecPAL Presented by Daniel Pechulis CS5204 – Operating Systems1.
Advanced CAMP: BoF Summaries. 2 Role-based Access Control (RBAC)
Authentication and Authorisation for Research and Collaboration Peter Solagna Milano, AARC General meeting Current status and plans.
Sponsored by the National Science Foundation Establishing Policy-based Resource Quotas at Software-defined Exchanges Marshall Brinn, GPO June 16, 2015.
SOFTWARE TESTING. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves any activity.
Authorization: Just when you thought middleware was no fun anymore Keith Hazelton, Senior IT Architect, Univ. of Wisconsin-Madison Member, Internet2 Middleware.
Networks ∙ Services ∙ People eduGAIN Townhall Meeting Nicole Harris (or updating the eduGAIN policy suite) “Unicorns can be sued in Wales”
Sponsored by the National Science Foundation 1 March 15, 2011 GENI I&M Update: I&M Service Types, Arrangements, Assembling Goals Architecture Overview.
AuthZ WG Conceptual Grid Authorization Framework document Presentation of Chapter 2 GGF8 Seattle June 25th 2003 Document AID 222 draft-ggf-authz-framework pdf.
Attribute Filtering. © 2010 SWITCH 2 Terms: Attribute Filter Policy A policy containing a trigger, that indicates if the policy is active, and a set of.
Clearing house for all GENI news and documents GENI Architecture Concepts Global Environment for Network Innovations The GENI Project Office.
Prepared by Amira Selim 31 st October 2009 Revised by Dahlia Biazid Requirements Analysis.
Active Directory Domain Services (AD DS). Identity and Access (IDA) – An IDA infrastructure should: Store information about users, groups, computers and.
D u k e S y s t e m s Some Issues for Control Framework Security GEC7 Jeff Chase Duke University.
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
Designing a Federated Testbed as a Distributed System Robert Ricci, Jonathon Duerig, Gary Wong, Leigh Stoller, Srikanth Chikkulapelly, Woojin Seok 1.
Operating Framework of Connection Networks OGF/NSI Working Group Chicago Oct. 10, 2012 John Vollbrecht & Leon Gommans University of Amsterdam.
Sponsored by the National Science Foundation ABAC and GPO Clearinghouse Authorization Marshall Brinn, GPO GEC20: June 22, 2014.
Operating Framework of Connection Networks
Identity Federations - Overview
Stitching: the ORCA View
Certificates An increasingly popular form of authentication
Appropriate Access InCommon Identity Assurance Profiles
Protecting Privacy During On-line Trust Negotiation
Advanced Tips and Tricks
Presentation transcript:

D u k e S y s t e m s Building the GENI Federation With ABAC Jeff Chase Duke University Thanks: NSF TC CNS

IdP.faculty  D SA Reading the slides IdP.student  T GENI users Test Tube Guy and Dr. D, and some of their credentials A coordination service implementing some clearinghouse function, such as a Slice Authority Indicates trust of one principal in another, often associated with some kind of formal agreement: Indicates a request Indicates credential flow A A generic principal AM Aggregate TD

Bidirectional trust based on agreements GENI Federation Oversight GENI trust structure: overview (v1.0) CH AM Users and tools Principals are users and organizations, and tools or servers acting on their behalf. Users create global slices and request aggregates to bind local resources to those slices.

GENI trust structure: overview (v2.0) AM GOC Each of these entities may: – Speak with its own keypair. – Wield credentials. There are limited trust relationships among them. Trust reflects agreements, and is limited by their scope. Credentials capture this trust. Trust may be transitive. GMOC I&M IdP PA SA Nothing has really changed, but we have named some of the CH coordination services, and introduced a federation root (GOC) to endorse federation-affiliated services. See the intro slide deck. AMs trust the coordination services, transitively. GENI “clearinghouse”

Reasoning about trust graphs AM GOC This is a trust graph. – Edges represent limited trust by source entity in the target. We can capture trust graphs in a delegation logic. o Some out-edges are facts given by an entity’s local operator. o The others are inferred locally by applying locally accepted policy rules to facts. GMOC I&M IdP PA SA Given a suitable trust management framework (e.g., ABAC), trust delegations and policies for inferring trust (by finding trust paths) may be specified declaratively and checked automatically.

Overview Walk through the GENI trust graph step by step. Show how to represent it in ABAC. Familiarity with ABAC (RT0 delegation logic) is assumed. There is another slide deck on that. Walk through a canonical GENI example of a sequence of requests through the trust graph. For each step in the sequence, give examples of authorization policies represented in ABAC. Show how automated policy checking combines the policies of multiple “coordinator” entities. – PA, SA, AM

GOC endorses GENI services GOC GMOC I&M IdP PA SA GOC.sliceAuthority  SA GOC.projectAuthority  PA GOC.idp  IdP GOC.aggregate  AM AM These endorsements are facts asserted by GOC under its key. Each fact endorses another entity’s key for some role. An endorsement may be based on an agreement or on trust in an entity’s controlling domain. These endorsements by GOC are credentials that are visible to other entities, and may lead those entities to infer transitive trust. agreements Common CH domain

Coordinators in the federation GOC GMOC I&M IdP PA SA Sample policy rules for each coordinator C: C.sliceAuthority  (C.root).sliceAuthority C.projectAuthority  (C.root).projectAuthority C.idp  (C.root).idp C.aggregate  (C.root).aggregate C.root  GOC Each coordinator C has a local fact naming the federation root. – For C in {IdP, PA, SA} Typical policy rules at C might tell C to trust root endorsements of other federation services. I believe whatever the root tells me about other services in this federation.

Aggregates join the federation AM GOC AMs trust the coordination services, transitively. Each AM has a local fact for its trust in the federation root. Typical AM policy rules might trust the root’s endorsements of coordinators and perhaps other aggregates. Sample AM policy rules: AM.sliceAuthority  (AM.root).sliceAuthority AM.projectAuthority  (AM.root).projectAuthority AM.idp  (AM.root).idp inferred trust AM.root  GOC

Filling in the trust structure GOC GMOC I&M IdP PA SA AM These sample policy rules define sets of valid trust paths. A trust path indicates inferred trust by the source entity in the destination entity. Inferred trust bidirectional Inferred facts: AM.sliceAuthority  SA AM.projectAuthority  PA AM.idp  IdP C.aggregate  AM C.sliceAuthority  SA C.projectAuthority  PA C.idp  IdP for each coordinator C in {IdP, PA, SA} Aggregates and coordinators trust one another.

GOC IdP Issue user credentials PA Create project Project x created Users have roles e.g., student, faculty. SA Register user user registered Delegate Issue project credentials project credentials Create slice in x Slice s created Issue slice credentials AM Create sliver in in s

IdP Issue user credentials Users have roles e.g., student, faculty. Register user user registered Identity Portal/Provider (IdP) IdP.geniUser  T IdP.student  T IdP.enrolled(CS-114)  T IdP.geniUser  D IdP.faculty  D An IdP asserts facts about users. User attributes may include inCommon attributes harvested through indirect delegation to Shibboleth IdPs. These attributes may have parameters with simple values (strings or numbers). The delegation logic should support parameterized attributes (e.g., RT1). D T

IdP PA Create project SA Register user Delegate project credentials Create slice in x AM Create sliver in in s Verify user identity, obtain attributes, check that user is qualified, execute agreement. Verify that user is authorized to create project and act as project leader. Verify that project x is valid and user is authorized to create slice s in project x. Verify that slice s is valid and user is authorized to request resources for s. Authorization

Guards Before a server executes a request, it checks it for compliance with an authorization policy. The policy is implemented by a guard: a predicate that must be satisfied (i.e., evaluate to true). A guard may itself be a conjunction of predicates. These predicates are also guards: they must all be satisfied to allow the operation. ClientServer reference monitor Request r on object x G1G1 G2G2 AND G3G3 request Guard Guard for r(x): a conjunction of predicates

Representing guards We introduce some new syntax for guards. If a coordinator C creates an object x, call the object by the global name C.x. – E.g., project PA.x and slice SA.s For operation request r on an object x created by a coordinator C, state the guards in sequence: G 1 : r(C.x): G 2 : r(C.x): … G N : r(C.x): G1G1 G2G2 AND G3G3

Guards and ABAC A guard predicate is typically an ABAC role or attribute that can be checked automatically by an inference engine. We break them out so that we can talk about them separately without writing down the conjunctions (long ABAC “type 4” rules). G1G1 G2G2 AND G3G3 r(C.x) Also, we want to allow more general guards whose predicates are evaluated outside of ABAC. Or guards that generate an ABAC query “on the fly” from a template, based on other info in the request. Or guards that modify the request, e.g., degrade the class of service if a particular credential is missing. More on all this later…

Project Authority (PA) Project Authority has policies for who can create a project. For each new project x (global name PA.x), PA issues facts and policy rules defining powers and rights of x and how they can be delegated. GOC PA Create project User credentials for Dr. D Project x created Issue project credentials PA.leader_x  D Sample guards for creating a project G 1 :createProject: (PA.idp).faculty G 2 :createProject: (PA.idp).geniUser Sample policy rules for project x PA.in_x  (PA.leader_x).in_x PA.createSliceFor_x  PA.in_x D

PA policies: a closer look PA Any approved GENI user who is also a faculty member can create/lead a project. Sample guards for creating a project G 1 :createProject: (PA.idp).faculty G 2 :createProject: (PA.idp).geniUser Sample policy rules for project x G 1 : in_x: (PA.leader_x).in_x G 2 : in_x: (PA.idp).geniUser G 1 : createSliceFor_x: PA.in_x The project leader may delegate membership in the project to any GENI user. Any project member may create a slice for the project. Project Authority may customize these rules on a per-project basis. PA generates them from a template when it creates project PA.x. Your policies may vary.

Slice Authority (SA) SA has policies for who can create/register a slice for use at affiliated aggregates. For each new slice s (global name SA.s), SA issues facts and policy rules defining powers and rights of s and how they can be delegated. GOC SA Create/register slice Slice s created Issue slice credentials Sample guards for creating a slice G 1 :createSliceFor(PA.x): SA.projectAuthority  PA G 2 :createSliceFor(PA.x): PA.createSliceFor_x Sample policy rules for a slice s G 1 :createSliver_s: SA.creator_s SA.creator_S  T T

SA policies: a closer look SA Anyone can create a slice for a project PA.x if x was approved by a Project Authority I trust, and the request conforms to project policies. Only the creator of a slice s may create a sliver for s. Slice Authority may customize these rules on a per-slice basis. SA generates them from a template when it creates slice SA.s. Sample guards for creating a slice G 1 :createSliceFor(PA.x): SA.projectAuthority  PA G 2 :createSliceFor(PA.x): PA.createSliceFor_x Sample policy rules for a slice s G 1 :createSliver_s: SA.creator_s Later we’ll consider how to represent more flexible policies for slices, e.g., SFA capabilities supplemented with GENI safety restraints. Your policies may vary.

D.in_x  T PA Create project PA.leader_x  D SA Create slice in PA.x SA.creator_s  T Approved SA.createSliceFor(PA.x)  T SA authorization policy G 1 :createSliceFor(PA.x): SA.projectAuthority  PA G 2 :createSliceFor(PA.x): PA.createSliceFor_x Project x created Example: createSlice authorization PA policy for PA.x G 1 : createSliceFor_x: PA.in_x G 1 : in_x: (PA.leader_x).in_x G 2 : in_x: (PA.idp).geniUser IdP.geniUser  T T D

Project organization In general, the leader controls project organization. – Membership in_x is just an example of project rights (i.e., a role). – Leader may delegate rights without notifying PA. Some projects could be organized into subgroups. – Leader may delegate control of subgroups, if permitted by PA. – PA policies may constrain the leader’s power to delegate membership. PA PA.in_x  (PA.leader_x).in_x D.in_x  T Infer: PA.in_x  T Add T to Project x PA.leader_x  D Your policies may vary. T D

Create sliver for slice s Approved AM.createSliver(SA.s)  T SA AM Example: createSliver authorization SA.creator_s  T IdP.geniUser  T AM authorization policy G 1 :createSliver(SA.s): AM.sliceAuthority  SA G 2 :createSliver(SA.s): SA.createSliver_s SA policy for SA.s G 1 :createSliver_s: SA.creator_s Later we’ll consider more flexible policies for slices. T

Are we done yet? Not quite. 1.We would like to represent more flexible policies. 2.These policies are not fully specified for implementation in RT0 delegation logic. – We need roles with parameters (RT1), at least for inCommon user identity attributes. – And what are those funny embedded object names in roles like leader_x, in_x, and creator_s? – What are those object-valued parameters for guards like SA.createSliceFor(PA.x) and AM.createSliver(SA.s)? 3.Can AMs mix and match coordinators? What if there are multiple intertwined federations? 4.How to get the right credentials in the right place at the right time, safely?