!

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 screen 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 or cloud services configured for Pitt Passport access will present users with the same familiar login screen and Web address utilized by enterprise University services such as My Pitt Email, PeopleSoft, and My Pitt Portal. 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 portal, the first thing that happens is that the portal 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 portal 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.

First Steps: Determining Your Service or Applications Single Sign-on Attributes

Configuring an Application to Work with Pitt Passport

When working with Pitt Passport, there are a few questions to ask the vendor (or your development team if your building the application) about supporting single sign-on.

  1. Does your application/service support Security Assertion Markup Language (SAML)? This is an XML-based open-standard data format for exchanging authentication and authorization data between two applications. In most cases, between an identity provider and a service provider. Specifically, Pitt Passport supports SAML version 2.0.
  2. Does your application/service support the use of Shibboleth implementation? Shibboleth is at the heart of Pitt Passport and is single sign-on technology.
  3. If your service/application supports Shibboleth, are you also part of the InCommon Federation? Being a part of the InCommon Federation allows for an easier integration path. When integrating Service Providers with Identity Providers, both parties will exchange metadata about themselves with each other. The InCommon Federation will automatically exchange this information with all parties that have participated in the federation.
  4. If your service provider organization is not part of the InCommon, what attributes does your application/service require to identify a unique user?

Configuring a Cloud-hosted Service to Work with Pitt Passport

When working with Pitt Passport, there are a few questions to ask your cloud service vendor about supporting single sign-on.

  1. Does your vendor's interface supports Security Assertion Markup Language (SAML)? SAML is an XML-based open-standard data format for exchanging authentication and authorization data between two applications. In most cases, between an identity provider and a service provider. Specifically, Pitt Passport supports SAML version 2.0.
  2. Does your cloud service provider support the use of Shibboleth implementation? Shibboleth is at the heart of Pitt Passport and is single sign-on technology.
  3. Is your cloud provider part of the InCommon Federation? Being a part of the InCommon Federation allows for an easier integration path. When integrating Service Providers with Identity Providers, both parties will exchange metadata about themselves with each other. The InCommon Federation will automatically exchange this information with all parties that have participated in the federation.
  4. What attributes does your cloud service provider require to identify a unique user? (If they are not part of the InCommon Federation)

Configuring an On-premises Service or Application to Work with Pitt Passport

When working with Pitt Passport, there are a few questions to ask the vendor of your on-premises service/application about supporting single sign-on.

  1. Does the service/application interface support Security Assertion Markup Language (SAML)? SAML is an XML-based open-standard data format for exchanging authentication and authorization data between two applications. In most cases, between an identity provider and a service provider. Specifically, Pitt Passport supports SAML version 2.0.
  2. Does the service/application support the use of Shibboleth implementation? Shibboleth is at the heart of Pitt Passport and is single sign-on technology.

Configuring a Drupal Web Site to Work with Pitt Passport

In order to configure a Drupal site for Pitt Passport single sign-on (SSO) authentication, you will need to download the "SSO Plugin for Drupal" zipped file archive for either Windows or Linux. Both of these file archives are accessible via the Software Download Service which is accessible through the My Pitt Portal. The archives include a licensed plugin that can be used to make the process of adding SAML authentication to a Drupal site easier. Installation instructions are also included.

Configuring a Wordpress Web Site to Work with Pitt Passport

In order to configure a WordPress site for Pitt Passport single sign-on (SSO) authentication, you will need to download the "SSO Plugin for WordPress" zipped file archive for either Windows or Linux. Both of these file archives are accessible via the Software Download Service which is accessible through the My Pitt Portal. The archives include a licensed plugin that can be used to make the process of adding SAML authentication to a WordPress site easier. Installation instructions are also included.

Next Steps: Registering Your Service or Application

Once you have determined your service or application’s single sign-on attributes, you need to put in the tickets necessary to initiate the registration process. The first step in this process is to put in a ticket to register the service or application with the University.

  1. In order to proceed, you will need to know the following:
    • Display Name
    • Service Description (A couple of sentences describing what the application offers)
    • Information URL (Sometimes a link from the vendor’s Web site that explains the application in full.)
    • Account Type Entitlement (student, faculty, staff, alumni, applicant, sponsored)
    • Contact Information for Primary and Secondary (sometimes this can be the vendor’s support information)
      • Primary Contact Name
      • Primary Contact Email Address
      • Primary Contact Phone Number
      • Primary Contact Department (or company name if not with the University)
      • Primary Contact Type (admin, technical, vendor, other)
      • Secondary Contact Name
      • Secondary Contact Email Address
      • Secondary Contact Phone Number
      • Secondary Contact Department (or company name if not with the University)
      • Secondary Contact Type (admin, technical, vendor, other)

  2. Once you have all of these data fields determined, download and fill out the

  3. Contact the Technology Help Desk and create a ticket to add your service or application to Pitt Passport single sign-on authentication. You will need to submit the completed Pitt Passport Online Vendor Application Request Form as part of this process so consider initiating your help ticket request via email to helpdesk@pitt.edu with the completed form attached.

Once your ticket is submitted, a CSSD representative will contact you to assist you through the process.

Final Steps: Export Service Provider Metadata and Finalize Service Provider Registration

Once the application configuration is completed, the last steps involve generating and exporting the service provider’s metadata. and complete the service registration.

  1. Gather the following information. Typically, this information can be provided by the vendor or the application technical contact in your department.
    • Entity ID
    • Requested Attributes (the following attributes are released without requiring further permission for release)
      • eduPersonPrincipalName
      • eduPersonScopedAffiliation
      • eduPersonTargetedID
      • PittAccountType
      • PittL
      • PittPSStudentRC
      • PittSponsorRC
      • eduPersonEntitlement
      • eduPersonAffiliation
      • eduPersonNickname
      • PittDepartmentID
      • PittDeptDescription
      • PittEmployeeRC
    • Service URL (The URL of the application’s login page)
    • Service Provider Technology (Typically one of the following)
      • ADFS
      • Ping Federation
      • Shibboleth SP
      • F5
      • OKTA
      • Other
      • Service Provider Metadata
      • Logo URL (Optional)
      • Logo Width (Optional)
      • Logo Height (Optional)

    • Once you have these data fields determined, download and fill out the Pitt Passport Service Provider Registration Form.

    • Contact the Technology Help Desk and create a ticket to complete the registration of your service or application to Pitt Passport single sign-on authentication. You will need to submit the completed Pitt Passport Service Provider Registration Form as part of this process so consider initiating your help ticket request via email to helpdesk@pitt.edu with the completed form attached.

Required Files

You will need the following files to register your application or service with the InCommon Federation using the production Pitt Passport (Shibboleth) service:

You will need the following files to register your application or service with the InCommon Federation using the development Pitt Passport (Shibboleth) service: