Knowledge Base
API DocsIntegrationsPagerDuty UniversityPagerDuty CommonsContact SupportMy Support Tickets

Single Sign-On (SSO)

Streamline user authentication and access management

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, you can also configure your account to use Google authentication with the OAuth 2.0 protocol (with user consent). Accessing Private Status Pages is handled via the OpenID Connect (OIDC) protocol.

SSO comes with the following benefits:

  • One-Click Corporate Login: This eliminates the need for a separate PagerDuty username and password.
  • 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.

📘

Availability

Single Sign-On is available on the following pricing plans: Professional, Business, Enterprise for Incident Management and Digital Operations (Legacy). Please contact our Sales team to upgrade to a plan with Single Sign-On.

🚧

Required User Permissions

The Account Owner is the only user that can configure Single Sign-On settings.

Configure Identity Provider Single Sign-On (SAML)

To configure SAML SSO:

  1. Navigate to our Integrations Directory and select your identity provider’s integration guide.
  2. In the PagerDuty web app, navigate to User Icon Account Settings Single Sign-On. Select the option SAML and continue following the steps in the integration guide.
    1. Note: Not all identity providers require this step. Please refer to the instructions in the integration guide for specific instructions.
  3. 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.
  4. Optional: Under User Provisioning you can choose to Auto-provision users on first login or Redirect non-provisioned users.
  5. Once you are finished with the steps in your integration guide, click Save in PagerDuty.

Custom SAML Configuration

For custom SAML configurations, please use the following metadata URL:

https://{subdomain}.pagerduty.com/sso/saml/metadata

Required Attributes

For manual SAML configurations, we will validate and enforce the following attributes in the SAML payload:

  1. Destination (sometimes labeled SAML Recipient in identity provider configuration forms) is expected to be: 
https://{subdomain}.pagerduty.com/sso/saml/consume
  1. Audiences (sometimes labeled SAML Audience in identity provider configuration forms) is expected to be:
https://{subdomain}.pagerduty.com

🚧

Trailing Slashes

There should be no trailing slash at the end of the URL. Users will receive an error HTTP 400 when they try to log in if there is a / at the end of the URL.

  1. Name ID is expected to be the user's email address:
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Optional Attributes for Auto-Provisioning

If you enable the option to Auto-provision users on first login, please keep the following in mind:

  • User name: User names will be set to the value of the Name or name attribute we receive in your SAML payload. If there is no Name or name attribute in your SAML payload, then the user's name will default to their email address.
  • User role: User roles will be set to the value of the Role or role attribute we receive, where the value must match one of our REST API user role values: admin, limited_user, user or read_only_user (known as Stakeholder user). Accounts with Advanced Permissions may also use the observer role. If there is no Role or role attribute in your SAML payload then the user's role will default to user. This User role is linked to the User basic role and Manager advanced permission role.
  • Job title:The job title of the user will be taken from the jobresponsibilities attribute in the SAML payload, if present.

📘

Attributes

These attributes will only be used when a user is initially created. Changing a user's email address, name, or role in your identity provider will not change these values in PagerDuty. You will need to update a user's login email address, name, or role in PagerDuty if you change them in your identity provider after the user has already been automatically provisioned in PagerDuty.

Configure Google Authentication (OAuth 2.0)

To configure Google Authentication:

  1. In the PagerDuty web app, navigate to User Icon Account Settings Single Sign-On. Select the Google radio button.
  2. Enter the Google Domain associated with your Google Apps account.
  3. Depending on your preferences, optionally select whether you would like to Allow username/password login and/or Auto-provision users on first login.
  4. Click Save.

When users Log In to PagerDuty, they 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 account in PagerDuty. You must still log in to the PagerDuty web app to remove them from schedules, escalation policies, and delete their user account. Please read Offboarding for more information about removing user accounts in PagerDuty.

❗️

Google Workspace Multiple Domains Limitation

The PagerDuty Google Auth integration supports a single domain and cannot be used for multiple Google Workspaces.

Configure Open ID Connect (OIDC)

Users can access private status pages via SSO using the OpenID Connect protocol. Please read Private Status Pages for more information.

User Log In via SSO

Please read Log In to PagerDuty for more information about logging in to PagerDuty via SSO as an end user.

Redirect Non-Provisioned Users

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.

To redirect non-provisioned users to a destination link:

  1. In the PagerDuty web app, navigate to User Icon Account Settings Single Sign-On.
  2. 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.
  3. Click Save Changes.
Redirect non-provisioned users

Redirect non-provisioned users

FAQ

How do I know if my identity provider is "pinning" certificates?

PagerDuty rotates its SAML certificate every year, and we send out communications with instructions about how to rotate the certificate.

If your identity provider uses a static copy of PagerDuty’s SAML certificate (i.e., certificate pinning), you will need to update your identity provider every time PagerDuty rotates its certificate. If certificates are manually uploaded/configured rather than pulled from PagerDuty's metadata endpoint, you're likely pinning certificates. Check with your identity provider administrator to confirm.

No action is needed if your identity provider uses PagerDuty's SAML metadata endpoint (i.e., https://{subdomain}.pagerduty.com/sso/saml/metadata) to configure certificates dynamically. If you can log in via SSO without errors after certificate rotation dates, you're likely using dynamic configuration and no action is needed.

What should I do if role assignment isn't working?

If you notice that role assignment isn’t working as expected, or that users are created with a Stakeholder role instead of the intended role defined in the SAML payload, the following issues may be the cause:

  • Insufficient user licenses available on your account
  • Incorrect role attribute values in the SAML payload
  • The role attribute was not properly configured in your identity provider

Please confirm that your account has user licenses available and verify that role attribute values match PagerDuty's expected values exactly. Please read our developer documentation article Create a user for more information about valid role names.

Why do some users get authentication errors with Microsoft SSO?

Users may encounter an authentication error AADSTS75011 when using some authentication methods (e.g., MFA, passwordless, certificates). The full error is Authentication method by which the user authenticated with the service doesn't match requested authentication method.

If you receive this error, please contact our Support Team, who can enable authentication context bypass for your account. This will allow your identity provider to handle authentication requirements directly.

Why do I see an error An unexpected error occurred. Please try again. after entering my X.509 cert?

If you see an error An unexpected error occurred. Please try again. after entering your X.509 cert, please check the following:

  1. Confirm that the X.509 certificate is valid.
  2. Confirm that each row in your X.509 certificate is a maximum of 64 characters.
  3. Confirm that -----BEGIN CERTIFICATE----- is at the beginning of the certificate and -----END CERTIFICATE----- is at the end.

Example:

-----BEGIN CERTIFICATE-----
MIIDdjCCAl6gAwIBAgIURghXgSldiQTb3HEFXKz/MAoxnWwwDQYJKoZIhvcNAQEL
BQAwZzELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcM
DVNhbiBGcmFuY2lzY28xFTATBgNVBAoMDEV4YW1wbGUgQ29ycDEUMBIGA1UEAwwL
ZXhhbXBsZS5jb20wHhcNMjUwNjIzMTYzNjUyWhcNMjYwNjIzMTYzNjUyWjBnMQsw
CQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZy
YW5jaXNjbzEVMBMGA1UECgwMRXhhbXBsZSBDb3JwMRQwEgYDVQQDDAtleGFtcGxl
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAInvxB/KIvOpdxeG
yuEP9glNNyjZjj2qnrjimShHmUCgP0FvdZtjIzQcHsV375+K17QJQygiKQrW/L1r
aDvGmRkZsOOuuC7voiQ8sCb9oQ2YuQiRXZIFZhOEPI4N06sh4SHKShyhsXFdegZJ
S6BHYtO9gYEog9ILq2RH7gqcUBSG4aBiVw3EpN5kspnTBi30MX0g78T/ETSvn9j9
0y8kqaDghXNH+3SqArcN5P15K3NVW7A5lSWroMtcWv/7caycTh8JX4Plxy4laTnb
aG2uvrsUKMIf6nGDfeIso7i2XcrXTAB0EF5o4uIKVPB6I1vBtF0c/OEzx/o2T6xU
wepgdVsCAwEAAaMaMBgwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wDQYJKoZIhvcN
AQELBQADggEBAELrui2b3tVUq+NmK3C7xYEw0Hiqo0B1x8ijcvSHSHpiLOxOtcVl
ZMSScW7Xtqu21erw/LEQOI48CHnIw6JSS8XnsKQUoLT8NLcc2EkxkYWlIwBWmaN+
p8YaE+wy49JfdlaYI+3X9utCGrAoFJ/mMNX/ONKXdxV9SxlRxTnrvymHQb2S23uM
4uophIWmb8Gz1kaGBA/lxjVzKHPaFas7JRHVQG7TF/pyxKNmfsz205a+/6bxQ8QP
w3UsE2bPUXSiAVHygZE1Kgn7vLhkQY7G00NJaFpDgzNESRawWYBoDBSLWNgXHUvv
biTMqQD2QXqngpt4OjA9c7eLuiMd5wDNVT4=
-----END CERTIFICATE-----

Can I use a self-signed certificate for my SAML SSO integration?

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.

Why does the Account Owner have the ability to log in using email and password after enabling SSO?

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.

What happens if my identity provider has an outage?

If your identity provider has an outage and users are unable to log in via SSO, the Account Owner can log in using their email and password and temporarily enable email/password login for all users.

  1. In the PagerDuty web app, navigate to User Icon Account Settings.
  2. Select the tab Single Sign-on.
  3. In the section Allow username/password login, switch the toggle to the on position.
  4. At the bottom of the screen, click Save.

Note: Please remember to turn this setting off again after your identity provider restores service.

Can one PagerDuty Account have multiple SSO/SAML providers?

Not at this time. Currently only one SSO option is configurable.

🚧

Security Recommendation

If configuring an on-premises identity provider, you should treat its private key with utmost secrecy and take appropriate security precautions.

When switching from password login to SSO, are password-using users logged out from their accounts?

Enabling SSO on the account, and then disabling the option to Allow username/password login, will not also log users out of the web app or mobile app. You can use the REST API to end users’ sessions, which will require them to log in again using SSO. Please note you will use a different endpoint for the web app and the mobile app:

Can I use Shibboleth for SSO?

Yes. Shibboleth is an open-source identity management system, which may require a custom metadata file. Its contents should look similar to the following. Be sure to replace subdomain with your own PagerDuty subdomain (e.g., https://subdomain.pagerduty.com).

In addition to defining the metadata, you will need to configure RelyingParty in Shibboleth, as in the example below. 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>

Updated 3 days ago

Learn more