Azure Active Directory SSO Integration Guide

Azure Active Directory (Azure AD) provides an easy way for businesses to manage identity and access, both in the cloud and on-premises. Your users can use the same work or school account for single sign-on to any cloud and on-premises web application.  Your users can use their favorite devices, including iOS, Mac OS X, Android, and Windows. Your organization can protect sensitive data and applications both on-premises and in the cloud with integrated multi-factor authentication ensuring secure local and remote access. Azure AD extends your on-premises directories so that information workers can use a single organizational account to securely and consistently access their corporate resources. Azure AD also offers comprehensive reports, analytics, and self-service capabilities to reduce costs and enhance security. The Azure AD SLA ensures that your business runs smoothly at all times and can be scaled to enterprise levels.

 

 

In Your Azure Management Portal

1. Click the Azure Active Directory icon, then in the left menu column click Enterprise Applications.
2. Click + New application.
3. Search for and select PagerDuty, then click Create.
4. Click on the step 1 tile Assign users and groups.
5. Select Add user/group in the upper left.
6. Select all desired users and groups, click Select at the bottom, then Assign.
   (Note: All users who will use SSO login for PagerDuty will need to be added to this PagerDuty app in Azure either individually or by group in order for login to work.)
7. Navigate back to the Overview at the top of the left menu column, go to step 2 Set up single sign on, and select the SAML tile.
8. Edit the first section, Basic SAML Configuration:
   • Set Identifier (Entity ID) to the following format using your subdomain:

     https://YOUR_SUBDOMAIN.pagerduty.com

   • Set Sign on URL to:

     https://YOUR_SUBDOMAIN.pagerduty.com/sso/saml/sign-in

   • Set Reply URL to:

     https://YOUR_SUBDOMAIN.pagerduty.com/sso/saml/consume

   • Click Save at the top on the left.
   • Click out of Basic SAML Configuration with the X box in the far upper right.
9. Edit the second section, User Attributes & Claims:
   • Click the required claim Unique User Identifier (Name ID).
   • Select Email address from the Choose name identifier format dropdown, set the Source attribute value to user.mail, then click Save.
     
   • Click Add new claim:
     • Set the Name field to name.
     • Make sure that Namespace is empty.
     • Set Source attribute to user.displayname.
     • Repeat the Add new claim step for each of the following optional attributes that you wish to be provisioned into PagerDuty:
       1. Name: emailaddress, Source attribute: user.mail.
       2. Name: jobresponsibilities, Source attribute: user.jobtitle.
       3. Name: role, Source attribute: This can be a hard-coded value, for example limited_user (a Responder role), if you wish for all users to be provisioned with the same role, or you can use Claim Conditions to determine the role based on group membership;  in either case, the value sent must be one of PagerDuty’s REST API user role values.
   • Click out of User Attributes & Claims with the X box in the far upper right.
10. In the third section, SAML Signing Certificate, download Certificate (base64).
11. Take note of the fourth section, Set up PagerDuty, and leave the page here;  you’ll need these values shortly on the PagerDuty side:
    • Login URL
    • Logout URL

In PagerDuty

1. Log in to PagerDuty in a new window as the Account Owner.
2. Click on the User Icon in the upper right hand corner, and select Account Settings.
3. Select the Single Sign-On tab at the top of the screen.
4. Select SAML as the login authentication type.
5. Open the previously-downloaded certificate, copy all its contents, and paste it in the X.509 Certificate field.
6. Toggle back to the Azure window to copy the values for Login URL and Logout URL.
7. Make sure the Require EXACT authentication context comparison option is checked.
8. If you’d like to disable username and password authentication for your PagerDuty account for all users, except the Account Owner, you can uncheck the Allow username/password login check box.
9. If you’d like PagerDuty to automatically create accounts for anyone who has access via Azure SSO upon their first login, check the box next to Auto-provision users on first login.

FAQ

Why are users being provisioned with only the email?

If the attribute claims are not properly configured, fields such as name and role will not transfer properly when a user is created upon first SSO login.  Commonly, this happens when Namespace is not empty on those claims.  Make sure that on each attribute claim (except the Unique User Identifier) the Namespace field is empty and each Name field’s value is spelled exactly as indicated in step 9 of the Azure section above. 

Why am I getting the error message “Authentication method ‘WindowsIntegrated’…doesn’t match the requested authentication method…”?

Part of the SAML request sent to Azure from PagerDuty during the first stage of authentication (when a user clicks Sign in with my identity provider and is redirected to Azure) is requested authentication context (the RequestedAuthnContext element), which is a stated preference for certain minimum level of security for user authentication in the identity provider. Our SAML service includes this when sending requests to every service provider, Azure included.

Per Azure’s SAML protocol implementation, only the password class of authentication type (urn:oasis:names:tc:SAML:2.0:ac:classes:Password) is supported when requesting an authentication context:

Azure AD supports only one AuthnContextClassRef value: urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

Furthermore, Azure’s SAML service requires the service provider to specify that there must be an exact match between the requested and authentication context to exactly match the one requested by the service provider (this is enabled via the Require EXACT authentication context comparison option); a different error stating that the context comparison must be exact will result otherwise.

In summary:

• PagerDuty includes the RequestedAuthnContext element to request that the identity provider use, at the bare minimum, password authentication to identify users.
• Azure expects the service provider require an exact match between the authentication type provided with the one requested, whenever RequestedAuthnContext is provided.
• Azure only supports requesting Password type authentication when specifying RequestedAuthnContext.

Users can get around this issue by using a different web browser that does not attempt to authenticate with the identity provider via the WindowsIntegrated authentication method, and using password authentication to access their identity.

If your organization and IT workflow requires Integrated Windows authentication and your end users are affected by this known issue, please share your feedback to us in the PagerDuty Community or by sending us an email.

For further reference:

• SAML 2.0 Protocol Core Specification
• Azure SAML Protocol