You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+30-15Lines changed: 30 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,19 +2,21 @@
2
2
services: active-directory
3
3
platforms: dotnet
4
4
author: jmprieur
5
-
level: 300
5
+
level: 200
6
6
client: Windows Desktop WPF
7
7
service: ASP.NET Web API
8
8
endpoint: AAD V2
9
9
---
10
10
11
-
# Calling an ASP.NET Web API protected by the Azure AD V2 endpoint from an Windows Desktop WPF application
11
+
# Calling an ASP.NET Web API protected by the Azure AD V2 endpoint from an Windows Desktop (WPF) application
12
12
13
13
## About this sample
14
14
15
15
### Scenario
16
16
17
-
You expose a Web API and you want to protect it so that only authenticated user can access it. This sample shows how to expose a ASP.NET Web API so it can accept tokens issued by personal accounts (including outlook.com, live.com, and others) as well as work and school accounts from any company or organization that has integrated with Azure Active Directory and show how a Windows Desktop application can request an access token to access that Web APIs.
17
+
You expose a Web API and you want to protect it so that only authenticated user can access it. This sample shows how to expose a ASP.NET Web API so it can accept tokens issued by personal accounts (including outlook.com, live.com, and others) as well as work and school accounts from any company or organization that has integrated with Azure Active Directory.
18
+
19
+
The sample also include a Windows Desktop application (WPF) that demonstrate how you can request an access token to access a Web APIs.
18
20
19
21
## How to run this sample
20
22
@@ -31,8 +33,9 @@ You can clone this sample from your shell or command line:
31
33
### Step 2: Register your Web API - *TodoListService* in the *Application registration portal*
32
34
33
35
1. Sign in to the [Application registration portal](https://apps.dev.microsoft.com/portal/register-app) either using a personal Microsoft account (live.com or hotmail.com) or work or school account.
34
-
1. Give a name to your Application, such as `AppModelv2-NativeClient-DotNet-TodoListService`. Make sure that the *Guided Setup* option is **Unchecked**. Then press **Create**. The portal will assign your app a globally unique *Application ID* that you'll use later in your code.
36
+
1. Give a name to your Application, such as `AppModelv2-NativeClient-DotNet-TodoListService`. Make sure that the *Guided Setup* option is **Unchecked** then press **Create**. The portal will assign your app a globally unique *Application ID* that you'll use later in your code.
35
37
1. Click **Add Platform**, and select **Web API**
38
+
1. Click **Save**
36
39
37
40
> Note: When you add a *Web API* the Application registration portal, it adds a pre-defined App Id URI and Scope, using the format *api://{Application Id}/{Scope Name}* named **access_as_user** (you can review it by clicking 'Edit' button). This sample code uses this default scope.
38
41
@@ -44,14 +47,15 @@ You can clone this sample from your shell or command line:
44
47
#### Step 3.1: Add the new scope to the *TodoListClient*`s app.config
45
48
46
49
1. Open the **app.config** file located in **TodoListClient** project's root folder and then paste **Application Id** from the application you just registered for your *TodoListService* under `TodoListServiceScope` parameter, replacing the string `{Enter the Application Id of your TodoListService from the app registration portal}`.
50
+
47
51
> Note: Make sure it uses has the format `api://{TodoListService-Application-Id}/access_as_user` (where {TodoListService-Application-Id} is the Guid representing the Application Id for your TodoListService).
48
52
49
53
### Step 4: Register the *TodoListClient* application in the *Application registration portal*
50
54
51
55
In this step, you configure your *TodoListClient* project by registering a new application in the Application registration portal. In the cases where the client and server are considered *the same application* you may also just reuse the same application registered in the 'Step 2.'.
52
56
53
57
1. Go back to [Application registration portal](https://apps.dev.microsoft.com/portal/register-app) to register a new application
54
-
1. Give a name to your Application, such as `NativeClient-DotNet-TodoListClient`, make sure that the *Guided Setup* option is **Unchecked**. Then press **Create**.
58
+
1. Give a name to your Application, such as `NativeClient-DotNet-TodoListClient`, make sure that the *Guided Setup* option is **Unchecked** then press **Create**.
55
59
1. Click **Add Platform**, and select **Native**.
56
60
1. Click **Save**
57
61
@@ -69,12 +73,12 @@ In this step, you configure your *TodoListClient* project by registering a new a
69
73
70
74
### Step 7: Pre-authorize your client application
71
75
72
-
One of the ways to allow users from other directories to acces your Web API is by adding the client client application in the list of *pre-authorized* applications for your Web API. In order to do this:
76
+
One of the ways to allow users from other directories to acces your Web API is by *pre-authorizing* the client applications to access your Web API by adding the Application Ids from client applications in the list of *pre-authorized* applications for your Web API. In order to do this:
73
77
74
78
1. Go back to the *Application registration portal* and open the properties of your **TodoListService**.
75
-
1. In the **Web API platform**, click on **Add application** under the *Pre-authorized applications* section
76
-
1. In the *Application ID* field, paste the application ID of the `TodoListClient` application
77
-
1. In the *Scope* field, click on the **Select** combo box and select the scope for this Web API `api://<Application ID>/access_as_user`
79
+
1. In the **Web API platform**, click on **Add application** under the *Pre-authorized applications* section.
80
+
1. In the *Application ID* field, paste the application ID of the `TodoListClient` application.
81
+
1. In the *Scope* field, click on the **Select** combo box and select the scope for this Web API `api://<Application ID>/access_as_user`.
78
82
1. Press the **Save** button at the bottom of the page.
79
83
80
84
### Step 8: Run your project
@@ -88,23 +92,34 @@ By default, when download this code sample and configure the application to use
88
92
89
93
To restrict who can sign in to your application, use one of the options:
90
94
91
-
### Restrict access to a single organization (single-tenant)
95
+
### Option 1: Restrict access to a single organization (single-tenant)
92
96
93
97
You can restrict sign-in access for your application to only user accounts that are in a single Azure AD tenant - including *guest accounts* of that tenant. This scenario is a common for *line-of-business applications*:
94
98
95
99
1. In the **web.config** file of your **TodoListService**, change the value for the `Tenant` parameter from `Common` to the tenant name of the organization, such as `contoso.onmicrosoft.com`.
96
100
2. In your [OWIN Startup class](#configure-the-authentication-pipeline), set the `ValidateIssuer` argument to `true`.
97
101
98
-
### Restrict access to a list of organizations
99
-
100
-
You can restrict sign-in access to only user accounts that are in a specific list of Azure AD organizations:
102
+
### Option 2: Restrict access to a list of known organizations
101
103
102
104
You can restrict sign-in access to only user accounts that are in an Azure AD organization that is in the list of allowed organizations:
103
105
104
106
1. In your [OWIN Startup class](#configure-the-authentication-pipeline), set the `ValidateIssuer` argument to `true`.
105
107
2. Set the value of the `ValidIssuers` parameter to the list of allowed organizations.
106
108
107
-
#### Use a custom method to validate issuers
109
+
###Option 3: Restrict the categories of users that can sign-in to your application
108
110
109
-
You can implement a custom method to validate issuers by using the **IssuerValidator** parameter. For more information about how to use this parameter, read about the [TokenValidationParameters class](https://msdn.microsoft.com/library/system.identitymodel.tokens.tokenvalidationparameters.aspx) on MSDN.
111
+
This scenario is a common for *SaaS* applications that are focused only on either consumers or organizations, therefore want to block accepting either personal accounts or work or school accounts.
110
112
113
+
1. In the **web.config** file of your **TodoListService**, use on of the values below for `Tenant` parameter:
114
+
115
+
Value | Description
116
+
----- | --------
117
+
`common` | users can sign in with any Work and School account, or Microsoft Personal account
118
+
`organizations` | users can sign in with any Work and School account
119
+
`consumers` | users can sign in with a Microsoft Personal account
120
+
121
+
> Note: the values above are not considered a *tenant*, but a *convention* to restrict certain categories of users
122
+
123
+
#### Option 4: Use a custom method to validate issuers
124
+
125
+
You can implement a custom method to validate issuers by using the **IssuerValidator** parameter. For more information about how to use this parameter, read about the [TokenValidationParameters class](https://msdn.microsoft.com/library/system.identitymodel.tokens.tokenvalidationparameters.aspx) on MSDN.
0 commit comments