Pitt Passport: Using Pitt Passport for Your Departmental Service or Application | Information Technology | University of Pittsburgh
!

Pitt Passport: Using Pitt Passport for Your Departmental Service or Application

Pitt Passport is the trusted, single sign-on service that presents a uniform login experience for all University web-based services. With Pitt Passport, Pitt users see the same, familiar login page and web address when they connect to web services provided by the University. This service can also be used to provide secure logins for department services including hosted (on-premises) and cloud-based. If you support a department application that requires a University login or administer access to a cloud-based service for University affiliates, please consider configuring your access to use Pitt Passport.

Advantages to Using Pitt Passport

There are numerous advantages to setting up access to a hosted departmental application or service using Pitt Passport. These include:

  • Familiar look and feel – Applications and cloud services configured for Pitt Passport will present users with the same familiar login page and web address used by enterprise University services such as Pitt Email (Outlook), the Student Information System (PeopleSoft), and My Pitt. This will make users less anxious about providing their credentials to access the department application or service.
  • Multifactor Access – Users can configure Pitt Passport to require an additional layer of security to log into University services. This information is a temporary code from an app on a user’s smartphone. So access to a protected online service will require something that the user knows (their username and password) plus something they have (the code from the multifactor app). This additional layer of security provides extra protection against systems being compromised by intercepted University credentials.

How it Works

Pitt Passport works by exchanging information with an application to determine if a user can properly access that application. This happens as an exchange of attributes between two parties.

For instance, when a user attempts to log into the My Pitt website, the first thing that happens is that the application attempts to determine if the user has already logged in or not. Typically, this is accomplished through a “session token” that the user will have in the browser. If the token is not there, the application knows that it needs to authenticate the user by asking them to log into Pitt Passport. Pitt Passport will give the My Pitt application the necessary attributes that the application needs to know in order for the user to log in. In this example, attributes such as eduPersonPrincipleName (EPPN) and/or eduPersonScopeAffiliation (EPSA) are used to make the determination.

In this case, EPPN is the attribute that indicates the user’s University Computing Account username. EPSA indicates whether the user is student, faculty, or staff. These two attributes along with many others can be sent to an application for it to determine if authentication is allowed and what level of access is authorized if authentication access is granted. Some attributes may have to be reviewed to determine if it is appropriate to release them to applications.