Presentation is loading. Please wait.

Presentation is loading. Please wait.

D u k e S y s t e m s Authorization Framework: Status Jeff Chase Duke University.

Similar presentations


Presentation on theme: "D u k e S y s t e m s Authorization Framework: Status Jeff Chase Duke University."— Presentation transcript:

1 D u k e S y s t e m s Authorization Framework: Status Jeff Chase Duke University

2 ABAC in GENI ABAC is a powerful declarative representation that can capture the GENI authorization/trust model. It saves a lot of code, provides a rigorous foundation, and preserves flexibility for future innovation. It should be easy for users, although we need some better tools there. (E.g., to delegate rights.) Libabac “works off the shelf” (RT0 does...RT2 too) In progress: policies for safe operational deployment. New http://groups.geni.net/geni/wiki/AuthStoryBoard GEC-12 Auth Session

3 Cloud-Based Credential Store IdP Issue user credentials PA Create project SA Register user Issue project x credentials Create slice in x Issue slice s credentials Create sliver in s 1 3 5 24 Delegate End-to-end credential flow

4 Create sliver for slice SA.s SA AM Policy mobility: a scenario SA.creator_s  T IdP.geniUser  T Anyone can create a sliver for a slice SA.s if s was approved by an SA I trust, and the request conforms to slice policies. Only the creator of a slice s may create a sliver for s.......or a delegate of the creator... Subject to the policies of the project that contains the slice..

5 Multi-federation? AM An aggregate might choose to affiliate with multiple federations.

6 Multi-federation AM To the extent that AMs overlap in the coordination services they affiliate with, those services should work to coordinate them… …even if the aggregate’s affiliation is not exclusive.

7 Multi-federation AM Federations may merge or split. There might be multiple instances of each kind of service within a federation. To the extent that AMs affiliate with shared coordination services, those services should work to coordinate those AMs.

8 I stopped there...the rest is background.

9 IdP PA Create project SA Register user Delegate project membership Create slice in x AM Create sliver in in s Verify user identity, obtain attributes, check that user is qualified, execute agreement. Verify that user is authorized to create project and act as project leader. Verify that project x is valid and user is authorized to create slice in project x. Verify that slice s is valid and user is authorized to request resources for s. 12 3 4 5 IdP: Identity Provider PA: Project Authority SA: Slice Authority

10 IdP Issue user credentials PA Create project Project x created SA Register user user registered Delegate Issue project credentials project credentials Create slice in x Slice s created Issue slice credentials AM Create sliver in in s 12 3 4 5 It’s all about credential flow

11 Create sliver for slice SA.s SA AM Policy mobility: a scenario SA.creator_s  T IdP.geniUser  T Anyone can create a sliver for a slice SA.s if s was approved by an SA I trust, and the request conforms to slice policies. Only the creator of a slice s may create a sliver for s.......or a delegate of the creator... Subject to the policies of the project that contains the slice..

12 Policy mobility: a scenario PA Any approved GENI user who is also a faculty member can create/lead a project. The project leader may delegate membership in the project to any GENI user. Any project member may create a slice for the project. SA Anyone can create a slice for a project PA.x if x was approved by a PA I trust, and the request conforms to project policies. Only the creator of a slice s may create a sliver for s, or a delegate of the creator, consistent with project policies.

13 Cloud-based credential storage Concept: always-on, highly available credential store. The store is lightly trusted: it cannot forge credentials, but we must trust it not to “forget” them. Server Put issued credentials and policies (certs) in the store. Get certs to “cache or check”. Pass credentials by reference in request. Cert Store See also: Conchord, CERTDIST

14 Bidirectional trust based on agreements GENI Operations and Control GENI trust structure: overview (v1.0) CH AM Users and tools Principals are users and organizations, and tools or servers acting on their behalf. Users create global slices and request aggregates to bind local resources to those slices.

15 GENI trust structure: overview (v2.0) AM GOC Each of these entities may: – Speak with its own keypair. – Wield credentials. – Produce/consume credentials. There are limited trust relationships among them. Trust reflects agreements, and is limited by their scope. Credentials capture this trust. Trust may be transitive. Transitive trust is inferred from facts and policy rules. GMOC I&M AMs trust the coordinators, transitively. GENI “clearinghouse” Example coordinators: identity and authorization services for a federation.

16 Declarative trust structure AM GOC This is a trust graph. – Edges represent partial trust by source entity in the target. We can capture trust graphs in a delegation logic. o Some out-edges are facts given by an entity’s local operator. o The others are inferred locally by applying locally accepted policy rules to facts. GMOC I&M Given a suitable trust management framework the trust delegations and policies for inferring trust (by finding trust paths) may be specified declaratively and checked automatically.


Download ppt "D u k e S y s t e m s Authorization Framework: Status Jeff Chase Duke University."

Similar presentations


Ads by Google