1 / 21

Digital Object Architecture

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.

luz
Download Presentation

Digital Object Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. GENI Federated Clearinghouse Spiral 1 Effort

  4. Resource Discovery Adapt in the Backend Cluster A Cluster B Discover & Access Discover & Access Adapt Adapt ? Interoperability Layer Discover & Access Discover & Access Cluster B Experimenter Cluster A Experimenter

  5. GENI Federated Clearinghouse (GFC) • Spiral 1: • Defined a basic data model of the GFC • Implemented a prototype of the GFC that federates records from ProtoGENI • 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

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

  7. GFC Homepage

  8. Resource Search Results

  9. Resource Record

  10. Namespace 10510 … 10510.0 (GPO) 10510.1 (TIED) 10510.3 (ProtoGENI) 10510.n … 10510.3.0 (Sandbox) 10510.3.1 (University of Utah Node) 10510.3.2 (University of Wisconsin Node) 10510.3.3 (University of Kentucky Node) 10510.3.4 (University of Washington Node) 10510.3.n For example, University of Wisconsin component identifier: 10510.3.2/2f61b3fe-22cb-102c-a837-00304868a4be-r-c7300-32-c Issued/Used by ProtoGENI Clearinghouse

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

  12. Security Model Spiral 1 Effort

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

  14. Proposed Security Model Trusted user claim False claim by an intruder 1. Claims to be 10510.3.1/456 1. Falsely Claims to be 10510.3.2/789 3. Issues PKI Challenge 4. Successfully Responds 3. Issues PKI Challenge 2. Trusts 10510.3.1/* & Retrieves Public Key 2. Trusts 10510.3.2/* & Retrieves Public Key 4. Fails the Challenge GENI Trusted Handle Services Organization Y 10510.3.2/* Organization X 10510.3.1/* 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 3. Denies the Claim GENI Service A GENI Service B GENI Service D GENI Service C

  15. Proposed Security Model • Complete details of the proposed model is available here: http://groups.geni.net/geni/attachment/wiki/DigitalObjectRegistry/ClearinghouseSecurityReqmnts.pdf • The model allows users to claim their identifiers (handles) explicitly or implicitly using certificates • The model requires trusting the Handle System • caBIG, 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

  16. Spiral 1 Integration Issues • GFC • Other than ProtoGENI, 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

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

  18. GENI Experiment Management Service (GEMS) Spiral 2 Effort

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

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

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

More Related