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.