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

2. TeraGrid Goals 1.Reaffirm strategic project goals a)Increase by an order of magnitude the number of scientists/students using TeraGrid resources b)Support/Create a National cyberinfrastructure for connecting a broad array of resources across the US academic research community. 1)Provide a core set of grid services with well defined (and interoperable) interfaces 2)Provide extensibility for inclusion of specialized ("boutique") resources 3)Provide easy access to US university researchers and support workflows using their campus infrastructures and TeraGrid resources 2.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. 3.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 Danes 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 –Cant 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