Towards Uniform Clearinghouse APIs

1. Towards Uniform Clearinghouse APIs GEC17 Developer Working Sessions July 23, 2013 0830-1030

2. Overview • This session is to discuss the effort to design and implement a common API for GENI-compatible Clearinghouses • What is a Clearinghouse (CH) ? • Why do we want a common CH API? • What might a common API look like?

3. What is a Clearinghouse? A Federationis a human activity of collaboration and trust among organizations, subject to certain policiesand agreements. A Clearinghouseprovides a collection of services that facilitates this collaboration and trust by ensuring these policies and agreements.

4. What is a Clearinghouse [2]? • Credentials are signed statements about people: Both assertions (what is true about this person) or policy (what is permitted about this person) • Services that mint and manage credentials are called Authorities. We have two kinds in GENI: • Member Authority: Generate User Credentials • What attributes are associated with a person • Slice Authority: Generate Slice Credentials • What a person may do on a slice

5. What is a Clearinghouse? [3] • A Federation is comprised of a set of collaborating organizations • The CH is a collection of the Aggregates and Authorities of these collaborating organizations that are selected to participate in this Federation • The CH provides directory services for looking up Federation Aggregates and Authorities • It is the source of trust root(s) for a given federation

6. What is a Clearinghouse? [4] • Clearinghouses are independent • No trust relationship exists between them • Members or Slices defined at the authorities in one CH are not necessarily recognized at another

7. Entity Relationships An aggregate can be a member of multiple CH’s AM-2 AM-3 AM-1 A CH can have multiple Authorities, and multiple AM’s. CH-2 CH-1 An authority can be a member of multiple CH’s MA-A MA-B SA-B SA-A A slice is a member of exactly one SA An experimenter is a member of exactly one MA

8. Why do we want a common CH API? • Many federations out there, each with their own authorities, and interfaces • In GENI, we have the GPO and PG CH • FIRE and OFELIA are working on setting up their own • Other international efforts underway • Need to support federations that are generated “on the fly” to represent time-limited initiatives • We want GENI tools to be able to be able to go to a CH (or any of a list of CH’s) and be able to interact with them in a uniform way

9. Clearinghouse API – Brief Overview • A CH API consists of these pieces: • The Clearinghouse API itself • The APIs of the Authorities available through the CH • Slice Authority (SA) API • Member Authority (MA) API • No need to specify the API of the aggregates that belong to a CH: this is the AM API The common CH API is still being edited and reviewed. A draft will be available shortly on the GENI wiki.

10. Clearinghouse API • Directory Services • getAuthorities: Get list of associated MA’s and SA’s (by URL plus some additional descriptive meta-data) • Selected by optional match criteria • getAggregates: Get list of associated aggregates (by URL plus some additional descriptive meta-data) • Selected by optional match criteria • Reverse Lookup: Find the authority associated with a given URN • Trust Root Services: • getTrustRoots: Get list of trust roots assocaited with the CH (that any member of the federation should take and insert into their own trust bundle).

11. Slice Authority API • Manage Slice Objects • Create, Renew, Update, Lookup • Slice Credentials • getCredentials: get credentials for given user relative to given slice • May be SFA Slice Credentials or ABAC Credentials or some other form supported by CH • Optional • Slice Membership • Projects and Project Membership • Slivers per Slice [Non-authoritative]

12. Member Authority API Breaking up the member information into these chunks enables different MA’s to apply different authorization/access policies to different kinds of information. • Lookup_publicmember_info Certificate, public SSH, SSL keys • Lookup_private_member_info • Private SSL, SSH keys • Lookup_identifying_member_info • Name, email, affiliation Creating/setting this member information is out-of-band: no common public I/F provided.

13. Diversity across CH’s • Note that not all CH’s will have the same object models and support the same services • Each may support a ‘slice object’ but may associate CH-unique attributes • Some may support slice-membership or projects, others may not • We want the CH/Authority API’s to support these kinds of variability • CHs/Authorities should support a get_version method that advertises its essential services and object models

14. Generic CH Object Model Slice Member: SLICE_URN: URN MEMBER_URN: URN ROLE: STRING Slice has many members of different roles Slice: SLICE_URN: URN SLICE_UID: UID SLICE_NAME: STRING SLICE_CREDENTIAL: CREDENTIAL SLICE_DESCRIPTION: STRING SLICE_EXPIRATION: UTC SLICE_EXPIRED : BOOLEAN SLICE_CREATION: UTC SLICE_EMAIL: EMAIL Member: MEMBER_URN: URN MEMBER_UID: UID MEMBER_FIRSTNAME: STRING MEMBER_LASTNAME: STRING MEMBER_CREDENTIAL: CREDENTIAL MEMBER_EMAIL: EMAIL Required Optional 1 : N N : 1 Project has many members of different roles N Credential: MEMBER_URN: CREDENTIAL SUBJECT: URN OBJECT: URN PREDICATE: STRING Project: PROJECT_URN: URN PROJECT_UID: UID PROJECT_NAME: STRING PROJECT_DESCRIPTION: STRING PROJECT_EXPIRATION: UTC PROJECT_EXPIRED: BOOLEAN PROJECT_CREATION: UTC PROJECT_EMAIL: EMAIL Project Member: PROJECT_URN: URN MEMBER_URN: URN ROLE: STRING Member Key: MEMBER_URN: URN KEY_ID: INT KEY_NAME: STRING KEY_TYPE: STRING KEY_VALUE: STRING ENCRYPTION_TYPE: STRING PUBLIC: BOOLEAN