Download Document

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.studentT
SA
IdP.facultyD
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.sliceAuthoritySA
GOC.projectAuthorityPA
GOC.idpIdP
GOC.aggregateAM
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.rootGOC
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.rootGOC
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.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}
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.geniUserT
IdP.studentT
IdP.enrolled(CS-114)T
IdP.geniUserD
IdP.facultyD
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_xPA.in_x
PA
Project x
created
D
Issue project
credentials
PA.leader_xD
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.projectAuthorityPA
G2:createSliceFor(PA.x): PA.createSliceFor_x
T
Issue slice
credentials
SA.creator_ST
SA policies: a closer look
Sample guards for creating a slice
G1:createSliceFor(PA.x):
SA.projectAuthorityPA
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_sT
Project x
created
PA.leader_xD
D
D.in_xT
T
IdP.geniUserT
Create
slice
in PA.x
SA authorization policy
G1:createSliceFor(PA.x):
SA.projectAuthorityPA
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_sT
T
IdP.geniUserT
AM authorization policy
G1:createSliver(SA.s):
AM.sliceAuthoritySA
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?