实施政PEP
策略执行点（PEP）负责接收发送到策略决策点（PDP）进行评估的授权请求。PEP可以位于应用程序中必须保护数据和资源或应用授权逻辑的任何位置。与PDP相比，PEP相对简单。PEP只负责请求和评估授权决策，不需要任何授权逻辑。与PDP不同，PEP不能集中在SaaS应用程序中。这是因为授权和访问控制需要在整个应用程序及其访问点中实现。PEP可以应用于API、微服务、前端后端（BFF）层或应用程序中需要或需要访问控制的任何点。在应用程序中普及PEP可以确保在多个点上经常和独立地验证授权。
要实现PEP，第一步是确定应用程序中应在何处执行访问控制。在决定PEP应集成到您的应用程序中的位置时，请考虑以下原则：
- 如果应用程序公开了API，那么应该对该API进行授权和访问控制。
- 这是因为在面向微服务或面向服务的架构中，API充当不同应用程序功能之间的分隔符。将访问控制作为应用程序功能之间的逻辑检查点是有意义的。我们强烈建议您将PEP作为访问SaaS应用程序中每个API的先决条件。还可以在应用程序的其他点集成授权。在单片应用程序中，可能需要将PEP集成到应用程序本身的逻辑中。对于PEP应包含在何处，没有一刀切的解决方案，但应考虑使用API原则作为起点。
请求授权决策
PEP必须向PDP请求授权决定。请求可以采取多种形式。请求授权决策的最简单和最易访问的方法是向PDP公开的RESTful API发送授权请求或查询（使用OPA术语）。这是将PEP与PDP集成的建议方法，因为这是一种常见的向应用程序中的多个服务公开功能的模式。在此模式中，PEP的唯一功能是转发授权请求或查询所需的信息。这可以像将API接收的请求作为输入转发到PDP一样简单。创建PEP还有其他方法。例如，您可以在本地将OPA PDP与以Go编程语言编写的应用程序集成为库，而不是使用API。
评估授权决策
PEP需要包含评估授权决策结果的逻辑。当PDP作为API公开时，授权决策可能采用JSON格式，并由API调用返回。PEP必须评估此JSON代码，以确定所采取的操作是否得到授权。例如，如果PDP被设计为提供布尔允许或拒绝授权决策，则PEP可以简单地检查该值，然后返回HTTP状态代码200以允许，返回HTTP状态码403以拒绝。这种将PEP作为访问API的先决条件的模式是在SaaS应用程序中实现访问控制的一种容易实现且高效的模式。在更复杂的场景中，PEP可能负责评估PDP返回的任意JSON代码。PEP必须包含解释PDP返回的授权决定所需的任何逻辑。由于PEP可能在应用程序中的许多不同位置实现，我们建议您将PEP代码打包为可重用的库或工件，使用您选择的编程语言。这样，您的PEP可以在应用程序的任何位置轻松集成，只需最少的返工。
