d u k e s y s t e m s building the geni federation with abac jeff chase duke university thanks: nsf...
TRANSCRIPT
D u k e S y s t e m s
Building the GENI FederationWith ABAC
Jeff ChaseDuke University
Thanks: NSF TC CNS-0910653
IdP.facultyD
SA
Reading the slides
IdP.studentT
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
AMAggregate
T D
Bidirectionaltrust based on
agreements
GENI Federation Oversight
GENI trust structure: overview (v1.0)
CH
AM AM AM 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 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 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.sliceAuthoritySAGOC.projectAuthorityPAGOC.idpIdPGOC.aggregateAM
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).sliceAuthorityC.projectAuthority(C.root).projectAuthorityC.idp(C.root).idpC.aggregate(C.root).aggregate
C.rootGOC
• 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 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).sliceAuthorityAM.projectAuthority(AM.root).projectAuthorityAM.idp(AM.root).idp
inferred trust
AM.rootGOC
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 trustbidirectional
Inferred facts:AM.sliceAuthoritySAAM.projectAuthorityPAAM.idpIdP
C.aggregateAMC.sliceAuthoritySAC.projectAuthorityPAC.idpIdPfor each coordinator C in {IdP, PA, SA}
Aggregates and coordinators trust one another.
GOC
IdP
Issue user credentials
PACreate project
Project x created
Users have roles e.g.,
student, faculty.
SARegister
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
1 2
3
4
5
IdP
Issue user credentials
Users have roles e.g.,
student, faculty.
Registeruser
user registered
Identity Portal/Provider (IdP)
IdP.geniUserTIdP.studentT
IdP.enrolled(CS-114)T
IdP.geniUserDIdP.facultyD
• 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 PACreate project
SARegister
user
Delegateproject
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
1 2
3
4
5
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.
Client Server
reference monitor
Request ron object x
G1
G2
AND
AND
G3
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:
G1: r(C.x): <predicate 1>G2: r(C.x): <predicate 2>…GN: r(C.x): <predicate N>
G1
G2
AND
AND
G3
<predicate 1>
<predicate 2>
<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).
G1
G2
AND
AND
G3
r(C.x)
<predicate 1>
<predicate 2>
<predicate 3>
• 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
PACreate project
User credentialsfor Dr. D
Project x created
Issue project credentials
PA.leader_xD
Sample guards for creating a projectG1:createProject: (PA.idp).facultyG2:createProject: (PA.idp).geniUser
Sample policy rules for project xPA.in_x(PA.leader_x).in_xPA.createSliceFor_xPA.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 projectG1:createProject: (PA.idp).facultyG2:createProject: (PA.idp).geniUser
Sample policy rules for project xG1: in_x: (PA.leader_x).in_xG2: in_x: (PA.idp).geniUserG1: 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 credentialsSample guards for creating a slice
G1:createSliceFor(PA.x): SA.projectAuthorityPAG2:createSliceFor(PA.x): PA.createSliceFor_x
Sample policy rules for a slice sG1:createSliver_s: SA.creator_s
SA.creator_ST
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 sliceG1:createSliceFor(PA.x):
SA.projectAuthorityPAG2:createSliceFor(PA.x):
PA.createSliceFor_x
Sample policy rules for a slice sG1: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_xT
PACreate project
PA.leader_xD
SA
Create slice
in PA.x
SA.creator_sT
ApprovedSA.createSliceFor(PA.x)T
SA authorization policyG1:createSliceFor(PA.x):
SA.projectAuthorityPAG2:createSliceFor(PA.x):
PA.createSliceFor_x
Project x created
Example: createSlice authorization
PA policy for PA.xG1: createSliceFor_x:
PA.in_xG1: in_x:
(PA.leader_x).in_xG2: in_x:
(PA.idp).geniUserIdP.geniUserT
T
D
Create sliver for
slice s
ApprovedAM.createSliver(SA.s)T
SA AM
Example: createSliver authorization
SA.creator_sT
IdP.geniUserT
AM authorization policyG1:createSliver(SA.s):
AM.sliceAuthoritySAG2:createSliver(SA.s):
SA.createSliver_s
SA policy for SA.sG1: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?