Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Duke Systems Building the GENI Federation With ABAC Jeff Chase Duke University Thanks: NSF TC CNS-0910653 Reading the slides GENI users Test Tube Guy and Dr. D, and some of their credentials T D IdP.studentT SA IdP.facultyD A A generic principal 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 Aggregate AM GENI trust structure: overview (v1.0) Users and tools GENI Federation Oversight CH Users create global slices and request aggregates to bind local resources to those slices. Bidirectional trust based on agreements AM AM AM AM Principals are users and organizations, and tools or servers acting on their behalf. GENI trust structure: overview (v2.0) • Each of these entities may: GENI “clearinghouse” – Speak with its own keypair. GOC – Wield credentials. • There are limited trust relationships among them. GMOC IdP • Trust reflects agreements, and is limited by their scope. • Credentials capture this trust. • Trust may be transitive. AM PA AMs trust the coordination services, transitively. I&M SA AM 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. Reasoning about trust graphs • This is a trust graph. – Edges represent limited trust by source entity in the target. GOC • We can capture trust graphs in a delegation logic. GMOC IdP PA I&M SA 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. AM AM 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.sliceAuthoritySA GOC.projectAuthorityPA GOC.idpIdP GOC.aggregateAM GOC • These endorsements are facts asserted by GOC under its key. GMOC IdP • 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. PA I&M SA Common CH domain agreements AM AM These endorsements by GOC are credentials that are visible to other entities, and may lead those entities to infer transitive trust. Coordinators in the federation C.rootGOC 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. GMOC IdP 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 PA I&M SA I believe whatever the root tells me about other services in this federation. Aggregates join the federation AM.rootGOC GOC • Each AM has a local fact for its trust in the federation root. AMs trust the coordination services, transitively. • Typical AM policy rules might trust the root’s endorsements of coordinators and perhaps other aggregates. inferred trust AM Sample AM policy rules: AM.sliceAuthority(AM.root).sliceAuthority AM.projectAuthority(AM.root).projectAuthority AM.idp(AM.root).idp AM Filling in the trust structure • These sample policy rules define sets of valid trust paths. GOC • A trust path indicates inferred trust by the source entity in the destination entity. Inferred facts: AM.sliceAuthoritySA AM.projectAuthorityPA AM.idpIdP C.aggregateAM C.sliceAuthoritySA C.projectAuthorityPA C.idpIdP for each coordinator C in {IdP, PA, SA} GMOC IdP AM PA I&M SA Inferred trust bidirectional Aggregates and coordinators trust one another. GOC 1 2 4 IdP Register user PA Create project Project x created user registered Issue user credentials Issue project credentials SA Create slice in x Slice s created Issue slice credentials 3 Users have roles e.g., student, faculty. Delegate project credentials AM Create sliver in in s 5 Identity Portal/Provider (IdP) IdP Register user user registered T Issue user credentials Users have roles e.g., D student, faculty. • 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). IdP.geniUserT IdP.studentT IdP.enrolled(CS-114)T IdP.geniUserD IdP.facultyD The delegation logic should support parameterized attributes (e.g., RT1). Authorization 1 2 4 IdP Register user Verify user identity, obtain attributes, check that user is qualified, execute agreement. PA Create project Verify that user is authorized to create project and act as project leader. 3 Delegate project credentials SA Create slice in x Verify that project x is valid and user is authorized to create slice s in project x. Create sliver in in s AM 5 Verify that slice s is valid and user is authorized to request resources for s. Guards • Before a server executes a request, it checks it for compliance with an authorization policy. request • The policy is implemented by a guard: a predicate that must be satisfied (i.e., evaluate to true). G1 • A guard may itself be a conjunction of predicates. AND • These predicates are also guards: they must all be satisfied to allow the operation. G2 AND G3 Client Guard Request r on object x Guard for r(x): a conjunction of predicates Server reference monitor 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: G1: r(C.x): <predicate 1> G2: r(C.x): <predicate 2> … GN: r(C.x): <predicate N> G1 <predicate 1> AND G2 <predicate 2> AND G3 <predicate 3> 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). • Also, we want to allow more general guards whose predicates are evaluated outside of ABAC. r(C.x) • Or guards that generate an ABAC query “on the fly” from a template, based on other info in the request. G1 • Or guards that modify the request, e.g., degrade the class of service if a particular credential is missing. G2 • More on all this later… <predicate 1> AND <predicate 2> AND G3 <predicate 3> 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 User credentials for Dr. D Create project Sample guards for creating a project G1:createProject: (PA.idp).faculty G2:createProject: (PA.idp).geniUser Sample policy rules for project x PA.in_x(PA.leader_x).in_x PA.createSliceFor_xPA.in_x PA Project x created D Issue project credentials PA.leader_xD PA policies: a closer look Sample guards for creating a project G1:createProject: (PA.idp).faculty G2:createProject: (PA.idp).geniUser Sample policy rules for project x G1: in_x: (PA.leader_x).in_x G2: in_x: (PA.idp).geniUser G1: createSliceFor_x: PA.in_x Any approved GENI user who is also a faculty member can create/lead a project. Your policies may vary. Project Authority may customize these rules on a per-project basis. PA generates them from a template when it creates project PA.x. PA The project leader may delegate membership in the project to any GENI user. Any project member may create a slice for the project. 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 Create/register slice SA Slice s created Sample policy rules for a slice s G1:createSliver_s: SA.creator_s Sample guards for creating a slice G1:createSliceFor(PA.x): SA.projectAuthorityPA G2:createSliceFor(PA.x): PA.createSliceFor_x T Issue slice credentials SA.creator_ST SA policies: a closer look Sample guards for creating a slice G1:createSliceFor(PA.x): SA.projectAuthorityPA G2:createSliceFor(PA.x): PA.createSliceFor_x Sample policy rules for a slice s G1:createSliver_s: SA.creator_s 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. Your policies may vary. SA 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. Later we’ll consider how to represent more flexible policies for slices, e.g., SFA capabilities supplemented with GENI safety restraints. Example: createSlice authorization PA SA Create project Approved SA.createSliceFor(PA.x)T SA.creator_sT Project x created PA.leader_xD D D.in_xT T IdP.geniUserT Create slice in PA.x SA authorization policy G1:createSliceFor(PA.x): SA.projectAuthorityPA G2:createSliceFor(PA.x): PA.createSliceFor_x PA policy for PA.x G1: createSliceFor_x: PA.in_x G1: in_x: (PA.leader_x).in_x G2: in_x: (PA.idp).geniUser Example: createSliver authorization SA AM Approved AM.createSliver(SA.s)T Create sliver for slice s SA.creator_sT T IdP.geniUserT AM authorization policy G1:createSliver(SA.s): AM.sliceAuthoritySA G2:createSliver(SA.s): SA.createSliver_s SA policy for SA.s G1:createSliver_s: SA.creator_s Later we’ll consider more flexible policies for slices. 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?