Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Sponsored by the National Science Foundation GEC17 Developer Sessions: ABAC: Life after Speaks-For Marshall Brinn, GPO July 22, 2013."— Presentation transcript:

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

2 Sponsored by the National Science Foundation2 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.

3 Sponsored by the National Science Foundation3 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?

4 Sponsored by the National Science Foundation4 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

5 Sponsored by the National Science Foundation5 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.

6 Sponsored by the National Science Foundation6 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?

7 Sponsored by the National Science Foundation7 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

8 Sponsored by the National Science Foundation8 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:

9 Sponsored by the National Science Foundation9 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

10 Sponsored by the National Science Foundation10 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

11 Sponsored by the National Science Foundation11 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.

12 Sponsored by the National Science Foundation12 BACKUP

13 Sponsored by the National Science Foundation13 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?

14 Sponsored by the National Science Foundation14 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

15 Sponsored by the National Science Foundation15 How is it decided who gets what role?

16 Sponsored by the National Science Foundation16 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

17 Sponsored by the National Science Foundation17 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

18 Sponsored by the National Science Foundation18 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"]}

19 Sponsored by the National Science Foundation19 Roles to Rights def 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

20 Sponsored by the National Science Foundation20 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 “*”

21 Sponsored by the National Science Foundation21 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

22 Sponsored by the National Science Foundation22 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

23 Sponsored by the National Science Foundation23 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]

24 Sponsored by the National Science Foundation24 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)]

25 Sponsored by the National Science Foundation25 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?


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

Similar presentations


Ads by Google