本文共兩個部分，這是第一部分，其中介紹了 ASP.NET Core 3 中旨在將授權邏輯與基本的用戶角色相分離的基于策略的授權模型。

此部分提供了此授權進程的基于生物識別信息（如人臉識別或語音識別）的具體示例。

在此示例中，檢測到未經授權的入侵時，將限制進入建筑。

Azure 機器學習內置的異常檢測服務將評估入侵的嚴重性。

進入場地

上下文是受高度保護的場地 - 如軍區、醫院或數據中心。通過一些限制來僅允許已授權的人員進入。下列步驟說明了在各個門口執行的用于進行人員簽入的安全流：

• 要求進入建筑的人員在門口的讀卡器上刷其訪問通信證。

  
  

• 攝像頭檢測手勢，并捕獲此人的面部和肢體；此過程應防止使用諸如打印的照片之類的來欺騙僅具有人臉識別的攝像頭。

  
  

• 讀卡器和攝像頭注冊為物聯網 (IoT) 設備，并將錄制的數據流式傳輸到 Azure IoT 中心。

  
  

• Microsoft 認知服務將此人與已授權進入建筑的人員數據庫進行比較。

  
  

• 授權流將 IoT 設備采集的生物識別信息與訪問通信證上的人員身份進行匹配。

  
  

• 調用 Azure 機器學習服務來評估訪問申請的風險級別，并評估是否屬于未經授權的入侵。

  
  

• ASP.NET Core Web API 核對前面的步驟中定義的配置文件包含的特定策略要求，并授予權限。

若檢測到的人員身份與訪問通信證不一致，將立即阻止其進入場地。反之，流查看是否存在下面的任何異常，并繼續操作：

• 進入建筑的頻率異常。

  
  

• 此人之前是否曾進入此建筑（簽出）。

  
  

• 每日允許的訪問次數。

  
  

• 此人是否值班。

  
  

• 建筑的關鍵性（可能無需限制對餐廳的訪問，但要對服務器數據中心訪問執行嚴格的策略）。

  
  

• 此人是否帶領其他人或攜帶其他物品同行。

  
  

• 同一個建筑發生過的類似訪問異常。

  
  

• 過去評估的風險級別的變化。

  
  

• 過去檢測到的入侵次數。

Azure 機器學習運行異常檢測服務，此服務返回評分來表示訪問偏離標準值的可能性。

使用 0 到 1 之間的數值表示此評分，其中 0 表示“未檢測到風險”、一切正常、已受到完全信任；1 表示“紅色警報”，要立即阻止進入！對于大于 0 的任意值，由各個建筑的風險級別決定用于允許進入建筑的可接受閾值。

ASP.NET Core 中的授權

ASP.NET Core 提供簡單的授權聲明性角色和豐富的基于策略的模型。使用要求表示授權，由處理程序針對這些要求評估用戶的聲明。

為說明如何向要訪問場地的用戶授權，下文將介紹如何生成自定義策略要求以及其授權處理程序。

有關 ASP.NET Core 中的授權模型的詳細信息，請參閱 bit.ly/2UYZaJh 中的文檔。

如上所述，自定義的基于策略的授權機制由要求和（通常情況下）授權處理程序組成。授權訪問建筑包括調用打開入口門鎖的 API。

IoT 設備將生物識別信息流式傳輸到 Azure IoT 中心，進而通過發送場地 ID（場地的唯一標識符）觸發驗證工作流。

若驗證成功，Web API POST 方法僅返回 HTTP 代碼 200 及包含用戶名和場地 ID 的 JSON 消息。反之，它引發相應的 HTTP 401“訪問未經授權”錯誤代碼。

接下來我們按順序操作：從 Web API 的 Startup 類開始，ConfigureServices 方法尤為重要，其中包含配置所需服務以運行 ASP.NET Core 應用程序的說明。

在服務對象上調用 AddAuthorization 方法，以添加授權策略。

調用 AddAuthorization 方法以授權其執行時，它接受 API 函數必須擁有的策略集合。在本示例中，僅需要一個策略，我們稱其為“AuthorizedUser”。?

但是此策略包含多個要滿足的要求，它們反映了要驗證的人員的生物特性：面部、肢體和聲音。

這三個要求分別由實現 IAuthorizationRequirement 接口的特定類表示，如圖 1 所示。列出 AuthorizedUser 策略的要求時，還指定了滿足要求所需的可信度。

如前文所述，此值介于 0 和 1 之間，并且表示相應的生物屬性識別的準確性。

稍后在探討使用認知服務進行生物識別時，我們將繼續介紹它。

圖 1 Web API 中的授權要求的配置

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); })

AuthorizedUser 授權策略包含多個授權要求，必須滿足所有要求才能使策略評估成功。換言之，按照 AND 原則處理添加到單個授權策略的多個授權要求。

在此解決方案中實現的三個策略要求都是實現 IAuthorizationRequirement 接口的類。此接口實際為空；也就是說，它不指示任何方法的實現。

一致通過以下方式實現這三個要求：指定 ConfidenceScore 公共屬性來捕獲若要視為此要求“成功”識別 API 應達到的預期可信度。

FaceRecognitionRequirement 類如下所示：

public class FaceRecognitionRequirement : IAuthorizationRequirement{ public double ConfidenceScore { get; } public FaceRecognitionRequirement(double confidence) => ConfidenceScore = confidence;}

以同樣的方式分別在 BodyRecognitionRequirement 和 VoiceRecognitionRequirement 類中實現針對肢體和語音識別的其他要求。

通過授權屬性控制對執行 Web API 操作的授權。簡而言之，通過向控制器或操作應用 AuthorizeAttri-bute，來將該控制器或操作的訪問權限限制在所有已授權用戶范圍內。控制場地訪問的 Web API 公開單個訪問控制器，其中僅包含 Post 操作。

若已滿足指定的“AuthorizedUser”策略中的所有要求，將向此操作授權：

[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); }}

由授權處理程序管理各個要求，如圖 2 中所示，它負責評估策略要求。可以選擇讓所有要求共用單個處理程序，也可以選擇讓各個要求擁有單獨的處理程序。

后面的方式更為靈活，因為它允許配置漸變的授權要求，這樣就可以輕松地在 Startup 類中配置它們。

面部、肢體和聲音要求處理程序擴展 AuthorizationHandler<TRequirement> 抽象類，其中 TRequirement 是要處理的要求。

由于要評估三個要求，因此需要編寫自定義處理程序來分別擴展 FaceRecognitionRequirement、BodyRecognitionRequirement 和 VoiceRecognitionRequirement 的 AuthorizationHandler。

具體而言，由 HandleRequirementAsync 方法決定是否滿足授權要求。由于此方法為異步方法，因此它不返回實際值，指示任務已完成時除外。

處理授權包括在授權處理程序上下文上調用 Succeed 方法以將要求標記為“成功”。

此過程實際上由“識別器”對象驗證，它在內部使用認知服務 API（詳見下一部分）。

識別方法執行的識別操作獲取所識別人員的姓名，并返回一個值（評分）來可信度，即識別準確度高（值接近 1）或準確度低（值接近 0）。

在 API 設置中指定了預期 API。可以將此值調整為任何適用于解決方案的閾值。

圖 2 自定義授權處理程序

public class FaceRequirementHandler :

AuthorizationHandler<FaceRecognitionRequirement>{ protected override Task HandleRequirementAsync( AuthorizationHandlerContext context, FaceRecognitionRequirement requirement) { string siteId = (context.Resource as HttpContext).Request.Query["siteId"]; IRecognition recognizer = new FaceRecognition(); if (recognizer.Recognize(siteId, out string name) >= requirement.ConfidenceScore) { context.User.AddIdentity(new ClaimsIdentity( new GenericIdentity(name))); context.Succeed(requirement); } return Task.CompletedTask; }}

除了評估特定要求，授權處理程序還為當前用戶添加身份聲明。生成身份后，可以為它分配一個或多個由受信任方發布的聲明。聲明是表示主體身份的姓名-值對。

在此示例中，將為上下文中的用戶分配身份聲明。

然后在訪問控制器的 Post 操作中檢索此聲明，并將其作為 API 響應的一部分返回。

啟用此自定義授權進程的最后一個步驟是注冊 Web API 內的處理程序。進行配置時，在服務集合中注冊處理程序：

services.AddSingleton<IAuthorizationHandler, FaceRequirementHandler>();services.AddSingleton<IAuthorizationHandler, BodyRequirementHandler>();services.AddSingleton<IAuthorizationHandler, VoiceRequirementHandler>();

此代碼使用 ASP.NET Core 的內置依存關系注入 (DI) 框架將各個要求處理程序注冊為單一實例。啟動應用程序時，將生成此處理程序的實例，依存關系注入將注冊的類注入到相關對象。

人臉識別

此解決方案將 Azure 認知服務用于視覺 API，來識別人的面部和肢體。有關認知服務及此 API 的詳細信息，請參閱 bit.ly/2sxsqry。

視覺 API 提供人臉屬性檢測和人臉驗證。人臉檢測指從圖像中檢測人臉的功能。

此 API 返回所處理的圖像中人臉位置的矩形坐標，還可以提取一系列與人臉相關的屬性，如頭部姿勢、性別、年齡、表情、面部毛發和眼鏡。

人臉驗證與之相反，它針對人員的預保存人臉驗證檢測到的人臉。它實際上是在評估兩個人臉是否屬于同一個人。這是用于此安全項目的特定 API。

請將下面的 NuGet 包添加到 Visual Studio 解決方案，以開始使用：Microsoft.Azure.Cognitive-Services.Vision.Face 2.2.0-preview

.NET 托管的包處于預覽狀態，因此在瀏覽 NuGet 時務必選中“包括預發行版”選項，如圖 3 所示

圖 3 人臉 API 的 NuGet 包

.NET 包、人臉檢測和人臉識別的用法非常簡單。大體而言，人臉識別說明了比較兩個不同的人臉以確定它們是否相似或是否屬于同一個人的工作過程。識別操作主要使用圖 4 列出的數據結構。

圖 4 人臉 API 的數據結構

驗證操作從在圖像中檢測到的人臉列表（DetectedFace 集合）提取人臉 ID，并將此 ID 與保存的人臉 (PersistedFace) 集合進行比較，來確定這些人臉是否屬于同一個人。保存的人臉圖像使用唯一的 ID 和名稱標識某個人員。

可以選擇將一組人員收集到一個 PersonGroup 中，以便改進識別性能。從根本上說，一個人員就是一個基本的身份單位，一個人員對象可以注冊一個或多個已知的人臉。

在一個特定的 PersonGroup（人員集合）中定義各個人員，并基于 PersonGroup 完成識別。

安全系統將創建一個或多個 PersonGroup 對象，然后將人員與這些對象關聯。

生成組后，必須先定型 PersonGroup 集合，然后才能使用它執行驗證。

此外，在添加或刪除任何人員或編輯任何人員已注冊的人臉后，必須重新定型此集合。由 PersonGroup 定型 API 完成定型。

如果使用的是客戶端庫，此過程只是對 TrainPersonGroupAsync 方法的調用：

await faceServiceClient.TrainPersonGroupAsync(personGroupId);

定型是異步進程。即使 TrainPersonGroupAsync 方法已返回，此進程可能仍未完成。需要使用 GetPersonGroupTrainingStatusAsync 方法查詢定型狀態，直至已準備就緒，才可繼續執行人臉檢測或驗證。

執行人臉驗證時，人臉 API 計算檢測到的人臉與組內所有人臉的相似度，并返回與該測試人臉相似度最高的人員。通過客戶端庫的 IdentifyAsync 方法完成此過程。需要使用上述步驟檢測測試人臉，然后將人臉 ID 作為第二個參數傳遞到識別 API。

一次可以識別多個人臉 ID，結果將包含所有識別結果。默認情況下，識別僅返回一個與測試人臉匹配度最高的人員。

如有必要，可以指定可選參數 maxNumOfCandidatesReturned，來讓識別返回多個候選人。圖 5 中的代碼演示了識別和驗證人臉的過程：

圖 5 人臉識別過程

public class FaceRecognition : IRecognition{ public double Recognize(string siteId, out string name) { FaceClient faceClient = new FaceClient( new ApiKeyServiceClientCredentials("<Subscription Key>")) { Endpoint = "<API Endpoint>" }; ReadImageStream(siteId, out Stream imageStream); // Detect faces in the image IList<DetectedFace> detectedFaces = faceClient.Face.DetectWithStreamAsync(imageStream).Result; // Too many faces detected if (detectedFaces.Count > 1) { name = string.Empty; return 0; } IList<Guid> faceIds = detectedFaces.Select(f => f.FaceId.Value).ToList(); // Identify faces IList<IdentifyResult> identifiedFaces = faceClient.Face.IdentifyAsync(faceIds, "<Person Group ID>").Result; // No faces identified if (identifiedFaces.Count == 0) { name = string.Empty; return 0; } // Get the first candidate (candidates are ranked by confidence) IdentifyCandidate candidate = identifiedFaces.Single().Candidates.FirstOrDefault(); // Find the person Person person = faceClient.PersonGroupPerson.GetAsync("", candidate.PersonId).Result; name = person.Name; return candidate.Confidence; }

首先需要傳遞訂閱密鑰和 API 終結點，來獲取人臉 API 的客戶端對象。可以從預配人臉 API 服務的 Azure 門戶中獲取這兩個值。然后檢測圖像中顯示的任何人臉，并作為流傳遞到客戶端人臉對象的 DetectWithStreamAsync 方法。

人臉對象實現人臉 API 的檢測和驗證操作。在檢測的人臉中，確保實際只檢測一個人臉，并獲取其 ID（它是已注冊人臉集合中的唯一標識符，該集合中的所有人員已被授權訪問該場地）。

然后 IdentifyAsync 方法在 PersonGroup 中識別檢測到的人臉，并返回按可信度排序的最佳匹配或候選人列表。通過第一個候選人的人員 ID 檢索人員姓名，并且最終會將此姓名返回到訪問 Web API。人臉授權要求已滿足。

語音識別

Azure 認知服務說話人識別 API 提供說話人驗證和說話人識別算法。

聲音具有唯一的特性，可以像使用指紋一樣將它們用于人員識別。本文中的安全解決方案將語音作為訪問控制信號，在此方案中主體通過語音將通行短語輸入到已注冊為 IoT 設備的麥克風。與人臉識別一樣，語音識別也需要預注冊已授權的人員。

說話人 API 將已注冊人員稱為“個人資料”。?注冊個人資料時，將錄制說話人陳述特定短語時的語音，然后提取一些特性，并識別已選定的短語。提取的特性和已選定的短語共同構成了唯一的語音簽名。進行驗證時，將輸入語音和短語與注冊語音簽名和短語進行比較，來驗證它們是否來自同一個人，以及短語是否正確。

從代碼實現可以看出，不同于人員 API，說話人 API 并未從 NuGet 中的托管包受益，因此我們將采用直接使用 HTTP 客戶端請求和響應機制調用 REST API 的方法。第一個步驟是使用驗證和數據類型的必要參數實例化 HttpClient：

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"));}

使用下面的幾個步驟生成圖 6 中的識別方法：從場地中的 IoT 設備獲取音頻流后，它嘗試基于已注冊的個人資料集合識別該音頻。在 IdentifyAsync 方法中為識別編碼。

此異步方法準備包含音頻流和識別個人資料 ID 的多部分請求消息，并向特定終結點提交 POST 請求。若 API 的響應為 HTTP 代碼 202（已接受），則返回值為在后臺運行的操作的 URI。識別方法每 100 毫秒查看一次所標識的 URI 上的該操作是否完成。操作成功后，即獲得所識別的人員的個人資料 ID。

借助此 ID，可以繼續驗證音頻流，它將最終確認錄制的語音屬于所識別的人員。

在 VerifyAsync 方法中實現此操作，此方法的工作原理與 IdentifyAsync 方法類似，但它返回的是包含人員的個人資料及其姓名的 VoiceVerificationResponse 對象。驗證響應包含可信度，與人臉 API 一樣，同時也會將其返回到訪問 Web API。

圖 6 語音識別

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);}

我要為此 API 添加一些額外說明，以表明它與人臉 API 的區別。語音驗證 API 返回 JSON 對象，其中包含驗證操作（接受或拒絕）、可信度（低、中、高）和識別的短語的整體結果：

{ "result" : "Accept", // [Accept | Reject] "confidence" : "Normal", // [Low | Normal | High] "phrase": "recognized phrase"}

此對象映射到 VoiceVerificationResponse C# 類，以便于在 VerifyAsync 方法中運行它，但它的可信度使用文本表示：

public class VoiceVerificationResponse{ [JsonConverter(typeof(StringEnumConverter))] public Result Result { get; set; } [JsonConverter(typeof(StringEnumConverter))] public Confidence Confidence { get; set; } public string Phrase { get; set; }}

而訪問 Web API 需要介于 0 到 1 之間的小數值（雙精度數據類型），因此為可信度枚舉指定了一些數字值：

public enum Confidence{ Low = 1, Normal = 50, High = 99}

然后在將這些值返回到訪問 Web API 之前，將它們轉換為雙精度值：

private double ToConfidenceScore(Confidence confidence){ return (double)confidence / 100.0d;}

總結

這是第一部分的全部內容，此部分說明了整個場地訪問安全流，并介紹了如何使用自定義策略和要求實現 ASP.NET Core Web API 中的授權機制。

之后說明了如何使用相關的認知服務 API 完成人臉和語音識別，來作為基于已預授權或已注冊人員個人資料的生物識別信息限制訪問的機制。

本文的第二個部分將詳細介紹作為請求訪問觸發點的 IoT 設備數據流，以及訪問 API 最終確認打開（或鎖定）入口的過程。

此外，還將說明每當嘗試訪問時都會運行以識別其風險的基于機器學習的異常檢測服務。

從 GitHub 獲取此解決方案的第一部分的源代碼：bit.ly/2IXPZCo。

總結

以上是生活随笔為你收集整理的ASP.NET Core 3.0中支持AI的生物识别安全的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。