mirrors/pinniped
1
0
Fork 0
mirror of https://github.com/vmware-tanzu/pinniped.git synced 2026-01-05 13:07:14 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Lots of small updates based on PR feedback

Browse Source
This commit is contained in:
Ryan Richard
2021-10-20 15:53:25 -07:00
parent 7ec0304472
commit dec43289f6
28 changed files with 208 additions and 160 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
deploy/supervisor/idp.supervisor.pinniped.dev_oidcidentityproviders.yaml
View File

@@ -114,32 +114,36 @@ spec:
Supervisor will request the following scopes: "openid", "offline_access",
"email", and "profile". See https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
for a description of the "profile" and "email" scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
for a description of the "offline_access" scope. By setting
this list to anything other than an empty list, you are overriding
the default value, so you may wish to include some of "offline_access",
"email", and "profile" in your override list. Some OIDC providers
may also require a scope to get access to the user''s group
membership, in which case you may wish to include it in this
list. Sometimes the scope to request the user''s group membership
is called "groups", but unfortunately this is not specified
in the OIDC standard. Generally speaking, you should include
any scopes required to cause the appropriate claims to be the
returned by your OIDC provider in the ID token or userinfo endpoint
results for those claims which you would like to use in the
oidcClaims settings to determine the usernames and group memberships
of your Kubernetes users. See your OIDC provider''s documentation
for more information about what scopes are available to request
claims. Additionally, the Pinniped Supervisor requires that
your OIDC provider returns refresh tokens to the Supervisor
from these authorization flows. For most OIDC providers, the
scope required to receive refresh tokens will be "offline_access".
See the documentation of your OIDC provider''s authorization
and token endpoints for its requirements for what to include
in the request in order to receive a refresh token in the response,
if anything. Note that it may be safe to send "offline_access"
even to providers which do not require it, since the provider
may ignore scopes that it does not understand or require (see
https://datatracker.ietf.org/doc/html/rfc6749#section-3.3).
for a description of the "offline_access" scope. This default
value may change in future versions of Pinniped as the standard
evolves, or as common patterns used by providers who implement
the standard in the ecosystem evolve. By setting this list to
anything other than an empty list, you are overriding the default
value, so you may wish to include some of "offline_access",
"email", and "profile" in your override list. If you do not
want any of these scopes to be requested, you may set this list
to contain only "openid". Some OIDC providers may also require
a scope to get access to the user''s group membership, in which
case you may wish to include it in this list. Sometimes the
scope to request the user''s group membership is called "groups",
but unfortunately this is not specified in the OIDC standard.
Generally speaking, you should include any scopes required to
cause the appropriate claims to be the returned by your OIDC
provider in the ID token or userinfo endpoint results for those
claims which you would like to use in the oidcClaims settings
to determine the usernames and group memberships of your Kubernetes
users. See your OIDC provider''s documentation for more information
about what scopes are available to request claims. Additionally,
the Pinniped Supervisor requires that your OIDC provider returns
refresh tokens to the Supervisor from these authorization flows.
For most OIDC providers, the scope required to receive refresh
tokens will be "offline_access". See the documentation of your
OIDC provider''s authorization and token endpoints for its requirements
for what to include in the request in order to receive a refresh
token in the response, if anything. Note that it may be safe
to send "offline_access" even to providers which do not require
it, since the provider may ignore scopes that it does not understand
or require (see https://datatracker.ietf.org/doc/html/rfc6749#section-3.3).
In the unusual case that you must avoid sending the "offline_access"
scope, then you must override the default value of this setting.
This is required if your OIDC provider will reject the request