本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 示例 4：使用 OPA 和 Rego 进行用户界面筛选
<a name="opa-ui-filtering-examples"></a>

OPA 和 Rego 的灵活性支持筛选用户界面元素的能力。以下示例演示了 OPA 部分规则如何通过授权决定哪些元素应显示在 RBAC 的 UI 中。此方法是使用 OPA 筛选用户界面元素的众多不同方法之一。

![使用 OPA 和 Rego 进行用户界面筛选](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/opa-example-4.png)


在此示例中，单页 Web 应用程序有四个按钮。假设你想过滤 Bob、Shirley 和 Alice 的用户界面，这样他们只能看到与其角色相对应的按钮。当用户界面收到用户的请求时，它会查询 OPA 部分规则以确定应在界面中显示哪些按钮。当 Bob（具有角色`viewer`）向 UI 发出请求时，查询会将以下内容作为输入传递给 OPA：

```
{
    "role": "viewer"
}
```

OPA 使用为 RBAC 结构化的外部数据来做出访问决策：

```
{
    "roles": {
        "viewer": ["viewUsers", "viewData"],
        "dataViewOnly": ["viewData"],
        "admin": ["viewUsers", "viewData", "updateUsers", "updateData"]
    }
}
```

OPA 部分规则使用外部数据和输入来生成允许的操作列表：

```
user_permissions[permissions] {
    permissions := data.roles[input.role][_]
}
```

在部分规则中，OPA 使用作为查询一部分的`input.role`指定来确定应显示哪些按钮。Bob 拥有该角色`viewer`，外部数据指定查看者有两个权限：`viewUsers`和`viewData`。因此，此规则对 Bob（以及任何其他具有查看者角色的用户）的输出如下所示：

```
{
    "user_permissions": [
        "viewData",
        "viewUsers"
    ]
}
```

`dataViewOnly`扮演角色的 Shirley 的输出将包含一个权限按钮：`viewData`。拥有该`admin`角色的 Alice 的输出将包含所有这些权限。查询 OPA 时，这些响应会返回到用户界面。`user_permissions`然后，应用程序可以使用此响应来隐藏或显示`viewUsersButton``viewDataButton`、`updateUsersButton`、和`updateDataButton`。