Overview
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 myPitt. 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.
Detail
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 myPitt 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.
- 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.
- Does your application/service support the use of Shibboleth implementation? Shibboleth is at the heart of Pitt Passport and is single sign-on technology.
- 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.
- If your service provider organization is not part of the InCommon, what attributes does your application/service require to identify a unique user?
First Steps: Determining Your Service or Applications Single Sign-on Attributes - 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.
- 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.
- 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.
- 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.
- What attributes does your cloud service provider require to identify a unique user? (If they are not part of the InCommon Federation)
First Steps: Determining Your Service or Applications Single Sign-on Attributes - 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.
- 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.
- Does the service/application support the use of Shibboleth implementation? Shibboleth is at the heart of Pitt Passport and is single sign-on technology.
First Steps: Determining Your Service or Applications Single Sign-on Attributes - Configuring a Drupal Website to Work with Pitt Passport
In order to configure a Drupal site for Pitt Passport single sign-on (SSO) authentication, you will need to log in to the Software Download Service which is accessible through myPitt and download the "SSO Plugin for Drupal" zipped file archive for either Windows or Linux. The archives include a licensed plug-in that can be used to make the process of adding SAML authentication to a Drupal site easier. Installation instructions are also included.
First Steps: Determining Your Service or Applications Single Sign-on Attributes - Configuring a Wordpress Website to Work with Pitt Passport
In order to configure a WordPress site for Pitt Passport single sign-on (SSO) authentication, you will need to log in to the Software Download Service which is accessible through myPitt and download the "SSO Plugin for WordPress" zipped file archive for either Windows or Linux. The archives include a licensed plug-in 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 open the cases necessary to initiate the registration process. The first step in this process is to open a case to register the service or application with the University.
- 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 website 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)
- Once you have all of these data fields determined, download and fill out the
- Contact the Technology Help Desk and create a case 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 request via email to helpdesk@pitt.edu with the completed form attached.
Once your case is submitted, a Pitt IT 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.
- 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)
- surName
- givenName
- displayName
- email
- commonName
- 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
- Once you have these data fields determined, download and fill out the Pitt Passport Service Provider Registration Form.
- Contact the Help Desk and create a case 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 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:
Related Information