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

Genesis II“Open Source, OGSA Implementation”

Genesis II:From Specification to Implementation

Andrew Grimshaw, Mark Morgan

Global Bio Grid Team

University of Virginia

“Open Source, OGSA Implementation”


Responsible Parties

• Andrew Grimshaw

• Mark Morgan

• John Karpovich

• Duane Merrill


Outline

• Background

• Genesis II

• Demo

• Next Steps


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 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!


Standards Represented in Genesis II

WSDL

SOAP

WS-Addressing

WS-SecurityXACML

SAML

ShibbolethOGF

OGSA

WS-Naming

BES

ByteIO

RNS

JSDL


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


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


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?


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


Outline

• Background

• Genesis II

• Demo

• Next Steps


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

• Every service/resource in Genesis II may implement RNS and/or ByteIO (and most do)


UNIX-like command line interface


UNIX-like command line interface


Other Filesystem Aware Interfaces


Interesting Combinations of RNS, ByteIO, and others


Using RNS to name non-filesystem components


Using RNS to name non-filesystem components


Genesis II’s BES implements RNS too!


Genesis II’s BES even implements ByteIO!


Genesis II’s BES even implements ByteIO!


Export Directory


WS-Naming and Genesis II

• Extensive use of Endpoint Identifiers

• Simple Resolvers

• Future Work– Security Modifications– Fault Tolerance– Performance– Etc.


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


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


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


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


Authentication Con’t


Genesis II EPRs

Example EPR

http://www.cs.virginia.edu/~mmm2a/epr.xml


Genesis II Statushttp://vcgr.cs.virginia.edu/genesisII


Outline

• Background

• Genesis II

• Demo

• Next Steps


Demo Participants

• University of Virginia

• University of Linz

• Imperial College London

• Texas Tech. University


Outline

• Background

• Genesis II

• Demo

• Next Steps


Next Steps

• Further integration of RNS/ByteIO into various grid components– Schedulers– Resolvers

• More sophisticated WS-Naming resolvers– Migration– QoS– Security


Next Steps (cont.)

• BES Queue Implementation

• More advanced schedulers

• Application Deployment and Configuration

• Workflows

• Native FS drivers


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


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

http://vcgr.cs.virginia.edu/genesisII

http://www.cs.virginia.edu/forums/viewforum.php?f=26



Documents

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