slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Building the GENI Federation with ABAC: Going Deeper PowerPoint Presentation
Download Presentation
Building the GENI Federation with ABAC: Going Deeper

Loading in 2 Seconds...

play fullscreen
1 / 32

Building the GENI Federation with ABAC: Going Deeper - PowerPoint PPT Presentation


  • 57 Views
  • Uploaded on

Building the GENI Federation with ABAC: Going Deeper. 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. A. A generic principal. IdP. student T. IdP. faculty D.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Building the GENI Federation with ABAC: Going Deeper' - larue


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Building the GENI Federation with ABAC: Going Deeper

Jeff Chase

Duke University

Thanks: NSF TC CNS-0910653

reading the slides
Reading the slides

GENI users Test Tube Guy and Dr. D, and some of their credentials

A

A generic principal

IdP.studentT

IdP.facultyD

A coordination service implementing some clearinghouse function, such as a Slice Authority

AM

SA

Indicates trust of one principal in another, often associated with some kind of formal agreement:

Indicates a request

Aggregate

Indicates credential flow

overview
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
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.
  • 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.

r(C.x)

G1

<predicate 1>

AND

G2

<predicate 2>

AND

G3

<predicate 3>

wrapping abac
Wrapping ABAC
  • 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:

G1

G4

G3

G2

  • 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

GeniAuth guard toolkit

cert store lib

X.509 cert lib

libabac

what is this wrapper
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.
authorization
Authorization

GPA

GSA

Create project

Create slice

in PA.x

Verify that project PA.xis valid and user is authorized to create slice in project PA.x.

Issue new slice SA.s.

Verify that user is authorized to create project and act as project leader.

Issue new project PA.x.

PA

SA

Create sliver in

in SA.s

GAM

AM

Delegate

project credentials

Verify that slice SA.sis valid and user is authorized to request resources for SA.s.

example createslice authorization
Example: createSlice authorization

Approved

SA.createSliceFor(PA.x)T

Create project

SA.creator_sT

SA authorization policy

G1:createSliceFor(PA.x):

SA.projectAuthorityPA

G2:createSliceFor(PA.x):

PA.createSliceFor_x

Project x created

PA.leader_xD

PA

SA

D

Create slice

in PA.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

D.in_xT

T

IdP.geniUserT

sa policy guards a closer look
SA policy/guards: a closer look

Sample guards for creating a slice

G1:createSliceFor(PA.x):

SA.projectAuthorityPA

G2:createSliceFor(PA.x):

PA.createSliceFor_x

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.

GSA

PA policy for PA.x

GPA: createSliceFor_x:

PA.in_x

G1: in_x:

(PA.leader_x).in_x

G2: in_x:

(PA.idp).geniUser

Your policies may vary.

SA

AND

G1

G2

GPA

AND

How to implement guards like this?

G1

G2

unpacking the sa guards 1
Unpacking the SA guards (1)

GSA

G1:createSliceFor(PA.x):

SA.projectAuthorityPA

AND

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.

G1

G2

  • Which coordinator? PA. Obtain PA’s public key from some object identifier in the request (PA.x).
  • Generate a query for the inference engine: do I trust PA to act as a coordinator for this type of object? SA.projectAuthorityPA?

G1

unpacking the sa guards 2
Unpacking the SA guards (2)

GSA

G2:createSliceFor(PA.x):

PA.createSliceFor_x

AND

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).

G1

G2

  • 3. Generate an OSR delegation rule from a template for this object type.
    • SA.createSliceFor_xPA.createSliceFor_x
  • 4. Generate query: does subject possess the OSR?
  • SA.createSliceFor_xT?

G2

evaluating project policy
Evaluating project policy

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

AND

G1

G2

GPA: PA.createSliceFor_xPA.in_x

G1: PA.in_x(PA.leader_x).in_x

G2: 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_xT?

GPA

  • Other PA facts and rules are needed to infer PA’s trust in the IdP.
global objects
Global objects

Let’s review. We got here because this syntax is not valid ABAC.

G1:createSliceFor(PA.x):

SA.projectAuthorityPA

  • 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 G1guard 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
Rule of Object Authority

Guard G2 delegates policy control for the request on x to its root (PA).

G2:createSliceFor(PA.x):

PA.createSliceFor_x

  • 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.
next example createsliver authorization
Next example: createSliver authorization

Approved

AM.createSliver(SA.s)T

AM authorization policy

G1:createSliver(SA.s):

AM.sliceAuthoritySA

G2:createSliver(SA.s):

SA.createSliver_s

Create sliver for slice s

AM

Your policies may vary.

SA

SA.creator_sT

SA policy for SA.s

G1:createSliver_s: SA.creator_s

T

Later we’ll consider more flexible policies for slices.

IdP.geniUserT

am policy guards a closer look
AM policy/guards: a closer look

AM authorization policy

G1: createSliver(SA.s):

AM.sliceAuthoritySA

G2: createSliver(SA.s):

SA.createSliver_s

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

SA policy for slice SA.s

G1: createSliver_s: SA.creator_s

AM

AND

G1

G2

  • Obtain SA’s public key from the slice identifier in the request (SA.s).
  • Generate a query for the inference engine: do I trust SA to act as a coordinator for this type of object? AM.sliceAuthoritySA?

GSA

Global object guard G1 says AM must accept this SA.

G1

unpacking the am guards
Unpacking the AM guards

G2

G2: createSliver(SA.s):

SA.createSliver_s

GSA

  • 3. Generate an OSR delegation rule from a template for this object type.
    • AM.createSliver_sSA.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_sT?

G1

Global object guard G2 says SA sets policy for the slice under the Rule of Object Authority.

G1

take a breath
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.
capability based protection for slices
Capability-based protection for slices

SA policy for SA.s

G1:createSliver_s:

SA.cap_s

SA.creator_sT

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.

Create slice

in PA.x

Creating user has all rights

SA.own_sSA.creator_s

SA.cap_sSA.own_s

Capability delegation

SA.own_s(SA.own_s).own_s

Capability confinement

SA.cap_s(SA.own_s).cap_s

SA

T

discussion capabilities
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
Gelded capabilities for GENI slices

The SA may add additional requirements for access.

E.g., a GENI-approved SA might add some additional policy provisions for strong central control.

1. Experimenters must register with a GOC-approved IdP and accept the GENI user agreement.

Experimenter accountability

G2: (SA.idp).geniUser

GOC “kill switch”

SA.cap_sSA.goc

2. GOC or its delegates are empowered to emergency-stop any GENI slice.

SA

GOC

implementation points
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
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.
Backup
global objects1
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

Owner credential

root

AM

object definition credential
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.

root

Object Definition Credential

R.objectsx

We can use any convenient format for this credential (e.g., ProtoGENI): the inference engine never sees it.

object specific roles osrs
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.objectsx

R.own_xA

R.cap_x

(R.own_x).cap_x

object policies
Object policies

root

  • 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

Owner Credential

AM

Policy rules

object capabilities
Object Capabilities

This sample policy is a declarative specification for capability-based access control.

Capability delegation

R.ownO(R.ownO).ownO

R.capOR.ownO

Capability confinement

R.capO(R.ownO).capO

root

R = root(o)

Object Policy Rules

Owner Credential

R.ownOE

Note: there may be multiple distinct cap_ocapability 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.

using global objects
Using global objects
  • A global object is usable at any site (server) that has a suitable trust path to the object’s root.
    • The site receives a request to operate on a global object.
      • E.g., AM receives createSliver in slice s
    • Request names the target object with its object credential.
    • Code in the server guard extracts root identity (e.g., root’s public key) from object credential.
    • Site queries local policy to check its trust in the root.
    • Site accepts policy rules from the object’s root.
    • Site queries to check that caller possesses the required OSR for the operation, according to the root’s policy.
    • Site local policy may impose additional constraints, which may consider other info in the object credential.
transitive object bindings
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_xs.
  • 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
Example: Binding a slice to a project

Slice credential binds s to PA.x.

SA

Object Definition Credential

Owner Credential

Policy rules

SA.slices_xs

Root(x) = PA

Capability ruleset

Experimenter accountability

GOC kill switch

AND PA.eligible_x

SA ruleset delegates to PA: PA may limit who is eligible to operate on slices bound to PA.x.