Monat: September 2017

Windows Authentication in Service Fabric and ASP.NET Core 2.0

Recently, I worked on a Service Fabric solution for a customer, where my team had to configure secure communication capabilities to existing reliable (stateless) services, built on top of the ASP.NET Core 2.0 framework. More specifically, we had to configure the Windows Authentication feature on them and choose WebListener as the web server, to process HTTP requests from remote Windows clients. We’ll see that there are slight differences in the names of some ASP.NET packages and libraries, and in the way we configure a weblistener on a stateless service, with the latest version of ASP.NET, with respect to the previous versions (1.x). This article will highlight these aspects and describe a way to properly configure a Service Fabric (SF) Reliable Service Stateless Service, given these requisites. We will leverage on the features, improvements and support made available by the latest release of Service Fabric SDK for Windows (v5.7.198). Among the others, I’d like to focus on the following feature: ASP.NET Core 2.0 Support: the Microsoft.ServiceFabric.AspNetCore.* NuGet packages now support ASP.NET Core 2.0, the latest major version of the open-source and cross-platform framework for building modern cloud-ready web applications. For a fully-documented release notes page, please visit the Azure Service Fabric Team Blog. In the following section, we’ll be building a simple ASP.NET Core 2.0 application, packaged as Stateless Service, using the Stateless ASP.NET Core project template provided by Visual Studio. We’ll then configure security on the application to perform Windows-authenticated calls. Some assumptions: Since the sample is built and deployed on a local SF cluster, make sure that the latest of both SF SDK and Runtime are installed on your local machine through the Web Platform Installer, and the cluster is started with the 1-Node / 5-Node configuration The latest .NET Core SDK is installed (v2.0.0) Visual Studio 2017 with support to ASP.NET Core 2.0 is installed (v15.3) Service Fabric Application 1. Open Visual Studio as Administrator.2. Create a Service Fabric application, name it MyApplication. 3. Create a Stateless ASP.NET Core Service, name it MyAspNetService. 4. Make sure you select ASP.NET Core 2.0 in the following dialog. For this example, I used Empty project template and No Authentication as authentication method (we’ll set it programmatically). Wait until Visual Studio has set up either the application and the service projects, then navigate to MyAspNetService.cs file, which contains the class representing the SF Stateless Service used for our purposes. Here’s the signature and the body of the CreateServiceInstanceListeners(…) method, that developers can override to create diverse listeners for this service instance, even custom ones:protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
return new ServiceInstanceListener[]
{
new ServiceInstanceListener(serviceContext =>
new KestrelCommunicationListener(serviceContext, “ServiceEndpoint”, (url, listener) =>
{
ServiceEventSource.Current.ServiceMessage(serviceContext, $”Starting Kestrel on {url}”);

return new WebHostBuilder()
.UseKestrel()
.ConfigureServices(
services => services
.AddSingleton<StatelessServiceContext>(serviceContext))
.UseContentRoot(Directory.GetCurrentDirectory())
.UseStartup<Startup>()
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
.UseUrls(url)
.Build();
}
)
)
};
}

As you can see, a communication listener based on Kestrel has already been set up as default listener for the only service endpoint configured (ServiceEndpoint). ASP.NET Core comes with two server implementations, briefly explained below. We chose WebListener as web server, since it supports Windows Authentication.
Kestrel
Kestrel is a cross-platform HTTP server based on libuv library, for asynchronous I/O operations on cross-platform architectures. As previously shown, Kestrel is the web server that is included by default in ASP.NET Core new project templates.
It supports the following features:

HTTPS
Opaque upgrade used to enable WebSockets
Unix sockets for high performance behind Nginx
WebListener
WebListener is a Windows-only HTTP server, based on the Http.Sys kernel mode driver.
WebListener supports the following features:

Windows Authentication
Port sharing
HTTPS with SNI
HTTP/2 over TLS (Windows 10)
Direct file transmission
Response caching
WebSockets (Windows 8)
Supported Windows versions:

Windows 7 and Windows Server 2008 R2 and later
Learn more about WebListener web server implementation in ASP.NET Core.
Modify the method CreateServiceInstanceListeners(…) as below:protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
return new ServiceInstanceListener[]
{
new ServiceInstanceListener(serviceContext =>
new WebListenerCommunicationListener(serviceContext, “ServiceEndpoint”, (url, listener) =>
{
ServiceEventSource.Current.ServiceMessage(serviceContext, $”Starting WebListener on {url}”);
return new WebHostBuilder()
.UseHttpSys(
options =>
{
options.Authentication.Schemes = AuthenticationSchemes.Negotiate; // Microsoft.AspNetCore.Server.HttpSys
options.Authentication.AllowAnonymous = false;
/* Additional options */
//options.MaxConnections = 100;
//options.MaxRequestBodySize = 30000000;
//options.UrlPrefixes.Add(“http://localhost:5000″);
}
)
.ConfigureServices(
services => services
.AddSingleton<StatelessServiceContext>(serviceContext))
.UseContentRoot(Directory.GetCurrentDirectory())
.UseStartup<Startup>()
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
.UseUrls(url)
.Build();
}
)
)
};
}

The following NuGet packages are required to make a successful build:

Microsoft.ServiceFabric.AspNetCore.WebListener (v2.7.198)
Microsoft.AspNetCore.Server.HttpSys (v2.0.0)
Here’s the using region:using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Server.HttpSys;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.ServiceFabric.Services.Communication.AspNetCore;
using Microsoft.ServiceFabric.Services.Communication.Runtime;
using Microsoft.ServiceFabric.Services.Runtime;
using System.Collections.Generic;
using System.Fabric;
using System.IO;
Considerations

The packages Microsoft.AspNetCore.Server.WebListener and Microsoft.Net.Http.Server have been merged into the aforementioned new package Microsoft.AspNetCore.Server.HttpSys. The namespaces have been updated to match. This is reflected in calling UseHttpSys() extension method instead of UseWebListener().

Windows Authentication is performed by the HttpSys options , by setting:
options.Authentication.Schemes to the enum AuthenticationSchemes.Negotiate
options.Authentication.AllowAnonymous to none.
Learn more about HTTP.sys web server implementation in ASP.NET Core.

I provided additional options in the code (commented) regarding:

maximum client connections
maximum request body size
URLs and port configuration options
Publish and test
Once you publish the application, and the service instance(s) is up and running in your local cluster environment, you can simulate HTTP requests towards the endpoint configured in the ServiceManifest.xml of the service project (in my example, http://localhost:8234).
Cluster:
Snippet from ServiceManifest.xml:

<?xml version=”1.0″ encoding=”utf-8″?>
<ServiceManifest Name=”MyAspNetServicePkg”
Version=”1.0.0″
xmlns=”http://schemas.microsoft.com/2011/01/fabric”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<ServiceTypes>
<!– This is the name of your ServiceType.
This name must match the string used in RegisterServiceType call in Program.cs. –>
<StatelessServiceType ServiceTypeName=”MyAspNetServiceType” />
</ServiceTypes>

<!– Code package is your service executable. –>
<CodePackage Name=”Code” Version=”1.0.0″>
<EntryPoint>
<ExeHost>
<Program>MyAspNetService.exe</Program>
<WorkingFolder>CodePackage</WorkingFolder>
</ExeHost>
</EntryPoint>
</CodePackage>

<!– Config package is the contents of the Config directoy under PackageRoot that contains an
independently-updateable and versioned set of custom configuration settings for your service. –>
<ConfigPackage Name=”Config” Version=”1.0.0″ />

<Resources>
<Endpoints>
<!– This endpoint is used by the communication listener to obtain the port on which to
listen. Please note that if your service is partitioned, this port is shared with
replicas of different partitions that are placed in your code. –>
<Endpoint Protocol=”http” Name=”ServiceEndpoint” Type=”Input” Port=”8234″ />
</Endpoints>
</Resources>
</ServiceManifest>

You can reach the fully working example on my GitHub repository. -AA
Quelle: Azure

Create flexible ARM templates using conditions and logical functions

In this blog post, I will walk you through some of the new capabilities we have in our template language expressions for Azure Resource Manager templates.

Background

A common ask from customers is, “how can we use conditions in our ARM templates, so if a user selects parameter A, then resource A is created. If not, resource B should be created?”.  The only way you could achieve this, would be by using nested templates and have a mainTemplate to manipulate the deployment graph.

A common pattern can be seen below, where the user will select either new or existing.

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"newOrExisting": {
"type": "String",
"allowedValues": [
"new",
"existing"
]
}
},
"variables": {
"templatelink": "[concat('https://raw.githubusercontent.com/krnese/ARM/master/', concat(parameters('newOrExisting'),'StorageAccount.json'))]"
},
"resources": [
{
"apiVersion": "2017-05-10",
"name": "nestedTemplate",
"type": "Microsoft.Resources/deployments",
"properties": {
"mode": "incremental",
"templateLink": {
"uri": "[variables('templatelink')]",
"contentVersion": "1.0.0.0"
},
…

In the variables declaration, the link to the template is constructed based on the parameter input.

The example shows that the URI to the template will either be ‘https://raw.githubusercontent.com/krnese/ARM/master/newStorageAccount.json’ or ‘https://raw.githubusercontent.com/krnese/ARM/master/existingStorageAccount.json’.  

This approach does work and you will have a successful deployment of the template, regardless whether the user selected new or existing in the parameter selection. However, the approach of having nested templates could indeed lead to many templates over time. Where some of the templates ended up being completely empty just to avoid having a failure in the deployment graph. Further, the complexity would grow as you would normally use other resource types – besides a storage account, and potentially have multiple conditions involved.

Another technique that also was frequently used, was to manipulate complex variables based on input parameters to determine certain properties for a resource. The example below shows how ARM could navigate within the complex variables to either create Linux or Windows virtual machines, based on the parameter platform, which allowed Windows or Linux as input.

"osType": "[variables(concat('osType',parameters('platform')))]",
"osTypeWindows": {
"imageOffer": "WindowsServer",
"imageSku": "2016-Datacenter",
"imagepublisher": "MicrosoftWindowsServer"
},
"osTypeLinux": {
"imageOffer": "UbuntuServer",
"imageSku": "12.04.5-LTS",
"imagepublisher": "Canonical"
},

Needless to say, we have heard from customers that this should be simplified, so that the template language should support and handle conditions more easily.

Introducing support for conditions

As we always appreciate the feedback from our customers, we are glad to remind you (announced at //BUILD this year) we have added support for conditions on resources, as well as many more capabilities. These include logical and comparison functions that can be used in the template language when handling conditions.

I will show a practical example of how the new capabilities can be leveraged in ARM templates. A typical example today, where you want your users to select whether a virtual machine should be Windows or Linux based, would require a complex variable being manipulated as demonstrated earlier in this blog post. In addition, if your user needs to decide if the virtual machine should go into production or not, by having an availability set as an optional resource would require nested templates that either deployed the resource or are empty.

In total, this would require at least 3 templates (remember that 2 of them would be nested templates).

By using conditions and functions, we can now accomplish this with a single template! Not to mention a lot less JSON. Let’s start by walking through some of the parameters we are using in the sample template, and explain the steps we have taken.

"parameters": {
"vmNamePrefix": {
"type": "string",
"defaultValue": "VM",
"metadata": {
"description": "Assign a prefix for the VM you will create."
}
},
"production": {
"type": "string",
"allowedValues": [
"Yes",
"No"
],
"metadata": {
"description": "Select whether the VM should be in production or not."
}
},
"platform": {
"type": "string",
"allowedValues": [
"WinSrv",
"Linux"
],
"metadata": {
"description": "Select the OS type to deploy."
}
},
"pwdOrssh": {
"type": "securestring",
"metadata": {
"description": "If Windows, specify the password for the OS username. If Linux, provide the SSH."
}
},

Besides assigning the virtual machine a prefix, we also have parameters for production and platform.

For production, the user can simply select yes or no. For yes, we want to ensure that the virtual machine being created gets associated with an availability set, since this resource needs to be in place prior to the virtual machine creation process. To support this, we have added the following resource to the template:

{
"condition": "[equals(parameters('production'), 'Yes')]",
"type": "Microsoft.Compute/availabilitySets",
"apiVersion": "2017-03-30",
"name": "[variables('availabilitySetName')]",
"location": "[resourceGroup().location]",
"properties": {
"platformFaultDomainCount": 2,
"platformUpdateDomainCount": 3
},
"sku": {
"name": "Aligned"
}
},

Note the condition property. We are using a comparison function, equals(arg1, arg2), which will check whether two values equal each other. In this case, if the parameter production equals yes, ARM will process this resource during runtime. If not true (No being selected), it will not be provisioned.

For the virtual machine resource in our template, we have declared the reference to the availability set based on the condition we introduced.

"properties": {
"availabilitySet": "[if(equals(parameters('production'), 'Yes'), variables('availabilitySetId'), json('null'))]",

We’re using if() which is one of our logical functions. This function takes three arguments. The first is the condition (Boolean), which is the value to check whether it is true or false. The second argument will be the true value, followed by the third argument which is false. The net result of this, would be to associate the virtual machine. When the user selects yes for the production parameter, then the virtual machine will get associated with the availability set declared in our template, which has already been created due to the condition. If the user selects no, the availability set won’t be created, hence there won’t be any association from the virtual machine resource.

We also have a parameter platform which decides if we are creating a Windows or Linux virtual machine. To simplify the language expression throughout the template, we added the values for Linux and Windows into our variables section.

"windowsOffer": "WindowsServer",
"windowsSku": "2016-Datacenter",
"windowsPublisher": "MicrosoftWindowsServer",
"linuxOffer": "UbuntuServer",
"linuxSku": "12.04.5-LTS",
"linuxPublisher": "Canonical",

On the virtual machine resource, more specifically within the storageProfile section where we distinguish between the image being used, we are referring to our variables for Windows or Linux.

"storageProfile": {
"imageReference": {
"publisher": "[if(equals(parameters('platform'), 'WinSrv'), variables('windowsPublisher'), variables('linuxPublisher'))]",
"offer": "[if(equals(parameters('platform'), 'WinSrv'), variables('windowsOffer'), variables('linuxOffer'))]",
"version": "latest",
"sku": "[if(equals(parameters('platform'), 'WinSrv'), variables('windowsSku'), variables('linuxSku'))]"
},

If a user selects WinSrv for the platform parameter, we will grab the values for the variables pointing to the Windows image. If not and Linux is selected, we refer to those variables instead. The result would either be a virtual machine using Windows Server 2016 or Ubuntu.

Last but not least, we also have our output section in the template, which will provide the user with some instructions based on their selection.

"outputs": {
"vmEndpoint": {
"type": "string",
"value": "[reference(concat(variables('pNicName'))).dnsSettings.fqdn]"
},
"platform": {
"type": "string",
"value": "[parameters('platform')]"
},
"connectionInfo": {
"type": "string",
"value": "[if(equals(parameters('platform'), 'WinSrv'), 'Use RDP to connect to the VM', 'Use SSH to connect to the VM')]"
}
}

If the user deploys a Windows Server, they will see the following output:

If the user deploys Linux, they will see this:

Summary

We believe, by introducing support for conditions on the resources you declare in your templates and enhancements to the template language itself with logical and comparison functions, we have set the scene for much simpler templates. You can now move away from the workarounds you previously had when implementing conditions, and should hopefully achieve much more flexibility while deploying complex apps, resources, and topologies in Azure.

The full template is available here.
Quelle: Azure