GENI CC-NIE Workshop GENI Network Stitching Architecture and Status
D u k e S y s t e m s Building the GENI Federation with ABAC: Going Deeper Jeff Chase Duke...
-
Upload
linette-johns -
Category
Documents
-
view
213 -
download
0
Transcript of D u k e S y s t e m s Building the GENI Federation with ABAC: Going Deeper Jeff Chase Duke...
D u k e S y s t e m s
Building the GENI Federation with ABAC: Going Deeper
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
Overview
• Show how to implement authorization guards in the GENI trust graph.– Assume familiarity with revisionist (“v2”) GENI trust graph.
– Assume familiarity with ABAC representations and guards.
– See Building the GENI Federation with ABAC slide deck.
• Show how to implement flexible guards for declarative policy using the ABAC inference engine.
• Show how to implement a rich policy: SFA capabilities with GENI safety restraints.
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.
Wrapping ABAC
X.509 cert lib
G1 G4G3G2
libabaccert store lib
GeniAuth guard toolkit
• Build a simple framework for pluggable guards.
• Most guards use ABAC to interpret policies and credentials.
• But guards may also employ custom logic including some minimal custom code and calls to other tools:
• Interpreters for XML signing and credential formats
• API to TLS/message layer for authentication
• Template engine to generate ABAC rules on the fly
• ABAC query templates
• Lib to fetch/cache certificates
What is this wrapper?
• We need a way to represent and implement policies and guards that are “mostly declarative”.– Views the ABAC inference engine as a subroutine.
– Opens the possibility that we can supplement simple ABAC delegation logic (RT0 or RT1) with a sprinkle of code.
– The sprinkling of new code enables useful policies that might otherwise require a more powerful logic.
– Example: “RT2-lite” slice credentials for GENI, represented outside of ABAC.
• Hypothesis: a small number of simple off-the-shelf design patterns can supplant the need for a more powerful logic and more complex inference.
PACreate project
SA
Delegateproject
credentials
Create slice
in PA.x
AM
Create sliver in in SA.s
Verify that user is authorized to create project and act as
project leader.Issue new project
PA.x.
Verify that project PA.x is valid and user is authorized to create slice in
project PA.x.Issue new slice
SA.s.
Verify that slice SA.s is valid and user is
authorized to request resources for SA.s.
Authorization
GPA GSA
GAM
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
D
T
SA policy/guards: a closer look
SA
Anyone can create a slice for a project PA.x if PA is a Project Authority that I trust and the request conforms to policies for PA.x set by PA.
Sample guards for creating a sliceG1:createSliceFor(PA.x):
SA.projectAuthorityPAG2:createSliceFor(PA.x):
PA.createSliceFor_x
How to implement guards like this?
GSA
G1 G2
AND
GPA
G1 G2
AND
PA policy for PA.xGPA: createSliceFor_x:
PA.in_xG1: in_x:
(PA.leader_x).in_xG2: in_x:
(PA.idp).geniUser
Your policies may vary.
Unpacking the SA guards (1)
G1:createSliceFor(PA.x):SA.projectAuthorityPA
What is PA.x?
It is a typed object (a project) whose existence is asserted by some coordinator, and which is visible to all AMs who trust that coordinator and who understand objects of that type.
GSA
G1 G2
AND
1. Which coordinator? PA. Obtain PA’s public key from some object identifier in the request (PA.x).
2. Generate a query for the inference engine: do I trust PA to act as a coordinator for this type of object?SA.projectAuthorityPA? G1
Unpacking the SA guards (2)
G2:createSliceFor(PA.x):PA.createSliceFor_x
What is createSliceFor_x?
It is an ABAC RT0 role: a string literal. But it is associated with x: the name x is embedded within it. It does not appear in any static policy: it came into existence when PA created PA.x. It is an object-specific role (OSR).
GSA
G1 G2
AND
3. Generate an OSR delegation rule from a template for this object type.
SA.createSliceFor_xPA.createSliceFor_x
4. Generate query: does subject possess the OSR?
SA.createSliceFor_xT?G2
Evaluating project policy
GPA
G1 G2
AND
G2• To satisfy SA guard G2, the ABAC inference engine must prove beliefs of PA.
• PA’s facts and rules regarding createSliceFor_x are available as credentials signed by PA.
GPA: PA.createSliceFor_xPA.in_xG1: PA.in_x(PA.leader_x).in_xG2: PA.in_x(PA.idp).geniUser
• SA must fetch and import these rules (credentials) into its inference engine prior to the query in Step 4:
SA.createSliceFor_xT?
• Other PA facts and rules are needed to infer PA’s trust in the IdP.
GPA
Global objects
G1:createSliceFor(PA.x):SA.projectAuthorityPA
Let’s review. We got here because this syntax is not valid ABAC.
• We can implement this “mostly declarative” guard by adding a sprinkle of code around ABAC using an off-the-shelf design pattern.
• This design pattern is called global object. The request is associated with an object (x) created by a coordinator (PA), who is the object root for x.
• The object x is “globally” visible and has a unique global name PA.x, and perhaps also a URN. PA.x is a self-certifying identifier (scid).
• This G1 guard is part of the design pattern: it ensures that the object’s root is accepted by the entity evaluating this guard.
• We can use the same pattern for slices, which are also global objects.
Rule of Object Authority
G2:createSliceFor(PA.x):PA.createSliceFor_x
Guard G2 delegates policy control for the request on x to its root (PA).
• G2 is also part of the global object design pattern. It executes after the pattern’s G1 guard has verified local trust in the object’s root.
• G2 evaluates the root’s policy OSR regarding who is authorized to make a request associated with this object.
• The G2 guard implements the Rule of Object Authority for global objects: an object’s root sets policy for the object.
• The root’s policy guards may reference other coordinators trusted by the root (e.g., IdP), and (transitively) their own policy guards, if any.
• Any server using this pattern may add other guards of its own, which may block some requests permitted by the root’s policy.
Create sliver for
slice s
ApprovedAM.createSliver(SA.s)T
SA AM
Next 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.
Your policies may vary.
T
AM policy/guards: a closer look
Anyone can create a sliver for a slice SA.s if SA is a Slice Authority that I trust, and the request conforms to policies for SA.s set by SA.
GAM
G1 G2
AND
GSA
G1
AM
AM authorization policyG1: createSliver(SA.s):
AM.sliceAuthoritySAG2: createSliver(SA.s):
SA.createSliver_s
SA policy for slice SA.sG1: createSliver_s: SA.creator_s
1. Obtain SA’s public key from the slice identifier in the request (SA.s).
2. Generate a query for the inference engine: do I trust SA to act as a coordinator for this type of object?AM.sliceAuthoritySA?
Global object guard G1 says
AM must accept this SA.
Unpacking the AM guards
3. Generate an OSR delegation rule from a template for this object type.
AM.createSliver_sSA.createSliver_s
4a. Fetch policy rules and facts for SA.s issued as credentials by SA, and import them into the inference engine.
4b. Generate query: does the intended subject possess the required OSR?
AM.createSliver_sT?G1
G2
GSA
G1
G2: createSliver(SA.s):SA.createSliver_s
Global object guard G2 says SA sets policy for the slice under the Rule
of Object Authority.
Take a breath
• We have shown how an AM can validate a slice while leaving the policy details to the SA.– AM delegates the details of who can operate on the slice (e.g.,
createSliver) to the SA….or it can add its own guards.
• SA may define richer policies on a per-slice basis.– We now discuss a specific example: SA slice policy supporting
SFA capabilities with GENI safety rails.
• Similarly, an SA can use the same approach to validate a project and leave the policy details to the PA. The PA can define richer policies on a per-project basis.– Left as an exercise.
SA
Create slice
in PA.x
SA.creator_sT
Capability-based protection for slices
SA policy for SA.sG1:createSliver_s:
SA.cap_s
Creating user has all rightsSA.own_sSA.creator_sSA.cap_sSA.own_s
Capability delegationSA.own_s(SA.own_s).own_s
Capability confinementSA.cap_s(SA.own_s).cap_s
This sample policy is a declarative specification for capability-based access control.
This policy has one example capability
OSR: cap_s. There could be others.
T
Discussion: capabilities• This policy uses Object-Specific Roles (OSRs).
– SA generates OSR rules on a per-slice basis from a template.
• No changes are required to the AM: “it just works”.– Slice policy is SA’s choice: SA makes the rules and the AM evaluates them.
There is no, repeat it, no specific support for capabilities in the AM.
– For slices with this policy, rights to the slice may now be freely delegated by their holders.
• This policy allows anyone to hold a capability.– Project Authority policies are still in effect. But the sample PA policy only
constrains who can create a slice. Once a slice exists, its rights can be delegated to anyone.
• So we may want to add some safety rails…
Gelded capabilities for GENI slices
Experimenter accountabilityG2: (SA.idp).geniUser
GOC “kill switch”SA.cap_sSA.goc
The SA may add additional requirements for access.
E.g., a GENI-approved SA might add some additional policy provisions for strong central control.
GOC
1. Experimenters must register with a GOC-approved IdP and accept the GENI user agreement.
2. GOC or its delegates are empowered to emergency-stop any GENI slice.
SA
Implementation points
• The SA issues a slice credential, which is passed with a request on the slice.– The global object pattern will work as long as the credential is signed by
the SA and has the object’s scid (SA.s) in it.
– E.g., we can base the slice credential on Protogeni.
– It will be convenient to add an RFC 4122 UUID in addition to the object’s global symbolic name (URN).
– Don’t use a URN as the name s: ABAC won’t allow it.
• Similarly, PA issues a project credential.
• It must be possible to obtain the policy rules for an object given its credential.– E.g., use scid to index a shared credential store.
Multi-federation?
• What happens if entities mix and match coordinators? – “Everything should work.”
• If an entity trusts a coordinator, other entities trusted by that coordinator are incorporated by reference.– SA chooses which PAs to trust, but lets them choose which
IdPs to trust to validate users.
– AM chooses which SAs to trust, but lets them choose which PAs to trust to validate projects.
• Any entity may add its own guards.– E.g., add guards to limit any indirect delegation to coordinators
whom that entity does not trust.
BACKUP
Here are some older and more abstract slides on the global object design pattern.
• This design pattern presumes: (1) the object’s global name (scid) is passed in the request; (2) the guards can retrieve the root public key and object name from the scid, and (3) G2 can access the root’s policy rules for the object given its scid.
Global objects
• Slices and projects are global objects created by an object root.– root(s) = SA; root(x) = PA
– These are GENI-specific examples, but there may be others.
• The object’s root:– names the object in a local name space;
– issues an object definition credential;
– issues policy rules and facts governing access to the object.
– Example: a GENI SA issues a slice credential, creator capability, and rules for a capability-based policy (see below).
Object Definition Credential
AM
Owner credential
root
Object definition credential
• R asserts the existence of a named object x rooted in R.– R uses a local name (e.g., a GUID x).
– Name is implicitly domain-qualified: R.x.
• Based on RT2 o-set credential.– The credential may assert other object
attributes for the object x.
• More restricted than RT2:– No delegation of object attributes.
– No object parameters for predicates. No functions.
Object Definition Credential
R.objectsx
root
We can use any convenient format for this credential (e.g., ProtoGENI): the inference engine never sees it.
Object-specific roles (OSRs)
• R generates roles for each object x.– Each RT0 role name is an atomic string.
– Object Specific Roles (OSRs) embed the object name with a standard separator character, e.g., in_x.
– OSRs for x define a vocabulary to reason about rights to operate on x.
• R issues rules for the new OSRs.– Delegation rules and constraints are
generated from a policy template.
– [See capability example below.]
Object Definition Credential
Policy rules
Owner Credential
R.cap_x(R.own_x).cap_x
R.own_xA
R.objectsx
Object policies
• Rule of Object Authority: a root controls policy for its objects.– Root issues signed policy rules for input
to the site inference engine.
– Need flexible delegation that allows for suitable constraints.
– Note: root has no choice but to trust sites to honor its policy!
• Relationships among objects transitive policy delegation. – E.g., a PA or project leader can issue rules
restricting the users of a slice bound to a project.
Object Definition Credential
Policy rules
root
AM
Owner Credential
Object Capabilities
Capability delegationR.ownO(R.ownO).ownO
R.capOR.ownO
Capability confinementR.capO(R.ownO).capO
Object Policy Rules
root
Note: there may be multiple distinct cap_o capability attributes (OSRs) that permit different operations on o. An owner of o may delegate each capability independently of the others. The root must define this vocabulary of capability OSRs; the server guards must understand them.
R = root(o)This sample policy is a declarative specification for capability-based access control.
Owner Credential
R.ownOE
Using global objects
• A global object is usable at any site (server) that has a suitable trust path to the object’s root.1. The site receives a request to operate on a global object.
• E.g., AM receives createSliver in slice s
2. Request names the target object with its object credential.
3. Code in the server guard extracts root identity (e.g., root’s public key) from object credential.
4. Site queries local policy to check its trust in the root.
5. Site accepts policy rules from the object’s root.
6. Site queries to check that caller possesses the required OSR for the operation, according to the root’s policy.
7. Site local policy may impose additional constraints, which may consider other info in the object credential.
Transitive object bindings
• How is a slice bound to a project?– The slice definition credential can bind the object to an OSR for the
project: SA.slices_xs.
• But then the slice credential for s includes an OSR for a different object (the project x)! Is that OK?– The slice credential must have the PA’s key in it somewhere, to
qualify the project name x.
– SA can issue policy rules for s that delegate directly to PA, using the PA key. AM does not need to know or care, since any inferences are made in the context of PA’s policy rules.
– But if site-local policies consider the project, then the slice credential should reference the object credential for x, and the AM must retrieve it.
Example: Binding a slice to a project
SASlice credential binds s to PA.x.
SA.slices_xs
Root(x) = PA
Object Definition Credential
Policy rules
Owner Credential
Capability rulesetExperimenter accountabilityGOC kill switchAND PA.eligible_x
SA ruleset delegates to PA: PA may limit who is eligible to operate on slices bound to PA.x.