TeraGrid Plans for Authentication and Authorization Testbed Von Welch, NCSA Science Gateway Call October 6, 2006 National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

Authentication vs Authorization Identifier: A unique name for an entity (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 National Center for Supercomputing Applications

Attributes Attribute: A property of an entity Entities may have lots of properties The same property may apply to many entities E.g. community membership, affiliation, age, gender, height, occupation Attribute-based authorization: Authorization based on who someone is (their identity) but what they are (their attributes) E.g. you can buy me a beer if your age > 21 years National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

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 * Provided there’s no collusion National Center for Supercomputing Applications

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 Hierarchies allowed (ala bond brokers) Individual traceability (maybe pseudonymous) National Center for Supercomputing Applications

Individual User Environment Resource TGCDB (G)Id uid project O(1000) O(1000) Grant Process O(10) Use cases: Traditional users, Development National Center for Supercomputing Applications

Authenticated User Environment Resource TGCDB (G)Id uid project Grant Process Use cases: Grid-savvy user communities, Production runs, user managed services National Center for Supercomputing Applications

Gateway Environment Gateway Resource TGCDB Grant Process Use cases: ComId uid GId Resource TGCDB project Grant Process Use cases: Large communities of users, novice users, public National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

Testbed National Center for Supercomputing Applications

Testbed Components Enhanced CTSSv3 stack Identify testbed resources 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 National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

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 National Center for Supercomputing Applications

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 National Center for Supercomputing Applications