We will continue the deployment and configuration of more business apps to allow you to test the different authentication mechanisms. For our support, we configure ServiceNow with SAML and active user provisioning from Azure AD to ServiceNow:

1. Navigate to Azure Active Directory | Enterprise Applications and add a New Application:

2. Choose ServiceNow and add the app from the gallery:

3. After adding the application, we will configure SAML to authenticate our users:

4. In the Basic SAML Configuration, we add our ServiceNow instance information, as shown in the following screenshot:

The following URIs need to be used:

https://.service-now.com/navpage.do
https://.service-now.com

5. For the manual configuration tasks, you can download the certificate by using the Base64 option:

6. Also, for manual configuration tasks, you can copy the following links into a Notepad:

7. Next, we will assign our Service Management Application Access group to the application:

8. Now, we can start to configure the ServiceNow instance for Single Sign-On.

9. First, we need to activate the Multi-Provider Single Sign-On Installer plugin:

10. You will find this option in the navigation pane on the left-hand side: System Definition | Plugins.
11. Activate the following plugin:

12. Click the Activate button in the dialog:

13. Next, we will configure the plugin under Multi-Provider SSO | Administration | Properties:

14. The following features need to be activated:

15. If you want to use the manual configuration method, you need to use the information in your Notepad.
16. We use the automatic option for the configuration; it's a little bit of a hidden option!
17. You will find it under View step-by-step instructions as shown in the following screenshot, in the SAML configuration section:

18. Click the option and the following dialog appears; enter your ServiceNow administrative credentials:

19. Click Configure Now.
20. Next, we can do additional configuration tasks on the ServiceNow part.
21. Navigate to Multi-Provider SSO | Identity Providers:

22. You will find the automatically generated Identity Provider:

23. We need to remove the populated Identity Provider's SingleLogoutRequest URL.

24. All the other fields can be left as their defaults:

25. Very important! Set the Auto Redirect IdP option, with the expected result:

26. Next, we need to choose the correct certificate for our configuration by navigating to the X.509 section:

27. Save the configuration.

Now, we have finished the SAML configuration of SeviceNow and we will follow up with the user provisioning:

1. Navigate to the Provisioning section of the ServiceNow application and change the Provisioning Mode to Automatic.
2. Insert the following values:

• • Instance Name
  • Admin Username
  • Admin Password
  • Notification Email (and check Send an email notification when a failure occurs):

3. Click Test Connection and you should receive a notification like the following example. The test of the connection is required to save:

4. Next, we will take a look into the synchronization configuration for users and groups.
5. Click the Synchronize Azure Active Directory Users to ServiceNow rule:

6. You will find the active Attribute Mapping. If you need to handle special considerations, such as if you connect to a filled ServiceNow instance, you can modify the mappings to fit your needs:

7. You will also get an actual overview of the Synchronization Details:

8. By clicking on View the "Account Provisioning" category in the audit logs for full details you will get the following screenshot:

9. Next, we will change to the Organization | User section in your ServiceNow instance.
10. Search for your test user, in my case [email protected], and you will see the result of the automatic provisioning:

The initial synchronization takes longer to perform than subsequent synchronizations, which occur approximately every 40 minutes as long as the service is running.

The next scenario we want to accomplish is the use of OpenID Connect and your on-premises ADFS infrastructure. To follow the authentication flow, use Chapter 6, Managing Authentication Protocols.

To configure this scenario on your YD1APP01 server, we need to copy the active-directory-dotnet-webapp-openidconnect folder from the code package to your desktop.

We configure your ADFS server (YD1ADS01) on your domain controller to get the following expected result at the end, a full working OpenID authenticated application:

In the next steps, we will configure the scenario:

1. We start with the creation of a new application group including a Server application (standalone application):

2. Next, a Client Id is generated; copy the ID to a notepad.

3. Enter the redirect URI, https://localhost:44320/, under which the application will run:

4. Click Next and check Generate a shared secret box; copy the key to the notepad:

5. Complete the wizard.
6. Next, we will create the Web API configuration by double-clicking on your new application group.

7. Choose Add application:

8. Use the Web API option:

9. Next, add the Identifier for the API: https://inovitdemos.ch/OpenIDDemo.
10. Click Next in the Access Control Policy section and all the other sections to finish the wizard.
11. For now, we change to the YD1APP01 server and open our Visual Studio.
12. Open the Solution file of the demo code: WebApp-OpenIDConnect-DotNet.sln.
13. Navigate in Solution Explorer to the web.config file: WebApp-OpenIDConnect-DotNet.sln.
14. Modify the code so that it looks like the following example:
    • Copy your Client Id from your notepad.
    • Configure the ida:ADFSDiscoveryDoc value so that it contains your ADFS FQDN: https://login.inovitdemos.ch.
    • Verify that the ida:PostLogoutRedirectUri value contains https://localhost:44320/:

 <appSettings>
 <add key="webpages:Version" value="3.0.0.0" />
 <add key="webpages:Enabled" value="false" />
 <add key="ClientValidationEnabled" value="true" />
 <add key="UnobtrusiveJavaScriptEnabled" value="true" /> 
 <add key="ida:ClientId" value="40ef7c28-2172-4e4d-84b5-e9a284b94f75" />
 <add key="ida:ADFSDiscoveryDoc" value="https://login.inovitdemos.ch/adfs/.well-known/openid- configuration" />
 <add key="ida:PostLogoutRedirectUri" value="https://localhost:44320/" />
</appSettings>

15. Next, navigate to the App_Start section and the Startup.Auth.cs file.
16. Directly under the public partial class Startup, the code needs to look like the following to tweak the OpenID Connect middleware initialization logic:

private static string clientId = ConfigurationManager.AppSettings["ida:ClientId"];
 //private static string aadInstance = ConfigurationManager.AppSettings["ida:AADInstance"];
 //private static string tenant = ConfigurationManager.AppSettings["ida:Tenant"];
private static string metadataAddress = ConfigurationManager.AppSettings["ida:ADFSDiscoveryDoc"];
private static string postLogoutRedirectUri = ConfigurationManager.AppSettings["ida:PostLogoutRedirectUri"];
 //string authority = String.Format(CultureInfo.InvariantCulture, aadInstance, tenant);

17. Next, we need to modify the OpenID Connect middleware options:

app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions 
 { 
 ClientId = clientId, 
 //Authority = authority, 
 MetadataAddress = metadataAddress, 
 RedirectUri = postLogoutRedirectUri, 
 PostLogoutRedirectUri = postLogoutRedirectUri

18. Now, we can verify the app; press F5 in Visual Studio. To analyze the traffic, you can use Fiddler. Note that you will be stuck with Fiddler on the authentication part:

19. Well done, you have configured an application that uses OpenID Connect!