Scaling TeraGrid AccessA Testbed for Attribute-based Authorization and Leveraging Campus Identity Management

http://gridshib.globus.org/tg-paper.html

TeraGrid Goals1. 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") resources3) 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.

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

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

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

Scaling and Usability Issues

• Authentication: Each user needs at least one credential from Dane’s list– Username/password, X.509

certificate, Science Gateway login

• Authorization: Each user needs to appear in a access-control list (/etc/passwd, grid-mapfile)

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

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

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

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– Can’t 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

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

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

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

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

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

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…

Incident Response

• (See notes from that section)

• Incident happens

• Responder gets user information from logs

• Responder maps user information to contact information

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

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

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

Testbed

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

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

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

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)

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

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