Page 23 - MSDN Magazine, June 2019

• 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 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 Machine Learning 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 imme- diately! The risk level of each building determines the threshold that’s considered acceptable for allowing access to the building for any value greater than zero.
Training is an asynchronous process.
Authorization in ASP.NET Core
ASP.NET Core provides a simple authorization declarative role and a rich policy-based model. Authorization is expressed in requirements, and handlers evaluate a user’s claims against those requirements. For the purpose of authorizing users to access a site, I’ll describe how to generate custom policy requirements and their authorization handler. For more information about the authorization model in ASP.NET Core, please refer to the documentation at bit.ly/2UYZaJh.
As noted, a custom policy-based authorization mechanism consists of requirements and (typically) an authorization handler. Granting access to a building consists of invoking an API that unlocks the entry door. IoT devices stream biometric informa- tion to an Azure IoT Hub, which in turn triggers the verification workflow by posting the site ID, a unique identifier of the site. The Web API POST method simply returns an HTTP code 200 and a JSON message with user name and site ID if the authorization is successful. Otherwise, it throws the expected HTTP 401 Unauth- orized Access error code. But let’s go in order: I begin with the Startup class of the Web API, specifically the ConfigureServices
Figure 1 Configuration of the Authorization Requirements in the Web API
method, which contains the instructions for configuring the necessary services to run the ASP.NET Core application. The auth- orization policies are added by calling the AddAuthorization method on the services object. The AddAuthorization method accepts a collection of policies that must be possessed by the API function when invoked for authorizing its execution. I need only one policy in this case, which I call “AuthorizedUser.” This policy, however, has several requirements to meet, which reflect the biometric char- acteristics of a person I want to verify: face, body and voice. The three requirements are each represented by a specific class that implements the IAuthorizationRequirement interface, as shown in Figure 1. When listing the requirements for the AuthorizedUser policy, I also specify the confidence level required for meeting the requirement. As I noted earlier, this value, between zero and one, expresses the accuracy of the identification of the respective biometric attribute. I’ll get back to this later when discussing bio- metric recognition with Cognitive Services.
The AuthorizedUser authorization policy contains multiple authorization requirements, and all requirements must pass in order for the policy evaluation to succeed. In other words, multiple authorization requirements added to a single authorization policy are treated on an AND basis.
The three policy requirements that I implemented in the solu- tion are all classes that implement the IAuthorizationRequirement interface. This interface is actually empty; that is, it doesn’t dictate the implementation of any method. I’ve implemented the three requirements consistently by specifying a public ConfidenceScore property for capturing the expected level of confidence that the recognition API should meet for considering this requirement successful. The FaceRecognitionRequirement class looks like this:
public class FaceRecognitionRequirement : IAuthorizationRequirement {
public double ConfidenceScore { get; }
public FaceRecognitionRequirement(double confidence) => ConfidenceScore = confidence;
Similarly, the other requirements for body and voice recognition are implemented, respectively, in the BodyRecognitionRequire- ment and VoiceRecognitionRequirement classes.
Authorization to execute a Web API action is controlled through the Authorize attribute. At its simplest, applying AuthorizeAttri- bute to a controller or action limits access to that controller or action to any authenticated user. The Web API that controls access to a site exposes a single access controller, which contains only the Post action. This action is authorized if all requirements in the specified “AuthorizedUser” policy are met:
[ApiController]
public class AccessController : ControllerBase {
[HttpPost]
[Authorize(Policy = "AuthorizedUser")]
public IActionResult Post([FromBody] string siteId) {
var response = new {
User = HttpContext.User.Identity.Name,
SiteId = siteId };
return new JsonResult(response); }
}
public void ConfigureServices(IServiceCollection services) {
var authorizationRequirements = new List<IAuthorizationRequirement> {
new FaceRecognitionRequirement(confidence: 0.9), new BodyRecognitionRequirement(confidence: 0.9), new VoiceRecognitionRequirement(confidence: 0.9)
};
services .AddAuthorization(options => {
options.AddPolicy("AuthorizedUser", policy => policy.Requirements = authorizationRequirements);
})
msdnmagazine.com
June 2019 19
}