Shibbolized TeraGrid User Portal Plans

From TeraGrid Wiki

Jump to: navigation, search

Overview

This document describes plans for allowing campus users to access their TeraGrid User Portal (TGUP) accounts via Shibboleth and their campus logins. This is work to be undertaken by TACC (see TACC-SOW) with assistance from NCSA (see NCSA-SOW), and follows current efforts to achieve InCommon Membership by TeraGrid.

This work is broken down into four phases (with phases 2 and 3 possibly occurring in parallel):

Phase 1 will allow users to access their TGUP accounts via Shibboleth authentication. This initial effort will only serve to grant the user access to administrative functions on the TGUP which do not entail submitting jobs to or interaction with RP Resources. This is due to the technical reason that the Shibboleth authentication to the TGUP will not provide the user with a MyProxy-issued Grid credential as normal authentication with their TeraGrid username and password would.

Phase 2 will extend the work from Phase 1 to grant users authenticating to the TGUP via Shibboleth a grid credential, allowing them to submit and manage jobs on RP resources as they do today.

Phase 3 will extend the work in Phase 1 to allow users to submit POPS proposal requests via Shibboleth authentication. This work is separated from Phase 1 because POPS integration in the TGUP is in progress and so this activity may have to come at a later date than Phase 1.

Phase 4 will extend the work in Phases 1 and 3 to allow for short-term access to Training Accounts.

Terminology and Abbreviations

eduPersonPerincipalName (ePPN): An eduPerson attribute identifying a user using the form of "user@scope." See [1], Section 2.2.8.
eduPersonScopedAffiliation (ePSA): An eduPerson attribute showing membership at an organization. E.g. faculty@illinois.edu. See [2], Section 2.2.9.
eduPersonTargetedID (ePTID): An eduPerson attribute which is a unique, non-reassignable identifier of the user which presents it. (Unlike a username, it is guaranteed to never be reassigned.) See [3], Section 2.2.10.
Existing User: A Existing User is a user with a TGUP account and presumably access to one or more TeraGrid RP resources.
InCommon: A federation of Shibboleth-using institutions which share configuration information such that users in those institutions can use Shibboleth to authenticate to institutions in the federation other than their own. See [4].
Linked User: A Linked User is an Existing User who has linked their Shibboleth authentication with their TGUP account as described in Use Case 1.1.
MyProxy: A TeraGrid service which verifies a username and password (using the TeraGrid Kerberos domain) and, on validation, returns a Grid credential.
New User: A New User is a user without a TGUP account
POPS: The allocations request system to be integrated into the TGUP. Currently at https://pops-submit.teragrid.org/
POPS User: A POPS User' is a user who has created a POPS account, but has no TGUP access otherwise.
Resource Provider (RP) Resource: A TeraGrid resource accessed, in the scope of this document, through the TGUP using a MyProxy-issued grid credential.
Security Assertium Markup Language (SAML): Standard for exchange of authentication and attribute information. See [5] and [6].
Shibboleth: Implementation of SAML for federation of user authentication and attributes across administrative domains (e.g. between a campus and TeraGrid). See [7].
TeraGrid Username and Password: The username and password used by a user to authenticate to the TeraGrid user portal, which used the TeraGrid MyProxy server to verify it.
TGCDB: TeraGrid Central DataBase
TGUP: TeraGrid User Portal

Goals

The goal of this work is to support for the following use cases. For all these use cases, it is assume the user in question is a member of a InCommon institution which provides the information described in #Campus-provided Information.

Phase 1 Goals

Phase 1 supports basic user access to the TGUP via Shibboleth, with no access to functionality that requires a Grid credential (e.g. process management on RP resources).

Use Case 1.1

An Existing User authenticates to the TGUP via Shibboleth for the first time using a campus identifier that is not currently linked to any TG account. They will be asked to authenticate with their TeraGrid Username and Password. Assuming that is done successfully, their Shibboleth identity will be linked with their TeraGrid account.

Use Case 1.2

A Linked User authenticates to the TGUP via Shibboleth using a campus identifier they previously linked to a TG account. They will be granted access to TGUP administrative functions without having to authenticate with their TeraGrid Username and Password. If they need to perform functions which interact with grid services on RP Resources, they will need to authenticate with their TeraGrid Username and Password (which will allow for the acquisition of a MyProxy-Issued credential in the TGUP on their behalf).

Use Case 1.3

A Linked User authenticates to the TGUP via Shibboleth using a campus identifier they previously linked to a TG account. They request unlinking of their Shibboleth identity. This will essentially reverse the changes made in Use Case 1.1, meaning that if they authenticate subsequently via Shibboleth using the campus identifier they will need to undertake the Use Case 1.1 linking process again.

Use Case 1.4

A linked User authenticates to the TGUP via Shibboleth using a campus identifier that is not currently linked to any TG account. They will be asked to authenticate with their TeraGrid Username and Password. Assuming that is done successfully, this Shibboleth identity will be linked with their TeraGrid account in addition to any previous Shibboleth identities they may have linked.

Use Case Implications

No campus identifier should ever be linked to more than one account.
A user may have multiple campus identifiers linked to a single TG account.

Phase 2 Goals

Phase 2 extends the Phase 1 work by allowing users accessing the TGUP via Shibboleth to perform job management functions requiring a Grid credential.

Use Case 2.1

An Existing User authenticates to the TGUP via Shibboleth after having undergone the linking process as described in Use Case 1.1. Building on Use Case 1.2, they will be granted access to TGUP administrative functions without having to authenticate with their TeraGrid Username and Password. Additionally they will be able to perform TGUP functions that interact with RP resources (e.g. the "SSH Terminal") without having to provide additional authentication (i.e. a MyProxy/Krb5 username and password).

Q: What are the other functions on the TGUP that take advantage of a Grid Credential other than the SSH Terminal? --Vwelch 19:56, 18 June 2008 (GMT)
A: There's also a TGUP File Manager (GridFTP) applet. --Jbasney 18:32, 6 April 2009 (GMT)

Phase 3 Goals

Phase 3 extends the Phase 1 work to include submission of proposals to POPS by new users. For reference, here is a capture of the POPS screen requesting the user's information: File:POPS PI personal info screen.pdf.

Use Case 3.1

A New User authenticates to the TGUP via Shibboleth. A new account is created for the user and they become a POPS User, however at this point, since they lack a Allocation, all they are capable of doing is requesting such an allocation through POPS.

Assuming that request is successful, they will be a Linked User, capable of actions as if they had undergone Use Case 1.1 (I.e. they could subsequently undertake Use Case 1.2 and/or 1.3).

Phase 4 Goals

There is current activity on defining requirement for training accounts. This activity is being tracked and this section will fill in as this activity matures.

Project Tasks and Status

Get sign-off on goals from following parties:
- TG Deputy Director
- Security, Operations and Networking Lead
- TACC as lead of TGUP development
- NCSA as lead on Shibboleth/CA integration activities.
Develop detailed plans for Phase 1
Initiate Phase 1 Activities
- Further task tracking will be in Phase 1 Detailed plans
Develop detailed plans for Phase 2
- Will be done in parallel with Phase 1 implementation
Develop detailed plans for Phase 3
- Will be done in parallel with Phase 2 implementation

Phase 1 Detailed Planning

Open Issue: TGUP Platform Change

A significant open issue here is a planned change of the current TGUP software base from GridSphere to some other platform (see Internet Framework Pilot). It appears this new platform will be Liferay. Shibboleth support in liferay needs to be investigated.

Updated Feb 5, 2009: This issue has become a roadblock as now it appears the TGUP will transition to WebSphere, but the process is stalled in contract negotiations with the third-party company providing the Application Hosting. At this point we are progressing with a deployment on a separate portal at NCSA with the intent of rolling the functionality back into the TGUP when it has completed its transition. See InCommon TeraGrid Certificate Authority Plans for details.

Campus-provided Information

From TeraGrid's InCommon membership agreement (section 3.1), here is the information it is expected campuses will provide to TeraGrid:

Campus Identity Providers should provide a globally unique, non-reassigned identifier for the user such as eduPersonTargetedID or ePPN (if it meets the non-reassignment criteria).
Campus Identity Providers should provide a string bearing a reasonable version of the user's legal name such as displayName.
Campus Identity Providers should provide eduPersonScopedAffiliation (ePSA). At a minimum, organizational membership (“member@foo.edu”), ideally an indication of the user’s position (“faculty@foo.edu”).
For access occurring under an arrangement to provide TeraGrid resources to members of a course, campus Identity Providers should provide the user's qualifying course identification as eduCourseOffering.
Any contact information (phone number, postal address) available for the user to help TeraGrid establish and remain in contact for the user regarding their TeraGrid allocation and usage.

How the Campus-provided Information is Used

The user identifier (#1 above) should be used as the user's identifier on the TGUP. It should be linked to the user's existing account such that it can be used to map the user to that account.
The legal name (#2 above) and contact information could be used to populate forms requesting similar information from the user, particularly when the user is making a POPS request (Use Case 2a.1 above). For subsequent accesses, this information could be used to ensure that the information TeraGrid has is up-to-date, i.e. it could be compared to what is in the TGCDB and if it differs, the users could be asked which is more accurate. It could be logged in any case to provide alternate information to what is in the TGCDB. We need experience with the availability and quality of this data to determine if this could be done.
The eduPersonScopedAffiliation could be used in Use Case 2a.1 to help vet that the user is eligible for an allocation. We need experience with the availability and quality of this data to determine if this could be done.
The eduCourseOffering has no use at this time -- it is for future activities.

Detailed Use Case Diagrams

Coming soon, diagrams showing use cases and resulting state changes in more detail.

Testing Plan

XXX

Alpha testers are probably TG staff. At what point do we get them involved?
Beta testers are select users. Who? How and when do we get them involved?

What are the common errors we need to test and make sure are well handled?
- User who school does not appear in TGUP SAML metadata (e.g. not from InCommon school)

Acceptance Criteria

XXX

What are the criteria from moving from Alpha to Beta and into production?
What other, non-technical things should happen at each step?
- When does user services get involved?

Maintenance

XXX

What has to be done to maintain the system?
- InCommon metadata on TGUP will need to be kept up.
I think "non-reassigned" is time-qualified, i.e., guaranteed non-reassigned for six months from last use. We need to confirm. If this is the case, then TGUP needs to keep track of identifier use and remove identifiers which haven't been used for a long time such that they may be re-assigned. --Jbasney
- The membership agreement just says "non-reassigned". Looking at the eduPerson specification (section 2.2.10), it explicitly prohibits reassignment: "Therefore particular values created by an identity provider MUST NOT be re-assigned such that the same value given to a particular service provider refers to two different principals at different points in time." So I believe we are OK on this front. --Vwelch 20:23, 18 June 2008 (GMT)
  - eduPersonTargetedID prohibits re-assignment, but eduPersonPrincipalName does not. --Jbasney 20:22, 16 March 2009 (GMT)

Phase 2, 3 and 4 Detailed Plans

Coming soon on separate pages...

References

TACC-SOW: See "Objective 4.1: Support of Shibboleth Integration in TGUP (NOS.Svc2 Core Services 2.0)" in Media:PY4_GIG_TACC_SOW.pdf
NCSA-SOW: See "NOS.Svc2 Core Services 2.0" in Media:PY4_GIG_NCSA_SOW.pdf
Other InCommon Shibboleth Services: https://spaces.internet2.edu/display/InCCollaborate/Federated+Services+Offered+Through+InCommon
eduPerson Specification: http://www.nmi-edit.org/eduPerson/internet2-mace-dir-eduperson-200806.html
Leveraging the InCommon Federation to access the NSF TeraGrid, Internet2 Member Meeting, October 15, 2008.: http://www.ncsa.uiuc.edu/~jbasney/basney-fall2008i2mm.ppt; http://www.ncsa.uiuc.edu/~jbasney/basney-fall2008i2mm.pdf

Retrieved from "http://www.teragridforum.org/mediawiki/index.php?title=Shibbolized_TeraGrid_User_Portal_Plans"

Categories: Identity Federation | Shibboleth

Views

Personal tools

Log in / create account

Search

Toolbox