Scaling TeraGrid Access
A Testbed for Attribute-based
Authorization and Leveraging
Campus Identity Management
http://gridshib.globus.org/tg-paper.html
TeraGrid Goals
1. 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") resources
3) 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. TGCampus 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