July 2019
Volume 34 Number 7
[ASP.NET Core 3.0]
Restrict Site Access with AI-Driven Authorization Policies in ASP.NET Core
ASP.NET Core introduces a claim authorization mechanism that accepts custom policies to restrict access to applications, or to portions of an application, depending on specific authorization attributes of the authenticated user. In my previous article, “AI-Powered Biometric Security in ASP.NET Core” in the June 2019 issue of MSDN Magazine (msdn.com/magazine/mt833460), I presented a policy-based model for decoupling authorization logic from the underlying user roles, and showed a specific usage of such authorization policies to restrict physical access to buildings when an unauthorized intrusion is detected. In this second article, I’m going to focus on the connectivity of security cameras and streaming of data to an Azure IoT Hub, triggering the authorization flow, and assessing the severity of a potential intrusion using an anomaly detection service built into Azure Machine Learning.
You’ll find more information about the ASP.NET Core authorization framework at bit.ly/2VN9Hmo, and the source code of my Web API at bit.ly/2IXPZCo.
Restricting Access
In my scenario, access to buildings is controlled by authorization policies that have to be met before the doors unlock. ASP.NET Core 3 offers a built-in framework for managing authorization policies, which I leverage in this solution and expose via a Web API. With this in mind, Figure 1 describes a scenario where a person requests access to a building by swiping an access pass, and cameras detect motion and capture face, body and voice of the person. The card reader and cameras are registered as IoT devices and stream recorded data to Azure IoT Hub.
.png "The Authorization Flow")
Figure 1 The Authorization Flow
In my previous article, I described the use of custom authorization policies in ASP.NET Core Web API for checking for specific claims owned by the user. Those claims are asserted as biometric information for face, body and voice, promptly recognized by means of Azure Cognitive Services for Vision and Speech processing.
I’ll now describe the process for registering cameras as IoT devices in Azure IoT Hub, and the definition of rules that trigger the authorization flow.
Registering IoT devices
Generally speaking, IoT applications can be described as things (devices) that send data that generates insights. The insights in turn generate actions to improve a business or process. In my application, an example is the camera (the IoT device) sending image and voice data. This data is used to evaluate whether the person is who they say they are (the insight). The insight is used to authenticate the person and grant them access to the site (the action). The reference architecture design for this solution in Figure 2 is similar to the recommended Azure IoT architecture (bit.ly/2I20Us2), which describes two ways to process telemetry data: warm path or cold path. The difference has to do with requirements for latency and data access. The warm path analyzes data in near-real time, as it arrives, with very low latency. This is the case for triggering vision and speech recognition with Azure Cognitive Services, and then authorizing user access. The cold path captures historical telemetry data for further processing, typically for data analysis or, as in this solution, for machine learning (ML).
.png "Azure IoT Reference Architecture")
Figure 2 Azure IoT Reference Architecture
The cloud gateway that the registered devices will stream data to is Azure IoT Hub, a managed service, hosted in the cloud, that acts as a central message hub for bi-directional communication between the devices it manages and the authorization application back end. IoT Hub supports communications both from the device to the cloud and from the cloud to the device. It also supports multiple messaging patterns, such as device-to-cloud telemetry, file upload from devices, request-reply methods to control your devices from the cloud, and direct methods, which are cloud-to-device commands that don’t require a reply from the device.
A device must be registered with your IoT hub before it can connect. One of the manual processes (there are many!) for device registration is to use Azure Cloud Shell. You first create the device identity by running this command:
az iot hub device-identity create --hub-name YourIoTHubName
--device-id MyDotnetDevice
YourIoTHubName is the name of the subscriber’s IoT Hub in Azure (refer to bit.ly/2JEMnph for a detailed description of how to create an IoT Hub using the Azure Portal), and MyDotnetDevice is the name of the device you’re registering. After registration, you’ll need the device’s connection string for streaming data. Run this command to obtain the connection string of the device just registered:
az iot hub device-identity show-connection-string --hub-name YourIoTHubName
--device-id MyDotnetDevice --output table
Make a note of the device connection string, which should look something like:
HostName={YourIoTHubName}.azure-devices.net; DeviceId=MyNodeDevice;
SharedAccessKey={YourSharedAccessKey}
You’ll also need the Event Hubs-compatible endpoint, Event Hubs-compatible path, and the primary key from your access policy to enable the back-end application to connect to your IoT hub and retrieve the messages. Although IoT Hub has a predefined “iothubowner” access policy, with full control on the hub, it’s recommended you create a less-privileged policy for device connection. The following commands retrieve these values for your IoT hub:
az iot hub show --query properties.eventHubEndpoints.events.endpoint
--name YourIoTHubName
az iot hub show --query properties.eventHubEndpoints.events.path
--name YourIoTHubName
az iot hub policy show --name YourAccessPolicy --query primaryKey
--hub-name YourIoTHubName
You can also enroll a device in an IoT hub using the Azure IoT Hub Provisioning Service Client in .NET. You’ll need the Microsoft.Azure.Devices.Provisioning.Service package as a prerequisite, which you can install in your Visual Studio solution from NuGet.
The DeviceRegistrationAsync method in Figure 3 registers a Trusted Platform Module (TPM)-based device using the device’s endorsement key, which is permanently embedded in the hardware, generally at the time of manufacture. It also requires a registration ID that’s used to uniquely identify a device. This may or may not be the same as the device ID. For TPM-based devices, the registration ID may be derived from the TPM itself, for example, an SHA-256 hash of the TPM endorsement key.
Figure 3 The DeviceRegistrationAsync Method
using Microsoft.Azure.Devices.Provisioning.Service;
static async Task DeviceRegistrationAsync()
{
Attestation attestation = new TpmAttestation("<TpmEndorsementKey>");
IndividualEnrollment enrollment = new IndividualEnrollment(
"<RegistrationId>", attestation)
{
DeviceId = "DeviceId"
};
var serviceClient = ProvisioningServiceClient.CreateFromConnectionString(
"<ConnectionString>");
IndividualEnrollment enrollmentResult = await
serviceClient.CreateOrUpdateIndividualEnrollmentAsync(enrollment)
.ConfigureAwait(false);
}
Querying the enrollmentResult.RegistrationState will indicate the registration status of the device.
Streaming Data to the IoT Hub
Once a device is successfully registered, it can start streaming data to the IoT Hub. IoT Hub supports the HTTPS and Advanced Message Queuing Protocol (AMQP) protocols for data ingestion, and it’s format-agnostic, meaning that the data format can be anything, really, from CS, to JSON to Avro (an Apache data serialization project: avro.apache.org). If you’re designing a connection of devices from remote locations, where a small code footprint is required or the network bandwidth is limited, you may want to consider Message Queuing Telemetry Transport (MQTT: mqtt.org), a lightweight messaging protocol for small sensors and mobile devices, optimized for high-latency or unreliable networks. There’s a 256K limit in a device-to-cloud message, though, which makes direct data streaming unpractical for capturing image and voice data. Another approach to data loading that IoT Hub supports is file upload to blob. A camera first records audio and video at the edge, that is, on the device itself, and then uploads this data to the IoT Hub. When the upload is complete, IoT Hub raises a file upload notification message through a service-facing endpoint. This event then triggers the authorization process that, eventually, invokes the Web API with the ASP.NET Core authorization policies. It’s important to note that the file upload mechanism requires an Azure Blob storage account. Messages aren’t brokered through IoT Hub itself. Instead, IoT Hub acts as a dispatcher to an associated storage account, so it’s obviously important to configure the storage account in Azure and associate it with your IoT hub. For detailed instructions, see bit.ly/2YOMz8Q.
To initialize a file upload process, a device sends a POST request to an endpoint on the IoT Hub with this format:
{iot hub}.azure-devices.net/devices/{deviceId}/files
The POST request contains this JSON body:
{
"blobName": "..."
}
IoT Hub returns a JSON response, which the device uses to upload the file:
{
"correlationId": "<correlation_id>",
"hostName": "<yourstorageaccount>.blob.core.windows.net",
"containerName": "<container_name>",
"blobName": "<blob_name>",
"sasToken": "<token>"
}
When the upload is complete, the device sends a POST request to:
{iot hub}.azure-devices.net/devices/{deviceId}/files/notifications
with the following JSON body:
{
"correlationId": "<correlation ID received from the initial request>",
"isSuccess": bool,
"statusCode": XXX,
"statusDescription": "Description of status"
}
If you’re more into C#, you can upload a file by setting up a device client from the device connection string and send it as a stream to the blob asynchronously:
async void SendToBlobAsync(string blobName, Stream stream)
{
using (DeviceClient deviceClient =
DeviceClient.CreateFromConnectionString(
"<ConnectionString>", TransportType.Http1))
{
await deviceClient.UploadToBlobAsync(blobName, stream);
}
}
Intrusion Detection
All the data-related activities described so far happen on what’s called the “warm path store,” as data is processed in near-real time. Telemetry data is also archived in Azure Blob storage persistently for further analysis. This is the “cold path store” used by Azure Machine Learning Studio as a data source for training a data model and detecting unauthorized intrusion.
If there’s a mismatch between the detected identity of the person and their access pass, access to the site is blocked immediately. Otherwise, the flow carries on by checking whether any of the following anomalies have been encountered:
- Atypical frequency of access to the building.
- Whether the person has exited the building earlier (check out).
- Number of accesses permitted per day.
- Whether the person is on duty.
- Criticality of the building (you may not want to restrict access to a canteen, but enforce a stricter policy for access to a server datacenter).
- Whether the person is bringing someone else or something else along.
- Past occurrences of similar access typologies to the same building.
- Risk-level changes measured in the past.
- Number of intrusions detected in the past.
The anomaly detection service runs in Azure ML and returns a score, expressed as a likelihood that the access is a deviation from the standard, or not. The score is expressed in a range between zero and one, where zero is “no risk detected,” all good, full trust granted; and one is “red alert,” block access immediately! The risk level of each building determines the threshold that’s considered acceptable for allowing access into the building for any value greater than zero.
Intrusion detection is an anomaly detection problem that identifies and predicts rare or unusual occurrences of data points in a cluster. ML anomaly detection has been broadly adopted for detecting potential payment frauds, catching abnormal device readings, discovering network intrusion and any application where there’s a need to explore a large dataset of unpredictable activities or elements.
For example, access to sites can be registered over time and grouped by different criteria (time of day, a person’s role, whether solo or escorted, previous access, and so forth). These criteria are called “features” and identify all the conditions that the ML algorithm will verify to assess the intrusion score, including whether it’s a new access and whether a data point sits within the average recorded values—a cluster—or outside. If the data point is outside, its distance from the border—deviation—is also measured, to indicate a lower or higher risk factor as a number between zero and one (see Figure 4).
.png "Anomalous Intrusion Representation")
Figure 4 Anomalous Intrusion Representation
There can be hundreds of features and each contributes, to varying extents, toward the intrusion probability. The degree to which each feature contributes to the intrusion score isn’t determined by a person, say the Head of Security, but is inferred by the ML process as part of the model training. So, with regard to the unauthorized building access, if the use of someone else’s pass to gain access to a building is proven to have high occurrences, the weight of such typology of intrusion will be equally so. And, if this practice diminishes, the contribution level would decrease in parallel. Simply put, these models self-learn without explicit programming, such as with a manual review.
The process of analyzing data to extrapolate a meaning is called feature engineering; in the field of anomaly detection, you typically want to look at:
- Aggregated variables: the total number of transactions per location in the last 24 hours, seven days, or 30 days, for example.
- Mismatch values: any mismatches between the biometric information of the user and the access pass, or detection of someone’s presence in multiple places at the same time or with too short a time difference between two places very distant from each other.
- Risk tables: intrusion risks calculated using historical probability, grouped by site, level of access restriction to a building and so on.
Azure Machine Learning Studio
Azure ML Studio provides a visual editor for building ML experiments starting from a dataset, and then executing model training, scoring and evaluation. But let’s go in order. Figure 5 shows the complete ML flow.
.png "Site Intrusion Detection Experiment in Azure Machine Learning Studio")
Figure 5 Site Intrusion Detection Experiment in Azure Machine Learning Studio
The first step is importing the dataset. As data is stored in an Azure Blob, Azure ML Studio provides a specific module called “Import Data” that you can use for connecting to an Azure Blob service. After importing data, you need to separate it into training and testing sets, using the “Split Data” module. You can choose different splitting modes, depending on the type of data you have, and how you want to divide it. For this solution, I’ve selected the Split Rows option to divide the data into two random parts, with 80 percent of the data assigned to the training dataset and the remaining to be used for testing. The ML flow then performs a training of the dataset. Anomaly detection is a classification problem that can be executed as supervised or unsupervised learning, using either of the following approaches:
- One-Class Support Vector Model
- Principal Component Analysis
You can use the One-Class Support Vector Model module to create an anomaly detection model that’s particularly useful in scenarios where the data is mostly “normal” data, without many cases of the anomalies you’re trying to detect. For example, you might need to detect fraudulent accesses, but not have many examples of fraud you can use to train a typical classification model, but you might have many examples of good cases.
Principal Component Analysis, which is frequently abbreviated to PCA, in contrast, is an established ML technique that can be applied to exploratory data analysis when the source dataset isn’t well known. PCA reveals the inner structure of the data and explains the variance in the data by analyzing multiple variables and the possible correlation and combination of values that best captures the differences in outcomes. These values are called “principal components” as they’re the key factors that influence outcome.
As at this stage I can’t anticipate which approach works better, I’ll use both, with two separate Train Anomaly Detection Model modules, then compare the reciprocal results with an evaluation of the predicted values. The “Score Model” module scores predictions for a trained model, and the “Evaluate Model,” as the name implies, evaluates the results of the classification model with standard metrics, such as accuracy (goodness of a classification model as the proportion of true results to total cases), precision (proportion of true results over all positive results) and recall (fraction of all correct results returned by the model). The scored dataset with the higher metrics would be the preferred one for producing the predictive service associated with this training experiment.
Azure ML Studio generates a Web service from a predictive experiment and exposes it as a REST API that external applications can consume. The API has an endpoint hosted on the services.azureml.net domain, which is unique to your service. It requires authentication with an API key passed in the HTTP request header as the Authorization:Bearer property. The content type of the request is application/json, and the request body assumes the form of a JSON payload that contains the input values for the predictive service. The output of the service is also a JSON response with the scored value. The C# code in Figure 6 shows how to consume the ML service with an HTTP client. After building the request as a collection of string arrays, the HTTP client is initialized with the API key in the request header’s authorization property, and its base address is set to the URI of the Web service. The request is submitted by POST as a JSON message, asynchronously.
Figure 6 Invoking the Azure ML Web Service
async Task InstrusionDetectionAsync()
{
using (var client = new HttpClient())
{
var scoreRequest = new
{
Inputs = new Dictionary<string, StringTable>
{
["input1"] = new StringTable
{
ColumnNames = new [] { "<Feature1>", "<Feature2>", "<Feature3>" },
Values = new [,] { { "<Value1>", "<Value2>", "<Value3>" } }
}
}
};
client.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue("Bearer", "<ApiKey>");
client.BaseAddress = new Uri("<EndpointURI>");
HttpResponseMessage response = await client.PostAsJsonAsync("", scoreRequest);
if (response.IsSuccessStatusCode)
{
string result = await response.Content.ReadAsStringAsync();
}
}
}
public class StringTable
{
public string[] ColumnNames { get; set; }
public string[,] Values { get; set; }
}
Wrapping Up
The Azure cloud offers a rich toolset of resources that, in the right combination, help build end-to-end solutions that integrate IoT, Machine Learning, Cognitive Services and ASP.NET Core API. The scenario illustrated in the previous article of this two-parter exposes the richness of the custom policy framework in .NET Core for user authorization, in synergy with the Vision and Speech APIs of Cognitive Service for recognition of biometric characteristics such as face and voice. The current article focuses on collecting such biometric information from cameras registered as IoT devices, and streaming data to an IoT Hub in Azure. The solution is enriched with an ML service that supports the authorization process with the analysis of the access request against an historical dataset, for detecting a potential unauthorized intrusion.
Stefano Tempesta is a Microsoft Regional Director, MVP on AI and Business Applications, and member of Blockchain Council. A regular speaker at international IT conferences, including Microsoft Ignite and Tech Summit, Tempesta’s interests extend to blockchain and AI-related technologies. He created Blogchain Space (blogchain.space), a blog about blockchain technologies, writes for MSDN Magazine and MS Dynamics World, and publishes machine learning experiments on the Azure AI Gallery (gallery.azure.ai).
Thanks to the following Microsoft technical expert for reviewing this article: Danilo Diaz