Genesis II: From Specification to Implementation

1. “Open Source, OGSA Implementation” Genesis II:From Specification to Implementation Andrew Grimshaw, Mark Morgan Global Bio Grid Team University of Virginia Genesis II “Open Source, OGSA Implementation”

2. Responsible Parties • Andrew Grimshaw • Mark Morgan • John Karpovich • Duane Merrill Genesis II “Open Source, OGSA Implementation”

3. Outline • Background • Genesis II • Demo • Next Steps Genesis II “Open Source, OGSA Implementation”

4. Background • Specifications cannot exist in vacuum • Implementations Vet Specifications • Implementation experience shows how spec’s interact • Grids have been around for a while, but adoption remains low – why? • Usability • Gap between grid designers and grid users Genesis II “Open Source, OGSA Implementation”

5. Genesis II Goals • Provide an open source, reference implementation of the OGSA and OGSA-related specifications • Use standards and proto-standards available from the OGF and OGSA to • Provide a secure, cohesive system in a production system available to users today! • Provide feedback into the OGF process on various standards based on implementation experience • Design the system from the ground up with the overriding mantra that users come first! Genesis II “Open Source, OGSA Implementation”

6. Standards Represented in Genesis II Shibboleth OGF WS-Addressing WSDL OGSA JSDL WS-Naming ByteIO And Others! SOAP BES RNS WS-Security XACML SAML Genesis II “Open Source, OGSA Implementation”

7. User’s First • A large percentage of a grid’s target audience is unable or unwilling to learn new interaction abstractions • Instead of asking the user to adapt to the grid, we should adapt the grid to the user Genesis II “Open Source, OGSA Implementation”

8. User Abstractions • One of the most ubiquitous user interaction abstractions is the file system • Drag-and-drop • Double Click • /proc filesystem • Named pipes • RNS, ByteIO, and WS-Naming provide the foundation for building these abstractions Genesis II “Open Source, OGSA Implementation”

9. Thought Games • What would it mean to browse a grid “directory” structure? • What if you double-clicked on a ByteIO resource in it? • What if you double-clicked on a grid resource representing a database query? • What about dragging a JSDL document onto a BES container? A scheduler? • What about “browsing” into a BES container? Genesis II “Open Source, OGSA Implementation”

10. Thought Games • Many different answers are possible • All represent semantics on top of familiar user abstractions which bring the grid closer to the end-user. • Is this proliferation of different answers a problem? • Maybe common abstractions are needed, maybe it should be configurable. • This question needs to be answered, but first we have to get it to work Genesis II “Open Source, OGSA Implementation”

11. Outline • Background • Genesis II • Demo • Next Steps Genesis II “Open Source, OGSA Implementation”

12. Genesis II • Standards based, production level grid system • Designed with the primary goal of putting users first • Provides data grid and compute grid technology using secure infrastructure Genesis II “Open Source, OGSA Implementation”

13. Genesis II Specifications • Written in Java 1.5.x using Jetty 5, Axis 1.4, and WSS4J • Pluggable security infrastructure currently supporting both Username/Password profile, and GAML (Genesis II SAML implementation) • Currently tested on Windows XP and Linux Genesis II “Open Source, OGSA Implementation”

14. Genesis II • Every service/resource in Genesis II may implement RNS and/or ByteIO (and most do) Genesis II “Open Source, OGSA Implementation”

15. UNIX-like command line interface Genesis II “Open Source, OGSA Implementation”

16. UNIX-like command line interface Genesis II “Open Source, OGSA Implementation”

17. Other Filesystem Aware Interfaces Genesis II “Open Source, OGSA Implementation”

18. Interesting Combinations of RNS, ByteIO, and others Genesis II “Open Source, OGSA Implementation”

19. Using RNS to name non-filesystem components Genesis II “Open Source, OGSA Implementation”

20. Using RNS to name non-filesystem components Genesis II “Open Source, OGSA Implementation”

21. Genesis II’s BES implements RNS too! Genesis II “Open Source, OGSA Implementation”

22. Genesis II’s BES even implements ByteIO! Genesis II “Open Source, OGSA Implementation”

23. Genesis II’s BES even implements ByteIO! Genesis II “Open Source, OGSA Implementation”

24. Export Directory Genesis II “Open Source, OGSA Implementation”

25. WS-Naming and Genesis II • Extensive use of Endpoint Identifiers • Simple Resolvers • Future Work • Security Modifications • Fault Tolerance • Performance • Etc. Genesis II “Open Source, OGSA Implementation”

26. Security Design Goals • Per-resource configurable information security: • Authentication (strong resource identity) • Confidentiality (encryption) • Integrity (digital signatures) • Authorization (pluggable schemes) • Standards-based: • Follow OGSA AuthN & AuthZ models as they develop • OGSA Basic Security Profile for placing keys in EPRs • Leverage standard profiles, specifically WS-Security token profiles: Username/Password, X.509, SAML Genesis II “Open Source, OGSA Implementation”

27. Resource Identity and Authentication • Cryptographic identity for individual resources: X.509 digital certificates • Public-key cryptography for AuthN of resources to clients • Leverage existing trust hierarchies and relationships • WS-Naming EPIs incorporated into certificates • Proper security under migration, replication • Digital certificate distribution via EPRs: certificate-chains embedded as non-critical EPR metadata Genesis II “Open Source, OGSA Implementation”

28. Separating AuthN, AuthZ, and Message-level Security Concerns • Hard to do • AuthN, AuthZ, and message security can leverage common cryptographic mechanisms (e.g., signing) • No systematic mutual-AuthN: • Resources are authenticated to clients via X.509 certificates • Clients are not authenticated per-se • Ensuring client identity treated as AuthZ decision of credentials • Credentials may be arbitrary SAML assertions, Username-token, X.509 identity, etc. • Doesn’t preclude client-privacy, anonymity, delegation • For message integrity/confidentiality, the caller can generate an anonymous keypair • In fact, SAML assertions may be delegated to this transient keypair • Both client and resource may separately specify message-level security requirements: • E.g., client has policy that interactions with certain resources must be encrypted • E.g., resource requires encrypted access • Resource message security requirements hinted within EPR metadata Genesis II “Open Source, OGSA Implementation”

29. Authorization • WS SOA paradigm: interface specification & implementation transparency: • How AuthZ policy is enforced is up to the implementer • e.g., engines for XACML, SecPAL, etc. • The credentials they leverage (and protocols for obtaining them), however, need to be profiled • SAML credentials • Powerful enough to represent any security credential scheme • Attribute Authorities (AAs) federate existing subject identity • e.g., LDAP, NIS, X.509, etc. • Support SAML Authentication Request profile • Optional support for Assertion Query and Request profile for Shibboleth-like anonymity • Credentials are signed, “holder-of-key” SAML attribute assertions • e.g., identity, roles, capabilities, etc. • Credentials may be delegated • Limited lifetimes and # of delegations • Also support WS-S Username-token and X.509 credentials Genesis II “Open Source, OGSA Implementation”

30. Authentication Con’t Genesis II “Open Source, OGSA Implementation”

31. Genesis II EPRs Example EPR Genesis II “Open Source, OGSA Implementation”

32. Genesis II Statushttp://vcgr.cs.virginia.edu/genesisII Genesis II “Open Source, OGSA Implementation”

33. Outline • Background • Genesis II • Demo • Next Steps Genesis II “Open Source, OGSA Implementation”

34. Demo Participants • University of Virginia • University of Linz • Imperial College London • Texas Tech. University Genesis II “Open Source, OGSA Implementation”

35. Outline • Background • Genesis II • Demo • Next Steps Genesis II “Open Source, OGSA Implementation”

36. Next Steps • Further integration of RNS/ByteIO into various grid components • Schedulers • Resolvers • More sophisticated WS-Naming resolvers • Migration • QoS • Security Genesis II “Open Source, OGSA Implementation”

37. Next Steps (cont.) • BES Queue Implementation • More advanced schedulers • Application Deployment and Configuration • Workflows • Native FS drivers Genesis II “Open Source, OGSA Implementation”

38. Next Steps(command line shell) • Command line shell • Tighter user integration • Familiar tools like tab completion and environment variables • Access to both local and remote resources seamlessly (through “mount” like configurations) • Automatic generation of JSDL documents and BES control mechanisms Genesis II “Open Source, OGSA Implementation”

39. Next Steps(GALE) • Grid Aware Legacy Environment (GALE) • Realization that part of a user’s first philosophy includes supporting the users’ applications • Allows legacy applications to use the grid without re-targeting, re-compiling, or re-implementation • Tightly bound with the command line shell mentioned before Genesis II “Open Source, OGSA Implementation”

40. Genesis IITake-away messages • Sufficient body of standards exist with which to build interesting, useful grid systems • Alpha Release available under Apache 2 licenses • Very active project! • Information and Download Page • http://vcgr.cs.virginia.edu/genesisII • Forum • http://www.cs.virginia.edu/forums/viewforum.php?f=26 Genesis II “Open Source, OGSA Implementation”