TeraGrid Plans for Authentication and Authorization Testbed

1. TeraGrid Plans for Authentication and Authorization Testbed Dane Skow, Argonne National Laboratory Computation Institute Seminar September 28, 2006

2. Workshop • Workshop on TeraGrid Authentication, Authorization, and Account Management - August 30-31, 2006, Argonne National Laboratory • Organizers: Von Welch, Tony Rimovsky, Jim Marsteller, Carolyn Peters, Dane Skow • Attendees: 42 persons, representatives from all TeraGrid Resource Provider sites, OSG, Internet2, Globus • http://www-fp.mcs.anl.gov/tgmeeting/AAA-Agenda.htm • Whitepaper (Von Welch, Ian Foster, Tom Scavo, Frank Siebenlist, Charlie Catlett)http//gridshib.globus.org/tg-paper.html

3. Authentication vs Authorization • Identifier: A unique name • (username, DN, GUID, SSN, etc.) • Authentication: Verifying Identity of users • associating them with a Identifier Authorization: Deciding whether or not a request will be granted • Different authentication methods have different levels of certainty • Authorization Policy: The set of rules by which an authorization decision is made • Authentication does not imply Authorization • E.g. just because you trust a CA doesn’t mean all the user with certificates from it are authorized

4. Issues with Authentication Status Quo • IDs sometimes contain sensitive information (e.g. SSN) • ID sources do not typically have direct, ongoing relationship with users • Many sources of authentication mean confusion, error and insecurity for all parties • Protection of online secrets is difficult and point of attack • Scaling beyond ~100 sources of identity call for index and/or hierarchy • 100+ in MacOS X default, etc • Currently 90+ CAs in IGTF PMA set • ~1500 Institutions in EDUCAUSE

5. Authorization Status Quo • Currently solely ID based • A user has only one mapping in the system • no capability for roles • Single group membership • Need prior knowledge of group membership • Maintenance /synchronization problem • No differentiation between services for access levels • Allocated users • Authenticated users • TG Community users • Partner/Campus users • Public • Scaling • Workload scales by ID not by group • Adds new sources of authority to manage

6. Account Management Status Quo • Single Account/authorization doesn’t map to rich set of services • Persistent Execution Environments • Pre-provisioning individual environments (accounts) has large overhead and vulnerabilities • Shared environments • Environment configuration for groups must be independently duplicated • Traceable actions • Need to preserve connection from actions (and costs) to individual initiating the action for troubleshooting

7. Operational Example • Number and Levels of Credentials • Resource specific (login) credentials • Direct machine logins • TeraGrid webpages • TeraGrid forum • Grid service credentials • Users internal TeraGrid X509 credentials (from kx509, MyProxy, etc) • Gateway/broker credentials • User’s external x509 credentials (from DOEGrids, etc) • Gateway community credentials • Portal login/password • Home institution credentials • Commercial credentials • Scale of compromise recovery effort is large • Single general server compromise 1000s of credentials

8. Authentication Process Today • User and RP share a secret. • RP authoritative itself • Maintains contact information • User <-> RP correction relationship • Individual traceability * • CAs issue identify credentials • RP can validate credentials (trusting CA) • CA maintains contact information (maybe) • Typically not available to RP • CA has loose relation to user • User <-> CA <-> RP correction relationship • Individual traceability * * Provided there’s no collusion

9. Future • User authenticates to local institution/authority, • authority vouches for user (by constructing appropriate attributes in credential) • RP can validate authority attribute and binding to request (?) • RP may itself be a local institution • Local institution maintains contact information with user • Heirarchies allowed (ala bond brokers) • Individual traceability (maybe pseudynmous)

10. Individual User Environment (G)Id uid (G)Id uid (G)Id uid project O(10) O(1) O(1) Resource TGCDB O(1000) O(1000) Grant Process O(10) Use cases: Traditional users, Development

11. Authenticated User Environment O(10) O(1) O(1) (G)Id O(1) (G)Id O(10) ? uid project (G)Id O(10) Resource TGCDB Grant Process Use cases: Grid-savvy user communities, Production runs, user managed services

12. Gateway Environment O(10) O(1000) O(100-106) ? O(1) ? O(100) O(10) O(1000) O(1) GId uid O(100) ? O(1) ? O(1) O(1) uid project O(10) O(100) Gateway ComId Resource TGCDB Grant Process Use cases: Large communities of users, novice users, public

13. Community Gateway 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 • or perhaps (a mapped set of) virtual machine images • Except accounting and troubleshooting. We still need an individual identifier

14. The Proposal • Plan for a world where users 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

15. Testbed

16. Testbed Components • Enhanced CTSSv3 stack • Existing GT component extensions to enable attribute-based authorization • Identify testbed resources • UChicago/ANL, NCSA Mercury, ORNL • Use OSG/TG VOMS test server • Handful of user communities • Science Gateway, Educational, OSG, others TBD. • Use of Shibboleth and related software • myVocs, GridShib • Leverage InQueue/TestShib, UT Fed

17. Testbed Use Cases • Individual New User • Individual Existing User Access • Shibboleth authentication to Gateway • Gateway attribute authorization to RP Use Case • OSG/VOMS access • Educational Access • Incident Response

18. Individual New TG User • Registration process here… • Campus id gets into TGCDB as part of process • Utilize Shibboleth tooling for Registration 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 • DN+attribute registration matched to local UID through gxmap (mod) • RP does authorization based on DN • Provisioning may use attribute common set (TBD) • TP logs other attributes

19. Identifying Key Communities • Large enough to suffer scaling problems • So there’s a payoff for the work • Feasibly represented by Shibboleth or VOMS in the next 2 years • Or represented by a persistent attribute authority (e.g. a Gateway) • So that it’s not yet another security system • Some subset of community represented now • So that there’s someone to work with in evaluating the use cases

20. Technical and Policy Issues to be Resolved (a subset) • What identifiers and attributes are needed by TeraGrid from campuses? • How will other attributes be sourced? E.g. Gateway communities. • Policy distribution mechanisms • Consistent TG-wide policy vs Site autonomy • Agreement between TeraGrid and campuses providing attributes • Identify issues related to forensics/incident response and accounting • Scaling issues with key services

21. Issues which will remain challenges • Numerous, small, dynamic VOs will remain difficult to support • This is key to capturing the ultimate vision of grid as infrastructure • Policy rules (expression and interpretation) remain terra incognita • There are grammars and engines, but little operating experience • Scaling growth in number of authorities needs improvement • Lessons to be learned from DNS

22. Phased Deployment • Enable logging of attributes through the system • Improves traceability and prepares for attribute handling • Enable group membership decisions based on attributes • Provides for community based authorization • Enable attribute based authorization/provisioning decisions • Enables user mapping to different environments • Enables specialized provisioning by attribute set