GEC17 Developer Sessions: ABAC: Life after Speaks-For

1. GEC17 Developer Sessions:ABAC: Life after Speaks-For Marshall Brinn, GPO July 22, 2013

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.

3. 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. 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. 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. RBAC in GENI [2] How do we decide what people get which roles on which slices? Do the aggregates actually obey the permissions of these roles? • [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 “*”)

7. 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. So before we discuss ABAC… I would like to avoid two outcomes: • 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

9. 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. 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. 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. Backup

13. 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. 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. How is it decided who gets what role?

16. 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. 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. 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. Roles to Rights defdetermine_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. 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. 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. 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. 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. 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. 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?