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

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
Whitepaper (Von Welch, Ian Foster, Tom Scavo, Frank Siebenlist, Charlie Catlett) http//gridshib.globus.org/tg-paper.html
National Center for Supercomputing Applications

3. 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

4. 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

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

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

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

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

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

10. 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

11. 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

12. 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

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

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

15. Testbed
National Center for Supercomputing Applications

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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