1. D u k e S y s t e m s Building the GENI Federation with ABAC: Going Deeper Jeff Chase Duke University Thanks: NSF TC CNS-0910653

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

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). G1G1 G2G2 AND G3G3 r(C.x) 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.

5. Wrapping ABAC X.509 cert lib G1G1 G4G4 G3G3 G2G2 libabaccert store lib GeniAuth guard toolkit 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: 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

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. PA Create project SA Delegate project credentials Create slice in PA.x AM Create sliver in in SA.s Verify that user is authorized to create project and act as project leader. Issue new project PA.x. Verify that project PA.x is valid and user is authorized to create slice in project PA.x. Issue new slice SA.s. Verify that slice SA.s is valid and user is authorized to request resources for SA.s. Authorization G PA G SA G AM

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

9. SA policy/guards: a closer look SA 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. Sample guards for creating a slice G 1 :createSliceFor(PA.x): SA.projectAuthority  PA G 2 :createSliceFor(PA.x): PA.createSliceFor_x How to implement guards like this? G SA G1G1 G2G2 AND G PA G1G1 G2G2 AND PA policy for PA.x G PA : createSliceFor_x: PA.in_x G 1 : in_x: (PA.leader_x).in_x G 2 : in_x: (PA.idp).geniUser Your policies may vary.

10. Unpacking the SA guards (1) G 1 :createSliceFor(PA.x): SA.projectAuthority  PA 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. G SA G1G1 G2G2 AND 1.Which coordinator? PA. Obtain PA’s public key from some object identifier in the request (PA.x). 2.Generate a query for the inference engine: do I trust PA to act as a coordinator for this type of object? SA.projectAuthority  PA? G1G1

11. Unpacking the SA guards (2) G 2 :createSliceFor(PA.x): PA.createSliceFor_x 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). G SA G1G1 G2G2 AND 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? G2G2

12. Evaluating project policy G PA G1G1 G2G2 AND G2G2 To satisfy SA guard G 2, the ABAC inference engine must prove beliefs of PA. PA’s facts and rules regarding createSliceFor_x are available as credentials signed by PA. G PA : PA.createSliceFor_x  PA.in_x G 1 : PA.in_x  (PA.leader_x).in_x G 2 : 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? Other PA facts and rules are needed to infer PA’s trust in the IdP. G PA

13. Global objects G 1 :createSliceFor(PA.x): SA.projectAuthority  PA Let’s review. We got here because this syntax is not valid ABAC. 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 G 1 guard 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 G 2 :createSliceFor(PA.x): PA.createSliceFor_x Guard G 2 delegates policy control for the request on x to its root (PA). G 2 is also part of the global object design pattern. It executes after the pattern’s G 1 guard has verified local trust in the object’s root. G 2 evaluates the root’s policy OSR regarding who is authorized to make a request associated with this object. The G 2 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. Create sliver for slice s Approved AM.createSliver(SA.s)  T SA AM Next example: createSliver authorization SA.creator_s  T IdP.geniUser  T AM authorization policy G 1 :createSliver(SA.s): AM.sliceAuthority  SA G 2 :createSliver(SA.s): SA.createSliver_s SA policy for SA.s G 1 :createSliver_s: SA.creator_s Later we’ll consider more flexible policies for slices. Your policies may vary. T

16. AM policy/guards: a closer look 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. G AM G1G1 G2G2 AND G SA G1G1 AM AM authorization policy G 1 : createSliver(SA.s): AM.sliceAuthority  SA G 2 : createSliver(SA.s): SA.createSliver_s SA policy for slice SA.s G 1 : createSliver_s: SA.creator_s 1.Obtain SA’s public key from the slice identifier in the request (SA.s). 2.Generate a query for the inference engine: do I trust SA to act as a coordinator for this type of object? AM.sliceAuthority  SA? Global object guard G 1 says AM must accept this SA.

17. Unpacking the AM guards 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? G1G1 G2G2 G SA G1G1 G 2 : createSliver(SA.s): SA.createSliver_s Global object guard G 2 says SA sets policy for the slice under the Rule of Object Authority.

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. SA Create slice in PA.x SA.creator_s  T Capability-based protection for slices SA policy for SA.s G 1 :createSliver_s: SA.cap_s 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 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. 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 Experimenter accountability G 2 : (SA.idp).geniUser GOC “kill switch” SA.cap_s  SA.goc The SA may add additional requirements for access. E.g., a GENI-approved SA might add some additional policy provisions for strong central control. GOC 1. Experimenters must register with a GOC-approved IdP and accept the GENI user agreement. 2. GOC or its delegates are empowered to emergency-stop any GENI slice. SA

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. BACKUP 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) G 2 can access the root’s policy rules for the object given its scid.

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 AM Owner credential root

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. Object Definition Credential R.objects  x root 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.cap_x  (R.own_x).cap_x R.own_x  A R.objects  x

28. Object policies 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 Policy rules root AM Owner Credential

29. Object Capabilities Capability delegation R.own O  (R.own O ).own O R.cap O  R.own O Capability confinement R.cap O  (R.own O ).cap O Object Policy Rules root Note: there may be multiple distinct cap_o capability 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. R = root(o) This sample policy is a declarative specification for capability-based access control. Owner Credential R.own O  E

30. Using global objects A global object is usable at any site (server) that has a suitable trust path to the object’s root. 1.The site receives a request to operate on a global object. E.g., AM receives createSliver in slice s 2.Request names the target object with its object credential. 3.Code in the server guard extracts root identity (e.g., root’s public key) from object credential. 4.Site queries local policy to check its trust in the root. 5.Site accepts policy rules from the object’s root. 6.Site queries to check that caller possesses the required OSR for the operation, according to the root’s policy. 7.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 SA Slice credential binds s to PA.x. SA.slices_x  s Root(x) = PA Object Definition Credential Policy rules Owner Credential 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.