1 / 12

ABAC and GPO Clearinghouse Authorization

ABAC and GPO Clearinghouse Authorization. Marshall Brinn, GPO GEC20: June 22, 2014. 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:

milos
Download Presentation

ABAC and GPO Clearinghouse Authorization

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ABAC and GPO Clearinghouse Authorization Marshall Brinn, GPO GEC20: June 22, 2014

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

  3. 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?”

  4. 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 iffeither proof succeeds for each subject

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

  6. Example Consider the SA method create_slice: defcreate_slice(self, credentials, options): The following JSON represents the ABAC policies applied to authorize an invocation of create_slice: "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" ] } Each of these is asserted IF TRUE Think of these as “OR”ed. We seek any path leading to a proof.

  7. Example: Project Member Tries to Create Slice

  8. 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” ] } INFO:chapi:SA: Policy File Changed: /etc/geni-chapi/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" ] }

  9. Before Policy Edit

  10. After Policy Edit

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

  12. 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: http://abac.deterlab.net • Federation API:http://groups.geni.net/geni/wiki/CommonFederationAPIv2 • GPO Clearinghouse: help@geni.net

More Related