|
ACS Home Related Links:
Advanced Campus Services |
NMI Integration Testbed Program
On the Call: UAB Jill Gemmill, Jason Lynn, John-Paul Robinson UAHSandi Redman UARKAmy Apon UChicagoTom Barton (invited speaker)
GSUArt Vandenberg, LSUGabrielle Allen, Ryan Dooely, Andrei Hutanu, Ian Kelley, Zhou Lei UMichBill Doster, Beth Kirschner, Shawn McKeeSURAMary Fran Yafchak USCShelley Henderson USC/ISIJohn McGee TACCAshok Adiga TTUJerry Perez, Phil Smith TulaneRene Salmon
Purpose of meeting - Presentation/discussion of GridShib with Tom Barton
Summary of Discussion I. GridShib Tom Barton, University of Chicago , lead a discussion on GridShib ( http://grid.ncsa.uiuc.edu/GridShib/ ). GridShib is recent NMI Award with Principle Investigators Von Welch, NCSA, Tom Barton and Kate Keahey, University of Chicago , and Frank Siebenlist, Argonne National Laboratory.
General purpose of GridShib is to: Enable runtime authorization to be provisioned for grid resources (using attributes, not authentication per se) Use a trust fabrics that are in place (with mechanism such as SAML for secure transmission) Essentially: allow use of Shibboleth-issued attributes for authorization in Grids built on Globus Toolkit
GridShib is looking for use cases, for example: 1) Scenario where a relatively large # of people need differential access to a resource, and want to avoid identity credentialing overhead (i.e. willing to accept someone else's word about who someone is) 2) VOMs (Virtual Organization Membership Services) - that have an attribute repository or authority and want a standard means of conveying info to resources involved. Some VOMS exist already (for instance, see: http://hep-project-grid-scg.web.cern.ch/hep-project-grid-scg/voms.html )
GridShib principles (from Von Welch. GridShib: Grid-Shibboleth Integration Overview . NMI Management Call, November 2004 at < http://grid.ncsa.uiuc.edu/presentations/GridShib-Overview.ppt > • No modification to typical grid client applications • Leverage shibboleth's attribute administration and end-user maintenance of attribute release policies • Leverage high-quality Campus Identity Provider operations • Leverage high-quality Shib and Grid software GridShib challenges ( from Von Welch's Overview at GridShib Site):
Discussion clarified that GridShib is looking to leverage existing NMI components base, especially Shibboleth, focusing on the trust fabric of Shibboleth. Federation among institutions is established because of their agreed to identity policy/practices and then secure mechanism to pass Attributes to gain access to web resources. GridShib uses same mechanism for grid resources, but no necessity (requirement) for local authentication - option for that to be sufficient. GridShib mainly is asking, "What kind of attributes need to be marshaled prior to grid use?"
Tom noted that oftentimes grid resources are controlled by admin identities close to the resources (e.g., Unix accounts) - who therefore need to manage identifiers. GridShib is proposing is an alternative to requirement for a Unix account on each system you have access to and the gridmap file has to include an entry for each as well.
GridShib Workplan: Version of GRAM that will allow mapping of remotely authenticated individuals to use of resources - mapping multiple users to the resource without having to do so via individual one-to-one accounts. Gist of what is planned is a pipeline in which there is a place to marshal, cache, and set canonical attributes to determine authorization. There are several different means by which the GridShib plumbing will be leveraged for this.
What GridShib really is: techniques and technology by which a Globus supported resource will be able to marshal attributes form a Shibboleth attribute authority. Using Grid_Proxy_Init style entity certs and using certs to identify and authenticate/validate messages being sent, assertions will be consumed by Globus runtime so that real access control can occur.
How does Grid Shib appear to the user? User perspective should be the same, what's changing is how the access control that allows you to submit a job - your authenticated identity is what determines what attributes will be submitted. Actual attributes aren't in the certificate but the source of where to get them. Very much like current Shib protocol exchanges. Penn State LionShare ( http://lionshare.its.psu.edu/main/ ) Shib project for non-Web applications is similar at some points to GridShib.
GridShib development will be based on GT4. First run is with Globus Proxy Service. Have had some conversations about using Web services but no plans yet - would like to get to that point.
What's the best reading to get everyone on the same page in understanding this? Best background materials specific to GridShib are on the GridShib Web site; also see: Shibboleth http://shibboleth.internet2.edu Globus: http://www.globus.org
Discussion on possible tie-ins with SURAGrid work: Currently SURAGrid is working on a persistent grid, cross-certified by BridgeCA and with set of applications that can be tested across the grid. Once we have this, we'd be interested to see how GridShib could work with that. SURAGrid has included discussions about acceptance of certificates but still need to manage the gridmap file, authorization levels, etc. SURAGrid represents a large dynamic user community with resources for multi-project use and could provide data to GridShib re: user base, kinds of authZ required, use cases, policies on shared use.
Call attendees agreed that SURAGrid would like to schedule Tom for an update on this a few months out. Per Tom, O.K. to email him ( tbarton@uchicago.edu ) with questions, comments meanwhile.
ACTION ITEMS: a) Review GridShib materials
II. Action Items - ACTION ITEMS: We agreed to make concerted efforts to advance action items. Listed here (with progress report):
Everyone will review and provide info to Art for an update to the Table of Resources (Need status updates!)
MFY will explore SURA member survey re enterprise Certificate Authorities (CA) (Will work with SURA GridPlan Infrastructure WG once GridPlan is further along. Keep on list to revisit status in mid-February)
Art will broker conference call with Jim Jokl, UAH, UArk, GSU, UMICH to review cross certification steps (Need status update - Call scheduled January 31, 2005 , 4PM ET )
John-Paul will document UAB "Blast" application as potential shared app on Testbed Grid (Need status update)
Sandi will check for potential shared applications with UAH developers. (Need status update)
MFY will contact LSU to document Task Farming Application as potential shared app. (Confirmed that contact at LSU will be Ian Kelley. Have some earlier doc from him and will draft something to send to him soon for addition/review.)
Art/Victor to review PKI-lite to brief group and develop straw man policy doc(s). Everyone will send their grid policy statements to Art as reference to same. (Need status update)
MFY to set call with SURA GridPlan Funding group to brainstorm/plan funding approaches. (Need to gather names on this call so MFY knows who to work with re: scheduling.)
Status/Continued progress on persistent grid-building (All sites interested in participating in a persistent grid should make as much progress as possible on installation & cross-certification.)
Additional ongoing action items: a) Shawn/UMich: Can find a couple of machines. Has MGrid CA . On list to work on getting cross-certified. b) Jim/UVA: Has 5-node cluster on hand to use. Is cross-certified. c) Amy/UArk: Has 5-node cluster could use. On list to work on getting cross-certified. d) Greg/GPN: Will talk w/some of university contacts within Great Plains Network community. e) John-Paul/UAB: 8-node Dell cluster. Is cross-certified. f) Warren/GATech: Update - "an old 4-node cluster" g) Art/GSU: Grid-enabling Beowulf cluster. On list to work on getting cross-certified. h) Rene/Tulane: [We were over time and Rene was no longer on the call...] i) Phil/George Mason: Update: 2 Dell Servers, 3 Sun Servers and would like to be on the waiting list for cross certification. j) Phil/TTU: 3 node cluster in progress. Will wait until "second wave" to get cross-certified. k) Shelley/USC: Can make Condor pool available for sure. Update: Also a 4-node Netra cluster. Almost cross-certified. l) Sandi/UAH: Can come up with something. Will check and send details.
III. SURAGrid - By consensus, we agreed that we'd use SURAGrid as name, replacing prior SURA NMI Testbed Grid as the NMI Integration Testbed project is closing.
See: http://www.nc.gsu.edu/~wwwacs/GRID_Group/NMI.html for minutes of previous meetings as posted.
NEXT CALL : Thursday January 27 , 2005 4:00-5:00pm ET |
Last Updated: March 2, 2006