Building the GENI Federation with ABAC: Going Deeper

1. Building the GENI Federation with ABAC: Going Deeper Jeff Chase Duke University Thanks: NSF TC CNS-0910653

2. Reading the slides GENI users Test Tube Guy and Dr. D, and some of their credentials A A generic principal IdP.studentT IdP.facultyD A coordination service implementing some clearinghouse function, such as a Slice Authority AM SA Indicates trust of one principal in another, often associated with some kind of formal agreement: Indicates a request Aggregate Indicates credential flow

3. Overview • Show how to implement authorization guards in the GENI trust graph. • Assume familiarity with revisionist (“v2”) GENI trust graph. • Assume familiarity with ABAC representations and guards. • See Building the GENI Federation with ABAC slide deck. • Show how to implement flexible guards for declarative policy using the ABAC inference engine. • Show how to implement a rich policy: SFA capabilities with GENI safety restraints.

4. Guards and ABAC • A guard predicate is typically an ABAC role or attribute that can be checked automatically by an inference engine. • We break them out so that we can talk about them separately without writing down the conjunctions (long ABAC “type 4” rules). • Also, we want to allow more general guards whose predicates are evaluated outside of ABAC. • Or guards that generate an ABAC query “on the fly” from a template, based on other info in the request. • Or guards that modify the request, e.g., degrade the class of service if a particular credential is missing. r(C.x) G1 <predicate 1> AND G2 <predicate 2> AND G3 <predicate 3>

5. Wrapping ABAC • Build a simple framework for pluggable guards. • Most guards use ABAC to interpret policies and credentials. • But guards may also employ custom logic including some minimal custom code and calls to other tools: G1 G4 G3 G2 • Interpreters for XML signing and credential formats • API to TLS/message layer for authentication • Template engine to generate ABAC rules on the fly • ABAC query templates • Lib to fetch/cache certificates GeniAuth guard toolkit cert store lib X.509 cert lib libabac

6. What is this wrapper? • We need a way to represent and implement policies and guards that are “mostly declarative”. • Views the ABAC inference engine as a subroutine. • Opens the possibility that we can supplement simple ABAC delegation logic (RT0 or RT1) with a sprinkle of code. • The sprinkling of new code enables useful policies that might otherwise require a more powerful logic. • Example: “RT2-lite” slice credentials for GENI, represented outside of ABAC. • Hypothesis: a small number of simple off-the-shelf design patterns can supplant the need for a more powerful logic and more complex inference.

7. Authorization GPA GSA Create project Create slice in PA.x Verify that project PA.xis valid and user is authorized to create slice in project PA.x. Issue new slice SA.s. Verify that user is authorized to create project and act as project leader. Issue new project PA.x. PA SA Create sliver in in SA.s GAM AM Delegate project credentials Verify that slice SA.sis valid and user is authorized to request resources for SA.s.

8. Example: createSlice authorization Approved SA.createSliceFor(PA.x)T Create project SA.creator_sT SA authorization policy G1:createSliceFor(PA.x): SA.projectAuthorityPA G2:createSliceFor(PA.x): PA.createSliceFor_x Project x created PA.leader_xD PA SA D Create slice in PA.x PA policy for PA.x G1: createSliceFor_x: PA.in_x G1: in_x: (PA.leader_x).in_x G2: in_x: (PA.idp).geniUser D.in_xT T IdP.geniUserT

9. SA policy/guards: a closer look Sample guards for creating a slice G1:createSliceFor(PA.x): SA.projectAuthorityPA G2:createSliceFor(PA.x): PA.createSliceFor_x Anyone can create a slice for a project PA.x if PA is a Project Authority that I trust and the request conforms to policies for PA.x set by PA. GSA PA policy for PA.x GPA: createSliceFor_x: PA.in_x G1: in_x: (PA.leader_x).in_x G2: in_x: (PA.idp).geniUser Your policies may vary. SA AND G1 G2 GPA AND How to implement guards like this? G1 G2

10. Unpacking the SA guards (1) GSA G1:createSliceFor(PA.x): SA.projectAuthorityPA AND What is PA.x? It is a typed object (a project) whose existence is asserted by some coordinator, and which is visible to all AMs who trust that coordinator and who understand objects of that type. G1 G2 • Which coordinator? PA. Obtain PA’s public key from some object identifier in the request (PA.x). • Generate a query for the inference engine: do I trust PA to act as a coordinator for this type of object? SA.projectAuthorityPA? G1

11. Unpacking the SA guards (2) GSA G2:createSliceFor(PA.x): PA.createSliceFor_x AND What is createSliceFor_x? It is an ABAC RT0 role: a string literal. But it is associated with x: the name x is embedded within it. It does not appear in any static policy: it came into existence when PA created PA.x. It is an object-specific role (OSR). G1 G2 • 3. Generate an OSR delegation rule from a template for this object type. • SA.createSliceFor_xPA.createSliceFor_x • 4. Generate query: does subject possess the OSR? • SA.createSliceFor_xT? G2

12. Evaluating project policy G2 • To satisfy SA guard G2, the ABAC inference engine must prove beliefs of PA. • PA’s facts and rules regarding createSliceFor_x are available as credentials signed by PA. GPA AND G1 G2 GPA: PA.createSliceFor_xPA.in_x G1: PA.in_x(PA.leader_x).in_x G2: PA.in_x(PA.idp).geniUser • SA must fetch and import these rules (credentials) into its inference engine prior to the query in Step 4: • SA.createSliceFor_xT? GPA • Other PA facts and rules are needed to infer PA’s trust in the IdP.

13. Global objects Let’s review. We got here because this syntax is not valid ABAC. G1:createSliceFor(PA.x): SA.projectAuthorityPA • We can implement this “mostly declarative” guard by adding a sprinkle of code around ABAC using an off-the-shelf design pattern. • This design pattern is called global object. The request is associated with an object (x) created by a coordinator (PA), who is the object root for x. • The object x is “globally” visible and has a unique global name PA.x, and perhaps also a URN. PA.x is a self-certifying identifier (scid). • This G1guard is part of the design pattern: it ensures that the object’s root is accepted by the entity evaluating this guard. • We can use the same pattern for slices, which are also global objects.

14. Rule of Object Authority Guard G2 delegates policy control for the request on x to its root (PA). G2:createSliceFor(PA.x): PA.createSliceFor_x • G2 is also part of the global object design pattern. It executes after the pattern’s G1 guard has verified local trust in the object’s root. • G2 evaluates the root’s policy OSR regarding who is authorized to make a request associated with this object. • The G2 guard implements the Rule of Object Authority for global objects: an object’s root sets policy for the object. • The root’s policy guards may reference other coordinators trusted by the root (e.g., IdP), and (transitively) their own policy guards, if any. • Any server using this pattern may add other guards of its own, which may block some requests permitted by the root’s policy.

15. Next example: createSliver authorization Approved AM.createSliver(SA.s)T AM authorization policy G1:createSliver(SA.s): AM.sliceAuthoritySA G2:createSliver(SA.s): SA.createSliver_s Create sliver for slice s AM Your policies may vary. SA SA.creator_sT SA policy for SA.s G1:createSliver_s: SA.creator_s T Later we’ll consider more flexible policies for slices. IdP.geniUserT

16. AM policy/guards: a closer look AM authorization policy G1: createSliver(SA.s): AM.sliceAuthoritySA G2: createSliver(SA.s): SA.createSliver_s Anyone can create a sliver for a slice SA.s if SA is a Slice Authority that I trust, and the request conforms to policies for SA.s set by SA. GAM SA policy for slice SA.s G1: createSliver_s: SA.creator_s AM AND G1 G2 • Obtain SA’s public key from the slice identifier in the request (SA.s). • Generate a query for the inference engine: do I trust SA to act as a coordinator for this type of object? AM.sliceAuthoritySA? GSA Global object guard G1 says AM must accept this SA. G1

17. Unpacking the AM guards G2 G2: createSliver(SA.s): SA.createSliver_s GSA • 3. Generate an OSR delegation rule from a template for this object type. • AM.createSliver_sSA.createSliver_s • 4a. Fetch policy rules and facts for SA.s issued as credentials by SA, and import them into the inference engine. • 4b. Generate query: does the intended subject possess the required OSR? • AM.createSliver_sT? G1 Global object guard G2 says SA sets policy for the slice under the Rule of Object Authority. G1

18. Take a breath • We have shown how an AM can validate a slice while leaving the policy details to the SA. • AM delegates the details of who can operate on the slice (e.g., createSliver) to the SA….or it can add its own guards. • SA may define richer policies on a per-slice basis. • We now discuss a specific example: SA slice policy supporting SFA capabilities with GENI safety rails. • Similarly, an SA can use the same approach to validate a project and leave the policy details to the PA. The PA can define richer policies on a per-project basis. • Left as an exercise.

19. Capability-based protection for slices SA policy for SA.s G1:createSliver_s: SA.cap_s SA.creator_sT This sample policy is a declarative specification for capability-based access control. This policy has one example capability OSR: cap_s. There could be others. Create slice in PA.x Creating user has all rights SA.own_sSA.creator_s SA.cap_sSA.own_s Capability delegation SA.own_s(SA.own_s).own_s Capability confinement SA.cap_s(SA.own_s).cap_s SA T

20. Discussion: capabilities • This policy uses Object-Specific Roles (OSRs). • SA generates OSR rules on a per-slice basis from a template. • No changes are required to the AM: “it just works”. • Slice policy is SA’s choice: SA makes the rules and the AM evaluates them. There is no, repeat it, no specific support for capabilities in the AM. • For slices with this policy, rights to the slice may now be freely delegated by their holders. • This policy allows anyone to hold a capability. • Project Authority policies are still in effect. But the sample PA policy only constrains who can create a slice. Once a slice exists, its rights can be delegated to anyone. • So we may want to add some safety rails…

21. Gelded capabilities for GENI slices The SA may add additional requirements for access. E.g., a GENI-approved SA might add some additional policy provisions for strong central control. 1. Experimenters must register with a GOC-approved IdP and accept the GENI user agreement. Experimenter accountability G2: (SA.idp).geniUser GOC “kill switch” SA.cap_sSA.goc 2. GOC or its delegates are empowered to emergency-stop any GENI slice. SA GOC

22. Implementation points • The SA issues a slice credential, which is passed with a request on the slice. • The global object pattern will work as long as the credential is signed by the SA and has the object’s scid (SA.s) in it. • E.g., we can base the slice credential on Protogeni. • It will be convenient to add an RFC 4122 UUID in addition to the object’s global symbolic name (URN). • Don’t use a URN as the name s: ABAC won’t allow it. • Similarly, PA issues a project credential. • It must be possible to obtain the policy rules for an object given its credential. • E.g., use scid to index a shared credential store.

23. Multi-federation? • What happens if entities mix and match coordinators? • “Everything should work.” • If an entity trusts a coordinator, other entities trusted by that coordinator are incorporated by reference. • SA chooses which PAs to trust, but lets them choose which IdPs to trust to validate users. • AM chooses which SAs to trust, but lets them choose which PAs to trust to validate projects. • Any entity may add its own guards. • E.g., add guards to limit any indirect delegation to coordinators whom that entity does not trust.

24. Here are some older and more abstract slides on the global object design pattern. • This design pattern presumes: (1) the object’s global name (scid) is passed in the request; (2) the guards can retrieve the root public key and object name from the scid, and (3) G2 can access the root’s policy rules for the object given its scid. Backup

25. Global objects • Slices and projects are global objects created by an object root. • root(s) = SA; root(x) = PA • These are GENI-specific examples, but there may be others. • The object’s root: • names the object in a local name space; • issues an object definition credential; • issues policy rules and facts governing access to the object. • Example: a GENI SA issues a slice credential, creator capability, and rules for a capability-based policy (see below). Object Definition Credential Owner credential root AM

26. Object definition credential • R asserts the existence of a named object x rooted in R. • R uses a local name (e.g., a GUID x). • Name is implicitly domain-qualified: R.x. • Based on RT2 o-set credential. • The credential may assert other object attributes for the object x. • More restricted than RT2: • No delegation of object attributes. • No object parameters for predicates. No functions. root Object Definition Credential R.objectsx We can use any convenient format for this credential (e.g., ProtoGENI): the inference engine never sees it.

27. Object-specific roles (OSRs) • R generates roles for each object x. • Each RT0 role name is an atomic string. • Object Specific Roles (OSRs) embed the object name with a standard separator character, e.g., in_x. • OSRs for x define a vocabulary to reason about rights to operate on x. • R issues rules for the new OSRs. • Delegation rules and constraints are generated from a policy template. • [See capability example below.] Object Definition Credential Policy rules Owner Credential R.objectsx R.own_xA R.cap_x (R.own_x).cap_x

28. Object policies root • Rule of Object Authority: a root controls policy for its objects. • Root issues signed policy rules for input to the site inference engine. • Need flexible delegation that allows for suitable constraints. • Note: root has no choice but to trust sites to honor its policy! • Relationships among objects  transitive policy delegation. • E.g., a PA or project leader can issue rules restricting the users of a slice bound to a project. Object Definition Credential Owner Credential AM Policy rules

29. Object Capabilities This sample policy is a declarative specification for capability-based access control. Capability delegation R.ownO(R.ownO).ownO R.capOR.ownO Capability confinement R.capO(R.ownO).capO root R = root(o) Object Policy Rules Owner Credential R.ownOE Note: there may be multiple distinct cap_ocapability attributes (OSRs) that permit different operations on o. An owner of o may delegate each capability independently of the others. The root must define this vocabulary of capability OSRs; the server guards must understand them.

30. Using global objects • A global object is usable at any site (server) that has a suitable trust path to the object’s root. • The site receives a request to operate on a global object. • E.g., AM receives createSliver in slice s • Request names the target object with its object credential. • Code in the server guard extracts root identity (e.g., root’s public key) from object credential. • Site queries local policy to check its trust in the root. • Site accepts policy rules from the object’s root. • Site queries to check that caller possesses the required OSR for the operation, according to the root’s policy. • Site local policy may impose additional constraints, which may consider other info in the object credential.

31. Transitive object bindings • How is a slice bound to a project? • The slice definition credential can bind the object to an OSR for the project: SA.slices_xs. • But then the slice credential for s includes an OSR for a different object (the project x)! Is that OK? • The slice credential must have the PA’s key in it somewhere, to qualify the project name x. • SA can issue policy rules for s that delegate directly to PA, using the PA key. AM does not need to know or care, since any inferences are made in the context of PA’s policy rules. • But if site-local policies consider the project, then the slice credential should reference the object credential for x, and the AM must retrieve it.

32. Example: Binding a slice to a project Slice credential binds s to PA.x. SA Object Definition Credential Owner Credential Policy rules SA.slices_xs Root(x) = PA Capability ruleset Experimenter accountability GOC kill switch AND PA.eligible_x SA ruleset delegates to PA: PA may limit who is eligible to operate on slices bound to PA.x.