CASE STUDY 1: SSO AND USER MANAGEMENT FOR THIRD-PARTY SAAS

In this case study, Adatum Inc. is an Office 365 customer. One of the departments recently selected Salesforce as its customer relationship management (CRM) solution. Adatum Inc. likes the turnkey nature of cloud-based SaaS so that it does not need to add and manage more on-premises infrastructure.

Challenge

Adatum Inc. faced two challenges with this decision. First, IT needed to manage Salesforce users separately in Salesforce. Second, Salesforce users needed to manage their own login credentials and passwords, which are separate from their AD credentials.

Resolution

Adatum Inc. chose to extend AAD to provide SSO for Salesforce. After all, users were already synchronized to AAD, and the company’s SSO infrastructure was already deployed. Using an existing IDM was the best approach in this scenario. Figure 10-2 depicts how AAD will be used for Salesforce for Adatum Inc.

EXTENDING AAD FOR A THIRD-PARTY SAAS

The following exercise walks you through the steps that Adatum Inc. took to extend AAD to Salesforce. This exercise shows the steps of extending AAD for provisioning and authenticating Salesforce accounts. At the time of writing, the new Preview Portal does not include the ability to configure AAD, so this exercise uses the traditional Portal.

In order to configure Salesforce with AAD, you may need to go back and forth between Salesforce and AAD, so it is recommended that you open a separate browser window for the Salesforce configuration. Doing so minimizes confusion and will help you keep track of the configuration process. This exercise also assumes the following:

• AAD and AAD Sync have been configured, if you want to integrate third-party SaaS provisioning as part of your organization’s AD account provisioning and de-provisioning (recommended).
• There is an existing enterprise Salesforce account.
• Your organization already has an Azure Active Directory Premium subscription, or you have signed up for a trial AADP subscription. If you do not have AADP, you may not be able to see some of the options described in the following exercises—for example, self-service password reset (SSPR).

Follow these steps:

1. Go to the AAD that will be used for Salesforce authentication, and click Applications, as shown in Figure 10-3.

   

   Figure 10-3. Adding a new third-party SaaS to AAD

2. In the pop-up window, select Add An Application From The Gallery, type salesforce in the search window, and click the magnifying glass, as shown in Figure 10-4.

   

   Figure 10-4. Adding Salesforce to AAD from the gallery

3. Select Salesforce from the search results, and click the check mark in the lower-right corner of the screen.
4. Once Salesforce has been added, under Step 1, click the green Configure Single Sign-On button.
5. For this exercise, select Windows Azure AD Single Sign-On, and then click the arrow in the lower-right corner.

    Note  In your organization’s actual deployment scenario, select the SSO method that best matches your identity-management scenario.

6. On the Configure App Settings screen, click the Learn More link, and view the configuration instructions, as shown in Figure 10-5. Note that you need to do this each time you add a different SaaS application to AAD, because each application from the gallery has different steps and requirements; read the instructions so you have a better idea of what to expect. This exercise, however, walks you through the entire setup process.

   

   Figure 10-5. Viewing custom instructions to add Salesforce to AAD

7. Open a new, separate browser window, and log in to your Salesforce account at https://login.salesforce.com.
8. Along the left side of the screen, expand the Domain Management menu, and click My Domain, as shown in Figure 10-6.

   

   Figure 10-6. Registering a Salesforce subdomain

9. Enter a subdomain name, and click Check Availability. If the subdomain is available, a green Available notification appears, as shown in Figure 10-6. Read the Terms and Conditions, check the box to agree, and then click Register Domain. Make a note of your subdomain name, which you use in step 10.
10. Return to the AAD configuration browser screen, shown in Figure 10-5, and enter the Salesforce subdomain URL you registered in step 9, making sure you prefix the URL with https:// (for example, https://apressdemo-dev-ed.my.salesforce.com). Then click the arrow in the lower corner.
11. In the Configure Single Sign-On At Salesforce page, click Download Certificate, as shown in Figure 10-7. Save the certificate to your computer. Make a note of the location and filename, because you will need to upload the certificate to Salesforce later. You can view the Salesforce configuration instructions, but this exercise walks you through the process.

    

    Figure 10-7. Downloading a certificate for Salesforce

12. Return to the Salesforce browser window to continue with the Salesforce configuration.
13. Expand Security Controls in the menu on the left, and select Single Sign-On Settings, as shown in Figure 10-8.

    

    Figure 10-8. Configuring Salesforce SSO settings

14. Click Edit to configure SAML.
15. Enable SAML by selecting the SAML Enabled check box. Click Save.
16. Click New under SAML Single Sign-On Settings.
17. Type in a name for this SAML configuration. Use the name AzureSSO for this exercise.
18. Return to the Azure AD configuration browser window, shown in Figure 10-7, and copy the issuer URL to the clipboard by clicking the icon located at the end of the URL, as shown in Figure 10-9.

    

    Figure 10-9. Copying URLs from AAD to paste into the Salesforce configuration

19. Return to the Salesforce browser where you’re configuring the Salesforce SSO, and paste the URL into the Issuer field.
20. Repeat steps 18 and 19 to copy the remote login URL from AAD and paste it into the Identity Provider Login URL field in Salesforce.
21. Again, repeat steps 18 and 19 to copy the remote logout URL from AAD and paste it into the Identity Provider Logout URL field in Salesforce.
22. Still in the Salesforce SSO configuration browser, click the Browse button next to Identity Provider Certificate. Navigate to the certificate downloaded in step 11, select the certificate, and click Open.
23. In the SAML Identity Type section, select Assertion Sontains User’s salesforce.com Username.
24. In the SAML Identity Location section, select Identity Is In The NameIdentifer Element Of The Subject Statement.
25. For Service Provider Initiated Request Binding, select HTTP Redirect.
26. In the Entity ID field, enter the Salesforce subdomain URL registered in step 10, making sure you prefix the URL with https:// (for example, https://apressdemo-dev-ed.my.salesforce.com).
27. Click the Save button on the Salesforce SSO configuration screen to save the settings.
28. Click and expand the Domain Management menu in Salesforce, and select My Domain.
29. On the My Domain page in the Authentication Configuration section, click the Click Here To Login button.
30. After the login completes, make the custom Salesforce domain available by clicking Deploy To Users.
31. When you see the warning that the deployment cannot be reversed, click OK.
32. In the Authentication Configuration section, click Edit.
33. If you have a custom logo, you can choose to upload it to brand your organization’s Salesforce subscription.
34. Select Azure SSO as an authentication service. Optionally, you can de-select Login Page if you only want to allow authentication through Azure SSO without the option of preventing a Salesforce-only account from logging in.
35. Click Save.
36. Return to the AAD configuration browser. You should still be on the Configure Single Sign-On At Salesforce screen. Select the “Confirm that you have configured single sign-on as described above. Checking this will enable the current certificate to start working for this application” check box at the bottom of the screen.
37. Click the arrow to advance to the next screen.
38. Verify and provide an e-mail address for notification of successful configuration, and then click the check mark at the bottom of the screen to complete the setup.
39. Click the Configure User Provisioning option in step 2.
40. Enter your Salesforce admin account and password.
41. For the User Security Token field, do the following:
    1. Go to the browser with your Salesforce configuration. Click the down arrow next to your name at upper-right, and select My Settings.
    2. Expand Personal in menu at left, and select Reset My Security Token.
    3. Click the blue Reset Security Token button.
    4. The new security token is e-mailed to you.
    5. Copy the security token string from the e-mail.
    6. Return to the Azure SSO User Provisioning configuration screen.
    7. Ignore the instructions to append the security token to your password. Instead, enter the security token string from the e-mail into the User Security Token field.
42. Click the arrow at the bottom of the screen.
43. If there are no errors, you see a confirmation screen. Click in the lower-right corner to complete the configuration for user provisioning.
44. Once AAD and Salesforce have been configured, you can test authentication to Salesforce through SSO. However, before doing so, you must assign users to the application:
    1. Click the Assign Users button in the Salesforce application configuration window.
    2. In the Users And Groups window, select the user or users to whom you want to assign access, and click Assign at the bottom of the screen, as shown in Figure 10-10.
    3. Select the appropriate Salesforce role for your users, and click the check mark in the lower-right corner.

Users can now log in to Salesforce using their Active Directory credentials without being prompted for their user name or password.

CASE STUDY 2: SSO FOR CUSTOM DEVELOPED APPS

SSO for third-party SaaS was introduced in the previous case study. What about the case where in-house custom applications also require SSO?

Challenge

Adatum Inc. has several in-house custom line-of-business (LOB) applications, which are claims-based apps in the demilitarized zone (DMZ). Adatum Inc. would like to allow employees access to these applications from the Access Panel and to experience a SSO experience similar to that of third-party SaaS.

Resolution

The process to extend AAD to provide SSO for in-house custom applications is similar to the steps outlined in Case Study 1 for third-party SaaS. However, instead of selecting Add An Application From The gallery in step 3 of the exercise “Extending AAD for a Third-Party SAAS,” choose the option Add An Application My Organization Is Developing, as shown in Figure 10-13.

Adatum Inc.’s developers must make sure custom in-house apps can federate and authenticate with AAD. Therefore, the developers need to understand the concept of claims-based protocols, such as SAML and OAuth, as well as security and access concepts, such as the Service Principal Name of an application. Going into the details about such developer-specific topics is beyond the scope of this book, but there are many good resources on this topic, including this blog post from Vittorio Bertocci, a Microsoft developer: www.cloudidentity.com/blog/2012/07/12/single-sign-on-with-windows-azure-active-directory-a-deep-dive-2.

AAD continues to evolve rapidly. You can keep up to date on all the new and upcoming features of AAD through the AD Team Blog: http://blogs.technet.com/b/ad.

In this case study, AAD is also used for in-house custom LOB applications. This provides SSO for most modern applications and thus provides users with a more seamless experience when accessing applications after the initial authentication. It also provides IT administrators with a single model to provision users through AD and AAD without having to manage disparate IDMs specific to individual applications.

CASE STUDY 3: SELF-SERVICE PASSWORD RESET (SSPR)

Adatum Inc. is exploring options to streamline IT operations by reducing the amount of busywork for IT administrators so that precious IT resources can be put to better use. Adatum Inc. would also like to provide better customer service for employees and 24×7 support for as many IT requests as possible.

Challenge

Adatum Inc. needs to optimize the use of IT resources in order to remain competitive. As a multinational corporation, Adatum Inc. has employees located throughout the world, and it may not be economical to have multiple Help Desks or even a single 24×7 Help Desk to support a global workforce. But whenever IT issues prevent employees from accessing Adatum Inc.’s systems, there is a loss of productivity that impacts revenues.

Resolution

Adatum Inc. discovered that, in addition to SSO for third-party SaaS, AAD also provides users with the self-service capability to reset passwords securely. With this ability, employees around the world can reset their passwords without contacting the Help Desk.

ENABLING USER SELF-SERVICE WITH AAD

This exercise demonstrates the steps required to configure user SSPR as well as the end-user experience. It also shows the steps to configure AAD SSPR:

1. Go to the Azure Management Portal at https://manage.windowsazure.com.
2. Select the desired directory in Azure, and click Configure, as shown in Figure 10-14.

   

   Figure 10-14. Configuring a directory in Azure

3. Configure the parameters under User Password Reset Policy, also shown in Figure 10-14. The options are self-explanatory, so it is left to you to finish configuring the password-reset policy based on the organization’s needs.
4. Once the self-service password policy has been set, users must be provided with this link in order to be guided through a registration process to provide verification information: http://aka.ms/ssprsetup. This link can be sent via e-mail or placed on the organization’s intranet page. Alternatively, you can turn on the option to require a user to be prompted automatically for the information upon initial login.