PagerDuty can be configured with Single Sign-On (SSO) to external identity providers (IdPs) such as Microsoft Active Directory (using ADFS), Bitium, OneLogin, Okta, Ping Identity, SecureAuth and others using the SAML 2.0 protocol. Alternatively, your account can also be configured to support Google authentication using the OAuth 2.0 protocol (with user consent). SSO comes with the following benefits:
- One-Click Corporate Login: This eliminates the need for a separate PagerDuty username and password, which means one less thing to remember.
- On-Demand User Provisioning: PagerDuty user accounts are created on-demand once access is granted via the SSO provider.
- Revoke User Access: When an employee leaves the company, administrators can quickly remove PagerDuty access within the SSO provider.
Single Sign-On is available on Professional, Business, and Digital Operations pricing plans. Please contact our Sales team to upgrade to a plan with this feature.
Required User Permissions
Only Account Owners can configure Single Sign-On.
To configure SAML SSO:
- Search for your Identity Provider’s integration guide and follow the instructions in the guide.
- If the guide instructs you to paste information from your identity provider into your PagerDuty SSO configuration page, the Account Owner can access SSO settings by navigating to User Icon Account Settings Single Sign-On. Select the SAML radio button to continue steps in the integration guide. Note: Not all identity providers require this step. Please defer to the instructions in the integration guide.
- Configure your settings related to Allow username/password login, Require EXACT authentication context comparison and Require signed authentication requests depending on your integration guide’s instructions and your preferences.
- Optional: Under User Provisioning you can choose to Auto-provision users on first login or Redirect non-provisioned users.
- Once you are finished with the steps in your integration guide, click Save Changes in PagerDuty.
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 in 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>
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 identity provider configuration forms) is expected to be:
- Audiences (sometimes labeled SAML Audience in identity provider configuration forms) is expected to be:
There should be no trailing slash. Users will receive an
HTTP 400error when trying to log in if there is a
/at the end of the URL.
- Name ID is expected to be the user's email address:
- 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). Accounts with Advanced Permissions may also pass an
observerrole. If there is no
roleattribute in your SAML payload then the user's role will default to the
userrole. This User role is linked to the User basic role and Manager advanced permission role.
- The job title of the user will be derived from the
jobresponsibilitiesattribute in the SAML payload, if present.
These attributes will only be used when a user is initially created. Changing the user's email address, name, or role in your identity provider will not change these values in PagerDuty; you will still need to update a user's login email address, name, or role in PagerDuty via API if you change them in your identity provider after the user has already been automatically provisioned in PagerDuty.
Auto-provisioning users can get responders up and running quickly, but it will affect your account’s billing. If you do not wish to auto-provision users, you can optionally redirect non-provisioned users to a destination link, such as an internal wiki, for more information about getting provisioned in your identity provider.
Required User Permissions
Only the Account Owner can configure non-provisioned user settings.
To redirect non-provisioned users to a destination link:
- Navigate to User Icon Account Settings Single Sign-On.
- The SAML radio button should be selected. Under the User Provisioning section, check the checkbox next to Redirect non-provisioned users and enter the Destination Link where they should be redirected.
- Click Save Changes.
Required User Permissions
Only Account Owners can configure Google Authentication (OAuth 2.0).
To configure Google Authentication:
- Navigate to User Icon Account Settings Single Sign-On. Select the Google radio button.
- Enter the Google Domain associated with your Google Apps account.
- Depending on your preferences, optionally select whether you would like to Allow username/password login and/or Auto-provision users on first login.
- Click Save Changes. Users will now be prompted to login via Google Authentication.
Revoke User Access
Revoking a user's access in 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 the PagerDuty web app to remove them from schedules, escalation policies, and delete their user account.
GSuite Multiple Domains Limitation
The PagerDuty Google Auth integration supports a single domain and cannot be used for multiple domains available in GSuite.
Please read Log In to PagerDuty for more information about logging in to PagerDuty via SSO as an end user.
- Confirm that you are using a valid x509 certificate.
- Confirm that each row in your x.509 certificate is a maximum of 64 characters.
- Confirm there is the text
-----BEGIN CERTIFICATE-----at the beginning of the certificate and
-----END CERTIFICATE-----at the end of the certificate.
Yes. PagerDuty will treat signatures from the identity provider as valid as long as:
- The certificate stored in the PagerDuty SAML settings matches the private key that the identity provider uses to sign SAML responses, and:
- The identity provider is configured to sign assertions.
Once these conditions have been met, users should be able to authenticate.
Account Owners retain the ability to log in by email address and password in the event that there is an issue with the SSO provider. This cannot be turned off.
Not at this time. Currently only one SSO option is configurable.
If configuring an on-premises identity provider, you should treat its private key with utmost secrecy and take appropriate security precautions.
Enabling SSO on the account, and then unchecking the option to Allow username/password login, does not by default log out any users currently logged in. If you would like all users to be force-logged-out and then required to log back in via SSO, there is a public API to manage user sessions that an account Admin can use to log out all users after the switch to SSO has occurred.
Updated about 1 month ago