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

Change default of additionalScopes and disallow "hd" in additionalAuthorizeParameters

Browse Source
This commit is contained in:
Ryan Richard
2021-10-18 16:41:31 -07:00
parent d68bebeb49
commit c43e019d3a
17 changed files with 773 additions and 734 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
generated/latest/apis/supervisor/idp/v1alpha1/types_oidcidentityprovider.go generated
View File

@@ -38,60 +38,59 @@ type OIDCIdentityProviderStatus struct {
// OIDCAuthorizationConfig provides information about how to form the OAuth2 authorization
// request parameters.
type OIDCAuthorizationConfig struct {
// DoNotRequestOfflineAccess determines if the "offline_access" scope will be requested from your OIDC provider in
// the authorization request during an OIDC Authorization Code Flow and in the token request during a Resource Owner
// Password Credentials Grant in order to ask to receive a refresh token in the response. Starting in v0.13.0, 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 https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess for a description of the "offline_access"
// scope. 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. By default,
// DoNotRequestOfflineAccess is false, which means that "offline_access" will be sent in the authorization request,
// since that is what is suggested by the OIDC specification. 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, set DoNotRequestOfflineAccess to true. This is required if your OIDC provider will reject
// the request when it includes "offline_access" (e.g. GitLab's OIDC provider). If you need to send some other scope
// to request a refresh token, include the scope name in the additionalScopes setting. Also note that some OIDC
// providers may require that the "prompt" param be set to a specific value for the authorization request during an
// OIDC Authorization Code Flow in order to receive a refresh token in the response. To adjust the prompt param, see
// the additionalAuthorizeParameters setting.
// +optional
DoNotRequestOfflineAccess bool `json:"doNotRequestOfflineAccess,omitempty"`
// AdditionalScopes are the additional scopes that will be requested from your OIDC provider in the authorization
// additionalScopes are the additional scopes that will be requested from your OIDC provider in the authorization
// request during an OIDC Authorization Code Flow and in the token request during a Resource Owner Password Credentials
// Grant. Note that the "openid" scope will always be requested regardless of the value in this setting, since it is
// always required according to the OIDC spec. The "offline_access" scope may also be included according to the value
// of the DoNotRequestOfflineAccess setting. Any other scopes required should be included here in the AdditionalScopes
// list. For example, you might like to include scopes like "profile", "email", or "groups" in order to receive the
// related claims in the returned ID token or userinfo endpoint results if you would like to make use of those
// claims in the OIDCClaims settings to determine the usernames and group memberships of your Kubernetes users. See
// always required according to the OIDC spec. By default, when this field is not set, the 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). 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 when it includes "offline_access" (e.g. GitLab's OIDC provider).
// +optional
AdditionalScopes []string `json:"additionalScopes,omitempty"`
// AdditionalAuthorizeParameters are extra query parameters that should be included in the authorize request to your
// additionalAuthorizeParameters are extra query parameters that should be included in the authorize request to your
// OIDC provider in the authorization request during an OIDC Authorization Code Flow. By default, no extra
// parameters are sent. The standard parameters that will be sent are "response_type", "scope", "client_id",
// "state", "nonce", "code_challenge", "code_challenge_method", and "redirect_uri". These parameters cannot be
// included in this setting. This setting does not influence the parameters sent to the token endpoint in the
// Resource Owner Password Credentials Grant. Starting in v0.13.0, the Pinniped Supervisor requires that your OIDC
// provider returns refresh tokens to the Supervisor from the authorization flows. Some OIDC providers may require
// a certain value for the "prompt" parameter in order to properly request refresh tokens. See the documentation of
// your OIDC provider's authorization endpoint for its requirements for what to include in the request in
// order to receive a refresh token in the response, if anything. If your provider requires the prompt parameter to
// request a refresh token, then include it here. Also note that most providers also require a certain scope to be
// requested in order to receive refresh tokens. See the doNotRequestOfflineAccess setting for more information about
// using scopes to request refresh tokens.
// included in this setting. Additionally, the "hd" parameter cannot be included in this setting at this time.
// The "hd" parameter is used by Google's OIDC provider to provide a hint as to which "hosted domain" the user
// should use during login. However, Pinniped does not yet support validating the hosted domain in the resulting
// ID token, so it is not yet safe to use this feature of Google's OIDC provider with Pinniped.
// This setting does not influence the parameters sent to the token endpoint in the Resource Owner Password
// Credentials Grant. The Pinniped Supervisor requires that your OIDC provider returns refresh tokens to the
// Supervisor from the authorization flows. Some OIDC providers may require a certain value for the "prompt"
// parameter in order to properly request refresh tokens. See the documentation of your OIDC provider's
// authorization endpoint for its requirements for what to include in the request in order to receive a refresh
// token in the response, if anything. If your provider requires the prompt parameter to request a refresh token,
// then include it here. Also note that most providers also require a certain scope to be requested in order to
// receive refresh tokens. See the additionalScopes setting for more information about using scopes to request
// refresh tokens.
// +optional
// +patchMergeKey=name
// +patchStrategy=merge
// +listType=map
// +listMapKey=name
AdditionalAuthorizeParameters []Parameter `json:"extraAuthorizeParameters,omitempty"`
AdditionalAuthorizeParameters []Parameter `json:"additionalAuthorizeParameters,omitempty"`
// AllowPasswordGrant, when true, will allow the use of OAuth 2.0's Resource Owner Password Credentials Grant
// allowPasswordGrant, when true, will allow the use of OAuth 2.0's Resource Owner Password Credentials Grant
// (see https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) to authenticate to the OIDC provider using a
// username and password without a web browser, in addition to the usual browser-based OIDC Authorization Code Flow.
// The Resource Owner Password Credentials Grant is not officially part of the OIDC specification, so it may not be
@@ -106,7 +105,7 @@ type OIDCAuthorizationConfig struct {
// Credentials Grant means that the Pinniped CLI and Pinniped Supervisor will directly handle your end users' passwords
// (similar to LDAPIdentityProvider), and you will not be able to require multi-factor authentication or use the other
// web-based login features of your OIDC provider during Resource Owner Password Credentials Grant logins.
// AllowPasswordGrant defaults to false.
// allowPasswordGrant defaults to false.
// +optional
AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"`
}