Scaling TeraGrid Access A Testbed for Attribute-based Authorization and Leveraging Campus Identity Management

1. Scaling TeraGrid AccessA Testbed for Attribute-based Authorization and Leveraging Campus Identity Management http://gridshib.globus.org/tg-paper.html

2. TeraGrid Goals • Reaffirm strategic project goals • Increase by an order of magnitude the number of scientists/students using TeraGrid resources • Support/Create a National cyberinfrastructure for connecting a broad array of resources across the US academic research community. • Provide a core set of grid services with well defined (and interoperable) interfaces • Provide extensibility for inclusion of specialized ("boutique") resources • Provide easy access to US university researchers and support workflows using their campus infrastructures and TeraGrid resources • Develop a consensus design for an account management/authorization system which supports those goals and addresses the operational and security concerns with the current system. • Design a prototype testbed for integration of the Internet2 Shibboleth infrastructure with the TeraGrid proxy based systems.

3. Objectives of Idm Activity • Allow for the leveraging of existing Campus identity management systems • Get ourselves out of the business of credentialing every user • Allow TeraGrid and RPs to scale access by expressing access control policy on groups or communities of users instead of single users

4. Benefits • Reduce TG and Gateway overhead for each user by removing password maintenance cost for each user (allow scalability) • Allow authorization based on community membership instead of identity • Where community membership may be defined by campus, other Grid (e.g. OSG) • Provide additional information to TG, RP sites and Science Gateways in form of user attributes • Additional ease of use for users in one less password, easier registration process

5. Testbed Goals • Validate perceived benefits of leveraging campus authentication and applying attribute-based authorization • Identify policy issues that need to be resolved • E.g. TG<->Campus agreements • Identify technical issues to be resolved • E.g. policy distribution

6. Scaling and Usability Issues • Authentication: Each user needs at least one credential from Dane’s list • Username/password, X.509 certificate, Science Gateway login • Authorization: Each user needs to appear in a access-control list (/etc/passwd, grid-mapfile)

7. Community Accounts • Shift authentication and authorization from RP to the Science Gateway • Whole community then appears as “one” user to the RP in terms of authorization • One grid-mapfile and /etc/password entry • Except that for accounting and auditing we still want to know the individual users involved

8. Our Proposal • Plan for a world where all users are can be authenticated via their home campus identity management system • Enable attribute-based authorization of users by RP site • Allow for user authentication with authorization by community • Prototype system in testbed, with involvement of interested parties to work out issues • All usage still billed to an allocation • Community or individual

9. Testbed Use Cases • Individual Existing User Access • Individual New User • Shib authentication to Gateway • Gateway attribute authz to RP Use Case • OSG/VOMS access • Educational Access • Incident Response

10. Individual Existing User Access • (Start with user having allocation and TG account) • User authenticate with campus credentials • Gets short-lived X509 credential with DN based on Shibboleth-provided Id • With campus attributes • No TG attributes (maybe project in future?) • User registers DN with TeraGrid (one-time process) and bind to TG TGCDB row for that user • Can’t be automated - DN comes from Campus Id • Through user portal - shib and kerberos authenticated binder • User access via gsi-ssh, GRAM, gridftp • Includes both UT Federation Users, as well as InQueue/TestShib users • X509 cred w/attributes presented to RP • RP does authz based on DN/grid-mapfile • TP logs other attributes

11. Individual New TG User • Registration process here… • Campus id gets into TGCDB as part of process • User authenticate with campus credentials • Gets short-lived X509 credential with DN based on Shibboleth-provided Id • With campus attributes • No TG attributes (maybe project in future?) • User access via gsi-ssh, GRAM, gridftp • X509 cred w/attributes presented to RP • RP does authz based on DN • TP logs other attributes

12. Shib-Enabled Gateway Use Case • Gateway is shib-protected (standard shib) • Gateway must Shibboleth SP software • User needs to provide campus id to gateway • User authenticates to Gateway using campus id • Gateway authorizes user based on campus id • Logs other attributes

13. Gateway Attribute-based authz Use case • This case could follow previous or be use another authentication method • Gateway registers attribute-signing key with RPs • RP maps Gateway attribute to local UID/GID • Gateway gets short-lived X509 cred • Gets EEC from MyProxy • Creates signed attribute and inserts into proxy, bound to user DN • With community attribute + campus attributes (if available) • Gateway access vis gsi-ssh, GRAM, gridftp • Presentation of X509 cred w/attributes to end resource • RP maps to community account based on community attribute • Verified and validates attribute from gateway • TP logs other attributes

14. Gateway Attribute-based authorization to RP • Gateway generates X.509 credential • Or requests one from MyProxy • Includes local gateway attribute with their identity for user • Policy to ensure uniqueness • Gateway access vis gsi-ssh, GRAM, gridftp • Presentation of X509 cred w/attributes to end resource • RP maps to community account based on community attribute • RP logs other attributes

15. CMS/VOMS access • User authenticates in standard OSG manner • Obtains VOMS credential • User access via gsi-ssh, GRAM, gridftp • Presentation of X509 cred w/VOMS attributes to end resource • RP maps to community account based on community attribute • TP logs other attributes

16. Educational Access Use Case • Based on current training account model • Create N accounts and hand out N usernames/passwords • PI given class allocation • Process issue TBD • PI creates accounts • Number, duration • TGCDB handles expiration? • PI gets list of usernames and passwords for accounts • RPs create accounts • PI hands out username & password to each student • Students does one-time registration with provided password to bind Shib-derived DN to training account • Students authenticate with campus credentials to GridShib-CA • Looks like normal individual user at this point…

17. Incident Response • (See notes from that section) • Incident happens • Responder gets user information from logs • Responder maps user information to contact information

18. Needed Functionality • On Resource: • Attribute-aware authorization • Attribute-aware mapping to UID and GID • Attribute-aware logging • Attributes available to OS level? • Gateway: • Shibboleth authentication • Attribute-aware logging • Interface for Shib->X509 conversion • Interface for adding community attributes

19. Needed functionality (cont) • Other services: • Shib->X509 gateway for Science Gateways • Shib->X509 gateway for end users • User attribute->contact mapping • Policy distribution • attribute info, federation, … • To gateways, RPs • Creation of temporary class/workshop accounts • Method to bind campus id to TG user

20. Testbed Components • Enhanced CTSSv3 stack • Existing GT components to enable attribute-based authorization • Identify testbed resources • Handful of user communities • Science Gateway, Educational, OSG, others TBD. • Use of Shibboleth and related software • myVocs, GridShib

21. Testbed

22. Must keep this tied to users • Has potential to suffer from “copper plumbing” syndrome - better infrastructure without obvious user benefit • Identify a small number of target communities to participate in testbed • Need right combination of Shibboleth deployment and TeraGrid interest

23. Identifying Key Communities • Large enough to cause scaling problems • Feasibility represented by Shibboleth or VOMS in the next 2 years • Or represented by a persistent attribute authority (e.g. a Gateway) • Some subset of community represented now

24. Identifying Key Resources • Able to deploy and maintain experimental software stack for the life of the testbed • Willing to serve (some subset of) identified communities • AMIE integration • For account management • Accounting? Not necessary, but would be good to test system

25. Existing Components • InQueue/TestShib & UT Federation • MyProxy CA for issuing short-lived credentials • GridShib-CA for converting Shib->X509 • Uses MyProxy • Shibboleth code for for Apache • GT extensions for attribute-based authorization • CTSSv3 (GT4.0.x)

26. Proposal • Leverage InQueue/TestShib, UT Fed • Build enhanced CTSSV3 software stack • Deploy GridShib-CA, test MyProxy as Shib->X509 gateways • MyProxy creates X509 for GridShib CA, Gateways • Initially inserts attribute based on requestor • Use OSG/TG VOMS test server

27. Steps Forward • Make Enhanced CTSSv3 that can sit along-side current CTSSv3 deployments • Or add-on to CTSSv3 • Put this under existing Software Integration allocation • Create RAT for testbed design