Gianlucb

Azure AD, Scope-based authorization

GianlucaBertelli — Tue, 05 Dec 2017 10:37:41 GMT

"Hello World!" Continuing the customization of the basic two tiers scenario introduced in my previous posts, I would like to talk about scopes. OAuth2 defines the concept of scope as a "list of space-delimited, case-sensitive strings" that specifies the scope of the access request. These scopes can be used by a target application to allow or deny the access to its resources. Hence, with the scopes we can fine-tune the API access based on the caller access token. To make it simple:

The target application (Api) defines which scopes supports (i.e.: "scopeA", "scopeB” ...)
The client application (FrontEnd) specifies which scopes wants during the access token request **
The authentication server (Azure AD) replies with an access token that contains a field (scp) with all the valid scopes
The target application (Api) inspects the access token and takes the proper actions (allow, deny, redirect... etc)

Let's us start from the last step, the target application configuration. From the point of view of the target application scopes are just strings (or better claims) part of the JWT token:

"appid": "6fa546d0-c2b8-4902-8415-a2b5bdc07472",
"appidacr": "0",
"e_exp": 262800,
"family_name": "Standard",
"given_name": "User",
"ipaddr": "167.220.197.30",
"name": "user",
"oid": "703edbe8-0fcd-4d2e-8a99-c1ee78df2231",
"scp": "aad.scopeA aad.scopeB user_impersonation",
"sub": "4LSAbYQx-PYbh5LI98jS22dBq4AcFhy47CRmIXIbsAY",
"tid": "f7ad0521-ba5a-4622-bab1-8eae3e485430",
"unique_name": "user@bizspark7demooutlook.onmicrosoft.com",
"upn": "user@bizspark7demooutlook.onmicrosoft.com",
"uti": "VnxNhOlxE06flrDmAp4fAA",
"ver": "1.0"

In Asp.Net Core 2.0 we can easily integrate the scopes control defining authorization policies in the Startup class:

services.AddAuthorization(options => {
   //custom scopes
   options.AddPolicy("A", policyBuilder => policyBuilder.Requirements.Add(new HasScopeRequirement("aad.scopeA")));
   options.AddPolicy("B", policyBuilder => policyBuilder.Requirements.Add(new HasScopeRequirement("aad.scopeB")));
});
//HasScopeRequirement is a custom class

and then use such policies to control the API access:

[Authorize(Policy = "A")]
public string GetWithScopeA()
{
   return "Hello from API (Scope A)";
}
 
[Authorize(Policy = "B")]
public string GetWithScopeB()
{
   return "Hello from API (Scope B)";
}

In this manner we are allowing to access to our API only the users that have the right scopes in the access token, otherwise a 403 forbidden message is returned. So far so good. The next step is to tell Azure AD which are the supported scopes. Technically speaking the scopes are just a JSON configuration in the application manifest (they are also called OAuth2Permissions):

{
    "adminConsentDescription": "Allow the application access to scope B APIs",
    "adminConsentDisplayName": "Scope B access",
    "id": "b69ee3c9-c40d-4f2a-ac80-961cd1534e49",
    "isEnabled": true,
    "type": "User",
    "userConsentDescription": "Allow the application access to scope B APIs",
    "userConsentDisplayName": "Scope B access",
    "value": "aad.scopeB"
},
{
    "adminConsentDescription": "Allow the application access to scope A APIs",
    "adminConsentDisplayName": "Scope A access",
    "id": "b69ee3c9-c40d-4f2a-ac80-961cd1534e48",
    "isEnabled": true,
    "type": "User",
    "userConsentDescription": "Allow the application access to scope A APIs",
    "userConsentDisplayName": "Scope A access",
    "value": "aad.scopeA"
}

This is sufficient to create the scopes and exposes them to other applications in the same tenant. The scopes become visible in the "Required Permissions" settings of the other applications. We need to know that the scopes we select here are set as "default", that means every user will get such scopes in the access token, regardless of the client request. A working example can be found here ** The V1.0 endpoint does not honor the scopes requested by the client; It always fills the "scp" field with the scopes defined in the portal. So, it is a static configuration: the scopes/permissions not selected in this tab cannot be requested by the caller. *** The V2.0 endpoint honors the scopes in the client request as support dynamic and incremental consent pages

Azure AD and Group-based authorization

GianlucaBertelli — Fri, 27 Oct 2017 12:14:12 GMT

"Hello World!" In my previous post I talked about how to use Azure AD to secure an Asp.Net Core web API project. If we want to go further than just protect our web API, we can use groups to further customize the access. A typical example is to restrict the access only for users belonging to a specific group. Each directory user can be part of one or more groups, so we can leverage this membership to allow or deny the access to our API based on the calling user attributes. This is quite easy to implement, as Asp.Net Core uses the same authorization attribute we are used to:

[Authorize(Policy = "Admins")]
public IActionResult Get(int id)
{
   return Json(id);
}

As you can see we need to use the Policy property to specify the rules that apply to the decorated member. This obviously requires defining our access policies (the rules) during the startup phase:

services.AddAuthorization(options => {
   options.AddPolicy("Admins",
           policyBuilder => policyBuilder.RequireClaim("groups",
           "f761047b-2f49-4d8e-903c-1234567890cc"));
});

We simply check the presence of a specific group in the claims set of the calling user. In other words, means the user must belong to this particular group in order to access. Note that we need to use the GUID of the group and not the group name as the access_token we receive from Azure Ad uses a list of GUIDs to describe the user membership. Because by default the list of groups the user belongs to is not sent by Azure AD, we need to manually edit the manifest:

"groupMembershipClaims":"SecurityGroup"

Access an Azure AD secured Api with Asp.Net Core 2.0

GianlucaBertelli — Wed, 04 Oct 2017 10:23:53 GMT

tl;dr

Register a new Web App in AAD for the Api
Register a new Web App in AAD for the FronEnd
1. Add the permissions to access the Api app
Configure the Web apps code with the authentication details as usual (ClientID, Client Secret, Audience Uri..etc..).
In Azure portal edit the FrontEnd manifest enabling the implicit flow: "oauth2AllowImplicitFlow": true
To obtain an access token, in the FrontEnd app code, configure the OpenIdConnection options:
1. set the response type to "token id_token"
2. specify the Api Application ID
3. enable the saving of the tokens in the HttpContext

"Hello World!" In my previous post I talked about a delegation scenario with AzureAD and a classic Asp.Net web project. In this post I would like to explain a simpler solution: an Asp.Net Core 2.0 FrontEnd that needs to access a backend Api, both secured with the same AzureAD directory. Even if the theory and the protocols behind are always the same (OAuth2/OpenIdConnect) in Asp.Net Core 2.0 the default behavior is different, so we need to take and code different steps. These are the major differences:

On client side we need to use MSAL and not ADAL to obtain a token
On server side we need to configure the middleware to support AzureAd
The implicit flow is used (opposed to the "authorization code flow")

In order to protect with AAD an Asp.Net Core 2.0 project we need to add the OpenIdConnect support and configure it properly. This is not a trivial task, but fortunately, we can grab the needed code from the standard Asp.Net Core 2.0 template. If we create a new web project and select the "work or school account" authentication option we will have all the needed classes in the files AzureAdAuthenticationBuilderExtensions and AzureAdOptions. With these files enabling the authentication is straight forward, as we just need to configure the AzureAd parameters in the appsettings.json and the client secret using the "manage user secrets" option. By default the authentication library uses the "implicit flow", that means the client (browser) will get the required tokens directly from the authentication server. So differently from the "authorization code flow" (used with ADAL in Asp.Net) the server side receives the tokens from the caller and there is no "authorization code" that need to be redeemed. In other words this means the server side has no way to exchange the user credentials for an access token for the Api layer. Again by default the authentication library tells the client to ask only for the identity token (id_token) and not for any access token, so to obtain an access token for the Api layer we need to explicitly enable it:

//enable the access token request
options.ResponseType = "token id_token";
	     
//the target resource ID (access token for?)
options.Resource = "XXXXXX-YYYYYY-ZZZZZ-WWWWW";

//save tokens in the request context
options.SaveTokens = true;
	    
//these lines must be added in the Configure method of the ConfigureAzureOptions class.

It is important to note that kind of response type for the implicit flow is not enabled by default for AzureAd, so we need to edit the manifest via the Azure portal and enable it (for the FrontEnd application):

"oauth2AllowImplicitFlow": true

The library saves the tokens sent by the client in the HttpContext, so it is really easy retrieve them:

string accessToken = await HttpContext.GetTokenAsync("access_token");
string idToken = await HttpContext.GetTokenAsync("id_token");

Remember that the id_token represents the user for the current resource and cannot be used to access other resources. Vice versa the access_token is meant only for the target resource specified in request the options, so we need to use the latter to call the Api layer:

//example of Autorest client, created with --add-credentials 
string accessToken = await HttpContext.GetTokenAsync("access_token");
var credentials = new TokenCredentials(accessToken);
IMyApiLayer apiClient = new MyApiLayer(credentials);
apiClient.BaseUri = new Uri("https://localhost:57736");
var obj = apiClient.MyMethod();

You can find a sample demo code here

Create a Service Fabric Application on demand

GianlucaBertelli — Tue, 26 Sep 2017 11:20:47 GMT

"Hello World"! You probably already know that the Service Fabric SDK allows a developer to fully manage the cluster, the nodes, and the deployed applications by code. One of the features I like most of the Service Fabric programming is the ability to dynamically create and deploy new services. Or more in general the ability to manage the lifecycle of the running services. For example, If we want to deploy a new instance of an Application we just need few lines of code:

FabricClient fabricClient = new FabricClient();
Uri eventDeploymentUri = new Uri("fabric:/NewApp/");           
          
//check for existence
await fabricClient.QueryManager.GetApplicationListAsync(eventDeploymentUri);
if (applicationList.Count > 0) return; //already exists

//passing manifest parameters to the new application
NameValueCollection appParameters = new NameValueCollection();
appParameters.Add("Param1","1" );

ApplicationDescription applicationDesc = 
	new ApplicationDescription(eventDeploymentUri, "APP_TYPE", "APP_VERSION", appParameters);
await fabricClient.ApplicationManager.CreateApplicationAsync(applicationDesc);

This is super easy, we just ask the creation of a specific version of a registered application type (the type must be already registered). The cluster will take care of this operation in an async way and will manage all the tasks related to this new deployment (like moving other services, leveling the volume load, register the name in reverse proxy ..etc..). This dynamic operation is really useful if we want to build a multi-tenant or self-service solution that can instantiate multiple applications on-demand. To demonstrate this, I created a sample demo project that builds websites on demand with just a simple REST api call. In such demo the dynamically built application hosts an asp.net core website with a single page. The website is externally reachable as it is registered with the reverse proxy (read this post for more info about this point). Hope you will find this demo solution helpful to start with service fabric SDK programming.

Service Fabric Reverse Proxy Port discovery

GianlucaBertelli — Mon, 11 Sep 2017 17:50:12 GMT

Hello World! The reverse proxy is a feature of Service Fabric that allows to expose internal endpoints, taking care of naming resolution, discovery and maintenance. Basically each service can be reached using an URI like:

https://cluster-fqdn:PORT/[ApplicationName]/[ServiceName]

In this Uri PORT is the Reverse Proxy port, ApplicationName is the name of the deployed application (root of many services) and ServiceName is the name of the single service inside the application package. Unfortunately the reverse proxy port is not fixed! It depends from the node where the application is running, so it can even change during the application lifetime. This because the port is defined by the node type, so if the application change node type it changes the port. To avoid this you can force an application to be deployment only on a specific node type:


 NodeType == NodeType2

By the way even with a fixed node type, the port is not "well-known" and can change from cluster to cluster (as it is defined in the cluster config). If you need to get the port by code at runtime unfortunately there isn't an easy way yet. Basically you need to manually parse the xml cluster manifest, get the list of the node types, find the type where your application is deployed and then read the properties of the HttpApplicationGatewayEndpoint element. You can check the code needed for this looking at this simple project: SFHelper Also published as nuget package : https://www.nuget.org/packages/SFHelper/

Experimenting with Azure Managed Applications

GianlucaBertelli — Fri, 25 Aug 2017 15:56:11 GMT

"Hello World"! Today I'm playing with the new service "Azure Managed Applications" (Service Catalog) and would like to write down some key points I learned, and can be hopefully useful for new comers:

when you create a managed application this is nothing else than a standard ARM template, you need to create also other two JSON files but these are just for UI and some related stuff.
The ARM template will be deployed in the end-user subscription, but we get the access to the resources!
The end-user will not get access to the resources created, so we can "safely" deploy our intellectual properties
Being just an ARM template this defines a set of resources and their interconnections, by default so does not deploy any Bits or piece of code.
Once the end-user has created the managed application we can deploy our solution, having access to the created group

But If we want to have a "ready-to-use"/"self-installing", application we need to use an ARM template that deploys the solution code after the resources creation, otherwise the experience for the end-user will be an "empty" set of resources, and he needs to wait for us to deploy the solution in its group. Some template resources can execute extra steps after the resource creation, for example:

You can execute custom scripts on VM
A Web app can use WebDeploy to automatically deploy the code:

{
    "name": "MSDeploy",
    "type": "extensions",
    "location": "[resourceGroup().location]",
    "apiVersion": "2015-08-01",
    "dependsOn": [
        "[resourceId('Microsoft.Web/sites', parameters('webAppName'))]"
    ],
    "tags": {
        "displayName": "WebDeployMyProfile"
    },
    "properties": {
        "packageUri": "https://dx.blob.core.windows.net/dx-stageartifacts/content/MyDeploy.zip?st=2....-08-21T08%3A13%3A00Z&sp=rl&sv=2016-05-22&sr=b&sig=DfI556J0yG09pvw2Pkuliuhj7gxODmJb0p04Rq60oqc8%3D",
        "dbType": "None",
        "connectionString": "",
        "setParameters": {
	    "IIS Web Application Name": "[parameters('webAppName')]"
	    }
	}
}

Note: This is still in preview, so things may change very quickly :-)

Azure AD Delegation scenario

GianlucaBertelli — Thu, 24 Aug 2017 10:03:54 GMT

tl;dr

Register a new Web App in AAD for the Api
1. Add the required "delegated" permissions to the external resource (i.e: Microsoft Graph)
Register a new Web App in AAD for the FrontEnd
1. Add the permissions to access the Api app
Configure the Web apps code with the authentication details as usual (ClientID, Client Secret, Audience Uri..etc..). ADAL is the right choice for .NET code
In Azure portal edit the Api registration manifest adding the GUID of the FronEnd app: "knownClientApplications": ["XXXXXX-YYYY-ZZZZZZ-WWWWW-XXXXXXX"]
In the Api app code, save the bootstrap token during logon and use it to ask a new "On-Behalf-Of" token for the external resource with the user assertion "urn:ietf:params:oauth:grant-type:jwt-bearer"

"Hello World"! Protect a web resource with Azure AD is really easy and well documented, but in a delegation scenario where we need to access to an external resource impersonating the signed-in user the things can get little more complicated. Is not difficult, we just need few extra steps and configuration from the base case. If I would like to implement an architecture as the following: The very first steps are:

Register a new Web App in AAD for the Api
1. Add a redirect URL with "https://localhost"
2. Add the required "delegated" permissions to the external resource (i.e: Microsoft Graph)
Register a new Web App in AAD for the Frontend
1. Add redirect URLs to point to the main page
2. Add the permissions to access the Api app
Configure the apps code with the authentication details as usual (ClientID, Client Secret, Audience Uri..etc..)

As you know the first time we access a resource protected by an Oauth based protocol (like OpenIDConnect in AAD) we need to "visually" grant the access to that resource. The classic HTML page that requires the user input to continue. Because at step 2/b we specified the FrontEnd app needs to access the Api app the user will be prompted to confirm the access to both applications (FrontEnd + Api) in a single page. By default the ADAL library uses the OpenIDConnect "authorization code flow". This means that the FrontEnd app receives an authorization code as part of the login process. This authorization code can be reedemed and exchanged for an access token for the Api app. With ADAL this task can be done in the AuthorizationCodeReceived notification event (in Startup.Auth.cs). So far so good. We have authenticated the user, received an id_token that identifies the caller, reedemed the authorization code and obtained the access_token for the Api layer. Thus we can access the Api app as the calling user. Unfortunately this is not sufficent if the Api app needs to access an external resource acting as the signed in user (third hop). This because the token received from this layer is meant only to the Api app and cannot be used to access the external resource (i.e: Microsoft Graph). We need a specific token for this latter resource but there are two major issues at this point:

The user didn't be prompted for that, so he never granted the access to the external resource
The Api app is called via code (REST API) and therefore cannot display any HTML page to ask for such grant

In any case we also would like to silently access this resource in a SSO manner without asking again for credentials. Basically we need a way to grant the access to the external resource via the Api layer upfront. Fortunately this is possible manually editing the registration manifest for the Api app in the Azure portal:

"knownClientApplications": ["XXXXXX-YYYY-ZZZZZZ-WWWWW-XXXXXXX"]

Adding the GUID of the FrontEnd app to the "knownClientApplications" property we link the two registrations. This means the first time the user access the FrontEnd app, he will be prompted to grant the access for all the permissions specified by both apps and not only by the FrontEnd one. In other words, we obtain a consensus page that lists all the permissions and all the external resources accessed by the current application and all the linked ones. Now, as the user grants the access to all the resources upfront, the Api app can request a token for the external resource in a SSO manner. In this case we need to use the "On-Behalf-Of flow" that allows to get an access token that delegates the user credentials. To successfully request this kind token we need to:

provide the Bootstrap Token (this is just terminology, is the access_token sent by the FrontEnd to the Api app)
Specify the assertion "urn:ietf:params:oauth:grant-type:jwt-bearer"

if you are using ADAL this translates in two simple steps:

SaveSigninToken = true in TokenValidationParameters (as by default for performance is discarded after the access)
Request the token with:

UserAssertion userAssertion = new UserAssertion(bootstrapContext, "urn:ietf:params:oauth:grant-type:jwt-bearer", userName);
var result = await authContext.AcquireTokenAsync(resourceUri, clientCred, userAssertion);

WCF ETW Tracing

GianlucaBertelli — Fri, 28 Oct 2016 16:10:11 GMT

"Hello World"! Today I would like to share a quick way to enable and collect WCF tracing, machine wide, without any configuration change! We are all used to enable WCF diagnostic tracing using the application/web configuration file (leveraging our friend System.Diagnostics.XmlWriterTraceListener). But WCF uses also ETW for tracing, so we have a second option! The ETW provider used is called "Microsoft-Windows-Application Server-Applications". You can easily enable the tracing and convert the result to an human-readable text file with:

logman start WCFETWTracing -p "Microsoft-Windows-Application Server-Applications" -nb 256 1024 -bs 512 -ets -ct perf -f bincirc -max 500 -o mywcftrace.etl
…execute the program…
logman.exe stop WCFETWTracing –ets
netsh trace convert input=mywcftrace.etl wcf_repro.txt TXT

If you prefer to use powershell check the following script Please note that this ETW tracing is machine wide! If you want to collect the data only for one process you may use other methods/tools like Perfview. Last but not least, this tracing can also be enabled through the event viewer: Application Server-Applications / Debug and Analytic logs

WIF 4.5 Active/Passive/Delegation examples

GianlucaBertelli — Wed, 05 Oct 2016 12:55:09 GMT

"Hello World"! Lately more and more customers are asking me help and examples on how to use WIF 4.5+WCF in their projects, just a quick jump-start or how to "migrate" from the previous version (WIF on .NET 3.5). As you may know WIF is now part of the framework so the first thing to note is the change of namespace: from Microsoft.IdentityModel to System.IdentityModel. Second some classes are gone and some has been renamed. I created two working examples on how to use WIF 4.5 to secure a WCF web service. I tried to mock up the two most common scenarios:

#1 standard active scenario (1 hop / Client -> WCF) https://github.com/gianlucb/WIF-ActiveScenarioWCF
#2 delegation scenario (2 hops / Browser -> WEB -> WCF ) https://github.com/gianlucb/WIF-DelegationScenarioWCF

Basically WIF is used to secure a target WCF resource (Relying party) and also to retrieve the access token from the STS. I used an ADFS server but you can use any custom STS implementation. I put many comments in the source code and tried to be verbose as much as possible in order to help you to understand how WIF works and how must be configured. In these examples you can find also how to configure WIF programmatically, without using any configuration file! The example #1 is really simple, just a WCF service that must be consumed using a SAML Token as authentication method. Active scenario simply means the caller must go to STS to retrieve the token before to call the service, is not redirected automatically as happens with a browser for example. The example #2 is the implementation of this "old" guide: Identity Delegation with AD FS 2.0 Step-by-Step Guide. The guide was about .NET 3.5, the old VS version and ADFS 2.0, so it not updated anymore. Nowadays to setup a working delegation scenario there are some additional steps and some that are not necessary anymore, see the readme document for a detailed list of required steps for a delegation. Note that for a delegation scenario the service's caller must get a second token of type OnBehalfOf or ActAs, it cannot use the user's original token. In this example you can find two methods for this task:

Automatic: using CreateChannelWithOnBehalfOfToken (WCF get the token for us transparently)
Manual: call STS with WSTrustChannelFactory and forward the token with CreateChannelWithIssuedToken

Windows 10 App insights with Cortana

GianlucaBertelli — Wed, 11 May 2016 16:11:35 GMT

"Hello World"! My need was to quickly visualize a report of one of my published apps in the Windows Store. I just wanted a quick way to see the rating, the number of reviews and the active users. These information were all already available but scattered over many websites: mobile engagement, hockey app and windows store analytics to name a few. So I decided to bring all the data together and summarize them in a single view. What better of Cortana to visualize the report? In order to achieve this I created a really simple solution composed by:

Asp.Net REST web service (hosted on Azure as API app)
PowerBi dashboard

The web service has the responsibility to extract the data from all the sources and to expose the data as lists of items (JSON). In my case for sake of simplicity I choose to track active users with a custom monitoring implementation (an alternative is to export the data from Mobile Engagement API). This service is also able to pull all the app reviews from the windows store as detailed in my previous blog post . PowerBi is obviously the main part in this solution, it allowed me to quickly import the data from my web service and quickly transform the lists in fancy charts. The Cortana integration is provided by PowerBi and is really simple to setup:

Import all your sources (i.e: the web service URL)
Create a new report and configure it to work with Cortana:
- set the page size to "Cortana"
- set the keywords to use

Create the visualizations (charts)
If working with PowerBi Desktop client then publish the report to PowerBi online

Last point is to enable the Cortana integration and the scheduled refresh for each dataset:

Go to powerbi.com
Go to settings page, Datasets -> Your Dataset
- Enable the Scheduled Refresh
- Q&A and Cortana -> Allow Cortana to access this dataset

After the publish it took a while before to be ready for Cortana but once done was really straightforward to use. To get the report I just need to write one of the specified keywords in Cortana and wait until a match is found (actually when the PowerBi icon is shown): This report is available only on the devices where I synchronized the PowerBi account. Of course this is a really simple solution, just a proof of concept (PoC) of what a real solution can be. In case of an huge set of data I would also introduce some additional caching layers to store and organize the data in a more consistent way. Note that I created a middle tier web service that aggregates the data from multiple sources only because some of them were not "PowerBi ready" ! In a more simple way you can achieve a very similar solution without the need of a intermediate web service but just importing the Windows Dev Center content pack in PowerBi.