Thebes, WS SAML, and Federation Internet2 Fall Member Meeting November 3, 2010 Thebes Consortium Georgetown University Arnie Miles adm35@georgetown.edu http://code.google.com/p/thebes/
Back story I haven't been a developer since grad school If you try hard enough, you will trip me up on technical details! As a systems administrator for high performance computing at GU, ran into problems that Grid Computing should have solved Leveraging identities across 'administrative domains' Load balancing HPC devices Migrating load off over-subscribed machines Filling up under-subscribed machines
Back story Turned to grid technologies for solution Existing software did not deliver what was needed Scalability and complexity complaints Referred to SAML v 1.x The SAML (and Shibboleth) use case was for libraries Shibboleth was designed solely for web users Built the Condor-Shib proof of concept Successful, but very limited in scope, never released SAML v 2.0 and WS SAML opened the door to new possibilities
What we discovered... Attribute based access control are a good thing Higher Ed and Internet2 have demonstrated this Shibboleth promulgated the use of attributes in cross domain Federated security for Web Single Sign-on We chose to extend this notion of attribute based access control to the Web Services world We didn't know yet that WS SAML would be the solution
Where we ended up HPC Client and Service These are our first client and service deployment Beginnings of a Security Token Service Extended uses for attribute assertions Making use of the Shibboleth Attribute Resolver We are NOT in the business of making an STS! Understanding of further work to implement vision of policy engine interaction for authorization Oracle OEM? Argus?
Security Token Service A Security Token Service typically Queries local Identity Store Accepts user credentials Verifies user credentials Returns signed assertion containing user attributes Handles various security tokens in and out A hard thing to build, and not what we're in business to do
SAML with Web Services Use WS-Trust protocol to obtain security token Primary motivating use case is SAML assertion Thebes Security Token Service queries local identity store and creates assertion Token is conveyed to some service using WS-Security Security tokens and crypto mechanisms with SOAP Thebes complies with the WS SAML Token Profile Now we need to examine WS Federation
High Performance Computing Service and Client This is the problem we initially set out to solve, before we were even aware of WS SAML Still in pre-release state while a few more features are added Available for download
Example Application: HPC Client Collects job submission file data Collects user name and password Submits credentials and client IP address to STS Receives signed assertion Translates job submission data to JSDL Sends JSDL and SAML assertion to service Includes mechanisms for collecting results
Example Application: HPC Service Accepts JSDL and SAML from Client Filters SAML; submits SAML to policy engine Accepts results from policy engine: Go/NoGo Creates DRMAA file to submit to any DRM Interacts with DRM via DRMAA to return results, check job status, etc.
ThebesDemo.mov
Status of HPC Client/Service Next steps: Enable jobs to run as the submitting user Currently under construction Enable DRM specific tasks, such as Oracle Grid Engine supporting projects and queues Add Holder of Key functionality Waiting on selection of existing STS to work with
Potential for HPC Client/Service Enable projects and queues, and other DRM-specific features not covered by DRMAA Resource publication and discovery One we can discover services, a metascheduler would be a logical next step Potential for spawning, populating, and destroying virtual machines with proper authorization Potential for launching any work on remote machines, not limited to HPC
User Bearer vs. Holder of Key Certs User bearer: IP address of client is included in the signed cert, with a limited life Potentially vulnerable to IP address spoofing causing replay by unauthorized parties Because we started as a proof of concept, this is the current state of Thebes STS Not suitable for production
User Bearer vs. Holder of Key Certs Holder of Key: Client must be able to prove possession of key Client submits public key to STS in a signed request STS verifies client possesses private key by verifying signature STS includes Client public key in assertion STS signs assertion with Client public key Client signs soap message with assertion and job and sends to service
Summary, slide 1 Thebes provides a potential common security infrastructure for handling authentication to web services Thebes authentication mechanism is scalable Because Thebes leverages SAML and Federation, user identities are maintained in home institutions for superior curation and control Identity assertions comply with SAML standards, assuring compatibility across enterprises
Summary, slide 2 Often, publishing resources is a matter of creating a web service A standardized way to authenticate to a web service can encourage publication of secure services Creation of Federations for Web Services can only help grow web user SAML adoption Rich attributes support complex policies
Thebes Arnie Miles adm35@georgetown.edu http://code.google.com/p/thebes/