實作 PEP

政策強制執行點 (PEP) 負責接收傳送至政策決策點 (PDP) 以供評估的授權請求。PEP 可以位於應用程式中的任何位置，其中資料和資源必須受到保護，或套用授權邏輯。與 PDPs 相比PEPs 相對簡單。PEP 僅負責請求和評估授權決策，不需要任何授權邏輯。與 PDPs不同，PEPs 無法集中在 SaaS 應用程式中。這是因為需要在整個應用程式及其存取點中實作授權和存取控制。PEPs可以套用至 APIs、微服務、後端前端 (BFF) 層，或應用程式中需要或需要存取控制的任何點。讓 PEPs 在應用程式中普及，可確保在多個點時經常獨立驗證授權。   

若要實作 PEP，第一個步驟是判斷應用程式中應執行存取控制的位置。在決定應將哪些 PEPs 整合到您的應用程式中時，請考慮此原則： 

如果應用程式公開 API，則該 API 應具備授權和存取控制。

這是因為在微服務導向或服務導向架構中，APIs可做為不同應用程式函數之間的分隔符號。將存取控制作為應用程式函數之間的邏輯檢查點是合理的。我們強烈建議您納入 PEPs做為存取 SaaS 應用程式中每個 API 的先決條件。您也可以在應用程式中的其他時間點整合授權。在單體應用程式中，可能需要將 PEPs整合到應用程式本身的邏輯中。沒有應該包含 PEPs 的單一位置，但請考慮使用 API 原則做為起點。

請求授權決策

PEP 必須向 PDP 請求授權決策。請求可以採用多種形式。請求授權決策最簡單且最容易存取的方法，是將授權請求或查詢傳送至 PDP (OPA 或驗證許可） 公開的 RESTful API。如果您使用的是 Verified Permissions，您也可以使用 AWS SDK 來擷取授權決策，以呼叫 IsAuthorized 方法。此模式中 PEP 的唯一函數是轉送授權請求或查詢所需的資訊。這可以像將 API 收到的請求轉送為 PDP 輸入一樣簡單。還有其他建立 PEPs 的方法。例如，您可以將 OPA PDP 在本機與以 Go 程式設計語言撰寫的應用程式整合為程式庫，而不是使用 API。

評估授權決策

PEPs 需要包含邏輯來評估授權決策的結果。當 PDPs公開為 APIs時，授權決策可能採用 JSON 格式，並由 API 呼叫傳回。PEP 必須評估此 JSON 程式碼，以判斷所採取的動作是否已獲得授權。例如，如果 PDP 旨在提供布林值允許或拒絕授權決策，則 PEP 可能只檢查此值，然後傳回 HTTP 狀態碼 200 表示允許，傳回 HTTP 狀態碼 403 表示拒絕。這種將 PEP 整合為存取 API 的先決條件的模式，是在 SaaS 應用程式中實作存取控制的輕鬆實作和高效模式。在更複雜的案例中，PEP 可能負責評估 PDP 傳回的任意 JSON 程式碼。必須寫入 PEP，以包含解釋 PDP 傳回的授權決策所需的任何邏輯。由於 PEP 可能在您應用程式中的許多不同位置實作，我們建議您將 PEP 程式碼封裝為可重複使用的程式庫或您選擇的程式設計語言成品。如此一來，您的 PEP 就可以輕鬆地在應用程式中的任何時間點整合，只需最少的重新作業。