# Presentation: 148685

## Testbed Goals

- Validate perceived benefits of leveraging campus authn and applying attribute-based authz:
- Reduce TG and Gateway overhead for each user by removing password maintenance cost for each user (allow saclability)
- Provide additional information to TG/RPs/Science Gateways in form of user attributes
- Additional ease of use for users in one less password, easier registration process

## 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

## 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