Page 26 - MSDN Magazine, June 2019

the approach I’ll take is to invoke the REST API directly with an HTTP client request and response mechanism. The first step is to instantiate an HttpClient with the necessary parameters for auth- entication and data type:
public VoiceRecognition() {
_httpClient = new HttpClient();
_httpClient.BaseAddress = new Uri("<API Endpoint>"); _httpClient.DefaultRequestHeaders.Add("Ocp-Apim-Subscription-Key",
"<Subscription Key>"); _httpClient.DefaultRequestHeaders.Accept.Add(
new MediaTypeWithQualityHeaderValue("application/json"));
returns a JSON object that contains the overall result of the verifi- cation operation (Accept or Reject), confidence level (Low, Normal or High) and the recognized phrase:
{
}
}
This object is mapped to the VoiceVerificationResponse C# class for convenience of operation within the VerifyAsync method, but its level of confidence is expressed as a text:
public class VoiceVerificationResponse {
[JsonConverter(typeof(StringEnumConverter))] public Result Result { get; set; }
[JsonConverter(typeof(StringEnumConverter))] public Confidence Confidence { get; set; }
public string Phrase { get; set; } }
The Access Web API, instead, expects a decimal value (double data type) between zero and one, so I specified some numeric val- ues for the Confidence enumeration:
public enum Confidence {
Low = 1, Normal = 50, High = 99
}
I then converted these values to double before returning to the Access Web API:
private double ToConfidenceScore(Confidence confidence) {
return (double)confidence / 100.0d; }
Wrapping Up
That’s it for this first part, in which I discussed the overall site access security flow, and covered the implementation of the authoriza- tion mechanism in ASP.NET Core Web API using custom policies and requirements. I then illustrated face and voice recognition, using the relevant Cognitive Services API, as a mechanism to restrict access based on biometric information of pre-authorized, or enrolled, person profiles. In the second part of this article, I’ll go through the data streaming from the IoT devices as a triggering point for requesting access, and the final confirmation from the Access API to unlock (or lock!) the access door. I’ll also cover a machine learning-based anomaly detection service that will run on any access attempt to identify its risk.
The source code for this initial part of the solution is available on GitHub at bit.ly/2IXPZCo. n
Stefano tempeSta is a Microsoft Regional Director, MVP on AI and Business Applications, and member of Blockchain Council. A regular speaker at interna- tional 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 experi- ments on the Azure AI Gallery (gallery.azure.ai).
thankS to the following Microsoft technical expert who reviewed this article: Barry Dorrans
The Recognize method in Figure 6 develops in several steps, as follows: After obtaining the audio stream from the IoT device at the site, it attempts to identify that audio against a collection of enrolled profiles. Identification is coded in the IdentifyAsync method. This asynchronous method prepares a multipart request message that contains the audio stream and the identification profile IDs, and submits a POST request to a specific endpoint. If the response from the API is HTTP Code 202 (Accepted), then the value returned is a URI of the operation that runs in the background. This operation, at the identified URI, is checked by the Recognize method every 100 ms for completion. When it succeeds, you’ve obtained the profile ID of the identified person. With that ID, you can proceed with the verification of the audio stream, which is the final confirmation that the recorded voice belongs to the identified person. This is implemented in the VerifyAsync method, which works similarly to the IdentifyAsync method except that it returns a VoiceVerificationResponse object, which contains the profile of the person, and thus their name. The verification response includes a confidence level, which is also returned to the Access Web API, as with the Face API.
I want to add a few additional comments about this API, indi- cating how it differs from the Face API. The voice verification API
Figure 6 Voice Recognition
"result" : "Accept", // [Accept | Reject] "confidence" : "Normal", // [Low | Normal | High] "phrase": "recognized phrase"
public double Recognize(string siteId, out string name) {
ReadAudioStream(siteId, out Stream audioStream);
Guid[] enrolledProfileIds = GetEnrolledProfilesAsync(); string operationUri =
IdentifyAsync(audioStream, enrolledProfileIds).Result;
IdentificationOperation status = null; do
{
status = CheckIdentificationStatusAsync(operationUri).Result;
Thread.Sleep(100);
} while (status == null);
Guid profileId = status.ProcessingResult.IdentifiedProfileId;
VoiceVerificationResponse verification = VerifyAsync(profileId, audioStream).Result;
if (verification == null) {
name = string.Empty;
return 0; }
Profile profile = GetProfileAsync(profileId).Result; name = profile.Name;
return ToConfidenceScore(verification.Confidence); }
22 msdn magazine
ASP.NET Core 3.0