slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Scaling TeraGrid Access A Testbed for Attribute-based Authorization and Leveraging Campus Identity Management PowerPoint Presentation
Download Presentation
Scaling TeraGrid Access A Testbed for Attribute-based Authorization and Leveraging Campus Identity Management

Loading in 2 Seconds...

play fullscreen
1 / 27

Scaling TeraGrid Access A Testbed for Attribute-based Authorization and Leveraging Campus Identity Management - PowerPoint PPT Presentation


  • 283 Views
  • Uploaded on

Scaling TeraGrid Access A Testbed for Attribute-based Authorization and Leveraging Campus Identity Management http://gridshib.globus.org/tg-paper.html TeraGrid Goals Reaffirm strategic project goals Increase by an order of magnitude the number of scientists/students using TeraGrid resources

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Scaling TeraGrid Access A Testbed for Attribute-based Authorization and Leveraging Campus Identity Management' - benjamin


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

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

teragrid goals
TeraGrid Goals
  • Reaffirm strategic project goals
    • Increase by an order of magnitude the number of scientists/students using TeraGrid resources
    • Support/Create a National cyberinfrastructure for connecting a broad array of resources across the US academic research community.
      • Provide a core set of grid services with well defined (and interoperable) interfaces
      • Provide extensibility for inclusion of specialized ("boutique") resources
      • Provide easy access to US university researchers and support workflows using their campus infrastructures and TeraGrid resources
  • 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.
  • Design a prototype testbed for integration of the Internet2 Shibboleth infrastructure with the TeraGrid proxy based systems.
objectives of idm activity
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
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
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
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
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
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
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
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
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
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
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 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
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
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
Incident Response
  • (See notes from that section)
  • Incident happens
  • Responder gets user information from logs
  • Responder maps user information to contact information
needed functionality
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
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
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
must keep this tied to users
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
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
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
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
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
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