services | platforms | author |
---|---|---|
active-directory |
dotnet |
dstrockis,jmprieur |
In this sample a Windows console application (TodoListDaemonWithCert) calls a web API (TodoListService) using its app identity. This scenario is useful for situations where headless or unattended job or process needs to run as an application identity, instead of as a user's identity. The application uses the Active Directory Authentication Library (ADAL) to get a token from Azure AD using the OAuth 2.0 client credential flow, where the client credential is a certificate.
This sample is similar to Daemon-DotNet, except instead of the daemon using a password as a credential to authenticate with Azure AD, here it uses a certificate.
For more information about how the protocols work in this scenario and other scenarios, see Authentication Scenarios for Azure AD and Service to service calls using client credentials
Looking for previous versions of this code sample? Check out the tags on the releases GitHub page.
To run this sample, you will need:
- Visual Studio 2013 or above (also tested with Visual Studio 2015 and Visual Studio 2017)
- An Internet connection
- An Azure Active Directory (Azure AD) tenant. For more information on how to get an Azure AD tenant, please see How to get an Azure AD tenant
- (Optional) If you want automatically create the applications in AAD corresponding to the daemon and service, and update the configuration files in their respective Visual Studio projects, you can run a script which requires Azure AD PowerShell. For details on how to install it, please see the Azure Active Directory V2 PowerShell Module. Alternatively, you also have the option of configuring the applications manually through the Azure portal and by editing the code.
You can clone this repository from Visual Studio. Alternatively, from your shell or command line, use:
git clone https://github.com/Azure-Samples/active-directory-dotnet-daemon-certificate-credential.git
Step 2: Register the sample with your Azure Active Directory tenant and configure the code accordingly
There are two options:
- Option 1: you run the
Configure.ps1
PowerShell script which creates two applications in the Azure Active Directory, (one for the client and one for the service), and then updates the configuration files in the Visual Studio projects to point to those two newly created apps - Option 2: you do the same manually.
If you want to understand in more depth what needs to be done in the Azure portal, and how to change the code (Option 2), please have a look at Manual-Configuration-Steps.md. Otherwise (Option 1), the steps to use the PowerShell are the following:
If you have access to multiple Azure Active Directory tenants, you must specify the ID of the tenant in which you wish to create the applications. Here's how to find you tenant ID:
- Sign in to the Azure portal.
- On the top bar, click on your account and under the Directory list, choose the Active Directory tenant where you wish to register your application.
- Click on More Services in the left hand nav, and choose Azure Active Directory.
- Click on Properties and copy the value of the Directory ID property to the clipboard. This is your tenant ID. We'll need it in the next step.
- Open the PowerShell command window and navigate to the root directory of the project.
- The default Execution Policy for scripts is usually Restricted. In order to run the PowerShell script you need to set the Execution Policy to Unrestricted. You can set this just for the current PowerShell process by running the command
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted
- Now run the script.
.\Configure.ps1 <tenant ID>
Replace <tenantID>
with the tenant ID that you previously copied from the Azure portal.
- When requested, sign-in with the username and password of a user who has permissions to create applications in the AAD tenant.
The script executes and provisions the AAD applications (If you look at the AAD applications in the portal after that the script has run, you'll have two additional applications). The script also updates two configuration files in the Visual Studio solution (
TodoListDaemonWithCert\App.Config
andTodoListService\Web.Config
)
- If you intend to clean up the azure AD applications from the Azure AD tenant after running the sample see Step 5 below.
Since the web API is SSL protected, the client of the API (the web app) will refuse the SSL connection to the web API unless it trusts the API's SSL certificate. Use the following steps in Windows PowerShell to trust the IIS Express SSL certificate. You only need to do this once. If you fail to do this step, calls to the TodoListService will always throw an unhandled exception where the inner exception message is:
"The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."
Recent versions of Visual Studio will propose themselves to trust the IIS Express SSL certificate. If this is not the case for your installation please know that you will need to do this step only once.
To configure your computer to trust the IIS Express SSL certificate, begin by opening a Windows PowerShell command window as Administrator.
Query your personal certificate store to find the thumbprint of the certificate for CN=localhost
:
PS C:\windows\system32> dir Cert:\LocalMachine\My
Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\My
Thumbprint Subject
---------- -------
C24798908DA71693C1053F42A462327543B38042 CN=localhost
Next, add the certificate to the Trusted Root store:
PS C:\windows\system32> $cert = (get-item cert:\LocalMachine\My\C24798908DA71693C1053F42A462327543B38042)
PS C:\windows\system32> $store = (get-item cert:\Localmachine\Root)
PS C:\windows\system32> $store.Open("ReadWrite")
PS C:\windows\system32> $store.Add($cert)
PS C:\windows\system32> $store.Close()
You can verify the certificate is in the Trusted Root store by running this command:
PS C:\windows\system32> dir Cert:\LocalMachine\Root
Clean the solution, rebuild the solution, and run it. You might want to go into the solution properties and set both projects as startup projects, with the service project starting first. To do this you can for instance:
- Right click on the solution in the solution explorer and choose Set Startup projects from the context menu.
- choose Multiple startup projects
- TodoListDaemonWithCert: Start
- TodoListService: Start Start without debugging
- In the Visual Studio tool bar, press the start button: a web window appears running the service and a console application runs the dameon application under debugger. you can set breakpoints to understand the call to ADAL.NET.
The daemon will add items to its To Do list and then read them back.
When you are done with running and understanding the sample, if you want to remove your Applications from AD just run:
.\Cleanup.ps1 <tenant ID>
Replace with the tenant ID that you previously copied from the Azure portal.
If you do that you also probably want to undo the changes in the App.config
and Web.Config
TBD.
If you've looked at the code in this sample and are wondering how authorization works, you're not alone. See this Stack Overflow question. The TodoList Service in this solution simply validates that the client was able to authenticate against the tenant that the service is configured to work with. Effectively, any application in that tenant will be able to use the service.
First, in Visual Studio 2013 (or above) create an empty solution to host the projects. Then, follow these steps to create each project.
- In the solution, create a new ASP.Net MVC web API project called TodoListService and while creating the project, click the Change Authentication button, select Organizational Accounts, Cloud - Single Organization, enter the name of your Azure AD tenant, and set the Access Level to Single Sign On. You will be prompted to sign-in to your Azure AD tenant. NOTE: You must sign-in with a user that is in the tenant; you cannot, during this step, sign-in with a Microsoft account.
- In the
Models
folder add a new class calledTodoItem.cs
. Copy the implementation of TodoItem from this sample into the class. - Add a new, empty, Web API 2 controller called
TodoListController
. - Copy the implementation of the TodoListController from this sample into the controller. Don't forget to add the
[Authorize]
attribute to the class. - In
TodoListController
resolving missing references by addingusing
statements forSystem.Collections.Concurrent
,TodoListService.Models
,System.Security.Claims
.
- In the solution, create a new Windows --> Console Application called TodoListDaemon.
- Add the (stable) Active Directory Authentication Library (ADAL) NuGet, Microsoft.IdentityModel.Clients.ActiveDirectory, version 1.0.3 (or higher) to the project.
- Add assembly references to
System.Net.Http
,System.Web.Extensions
, andSystem.Configuration
. - Add a new class to the project called
TodoItem.cs
. Copy the code from the sample project file of same name into this class, completely replacing the code in the file in the new project. - Copy the code from
Program.cs
in the sample project into the file of same name in the new project, completely replacing the code in the file in the new project. - In
app.config
create keys forida:AADInstance
,ida:Tenant
,ida:ClientId
,ida:CertName
,todo:TodoListResourceId
, andtodo:TodoListBaseAddress
and set them accordingly. For the public Azure cloud, the value ofida:AADInstance
ishttps://login.microsoftonline.com/{0}
.
Finally, in the properties of the solution itself, set both projects as startup projects.
- How to use a pre-existing certificate instead of generating a self signed certificate.