Sponsored by the National Science Foundation GEC17 Developer Sessions: ABAC: Life after Speaks-For Marshall Brinn, GPO July 22, 2013

Sponsored by the National Science Foundation

GEC17 Developer Sessions:ABAC: Life after Speaks-For

Marshall Brinn, GPO

July 22, 2013

Sponsored by the National Science Foundation 2

Overview

• This session is intended to explore approaches to Authorization (AuthZ) in GENI– What do we do now?– What do we want to do?– What are we able to do?– What do we plan to do?

Given that we’ve agreed to implement a solution to the ‘speaks-for’ problem using ABAC, I suggest we specifically look at how this might (or might not) impact how we answer these questions.


A little Framing

• GENI has (at least) two different points of Authorization:– At Clearinghouse (Slice Authority, Member Authority)– At Aggregates

• Every aggregate is free to make its own AuthZ policy decisions

– Some tools have their own authorization schemes

• The main questions AuthZ seeks to answer is:– What methods are you (the experimenter, the caller)

allowed to invoke?• In what context?• With what arguments?


Two Essential Schemes

• Role-based Access Control (RBAC): A person is given a ‘role’ in a given context which permits them to take certain actions– Two tiers: People => Roles, Roles => Permissions

• Attribute-based Access Control (ABAC): A person has attributes (things that are certified to be true about that person) which are mapped to permissions by policy– Single tier: Attributes x Policies => Permissions


RBAC in GENI

• The SFA Credentials we currently use in GENI is an RBAC approach– A Slice Credential is a statement that an experiment

has a ‘role” with respect to a slice• Roles: “bind”, “resolve”, “embed”, “control”, “*”, etc.

– These roles map explicitly onto AM API calls, e.g.• “”embed” => “createsliver”, “renewsliver”, “deletesliver”, etc.


RBAC in GENI [2]

• [Correct me if I’m wrong but….]• I believe that currently we’re barely using the

potential of RBAC in GENI– The SA gives “*” credentials to anyone that asks– The aggregates don’t limit their actions based on role is

in the credential (even if it weren’t “*”)

How do we decide what people get which roles on which slices?Do the aggregates actually obey the permissions of these roles?


RBAC in GENI [3]

• SFA provides a whole framework for delegation– I delegate a credential over to someone else by signing

it with my private key.– Thus giving them the role I have in that credential, and

therefore the associated privileges

• [Correct me if I’m wrong but…]• I don’t think we’re using any actual delegation

anywhere in GENI


So before we discuss ABAC…

• We spend a lot of effort implementing the ABAC mechanisms in Clearinghouses and Aggregates– But no one has any policies other than “*” (or the

equivalent thereof)

• We spend a lot of effort implementing complicated attribute/policy schemes in the Clearinghouse and passing these credentials to aggregates– But the aggregates don’t use them for AuthZ decisions

I would like to avoid two outcomes:


I propose…

• Recall that AM API V3 allows for passing lists of credentials to aggregates– Actually, lists of [type, credential] pairs– So I can have a mix of SFA and ABAC credentials

• I would like to see the GPO CH/SA (at least) send back current SFA-style Slice Credentials and some ABAC attributes that can be passed to AM’s

• Initially, the Aggregates (V3 compliant) should at least be able to ignore the credentials it doesn’t know how to handle– But over time I would like aggregates to be able to use

the ABAC attributes and their own policies to implement (or augment) their AuthZ policies


ABAC Attributes? What ABAC Attributes?

• A CH holds a number of attributes about users (name, affiliation, email).– None of these, except perhaps affiliation which isn’t widely

available or uniform, are likely candidates on which to base policy

• Despite the unfortunate name-collision, the GPO CH has a notion of ‘roles’ for members of slices and projects– I’d suggest providing an attribute saying “X has role R in slice S”

(or similar).– Then an aggregate COULD make ABAC policies to say, e.g.

• “Leads” can create, delete, renew or update slivers• “Members” can create, delete, renew slivers• “Auditors” can only list slivers


Discussion

• This session is intended to explore approaches to Authorization (AuthZ) in GENI– What do we do now?– What do we want to do?– What are we able to do?– What do we plan to do?

• Please join in!– I’ve particularly asked representatives from the ABAC,

InstaGENI and ExoGENI teams to contribute their $.02.


BACKUP


• What do we have?• What do we want?• Separate out the goals/requirements from

implementation• We have two perfectly good schemes:

– SFA creedentials (RBAC)– ABAC credentials and engine (ABAC)

• But what do we want and need? How do we decide?


• Every aggregate is independent and can make its own AuthZ decisions– Who is entitled to make which AM API calls, and thus

have access to various resources


• How is it decided who gets what role?


RBAC

• Three essential rules– Role assignment: A subject can exercise a permission if the

subject has been assigned a role– Role authorization: A subject’s active role must be authorized for

the subject. With rule 1 above, this rule ensures that users can take on only roles for which they have been authorized

– Permission delegation: A subject can exercise a permission only if the permission is authorized for the subject’s active role. With rules 1 and 2, this ensures that users can exercise only permissions for which they are authorized

– Two tier authorization: Subject to Role, Role to Permission


Delegation

• A permission is that of delegation, which allows someone to delegate their permissions to another– This is different from bestowing on someone else a role

directly.– It is essentially saying “Whatever I can do, they can

do”, at least in the context of a particular role.– The


RBAC : SFA

privilege_table = {"authority": ["register", "remove", "update", "resolve", "list", "getcredential", "*"],

"refresh": ["remove", "update"], "resolve": ["resolve", "list", "getcredential"], "sa": ["getticket", "redeemslice", "redeemticket",

"createslice", "createsliver", "deleteslice", "deletesliver", "updateslice",

"getsliceresources", "getticket", "loanresources", "stopslice", "startslice", "renewsliver",

"deleteslice", "deletesliver", "resetslice", "listslices", "listnodes", "getpolicy", "sliverstatus"],

"embed": ["getticket", "redeemslice", "redeemticket", "createslice", "createsliver", "renewsliver", "deleteslice",

"deletesliver", "updateslice", "sliverstatus", "getsliceresources", "shutdown"],

"bind": ["getticket", "loanresources", "redeemticket"], "control": ["updateslice", "createslice", "createsliver",

"renewsliver", "sliverstatus", "stopslice", "startslice", "deleteslice", "deletesliver", "resetslice",

"getsliceresources", "getgids"], "info": ["listslices", "listnodes", "getpolicy"], "ma": ["setbootstate", "getbootstate", "reboot",

"getgids", "gettrustedcerts"], "operator": ["gettrustedcerts", "getgids"], "*": ["createsliver", "deletesliver",

"sliverstatus", "renewsliver", "shutdown"]}


Roles to Rightsdef determine_rights(type, name): rl = Rights()

# rights seem to be somewhat redundant with the type of the credential. # For example, a "sa" credential implies the authority right, because # a sa credential cannot be issued to a user who is not an owner of # the authority if type == "user":

rl.add("refresh")rl.add("resolve")rl.add("info")

elif type in ["sa", "authority+sa"]:rl.add("authority")rl.add("sa")

elif type in ["ma", "authority+ma", "cm", "authority+cm", "sm", "authority+sm"]:rl.add("authority")rl.add("ma")

elif type == "authority":rl.add("authority")rl.add("sa")rl.add("ma")

elif type == "slice": rl.add("refresh") rl.add("embed") rl.add("bind") rl.add("control") rl.add("info")# wouldn't that be authority+cm instead ? elif type == "component": rl.add("operator") return rl


• What we want to avoid– CH makes ABAC credentials but they aren’t used by

Aggregates– CH makes ABAC credentials but all anyone wants is “*”


• Speaks for is a reasonable use case• What are other use cases

– # of resources – Resource allocation policy– Differentiate based on signer (UKY vs. CH.GENI.NET)– Reserve a large chunk of resources

• AM API V3 – Receive ABAC credentials• Not getting strong feedback from resource users

and owners for policies– Maybe this isn’t a problem

• Maybe Internet2 will want this


• Role on slice– Lead, Admin, Member, Auditor, Operator : ATTRIBUTE– Read, Write, Use, Delegate : PRIVILEGE– Create_slice, etc. : ACTION– ASSERTION– CONTEXT_TYPE– POLICY

• AM API V3• ROLE X POLICY X PRIVILEGE => ACTIONS

– Read/Write

• RBAC : Bind Role, Embed Role• ABAC : Lead


• Tom is a LEAD on slice X• Tom has READ access on slice X• Tom may perform create_sliver on slice X

• CH returns a list of credentials not just a slice credential– Typed [SFA : sfa_credential, ABAC : abac_credential]


• EG only implements V2: what to do?• OMNI

– Only send SFA credentials to EG (V2)– Send a list of SFA and ABAC (untagged) – Send a list of tagged SFA and ABAC (tagged)

• CH API – Return list of credentials– Create Slice– Lookup Slice => Get YOUR slice credential– => List of credentials [Slice Credential + ABAC

Assertion (you are a member of this slice)]


• Examples• These resources are only for this tutorial

– Or for Kentucky students

• WE are going to create abac and use ABAC internally, and for speaks-for and we’re going to generate ABAC credentials

• It would be good if the Aggregates were to consume these

• What should we be sending– Something analogous to user and slice creds?

Documents

Sponsored by the National Science Foundation GEC17 Developer Sessions: ABAC: Life after Speaks-For Marshall Brinn, GPO July 22, 2013