Customers on our Standard and Enterprise pricing plans have access to Single Sign-On integrations. If your account is on one of these plans, the Account Owner can access SSO settings by going to Configuration > Account Settings > Single Sign-On.
What is Single Sign-On?
With Single Sign-On, you can:
Revoke user access: When an employee leaves the company, administrators can remove PagerDuty access within the SSO provider rather than having to log directly into PagerDuty.
Note: Revoking a user's access at your SSO provider will prevent the user from logging in via SSO, but will not delete the user in PagerDuty. You must still log in to PagerDuty to delete the user.
Have a one-click corporate login: This eliminates the need for a separate PagerDuty username and password, which means one less thing to remember!
Have on-demand user provisioning: It's easy to provision new users for PagerDuty access. PagerDuty user accounts are created on-demand once access is granted via the SSO provider.
How do I configure Single Sign-On (SSO)?
We currently have integration guides for the following SSO providers:
For custom SAML configurations, we provide the following metadata URL to make your configuration easier:
For manual SAML configurations, we will validate and enforce the following attributes in the SAML payload:
Destination (sometimes labeled SAML Recipient in IdP configuration forms) is expected to be:
Audiences (sometimes labeled SAML Audience in IdP configuration forms) is expected to be:
Note: There should be no trailing slash. Users will receive a 400 error when trying to log in if there is a
/after your subdomain.
Name ID is expected to be the user's email address:
Optional Attributes for Auto-Provisioning
User names will be set to the value of the
nameattribute we receive in your SAML payload. If there is no
nameattribute in your SAML payload then the user's name will default to their email address.
- User roles will be set to the value of the
roleattribute we receive, where the value must match one of our REST API user role values:
read_only_user(known as Stakeholder user). If there is no
roleattribute in your SAML payload then the user's role will default to the User role.
Note: These attributes will only be used when a user is initially created. Changing the user's email address, name, or role in your IdP will not change these values in PagerDuty; you will still need to update a user's login email address, name, or role in PagerDuty if you change them in your IdP after the user has already been automatically provisioned in PagerDuty.
Shibboleth Configuration Help
You can hand-craft a metadata file if you wish. The contents should look similar to the following. Be sure to replace subdomain with your own PagerDuty subdomain.
In addition to configuration via metadata, a RelyingParty configuration, such as shown the example below, will need to be created in Shibboleth. Be sure to replace the provider URL with your own.
<rp:RelyingParty id="https://subdomain.pagerduty.com" provider="https://domain/idp/shibboleth" defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" defaultSigningCredentialRef="IdPCredential"> <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true" assertionLifetime="300000" assertionProxyCount="0" signResponses="conditional" signAssertions="never" signRequests="conditional" encryptAssertions="never" encryptNameIds="never" /> </rp:RelyingParty>
Please contact our sales team if you are interested in upgrading to a Standard or Enterprise account to utilize SSO with PagerDuty, or contact our support team if you run into technical issues with your SSO integration.