7.5.4. 请求标头 CR 示例
以下自定义资源 (CR) 显示请求标头身份提供程序的参数和可接受值。
请求标题 CR
apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: requestheaderidp 1 mappingMethod: claim 2 type: RequestHeader requestHeader: challengeURL: "https://www.example.com/challenging-proxy/oauth/authorize?${query}" 3 loginURL: "https://www.example.com/login-proxy/oauth/authorize?${query}" 4 ca: 5 name: ca-config-map clientCommonNames: 6 - my-auth-proxy headers: 7 - X-Remote-User - SSO-User emailHeaders: 8 - X-Remote-User-Email nameHeaders: 9 - X-Remote-User-Display-Name preferredUsernameHeaders: 10 - X-Remote-User-Login
- 1
- 此提供程序名称作为前缀放在请求标头中的用户名前，以此组成身份名称。
- 2
- 控制如何在此提供程序的身份和
User对象之间建立映射。 - 3
- 可选：将未经身份验证的
/oauth/authorize请求重定向到的 URL，它将身份验证基于浏览器的客户端并将其请求代理到https://<namespace_route>/oauth/authorize。代理到https://<namespace_route>/oauth/authorize的 URL 必须以/authorize结尾（不含尾部斜杠）,以及代理子路径，以便 OAuth 批准流可以正常工作。${url}替换为当前的 URL，进行转义以在查询参数中安全使用。把${query}替换为当前的查询字符串。如果未定义此属性，则必须使用loginURL。 - 4
- 可选：将未经身份验证的
/oauth/authorize请求重定向到的 URL，它将身份验证期望WWW-Authenticatechallenges 的客户端，然后将它们代理到https://<namespace_route>/oauth/authorize。${url}替换为当前的 URL，进行转义以在查询参数中安全使用。把${query}替换为当前的查询字符串。如果未定义此属性，则必须使用challengeURL。 - 5
- 对包含 PEM 编码证书捆绑包的 OpenShift Container Platform
ConfigMap的引用。用作信任定位符，以验证远程服务器出示的 TLS 证书。重要自 OpenShift Container Platform 4.1 起，此身份提供程序需要
ca字段。这意味着您的代理必须支持 mutual TLS。 - 6
- 可选：通用名称 (
cn) 的列表。如果设定，则必须出示带有指定列表中通用名称 (cn) 的有效客户端证书，然后才能检查请求标头中的用户名。如果为空，则允许任何通用名称。只能与ca结合使用。 - 7
- 按顺序查找用户身份的标头名称。第一个包含值的标头被用作身份。必需，不区分大小写。
- 8
- 按顺序查找电子邮件地址的标头名称。第一个包含值的标头被用作电子邮件地址。可选，不区分大小写。
- 9
- 按顺序查找显示名称的标头名称。第一个包含值的标头被用作显示名称。可选，不区分大小写。
- 10
- 按顺序查找首选用户名的标头名称（如果与通过
headers中指定的标头确定的不可变身份不同）。在置备时，第一个包含值的标头用作首选用户名。可选，不区分大小写。
其他资源
-
有关适用于所有身份供应商的参数（如
mappingMethod）信息，请参阅身份供应商参数。
