Digital Object Architecture Giridhar Manepalli gmanepalli cnri reston va

Digital Object Architecture Giridhar Manepalli gmanepalli@cnri. reston. va. us Corporation for National Research Initiatives http: //www. cnri. net/

Proposed GENI Services • GENI Federated Clearinghouse • Security Model • GENI Experiment Management Service

GENI Federated Clearinghouse Spiral 1 Effort

Resource Discovery Adapt in the Backend Cluster B ss Cluster A Disc Interoperability Layer ove r& ss ce Ac & Di sc ce Ac Cluster A Experimenter ver ? r& ve co Dis ess cc &A pt Ada o sc ov er pt Di Ada Acc ess Cluster B Experimenter

GENI Federated Clearinghouse (GFC) • Spiral 1: – – Defined a basic data model of the GFC Implemented a prototype of the GFC that federates records from Proto. GENI Prototype is made available at http: //geni. doregistry. org/GFC/ Assumed that the GFC service was part of the control framework • Spiral 2: – Plan to integrate with other clusters and make the GFC operational – Assuming that the GFC service is an experimental service not a core control framework component • Goals – To allow resource (and other entities) discovery across clusters – To provide an interoperability layer between various existing clearinghouse models by defining a common mapping model – To provide an open-source clearinghouse software that future, or existing, GENI communities can use

Data Model User Identifier HRN Description Component Resource HRN Identifier Description Contact Identifier Public Key or X 509 Certificate Credentials Aggregate Status Component Manager Identifier Component Identifier Resource Identifier Credentials Identifier HRN Description Aggregate Manager Identifier Component Identifier Aggregate Identifier Service RSpec Slice Sliver Identifier HRN Description Sliver Identifier Slice Identifier Expiration User Identifier Status Credentials Identifier Resource Identifier Owner or Not Type Status Slice Authority Identifier Access Details Public Key or X 509 Certificate Policies Status

GFC Homepage

Resource Search Results

Resource Record

Namespace 10510. 0 (GPO) 10510. 3. 0 (Sandbox) 10510. 1 (TIED) 10510. 3. 1 (University of Utah Node) 10510. 3 (Proto. GENI) 10510. 3. 2 (University of Wisconsin Node) … 10510. n 10510. 3. 3 (University of Kentucky Node) 10510. 3. 4 (University of Washington Node) For example, University of Wisconsin component identifier: 10510. 3. 2/2 f 61 b 3 fe-22 cb-102 c-a 837 -00304868 a 4 be-r-c 7300 -32 -c Issued/Used by Proto. GENI Clearinghouse … 10510. 3. n

Scalability 1. Which Handle Server do I ask for handle 10510. 3. 1/456? 2. Ask Handle Server"1" GFC Client 3. Resolve 10510. 3. 1/456 Global Handle Registry GENI Federated Clearinghouse (GFC) 5. Resolve User 10510. 3. 1/456 6. User Record 4. Handle Record GFC Mirror Handle Server “ 1" Handle Server "X" Organization A Handle Record for 10510. 3. 1/456 Registry Information Type of Record: "User" Stored or not Organization N User Record for 10510. 3. 1/456 HRN Description Contact Public Key or X 509 Certificate Credentials GFC Mirror

Security Model Spiral 1 Effort

Security: PKI • Public Key Infrastructure, an effective and standards-based solution, allows for secure processing of identity claims • Issues – Trust is assumed to be transitive, e. g. , trusting certificate authorities (CA) implies trusting end users – Managing trust stores and revocation lists is manual and ad hoc – Every server part of a common service, e. g. , GENI service, needs to be explicitly synchronized among each other to be effective • Resolution – Need explicit “trust” management mechanism – Need dynamic, synchronized, and distributed management of trust stores

Proposed Security Model Trusted user claim False claim by an intruder 1. Claims to be 10510. 3. 1/456 3. Issues PKI Challenge 1. Falsely Claims to be 10510. 3. 2/789 GENI Service A 4. Successfully Responds 2. Trusts 10510. 3. 1/* & Retrieves Public Key 3. Issues PKI Challenge GENI Service B 2. Trusts 10510. 3. 2/* & Retrieves Public Key 4. Fails the Challenge GENI Trusted Handle Services Organization X 10510. 3. 1/* Organization Y 10510. 3. 2/* Un-trusted user claim Revoked user claim 2. Trusts 10510. 3. 2/* but fails to find the record 1. Falsely Claims to be 10510. 3. 2/abc 1. Claims to be abc/123 2. Does Not Trust abc/* & Denies the Claim GENI Service D GENI Service C 3. Denies the Claim

Proposed Security Model • Complete details of the proposed model is available here: http: //groups. geni. net/geni/attachment/wiki/Digital. Object. Registry/Clearinghouse. Security. Reqmnts. pdf • The model allows users to claim their identifiers (handles) explicitly or implicitly using certificates • The model requires trusting the Handle System – ca. BIG, a Grid application based on the Globus Toolkit (Grid middleware), verified and experimented with the Handle System successfully for service end-point authentication – CHI project, another Grid application using the Globus Toolkit, is currently using/experimenting with the Handle System for identifying metadata records and access controls – Frank Siebenlist, from Argonne National Laboratory, is the POC for the Handle System effort in those two projects

Spiral 1 Integration Issues • GFC – Other than Proto. GENI, no other cluster participated in the federation – Possible reasons: – Supporting the GFC to be a core control framework component may be orthogonal to the clusters’ goals • Clusters have, or soon will have, their own clearinghouses serving the users (so why support another clearinghouse) • Security Model – Unexplored by GENI members, so it’s still an unknown entity

Spiral 2 Integration Plan • GFC – Restate the role of the GFC as an experimental service • Consequently, the GFC does not affect the clusters’ approach to clearinghouses • Security Model – Push the model details to the OMIS group and get it evaluated • Work with the OMIS group to integrate with other clusters

GENI Experiment Management Service (GEMS) Spiral 2 Effort

Experiment Management • Experiments have, and result in, various resources which are related to each other (e. g. specs, logs, software, etc. ) • Packaging those resources together (logically) is important while archiving, in order to reuse, repurpose, or reanalyze – Those resources, however, exist on multiple platforms and environments • Solution: A unified service that establishes the relationship between various resources and that integrates with heterogeneous repositories would meet these requirements

GENI Experiment Management Service Experiment ID 1 Experiment ID 2 Specification ID X Source code ID Y Logs/Results ID A Logs/Results ID B I need to know about Experiment with ID 1. Access Layer Experiment Relationship Graph of Related Logs Regular User Experiment Relationship Graph of Related Documents Trac Graph of S/W Dependencies Graph of Related Logs Experiment Relationship Definition Layer Here are the logs. Tool Logs Source Code Here is the source code. Experimenter Subversion Repository Infrastructure Administrator File System/ Amazon S 3 Digital Object Repository

Spiral 2 Integration Plan • Host an Experiment Repository for GENI members – Done! • Develop a prototype demonstrating the GEMS capability – Done! • Work with both the Experiment and OMIS working groups to define an interface for the GENI Experiment Management Service, involving experimenters from various clusters