Sponsored by the National Science Foundation ABAC and GPO Clearinghouse Authorization Marshall Brinn, GPO GEC20: June 22, 2014

Sponsored by the National Science Foundation2 Overview The GPO Clearinghouse (CHAPI) adheres to the Federation Services API v2 –Including Registry, Member Authority and Slice Authority services The calls are like AM API calls in that they are: –Communicated via XMLRPC/SSL –Authenticated against a set trust root certs We use ABAC as the mechanism to Authorize calls: Specifying policies as well as determining authorization –This presentation provides some detail on how this works

Sponsored by the National Science Foundation3 ABAC Essentials ABAC (Attribute-based Access Control) provides a mechanism for creating assertions and proving queries against these assertions In order to authorize calls in CHAPI, we consider two kinds of assertions –Attributes: Claims about some entity “Joe is a member of project FOO” –Policies: Claims about members of sets “The lead or admins or members of a given project may create slices in that project” By gathering and reasoning on proper sets of assertions and policies, we can make authorization decisions –“May Joe create slices in project FOO?”

Sponsored by the National Science Foundation4 ABAC-Guard Authorization For a given method invocation –Determine the “subjects” (unique identities) on which the method seeks to operate (e.g. a list of slices or projects or members) –Gather the ‘context-free’ assertions about the caller E.g. “AUTHORITY.IS_OPERATOR  CALLER” –For each subject, Gather the assertions that are true in the context of that subject –E.g. “AUTHORITY.IS_MEMBER_$SLICE  CALLER” Instantiate the policies for this method and subject Try to prove either: – “AUTHORITY.MAY_$METHOD  CALLER” –“AUTHORITY.MAY_$METHOD_$SUBJECT  CALLER” The call is authorized iff either proof succeeds for each subject

Sponsored by the National Science Foundation5 Externalized Policies CHAPI authorization rules (what policies and attributes to try to assert) are stored externally –In a set of JSON files that are parsed at service initialization time We can edit these policies and modify ongoing Service behavior –NOT requiring a restart of the given (MA, SA) service This capability has been ‘live’ since GEC19.

Sponsored by the National Science Foundation6 Example "create_slice" : { "__DOC__" : "Operators, project Leads, members, admins may create slice", "assertions" : [ "ME.IS_$ROLE_$PROJECT<-CALLER" ], "policies" : [ "ME.MAY_$METHOD<-ME.IS_OPERATOR", "ME.MAY_$METHOD_$PROJECT<-ME.IS_LEAD_$PROJECT", "ME.MAY_$METHOD_$PROJECT<-ME.IS_ADMIN_$PROJECT", "ME.MAY_$METHOD_$PROJECT<-ME.IS_MEMBER_$PROJECT" ] } def create_slice(self, credentials, options): Consider the SA method create_slice: The following JSON represents the ABAC policies applied to authorize an invocation of create_slice: Think of these as “OR”ed. We seek any path leading to a proof. Each of these is asserted IF TRUE

Sponsored by the National Science Foundation7 Example: Project Member Tries to Create Slice

Sponsored by the National Science Foundation8 Editing Policy (from slice_authority_policy.json) "create_slice" : { "__DOC__" : "Operators, project Leads, members, admins may create slice", "assertions" : [ "ME.IS_$ROLE_$PROJECT<-CALLER" ], "policies" : [ "ME.MAY_$METHOD<-ME.IS_OPERATOR", "ME.MAY_$METHOD_$PROJECT<-ME.IS_LEAD_$PROJECT", "ME.MAY_$METHOD_$PROJECT<-ME.IS_ADMIN_$PROJECT", "ME.MAY_$METHOD_$PROJECT<-ME.IS_MEMBER_$PROJECT" ] } "create_slice" : { "__DOC__" : "Operators, project Leads, members, admins may create slice", "assertions" : [ "ME.IS_$ROLE_$PROJECT<-CALLER" ], "policies" : [ "ME.MAY_$METHOD<-ME.IS_OPERATOR", "ME.MAY_$METHOD_$PROJECT<-ME.IS_LEAD_$PROJECT", "ME.MAY_$METHOD_$PROJECT<-ME.IS_ADMIN_$PROJECT” ] } INFO:chapi:SA: Policy File Changed: /etc/geni-chapi/slice_authority_policy.json

Sponsored by the National Science Foundation9 Before Policy Edit

Sponsored by the National Science Foundation10 After Policy Edit

Sponsored by the National Science Foundation11 A few details… Due to ABAC syntax rules, entities are referenced in these ABAC rules by a ‘flattened’ version of their URN Determining the ‘subjects’ of a given call requires searching both –‘options’ argument (‘match’ and ‘fields’ elements) –‘arguments’ dictionary composed of other API call arguments, e.g. {‘project_urn’ : “urn:publicid:IDN+ch.geni.net+project+MYPROJ”} urn:publicid:IDN+ch.geni.net+user+mbrinn  urn_publicid_IDN_ch_geni_net_user_mbrinn

Sponsored by the National Science Foundation12 Summary ABAC is a powerful and efficient mechanism to express and enforce AuthN policies –Our experience using ABAC in CHAPI has shown that it is sufficiently expressive and performant for our needs ABAC also allows for a common representation of signed assertions –Enabling coordinated/distributed policy management by passing asserts among trusted partners –We encourage others (Services, Aggregates) to explore using ABAC for their respective AuthN needs For more information about –ABAC: –Federation API: –GPO Clearinghouse: