Towards Uniform Clearinghouse APIs

Sponsored by the National Science Foundation

Towards Uniform Clearinghouse APIs

GEC17 Developer Working Sessions

July 23, 2013 0830-1030

Sponsored by the National Science Foundation 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?


What is a Clearinghouse?

A Federation is a human activity of collaboration and trust among organizations, subject to certain policies and agreements.

A Clearinghouse provides a collection of services that facilitates this collaboration and trust by ensuring these policies and agreements.


What is a Clearinghouse [2]?

• 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

Credentials are signed statements about people: Both assertions (what is true about this person) or policy (what is permitted about this person)


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


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


Entity Relationships

CH-1 CH-2

SA-A SA-B MA-BMA-A

AM-1 AM-3AM-2

An authority can be a member of multiple CH’s

A CH can have multiple Authorities, and multiple AM’s.

An aggregate can be a member of multiple CH’s

A slice is a member of exactly one SA

An experimenter is a member of exactly one MA


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


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.


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


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]


Member Authority API

• Lookup_public member_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.

Breaking up the member information into these chunks enables different MA’s to apply different authorization/access policies to different kinds of information.


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


Generic CH Object Model

Slice:SLICE_URN: URNSLICE_UID: UIDSLICE_NAME: STRINGSLICE_CREDENTIAL: CREDENTIALSLICE_DESCRIPTION: STRINGSLICE_EXPIRATION: UTCSLICE_EXPIRED : BOOLEANSLICE_CREATION: UTCSLICE_EMAIL: EMAIL

Member:MEMBER_URN: URNMEMBER_UID: UIDMEMBER_FIRSTNAME: STRINGMEMBER_LASTNAME: STRINGMEMBER_CREDENTIAL: CREDENTIALMEMBER_EMAIL: EMAIL

Project:PROJECT_URN: URNPROJECT_UID: UIDPROJECT_NAME: STRINGPROJECT_DESCRIPTION: STRINGPROJECT_EXPIRATION: UTCPROJECT_EXPIRED: BOOLEANPROJECT_CREATION: UTCPROJECT_EMAIL: EMAIL

Project Member:PROJECT_URN: URNMEMBER_URN: URNROLE: STRING

Slice Member:SLICE_URN: URNMEMBER_URN: URNROLE: STRING

Member Key:MEMBER_URN: URNKEY_ID: INTKEY_NAME: STRINGKEY_TYPE: STRINGKEY_VALUE: STRINGENCRYPTION_TYPE: STRINGPUBLIC: BOOLEAN

Credential:MEMBER_URN: CREDENTIALSUBJECT: URNOBJECT: URNPREDICATE: STRING

Required

Optional

N : 1

1 : N

N

Slice has many members of different roles

Project has many members of different roles

Documents

Towards Uniform Clearinghouse APIs