TeraGrid Plans for Authentication and Authorization Testbed

1
TeraGrid Plans for Authentication and
Authorization Testbed

• Von Welch, NCSA
• Science Gateway Call
• October 6, 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 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 doesnt mean all
  the user with certificates from it are authorized

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 gt 21 years

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 doesnt 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
• Users 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 lt-gt 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 lt-gt CA lt-gt RP correction relationship
• Individual traceability
• Provided theres 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
• Hierarchies allowed (ala bond brokers)
• Individual traceability (maybe pseudonymous)

10
Individual User Environment
O(10)
O(1)
Resource
O(1)
TGCDB
O(1000)
O(1000)
Grant Process
O(10)
Use cases Traditional users, Development
11
Authenticated User Environment
Resource
TGCDB
Grant Process
Use cases Grid-savvy user communities,
Production runs, user managed services
12
Gateway Environment
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
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

18
Testbed Use Cases

1. Individual New User
2. Individual Existing User Access
3. Shibboleth authentication to Gateway
4. Gateway attribute authorization to RP Use Case
5. OSG/VOMS access
6. Educational Access
7. Incident Response

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
• DNattribute 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

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

21
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

22
Gateway Attribute-based authZ Use case

• This case could follow previous or 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

23
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

24
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

25
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

26
Identifying Key Communities

• Large enough to suffer scaling problems
• So theres 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 its not yet another security system
• Some subset of community represented now
• So that theres someone to work with in
  evaluating the use cases

27
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

28
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

29
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