djpbessems/ContainerImage.Pinniped
1
0
Fork 0
Code Issues Pull Requests 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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

79
apis/supervisor/idp/v1alpha1/types_oidcidentityprovider.go.tmpl
View File

@ -38,60 +38,59 @@ type OIDCIdentityProviderStatus struct {
// OIDCAuthorizationConfig provides information about how to form the OAuth2 authorization // OIDCAuthorizationConfig provides information about how to form the OAuth2 authorization
// request parameters. // request parameters.
type OIDCAuthorizationConfig struct { type OIDCAuthorizationConfig struct {
// DoNotRequestOfflineAccess determines if the "offline_access" scope will be requested from your OIDC provider in // additionalScopes are the additional scopes that will be requested from your OIDC provider in the authorization
// 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
// request during an OIDC Authorization Code Flow and in the token request during a Resource Owner Password Credentials // 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 // 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 // always required according to the OIDC spec. By default, when this field is not set, the Supervisor will request
// of the DoNotRequestOfflineAccess setting. Any other scopes required should be included here in the AdditionalScopes // the following scopes: "openid", "offline_access", "email", and "profile". See
// list. For example, you might like to include scopes like "profile", "email", or "groups" in order to receive the // https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims for a description of the "profile" and "email"
// related claims in the returned ID token or userinfo endpoint results if you would like to make use of those // scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess for a description of the
// claims in the OIDCClaims settings to determine the usernames and group memberships of your Kubernetes users. See // "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. // 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 // +optional
AdditionalScopes []string `json:"additionalScopes,omitempty"` 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 // 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", // 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 // "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 // included in this setting. Additionally, the "hd" parameter cannot be included in this setting at this time.
// Resource Owner Password Credentials Grant. Starting in v0.13.0, the Pinniped Supervisor requires that your OIDC // The "hd" parameter is used by Google's OIDC provider to provide a hint as to which "hosted domain" the user
// provider returns refresh tokens to the Supervisor from the authorization flows. Some OIDC providers may require // should use during login. However, Pinniped does not yet support validating the hosted domain in the resulting
// a certain value for the "prompt" parameter in order to properly request refresh tokens. See the documentation of // ID token, so it is not yet safe to use this feature of Google's OIDC provider with Pinniped.
// your OIDC provider's authorization endpoint for its requirements for what to include in the request in // This setting does not influence the parameters sent to the token endpoint in the Resource Owner Password
// order to receive a refresh token in the response, if anything. If your provider requires the prompt parameter to // Credentials Grant. The Pinniped Supervisor requires that your OIDC provider returns refresh tokens to the
// request a refresh token, then include it here. Also note that most providers also require a certain scope to be // Supervisor from the authorization flows. Some OIDC providers may require a certain value for the "prompt"
// requested in order to receive refresh tokens. See the doNotRequestOfflineAccess setting for more information about // parameter in order to properly request refresh tokens. See the documentation of your OIDC provider's
// using scopes to request refresh tokens. // 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 // +optional
// +patchMergeKey=name // +patchMergeKey=name
// +patchStrategy=merge // +patchStrategy=merge
// +listType=map // +listType=map
// +listMapKey=name // +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 // (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. // 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 // 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 // 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 // (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. // web-based login features of your OIDC provider during Resource Owner Password Credentials Grant logins.
// AllowPasswordGrant defaults to false. // allowPasswordGrant defaults to false.
// +optional // +optional
AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"` AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"`
} }

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

@ -56,28 +56,99 @@ spec:
the OAuth2 authorization request parameters to be used with this the OAuth2 authorization request parameters to be used with this
OIDC identity provider. OIDC identity provider.
properties: properties:
additionalAuthorizeParameters:
description: 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. 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.
items:
description: Parameter is a key/value pair which represents
a parameter in an HTTP request.
properties:
name:
description: The name of the parameter. Required.
minLength: 1
type: string
value:
description: The value of the parameter.
type: string
required:
- name
type: object
type: array
x-kubernetes-list-map-keys:
- name
x-kubernetes-list-type: map
additionalScopes: additionalScopes:
description: AdditionalScopes are the additional scopes that will description: 'additionalScopes are the additional scopes that
be requested from your OIDC provider in the authorization request will be requested from your OIDC provider in the authorization
during an OIDC Authorization Code Flow and in the token request request during an OIDC Authorization Code Flow and in the token
during a Resource Owner Password Credentials Grant. Note that request during a Resource Owner Password Credentials Grant.
the "openid" scope will always be requested regardless of the Note that the "openid" scope will always be requested regardless
value in this setting, since it is always required according of the value in this setting, since it is always required according
to the OIDC spec. The "offline_access" scope may also be included to the OIDC spec. By default, when this field is not set, the
according to the value of the DoNotRequestOfflineAccess setting. Supervisor will request the following scopes: "openid", "offline_access",
Any other scopes required should be included here in the AdditionalScopes "email", and "profile". See https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
list. For example, you might like to include scopes like "profile", for a description of the "profile" and "email" scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
"email", or "groups" in order to receive the related claims for a description of the "offline_access" scope. By setting
in the returned ID token or userinfo endpoint results if you this list to anything other than an empty list, you are overriding
would like to make use of those claims in the OIDCClaims settings the default value, so you may wish to include some of "offline_access",
to determine the usernames and group memberships of your Kubernetes "email", and "profile" in your override list. Some OIDC providers
users. See your OIDC provider's documentation for more information may also require a scope to get access to the user''s group
about what scopes are available to request claims. 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).'
items: items:
type: string type: string
type: array type: array
allowPasswordGrant: allowPasswordGrant:
description: AllowPasswordGrant, when true, will allow the use description: allowPasswordGrant, when true, will allow the use
of OAuth 2.0's Resource Owner Password Credentials Grant (see of OAuth 2.0's Resource Owner Password Credentials Grant (see
https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) to https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) to
authenticate to the OIDC provider using a username and password authenticate to the OIDC provider using a username and password
@ -103,82 +174,9 @@ spec:
your end users' passwords (similar to LDAPIdentityProvider), your end users' passwords (similar to LDAPIdentityProvider),
and you will not be able to require multi-factor authentication and you will not be able to require multi-factor authentication
or use the other web-based login features of your OIDC provider or use the other web-based login features of your OIDC provider
during Resource Owner Password Credentials Grant logins. AllowPasswordGrant during Resource Owner Password Credentials Grant logins. allowPasswordGrant
defaults to false. defaults to false.
type: boolean type: boolean
doNotRequestOfflineAccess:
description: 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.
type: boolean
extraAuthorizeParameters:
description: 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.
items:
description: Parameter is a key/value pair which represents
a parameter in an HTTP request.
properties:
name:
description: The name of the parameter. Required.
minLength: 1
type: string
value:
description: The value of the parameter.
type: string
required:
- name
type: object
type: array
x-kubernetes-list-map-keys:
- name
x-kubernetes-list-type: map
type: object type: object
claims: claims:
description: Claims provides the names of token claims that will be description: Claims provides the names of token claims that will be

7
generated/1.17/README.adoc generated
View File

@ -1099,10 +1099,9 @@ OIDCAuthorizationConfig provides information about how to form the OAuth2 author
[cols="25a,75a", options="header"] [cols="25a,75a", options="header"]
|=== |===
| Field | Description | Field | Description
| *`doNotRequestOfflineAccess`* __boolean__ | 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. | *`additionalScopes`* __string array__ | 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. 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).
| *`additionalScopes`* __string array__ | 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 your OIDC provider's documentation for more information about what scopes are available to request claims. | *`additionalAuthorizeParameters`* __xref:{anchor_prefix}-go-pinniped-dev-generated-1-17-apis-supervisor-idp-v1alpha1-parameter[$$Parameter$$] array__ | 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. 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.
| *`extraAuthorizeParameters`* __xref:{anchor_prefix}-go-pinniped-dev-generated-1-17-apis-supervisor-idp-v1alpha1-parameter[$$Parameter$$] array__ | 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. | *`allowPasswordGrant`* __boolean__ | 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 supported by your OIDC provider. If your OIDC provider supports returning ID tokens from a Resource Owner Password Credentials Grant token request, then you can choose to set this field to true. This will allow end users to choose to present their username and password to the kubectl CLI (using the Pinniped plugin) to authenticate to the cluster, without using a web browser to log in as is customary in OIDC Authorization Code Flow. This may be convenient for users, especially for identities from your OIDC provider which are not intended to represent a human actor, such as service accounts performing actions in a CI/CD environment. Even if your OIDC provider supports it, you may wish to disable this behavior by setting this field to false when you prefer to only allow users of this OIDCIdentityProvider to log in via the browser-based OIDC Authorization Code Flow. Using the Resource Owner Password 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`* __boolean__ | 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 supported by your OIDC provider. If your OIDC provider supports returning ID tokens from a Resource Owner Password Credentials Grant token request, then you can choose to set this field to true. This will allow end users to choose to present their username and password to the kubectl CLI (using the Pinniped plugin) to authenticate to the cluster, without using a web browser to log in as is customary in OIDC Authorization Code Flow. This may be convenient for users, especially for identities from your OIDC provider which are not intended to represent a human actor, such as service accounts performing actions in a CI/CD environment. Even if your OIDC provider supports it, you may wish to disable this behavior by setting this field to false when you prefer to only allow users of this OIDCIdentityProvider to log in via the browser-based OIDC Authorization Code Flow. Using the Resource Owner Password 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.
|=== |===

79
generated/1.17/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 // OIDCAuthorizationConfig provides information about how to form the OAuth2 authorization
// request parameters. // request parameters.
type OIDCAuthorizationConfig struct { type OIDCAuthorizationConfig struct {
// DoNotRequestOfflineAccess determines if the "offline_access" scope will be requested from your OIDC provider in // additionalScopes are the additional scopes that will be requested from your OIDC provider in the authorization
// 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
// request during an OIDC Authorization Code Flow and in the token request during a Resource Owner Password Credentials // 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 // 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 // always required according to the OIDC spec. By default, when this field is not set, the Supervisor will request
// of the DoNotRequestOfflineAccess setting. Any other scopes required should be included here in the AdditionalScopes // the following scopes: "openid", "offline_access", "email", and "profile". See
// list. For example, you might like to include scopes like "profile", "email", or "groups" in order to receive the // https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims for a description of the "profile" and "email"
// related claims in the returned ID token or userinfo endpoint results if you would like to make use of those // scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess for a description of the
// claims in the OIDCClaims settings to determine the usernames and group memberships of your Kubernetes users. See // "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. // 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 // +optional
AdditionalScopes []string `json:"additionalScopes,omitempty"` 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 // 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", // 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 // "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 // included in this setting. Additionally, the "hd" parameter cannot be included in this setting at this time.
// Resource Owner Password Credentials Grant. Starting in v0.13.0, the Pinniped Supervisor requires that your OIDC // The "hd" parameter is used by Google's OIDC provider to provide a hint as to which "hosted domain" the user
// provider returns refresh tokens to the Supervisor from the authorization flows. Some OIDC providers may require // should use during login. However, Pinniped does not yet support validating the hosted domain in the resulting
// a certain value for the "prompt" parameter in order to properly request refresh tokens. See the documentation of // ID token, so it is not yet safe to use this feature of Google's OIDC provider with Pinniped.
// your OIDC provider's authorization endpoint for its requirements for what to include in the request in // This setting does not influence the parameters sent to the token endpoint in the Resource Owner Password
// order to receive a refresh token in the response, if anything. If your provider requires the prompt parameter to // Credentials Grant. The Pinniped Supervisor requires that your OIDC provider returns refresh tokens to the
// request a refresh token, then include it here. Also note that most providers also require a certain scope to be // Supervisor from the authorization flows. Some OIDC providers may require a certain value for the "prompt"
// requested in order to receive refresh tokens. See the doNotRequestOfflineAccess setting for more information about // parameter in order to properly request refresh tokens. See the documentation of your OIDC provider's
// using scopes to request refresh tokens. // 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 // +optional
// +patchMergeKey=name // +patchMergeKey=name
// +patchStrategy=merge // +patchStrategy=merge
// +listType=map // +listType=map
// +listMapKey=name // +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 // (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. // 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 // 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 // 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 // (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. // web-based login features of your OIDC provider during Resource Owner Password Credentials Grant logins.
// AllowPasswordGrant defaults to false. // allowPasswordGrant defaults to false.
// +optional // +optional
AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"` AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"`
} }

180
generated/1.17/crds/idp.supervisor.pinniped.dev_oidcidentityproviders.yaml generated
View File

@ -56,28 +56,99 @@ spec:
the OAuth2 authorization request parameters to be used with this the OAuth2 authorization request parameters to be used with this
OIDC identity provider. OIDC identity provider.
properties: properties:
additionalAuthorizeParameters:
description: 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. 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.
items:
description: Parameter is a key/value pair which represents
a parameter in an HTTP request.
properties:
name:
description: The name of the parameter. Required.
minLength: 1
type: string
value:
description: The value of the parameter.
type: string
required:
- name
type: object
type: array
x-kubernetes-list-map-keys:
- name
x-kubernetes-list-type: map
additionalScopes: additionalScopes:
description: AdditionalScopes are the additional scopes that will description: 'additionalScopes are the additional scopes that
be requested from your OIDC provider in the authorization request will be requested from your OIDC provider in the authorization
during an OIDC Authorization Code Flow and in the token request request during an OIDC Authorization Code Flow and in the token
during a Resource Owner Password Credentials Grant. Note that request during a Resource Owner Password Credentials Grant.
the "openid" scope will always be requested regardless of the Note that the "openid" scope will always be requested regardless
value in this setting, since it is always required according of the value in this setting, since it is always required according
to the OIDC spec. The "offline_access" scope may also be included to the OIDC spec. By default, when this field is not set, the
according to the value of the DoNotRequestOfflineAccess setting. Supervisor will request the following scopes: "openid", "offline_access",
Any other scopes required should be included here in the AdditionalScopes "email", and "profile". See https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
list. For example, you might like to include scopes like "profile", for a description of the "profile" and "email" scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
"email", or "groups" in order to receive the related claims for a description of the "offline_access" scope. By setting
in the returned ID token or userinfo endpoint results if you this list to anything other than an empty list, you are overriding
would like to make use of those claims in the OIDCClaims settings the default value, so you may wish to include some of "offline_access",
to determine the usernames and group memberships of your Kubernetes "email", and "profile" in your override list. Some OIDC providers
users. See your OIDC provider's documentation for more information may also require a scope to get access to the user''s group
about what scopes are available to request claims. 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).'
items: items:
type: string type: string
type: array type: array
allowPasswordGrant: allowPasswordGrant:
description: AllowPasswordGrant, when true, will allow the use description: allowPasswordGrant, when true, will allow the use
of OAuth 2.0's Resource Owner Password Credentials Grant (see of OAuth 2.0's Resource Owner Password Credentials Grant (see
https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) to https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) to
authenticate to the OIDC provider using a username and password authenticate to the OIDC provider using a username and password
@ -103,82 +174,9 @@ spec:
your end users' passwords (similar to LDAPIdentityProvider), your end users' passwords (similar to LDAPIdentityProvider),
and you will not be able to require multi-factor authentication and you will not be able to require multi-factor authentication
or use the other web-based login features of your OIDC provider or use the other web-based login features of your OIDC provider
during Resource Owner Password Credentials Grant logins. AllowPasswordGrant during Resource Owner Password Credentials Grant logins. allowPasswordGrant
defaults to false. defaults to false.
type: boolean type: boolean
doNotRequestOfflineAccess:
description: 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.
type: boolean
extraAuthorizeParameters:
description: 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.
items:
description: Parameter is a key/value pair which represents
a parameter in an HTTP request.
properties:
name:
description: The name of the parameter. Required.
minLength: 1
type: string
value:
description: The value of the parameter.
type: string
required:
- name
type: object
type: array
x-kubernetes-list-map-keys:
- name
x-kubernetes-list-type: map
type: object type: object
claims: claims:
description: Claims provides the names of token claims that will be description: Claims provides the names of token claims that will be

7
generated/1.18/README.adoc generated
View File

@ -1099,10 +1099,9 @@ OIDCAuthorizationConfig provides information about how to form the OAuth2 author
[cols="25a,75a", options="header"] [cols="25a,75a", options="header"]
|=== |===
| Field | Description | Field | Description
| *`doNotRequestOfflineAccess`* __boolean__ | 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. | *`additionalScopes`* __string array__ | 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. 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).
| *`additionalScopes`* __string array__ | 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 your OIDC provider's documentation for more information about what scopes are available to request claims. | *`additionalAuthorizeParameters`* __xref:{anchor_prefix}-go-pinniped-dev-generated-1-18-apis-supervisor-idp-v1alpha1-parameter[$$Parameter$$] array__ | 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. 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.
| *`extraAuthorizeParameters`* __xref:{anchor_prefix}-go-pinniped-dev-generated-1-18-apis-supervisor-idp-v1alpha1-parameter[$$Parameter$$] array__ | 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. | *`allowPasswordGrant`* __boolean__ | 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 supported by your OIDC provider. If your OIDC provider supports returning ID tokens from a Resource Owner Password Credentials Grant token request, then you can choose to set this field to true. This will allow end users to choose to present their username and password to the kubectl CLI (using the Pinniped plugin) to authenticate to the cluster, without using a web browser to log in as is customary in OIDC Authorization Code Flow. This may be convenient for users, especially for identities from your OIDC provider which are not intended to represent a human actor, such as service accounts performing actions in a CI/CD environment. Even if your OIDC provider supports it, you may wish to disable this behavior by setting this field to false when you prefer to only allow users of this OIDCIdentityProvider to log in via the browser-based OIDC Authorization Code Flow. Using the Resource Owner Password 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`* __boolean__ | 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 supported by your OIDC provider. If your OIDC provider supports returning ID tokens from a Resource Owner Password Credentials Grant token request, then you can choose to set this field to true. This will allow end users to choose to present their username and password to the kubectl CLI (using the Pinniped plugin) to authenticate to the cluster, without using a web browser to log in as is customary in OIDC Authorization Code Flow. This may be convenient for users, especially for identities from your OIDC provider which are not intended to represent a human actor, such as service accounts performing actions in a CI/CD environment. Even if your OIDC provider supports it, you may wish to disable this behavior by setting this field to false when you prefer to only allow users of this OIDCIdentityProvider to log in via the browser-based OIDC Authorization Code Flow. Using the Resource Owner Password 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.
|=== |===

79
generated/1.18/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 // OIDCAuthorizationConfig provides information about how to form the OAuth2 authorization
// request parameters. // request parameters.
type OIDCAuthorizationConfig struct { type OIDCAuthorizationConfig struct {
// DoNotRequestOfflineAccess determines if the "offline_access" scope will be requested from your OIDC provider in // additionalScopes are the additional scopes that will be requested from your OIDC provider in the authorization
// 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
// request during an OIDC Authorization Code Flow and in the token request during a Resource Owner Password Credentials // 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 // 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 // always required according to the OIDC spec. By default, when this field is not set, the Supervisor will request
// of the DoNotRequestOfflineAccess setting. Any other scopes required should be included here in the AdditionalScopes // the following scopes: "openid", "offline_access", "email", and "profile". See
// list. For example, you might like to include scopes like "profile", "email", or "groups" in order to receive the // https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims for a description of the "profile" and "email"
// related claims in the returned ID token or userinfo endpoint results if you would like to make use of those // scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess for a description of the
// claims in the OIDCClaims settings to determine the usernames and group memberships of your Kubernetes users. See // "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. // 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 // +optional
AdditionalScopes []string `json:"additionalScopes,omitempty"` 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 // 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", // 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 // "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 // included in this setting. Additionally, the "hd" parameter cannot be included in this setting at this time.
// Resource Owner Password Credentials Grant. Starting in v0.13.0, the Pinniped Supervisor requires that your OIDC // The "hd" parameter is used by Google's OIDC provider to provide a hint as to which "hosted domain" the user
// provider returns refresh tokens to the Supervisor from the authorization flows. Some OIDC providers may require // should use during login. However, Pinniped does not yet support validating the hosted domain in the resulting
// a certain value for the "prompt" parameter in order to properly request refresh tokens. See the documentation of // ID token, so it is not yet safe to use this feature of Google's OIDC provider with Pinniped.
// your OIDC provider's authorization endpoint for its requirements for what to include in the request in // This setting does not influence the parameters sent to the token endpoint in the Resource Owner Password
// order to receive a refresh token in the response, if anything. If your provider requires the prompt parameter to // Credentials Grant. The Pinniped Supervisor requires that your OIDC provider returns refresh tokens to the
// request a refresh token, then include it here. Also note that most providers also require a certain scope to be // Supervisor from the authorization flows. Some OIDC providers may require a certain value for the "prompt"
// requested in order to receive refresh tokens. See the doNotRequestOfflineAccess setting for more information about // parameter in order to properly request refresh tokens. See the documentation of your OIDC provider's
// using scopes to request refresh tokens. // 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 // +optional
// +patchMergeKey=name // +patchMergeKey=name
// +patchStrategy=merge // +patchStrategy=merge
// +listType=map // +listType=map
// +listMapKey=name // +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 // (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. // 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 // 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 // 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 // (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. // web-based login features of your OIDC provider during Resource Owner Password Credentials Grant logins.
// AllowPasswordGrant defaults to false. // allowPasswordGrant defaults to false.
// +optional // +optional
AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"` AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"`
} }

180
generated/1.18/crds/idp.supervisor.pinniped.dev_oidcidentityproviders.yaml generated
View File

@ -56,28 +56,99 @@ spec:
the OAuth2 authorization request parameters to be used with this the OAuth2 authorization request parameters to be used with this
OIDC identity provider. OIDC identity provider.
properties: properties:
additionalAuthorizeParameters:
description: 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. 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.
items:
description: Parameter is a key/value pair which represents
a parameter in an HTTP request.
properties:
name:
description: The name of the parameter. Required.
minLength: 1
type: string
value:
description: The value of the parameter.
type: string
required:
- name
type: object
type: array
x-kubernetes-list-map-keys:
- name
x-kubernetes-list-type: map
additionalScopes: additionalScopes:
description: AdditionalScopes are the additional scopes that will description: 'additionalScopes are the additional scopes that
be requested from your OIDC provider in the authorization request will be requested from your OIDC provider in the authorization
during an OIDC Authorization Code Flow and in the token request request during an OIDC Authorization Code Flow and in the token
during a Resource Owner Password Credentials Grant. Note that request during a Resource Owner Password Credentials Grant.
the "openid" scope will always be requested regardless of the Note that the "openid" scope will always be requested regardless
value in this setting, since it is always required according of the value in this setting, since it is always required according
to the OIDC spec. The "offline_access" scope may also be included to the OIDC spec. By default, when this field is not set, the
according to the value of the DoNotRequestOfflineAccess setting. Supervisor will request the following scopes: "openid", "offline_access",
Any other scopes required should be included here in the AdditionalScopes "email", and "profile". See https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
list. For example, you might like to include scopes like "profile", for a description of the "profile" and "email" scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
"email", or "groups" in order to receive the related claims for a description of the "offline_access" scope. By setting
in the returned ID token or userinfo endpoint results if you this list to anything other than an empty list, you are overriding
would like to make use of those claims in the OIDCClaims settings the default value, so you may wish to include some of "offline_access",
to determine the usernames and group memberships of your Kubernetes "email", and "profile" in your override list. Some OIDC providers
users. See your OIDC provider's documentation for more information may also require a scope to get access to the user''s group
about what scopes are available to request claims. 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).'
items: items:
type: string type: string
type: array type: array
allowPasswordGrant: allowPasswordGrant:
description: AllowPasswordGrant, when true, will allow the use description: allowPasswordGrant, when true, will allow the use
of OAuth 2.0's Resource Owner Password Credentials Grant (see of OAuth 2.0's Resource Owner Password Credentials Grant (see
https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) to https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) to
authenticate to the OIDC provider using a username and password authenticate to the OIDC provider using a username and password
@ -103,82 +174,9 @@ spec:
your end users' passwords (similar to LDAPIdentityProvider), your end users' passwords (similar to LDAPIdentityProvider),
and you will not be able to require multi-factor authentication and you will not be able to require multi-factor authentication
or use the other web-based login features of your OIDC provider or use the other web-based login features of your OIDC provider
during Resource Owner Password Credentials Grant logins. AllowPasswordGrant during Resource Owner Password Credentials Grant logins. allowPasswordGrant
defaults to false. defaults to false.
type: boolean type: boolean
doNotRequestOfflineAccess:
description: 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.
type: boolean
extraAuthorizeParameters:
description: 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.
items:
description: Parameter is a key/value pair which represents
a parameter in an HTTP request.
properties:
name:
description: The name of the parameter. Required.
minLength: 1
type: string
value:
description: The value of the parameter.
type: string
required:
- name
type: object
type: array
x-kubernetes-list-map-keys:
- name
x-kubernetes-list-type: map
type: object type: object
claims: claims:
description: Claims provides the names of token claims that will be description: Claims provides the names of token claims that will be

7
generated/1.19/README.adoc generated
View File

@ -1099,10 +1099,9 @@ OIDCAuthorizationConfig provides information about how to form the OAuth2 author
[cols="25a,75a", options="header"] [cols="25a,75a", options="header"]
|=== |===
| Field | Description | Field | Description
| *`doNotRequestOfflineAccess`* __boolean__ | 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. | *`additionalScopes`* __string array__ | 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. 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).
| *`additionalScopes`* __string array__ | 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 your OIDC provider's documentation for more information about what scopes are available to request claims. | *`additionalAuthorizeParameters`* __xref:{anchor_prefix}-go-pinniped-dev-generated-1-19-apis-supervisor-idp-v1alpha1-parameter[$$Parameter$$] array__ | 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. 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.
| *`extraAuthorizeParameters`* __xref:{anchor_prefix}-go-pinniped-dev-generated-1-19-apis-supervisor-idp-v1alpha1-parameter[$$Parameter$$] array__ | 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. | *`allowPasswordGrant`* __boolean__ | 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 supported by your OIDC provider. If your OIDC provider supports returning ID tokens from a Resource Owner Password Credentials Grant token request, then you can choose to set this field to true. This will allow end users to choose to present their username and password to the kubectl CLI (using the Pinniped plugin) to authenticate to the cluster, without using a web browser to log in as is customary in OIDC Authorization Code Flow. This may be convenient for users, especially for identities from your OIDC provider which are not intended to represent a human actor, such as service accounts performing actions in a CI/CD environment. Even if your OIDC provider supports it, you may wish to disable this behavior by setting this field to false when you prefer to only allow users of this OIDCIdentityProvider to log in via the browser-based OIDC Authorization Code Flow. Using the Resource Owner Password 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`* __boolean__ | 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 supported by your OIDC provider. If your OIDC provider supports returning ID tokens from a Resource Owner Password Credentials Grant token request, then you can choose to set this field to true. This will allow end users to choose to present their username and password to the kubectl CLI (using the Pinniped plugin) to authenticate to the cluster, without using a web browser to log in as is customary in OIDC Authorization Code Flow. This may be convenient for users, especially for identities from your OIDC provider which are not intended to represent a human actor, such as service accounts performing actions in a CI/CD environment. Even if your OIDC provider supports it, you may wish to disable this behavior by setting this field to false when you prefer to only allow users of this OIDCIdentityProvider to log in via the browser-based OIDC Authorization Code Flow. Using the Resource Owner Password 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.
|=== |===

79
generated/1.19/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 // OIDCAuthorizationConfig provides information about how to form the OAuth2 authorization
// request parameters. // request parameters.
type OIDCAuthorizationConfig struct { type OIDCAuthorizationConfig struct {
// DoNotRequestOfflineAccess determines if the "offline_access" scope will be requested from your OIDC provider in // additionalScopes are the additional scopes that will be requested from your OIDC provider in the authorization
// 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
// request during an OIDC Authorization Code Flow and in the token request during a Resource Owner Password Credentials // 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 // 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 // always required according to the OIDC spec. By default, when this field is not set, the Supervisor will request
// of the DoNotRequestOfflineAccess setting. Any other scopes required should be included here in the AdditionalScopes // the following scopes: "openid", "offline_access", "email", and "profile". See
// list. For example, you might like to include scopes like "profile", "email", or "groups" in order to receive the // https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims for a description of the "profile" and "email"
// related claims in the returned ID token or userinfo endpoint results if you would like to make use of those // scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess for a description of the
// claims in the OIDCClaims settings to determine the usernames and group memberships of your Kubernetes users. See // "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. // 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 // +optional
AdditionalScopes []string `json:"additionalScopes,omitempty"` 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 // 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", // 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 // "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 // included in this setting. Additionally, the "hd" parameter cannot be included in this setting at this time.
// Resource Owner Password Credentials Grant. Starting in v0.13.0, the Pinniped Supervisor requires that your OIDC // The "hd" parameter is used by Google's OIDC provider to provide a hint as to which "hosted domain" the user
// provider returns refresh tokens to the Supervisor from the authorization flows. Some OIDC providers may require // should use during login. However, Pinniped does not yet support validating the hosted domain in the resulting
// a certain value for the "prompt" parameter in order to properly request refresh tokens. See the documentation of // ID token, so it is not yet safe to use this feature of Google's OIDC provider with Pinniped.
// your OIDC provider's authorization endpoint for its requirements for what to include in the request in // This setting does not influence the parameters sent to the token endpoint in the Resource Owner Password
// order to receive a refresh token in the response, if anything. If your provider requires the prompt parameter to // Credentials Grant. The Pinniped Supervisor requires that your OIDC provider returns refresh tokens to the
// request a refresh token, then include it here. Also note that most providers also require a certain scope to be // Supervisor from the authorization flows. Some OIDC providers may require a certain value for the "prompt"
// requested in order to receive refresh tokens. See the doNotRequestOfflineAccess setting for more information about // parameter in order to properly request refresh tokens. See the documentation of your OIDC provider's
// using scopes to request refresh tokens. // 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 // +optional
// +patchMergeKey=name // +patchMergeKey=name
// +patchStrategy=merge // +patchStrategy=merge
// +listType=map // +listType=map
// +listMapKey=name // +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 // (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. // 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 // 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 // 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 // (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. // web-based login features of your OIDC provider during Resource Owner Password Credentials Grant logins.
// AllowPasswordGrant defaults to false. // allowPasswordGrant defaults to false.
// +optional // +optional
AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"` AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"`
} }

180
generated/1.19/crds/idp.supervisor.pinniped.dev_oidcidentityproviders.yaml generated
View File

@ -56,28 +56,99 @@ spec:
the OAuth2 authorization request parameters to be used with this the OAuth2 authorization request parameters to be used with this
OIDC identity provider. OIDC identity provider.
properties: properties:
additionalAuthorizeParameters:
description: 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. 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.
items:
description: Parameter is a key/value pair which represents
a parameter in an HTTP request.
properties:
name:
description: The name of the parameter. Required.
minLength: 1
type: string
value:
description: The value of the parameter.
type: string
required:
- name
type: object
type: array
x-kubernetes-list-map-keys:
- name
x-kubernetes-list-type: map
additionalScopes: additionalScopes:
description: AdditionalScopes are the additional scopes that will description: 'additionalScopes are the additional scopes that
be requested from your OIDC provider in the authorization request will be requested from your OIDC provider in the authorization
during an OIDC Authorization Code Flow and in the token request request during an OIDC Authorization Code Flow and in the token
during a Resource Owner Password Credentials Grant. Note that request during a Resource Owner Password Credentials Grant.
the "openid" scope will always be requested regardless of the Note that the "openid" scope will always be requested regardless
value in this setting, since it is always required according of the value in this setting, since it is always required according
to the OIDC spec. The "offline_access" scope may also be included to the OIDC spec. By default, when this field is not set, the
according to the value of the DoNotRequestOfflineAccess setting. Supervisor will request the following scopes: "openid", "offline_access",
Any other scopes required should be included here in the AdditionalScopes "email", and "profile". See https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
list. For example, you might like to include scopes like "profile", for a description of the "profile" and "email" scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
"email", or "groups" in order to receive the related claims for a description of the "offline_access" scope. By setting
in the returned ID token or userinfo endpoint results if you this list to anything other than an empty list, you are overriding
would like to make use of those claims in the OIDCClaims settings the default value, so you may wish to include some of "offline_access",
to determine the usernames and group memberships of your Kubernetes "email", and "profile" in your override list. Some OIDC providers
users. See your OIDC provider's documentation for more information may also require a scope to get access to the user''s group
about what scopes are available to request claims. 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).'
items: items:
type: string type: string
type: array type: array
allowPasswordGrant: allowPasswordGrant:
description: AllowPasswordGrant, when true, will allow the use description: allowPasswordGrant, when true, will allow the use
of OAuth 2.0's Resource Owner Password Credentials Grant (see of OAuth 2.0's Resource Owner Password Credentials Grant (see
https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) to https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) to
authenticate to the OIDC provider using a username and password authenticate to the OIDC provider using a username and password
@ -103,82 +174,9 @@ spec:
your end users' passwords (similar to LDAPIdentityProvider), your end users' passwords (similar to LDAPIdentityProvider),
and you will not be able to require multi-factor authentication and you will not be able to require multi-factor authentication
or use the other web-based login features of your OIDC provider or use the other web-based login features of your OIDC provider
during Resource Owner Password Credentials Grant logins. AllowPasswordGrant during Resource Owner Password Credentials Grant logins. allowPasswordGrant
defaults to false. defaults to false.
type: boolean type: boolean
doNotRequestOfflineAccess:
description: 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.
type: boolean
extraAuthorizeParameters:
description: 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.
items:
description: Parameter is a key/value pair which represents
a parameter in an HTTP request.
properties:
name:
description: The name of the parameter. Required.
minLength: 1
type: string
value:
description: The value of the parameter.
type: string
required:
- name
type: object
type: array
x-kubernetes-list-map-keys:
- name
x-kubernetes-list-type: map
type: object type: object
claims: claims:
description: Claims provides the names of token claims that will be description: Claims provides the names of token claims that will be

7
generated/1.20/README.adoc generated
View File

@ -1099,10 +1099,9 @@ OIDCAuthorizationConfig provides information about how to form the OAuth2 author
[cols="25a,75a", options="header"] [cols="25a,75a", options="header"]
|=== |===
| Field | Description | Field | Description
| *`doNotRequestOfflineAccess`* __boolean__ | 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. | *`additionalScopes`* __string array__ | 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. 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).
| *`additionalScopes`* __string array__ | 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 your OIDC provider's documentation for more information about what scopes are available to request claims. | *`additionalAuthorizeParameters`* __xref:{anchor_prefix}-go-pinniped-dev-generated-1-20-apis-supervisor-idp-v1alpha1-parameter[$$Parameter$$] array__ | 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. 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.
| *`extraAuthorizeParameters`* __xref:{anchor_prefix}-go-pinniped-dev-generated-1-20-apis-supervisor-idp-v1alpha1-parameter[$$Parameter$$] array__ | 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. | *`allowPasswordGrant`* __boolean__ | 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 supported by your OIDC provider. If your OIDC provider supports returning ID tokens from a Resource Owner Password Credentials Grant token request, then you can choose to set this field to true. This will allow end users to choose to present their username and password to the kubectl CLI (using the Pinniped plugin) to authenticate to the cluster, without using a web browser to log in as is customary in OIDC Authorization Code Flow. This may be convenient for users, especially for identities from your OIDC provider which are not intended to represent a human actor, such as service accounts performing actions in a CI/CD environment. Even if your OIDC provider supports it, you may wish to disable this behavior by setting this field to false when you prefer to only allow users of this OIDCIdentityProvider to log in via the browser-based OIDC Authorization Code Flow. Using the Resource Owner Password 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`* __boolean__ | 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 supported by your OIDC provider. If your OIDC provider supports returning ID tokens from a Resource Owner Password Credentials Grant token request, then you can choose to set this field to true. This will allow end users to choose to present their username and password to the kubectl CLI (using the Pinniped plugin) to authenticate to the cluster, without using a web browser to log in as is customary in OIDC Authorization Code Flow. This may be convenient for users, especially for identities from your OIDC provider which are not intended to represent a human actor, such as service accounts performing actions in a CI/CD environment. Even if your OIDC provider supports it, you may wish to disable this behavior by setting this field to false when you prefer to only allow users of this OIDCIdentityProvider to log in via the browser-based OIDC Authorization Code Flow. Using the Resource Owner Password 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.
|=== |===

79
generated/1.20/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 // OIDCAuthorizationConfig provides information about how to form the OAuth2 authorization
// request parameters. // request parameters.
type OIDCAuthorizationConfig struct { type OIDCAuthorizationConfig struct {
// DoNotRequestOfflineAccess determines if the "offline_access" scope will be requested from your OIDC provider in // additionalScopes are the additional scopes that will be requested from your OIDC provider in the authorization
// 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
// request during an OIDC Authorization Code Flow and in the token request during a Resource Owner Password Credentials // 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 // 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 // always required according to the OIDC spec. By default, when this field is not set, the Supervisor will request
// of the DoNotRequestOfflineAccess setting. Any other scopes required should be included here in the AdditionalScopes // the following scopes: "openid", "offline_access", "email", and "profile". See
// list. For example, you might like to include scopes like "profile", "email", or "groups" in order to receive the // https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims for a description of the "profile" and "email"
// related claims in the returned ID token or userinfo endpoint results if you would like to make use of those // scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess for a description of the
// claims in the OIDCClaims settings to determine the usernames and group memberships of your Kubernetes users. See // "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. // 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 // +optional
AdditionalScopes []string `json:"additionalScopes,omitempty"` 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 // 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", // 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 // "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 // included in this setting. Additionally, the "hd" parameter cannot be included in this setting at this time.
// Resource Owner Password Credentials Grant. Starting in v0.13.0, the Pinniped Supervisor requires that your OIDC // The "hd" parameter is used by Google's OIDC provider to provide a hint as to which "hosted domain" the user
// provider returns refresh tokens to the Supervisor from the authorization flows. Some OIDC providers may require // should use during login. However, Pinniped does not yet support validating the hosted domain in the resulting
// a certain value for the "prompt" parameter in order to properly request refresh tokens. See the documentation of // ID token, so it is not yet safe to use this feature of Google's OIDC provider with Pinniped.
// your OIDC provider's authorization endpoint for its requirements for what to include in the request in // This setting does not influence the parameters sent to the token endpoint in the Resource Owner Password
// order to receive a refresh token in the response, if anything. If your provider requires the prompt parameter to // Credentials Grant. The Pinniped Supervisor requires that your OIDC provider returns refresh tokens to the
// request a refresh token, then include it here. Also note that most providers also require a certain scope to be // Supervisor from the authorization flows. Some OIDC providers may require a certain value for the "prompt"
// requested in order to receive refresh tokens. See the doNotRequestOfflineAccess setting for more information about // parameter in order to properly request refresh tokens. See the documentation of your OIDC provider's
// using scopes to request refresh tokens. // 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 // +optional
// +patchMergeKey=name // +patchMergeKey=name
// +patchStrategy=merge // +patchStrategy=merge
// +listType=map // +listType=map
// +listMapKey=name // +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 // (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. // 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 // 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 // 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 // (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. // web-based login features of your OIDC provider during Resource Owner Password Credentials Grant logins.
// AllowPasswordGrant defaults to false. // allowPasswordGrant defaults to false.
// +optional // +optional
AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"` AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"`
} }

180
generated/1.20/crds/idp.supervisor.pinniped.dev_oidcidentityproviders.yaml generated
View File

@ -56,28 +56,99 @@ spec:
the OAuth2 authorization request parameters to be used with this the OAuth2 authorization request parameters to be used with this
OIDC identity provider. OIDC identity provider.
properties: properties:
additionalAuthorizeParameters:
description: 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. 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.
items:
description: Parameter is a key/value pair which represents
a parameter in an HTTP request.
properties:
name:
description: The name of the parameter. Required.
minLength: 1
type: string
value:
description: The value of the parameter.
type: string
required:
- name
type: object
type: array
x-kubernetes-list-map-keys:
- name
x-kubernetes-list-type: map
additionalScopes: additionalScopes:
description: AdditionalScopes are the additional scopes that will description: 'additionalScopes are the additional scopes that
be requested from your OIDC provider in the authorization request will be requested from your OIDC provider in the authorization
during an OIDC Authorization Code Flow and in the token request request during an OIDC Authorization Code Flow and in the token
during a Resource Owner Password Credentials Grant. Note that request during a Resource Owner Password Credentials Grant.
the "openid" scope will always be requested regardless of the Note that the "openid" scope will always be requested regardless
value in this setting, since it is always required according of the value in this setting, since it is always required according
to the OIDC spec. The "offline_access" scope may also be included to the OIDC spec. By default, when this field is not set, the
according to the value of the DoNotRequestOfflineAccess setting. Supervisor will request the following scopes: "openid", "offline_access",
Any other scopes required should be included here in the AdditionalScopes "email", and "profile". See https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
list. For example, you might like to include scopes like "profile", for a description of the "profile" and "email" scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
"email", or "groups" in order to receive the related claims for a description of the "offline_access" scope. By setting
in the returned ID token or userinfo endpoint results if you this list to anything other than an empty list, you are overriding
would like to make use of those claims in the OIDCClaims settings the default value, so you may wish to include some of "offline_access",
to determine the usernames and group memberships of your Kubernetes "email", and "profile" in your override list. Some OIDC providers
users. See your OIDC provider's documentation for more information may also require a scope to get access to the user''s group
about what scopes are available to request claims. 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).'
items: items:
type: string type: string
type: array type: array
allowPasswordGrant: allowPasswordGrant:
description: AllowPasswordGrant, when true, will allow the use description: allowPasswordGrant, when true, will allow the use
of OAuth 2.0's Resource Owner Password Credentials Grant (see of OAuth 2.0's Resource Owner Password Credentials Grant (see
https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) to https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) to
authenticate to the OIDC provider using a username and password authenticate to the OIDC provider using a username and password
@ -103,82 +174,9 @@ spec:
your end users' passwords (similar to LDAPIdentityProvider), your end users' passwords (similar to LDAPIdentityProvider),
and you will not be able to require multi-factor authentication and you will not be able to require multi-factor authentication
or use the other web-based login features of your OIDC provider or use the other web-based login features of your OIDC provider
during Resource Owner Password Credentials Grant logins. AllowPasswordGrant during Resource Owner Password Credentials Grant logins. allowPasswordGrant
defaults to false. defaults to false.
type: boolean type: boolean
doNotRequestOfflineAccess:
description: 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.
type: boolean
extraAuthorizeParameters:
description: 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.
items:
description: Parameter is a key/value pair which represents
a parameter in an HTTP request.
properties:
name:
description: The name of the parameter. Required.
minLength: 1
type: string
value:
description: The value of the parameter.
type: string
required:
- name
type: object
type: array
x-kubernetes-list-map-keys:
- name
x-kubernetes-list-type: map
type: object type: object
claims: claims:
description: Claims provides the names of token claims that will be description: Claims provides the names of token claims that will be

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 // OIDCAuthorizationConfig provides information about how to form the OAuth2 authorization
// request parameters. // request parameters.
type OIDCAuthorizationConfig struct { type OIDCAuthorizationConfig struct {
// DoNotRequestOfflineAccess determines if the "offline_access" scope will be requested from your OIDC provider in // additionalScopes are the additional scopes that will be requested from your OIDC provider in the authorization
// 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
// request during an OIDC Authorization Code Flow and in the token request during a Resource Owner Password Credentials // 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 // 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 // always required according to the OIDC spec. By default, when this field is not set, the Supervisor will request
// of the DoNotRequestOfflineAccess setting. Any other scopes required should be included here in the AdditionalScopes // the following scopes: "openid", "offline_access", "email", and "profile". See
// list. For example, you might like to include scopes like "profile", "email", or "groups" in order to receive the // https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims for a description of the "profile" and "email"
// related claims in the returned ID token or userinfo endpoint results if you would like to make use of those // scopes. See https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess for a description of the
// claims in the OIDCClaims settings to determine the usernames and group memberships of your Kubernetes users. See // "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. // 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 // +optional
AdditionalScopes []string `json:"additionalScopes,omitempty"` 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 // 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", // 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 // "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 // included in this setting. Additionally, the "hd" parameter cannot be included in this setting at this time.
// Resource Owner Password Credentials Grant. Starting in v0.13.0, the Pinniped Supervisor requires that your OIDC // The "hd" parameter is used by Google's OIDC provider to provide a hint as to which "hosted domain" the user
// provider returns refresh tokens to the Supervisor from the authorization flows. Some OIDC providers may require // should use during login. However, Pinniped does not yet support validating the hosted domain in the resulting
// a certain value for the "prompt" parameter in order to properly request refresh tokens. See the documentation of // ID token, so it is not yet safe to use this feature of Google's OIDC provider with Pinniped.
// your OIDC provider's authorization endpoint for its requirements for what to include in the request in // This setting does not influence the parameters sent to the token endpoint in the Resource Owner Password
// order to receive a refresh token in the response, if anything. If your provider requires the prompt parameter to // Credentials Grant. The Pinniped Supervisor requires that your OIDC provider returns refresh tokens to the
// request a refresh token, then include it here. Also note that most providers also require a certain scope to be // Supervisor from the authorization flows. Some OIDC providers may require a certain value for the "prompt"
// requested in order to receive refresh tokens. See the doNotRequestOfflineAccess setting for more information about // parameter in order to properly request refresh tokens. See the documentation of your OIDC provider's
// using scopes to request refresh tokens. // 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 // +optional
// +patchMergeKey=name // +patchMergeKey=name
// +patchStrategy=merge // +patchStrategy=merge
// +listType=map // +listType=map
// +listMapKey=name // +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 // (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. // 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 // 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 // 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 // (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. // web-based login features of your OIDC provider during Resource Owner Password Credentials Grant logins.
// AllowPasswordGrant defaults to false. // allowPasswordGrant defaults to false.
// +optional // +optional
AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"` AllowPasswordGrant bool `json:"allowPasswordGrant,omitempty"`
} }

21
internal/controller/supervisorconfig/oidcupstreamwatcher/oidc_upstream_watcher.go
View File

@ -65,12 +65,12 @@ const (
) )
var ( var (
disallowedAdditionalAuthorizeParameters = map[string]bool{ //nolint: gochecknoglobals
// Reject these AdditionalAuthorizeParameters to avoid allowing the user's config to overwrite the parameters // Reject these AdditionalAuthorizeParameters to avoid allowing the user's config to overwrite the parameters
// that are always used by Pinniped in authcode authorization requests. The OIDC library used would otherwise // that are always used by Pinniped in authcode authorization requests. The OIDC library used would otherwise
// happily treat the user's config as an override. Users can already set the "client_id" and "scope" params // happily treat the user's config as an override. Users can already set the "client_id" and "scope" params
// using other settings, and the others never make sense to override. This map should be treated as read-only // using other settings, and the others never make sense to override. This map should be treated as read-only
// since it is a global variable. // since it is a global variable.
disallowedAdditionalAuthorizeParameters = map[string]bool{ //nolint: gochecknoglobals
"response_type": true, "response_type": true,
"scope": true, "scope": true,
"client_id": true, "client_id": true,
@ -79,6 +79,10 @@ var (
"code_challenge": true, "code_challenge": true,
"code_challenge_method": true, "code_challenge_method": true,
"redirect_uri": true, "redirect_uri": true,
// Reject "hd" for now because it is not safe to use with Google's OIDC provider until Pinniped also
// performs the corresponding validation on the ID token.
"hd": true,
} }
) )
@ -202,7 +206,7 @@ func (c *oidcWatcherController) validateUpstream(ctx controllerlib.Context, upst
result := upstreamoidc.ProviderConfig{ result := upstreamoidc.ProviderConfig{
Name: upstream.Name, Name: upstream.Name,
Config: &oauth2.Config{ Config: &oauth2.Config{
Scopes: computeScopes(authorizationConfig.AdditionalScopes, !authorizationConfig.DoNotRequestOfflineAccess), Scopes: computeScopes(authorizationConfig.AdditionalScopes),
}, },
UsernameClaim: upstream.Spec.Claims.Username, UsernameClaim: upstream.Spec.Claims.Username,
GroupsClaim: upstream.Spec.Claims.Groups, GroupsClaim: upstream.Spec.Claims.Groups,
@ -416,13 +420,15 @@ func getTLSConfig(upstream *v1alpha1.OIDCIdentityProvider) (*tls.Config, error)
return &result, nil return &result, nil
} }
func computeScopes(additionalScopes []string, includeOfflineAccess bool) []string { func computeScopes(additionalScopes []string) []string {
// First compute the unique set of scopes, including "openid" (de-duplicate). // If none are set then provide a reasonable default which only tries to use scopes defined in the OIDC spec.
if len(additionalScopes) == 0 {
return []string{"openid", "offline_access", "email", "profile"}
}
// Otherwise, first compute the unique set of scopes, including "openid" (de-duplicate).
set := make(map[string]bool, len(additionalScopes)+1) set := make(map[string]bool, len(additionalScopes)+1)
set["openid"] = true set["openid"] = true
if includeOfflineAccess {
set["offline_access"] = true
}
for _, s := range additionalScopes { for _, s := range additionalScopes {
set[s] = true set[s] = true
} }
@ -433,6 +439,7 @@ func computeScopes(additionalScopes []string, includeOfflineAccess bool) []strin
scopes = append(scopes, s) scopes = append(scopes, s)
} }
sort.Strings(scopes) sort.Strings(scopes)
return scopes return scopes
} }

76
internal/controller/supervisorconfig/oidcupstreamwatcher/oidc_upstream_watcher_test.go
View File

@ -125,6 +125,7 @@ func TestOIDCUpstreamWatcherControllerSync(t *testing.T) {
testSecretName = "test-client-secret" testSecretName = "test-client-secret"
testAdditionalScopes = []string{"scope1", "scope2", "scope3"} testAdditionalScopes = []string{"scope1", "scope2", "scope3"}
testExpectedScopes = []string{"openid", "scope1", "scope2", "scope3"} testExpectedScopes = []string{"openid", "scope1", "scope2", "scope3"}
testDefaultExpectedScopes = []string{"openid", "offline_access", "email", "profile"}
testAdditionalParams = []v1alpha1.Parameter{{Name: "prompt", Value: "consent"}, {Name: "foo", Value: "bar"}} testAdditionalParams = []v1alpha1.Parameter{{Name: "prompt", Value: "consent"}, {Name: "foo", Value: "bar"}}
testExpectedAdditionalParams = map[string]string{"prompt": "consent", "foo": "bar"} testExpectedAdditionalParams = map[string]string{"prompt": "consent", "foo": "bar"}
testClientID = "test-oidc-client-id" testClientID = "test-oidc-client-id"
@ -562,7 +563,7 @@ Get "` + testIssuerURL + `/valid-url-that-is-really-really-long-nananananananana
TLS: &v1alpha1.TLSSpec{CertificateAuthorityData: testIssuerCABase64}, TLS: &v1alpha1.TLSSpec{CertificateAuthorityData: testIssuerCABase64},
Client: v1alpha1.OIDCClient{SecretName: testSecretName}, Client: v1alpha1.OIDCClient{SecretName: testSecretName},
AuthorizationConfig: v1alpha1.OIDCAuthorizationConfig{ AuthorizationConfig: v1alpha1.OIDCAuthorizationConfig{
AdditionalScopes: append(testAdditionalScopes, "xyz", "openid", "offline_access"), // adds openid and offline_access unnecessarily AdditionalScopes: append(testAdditionalScopes, "xyz", "openid"), // adds openid unnecessarily
AllowPasswordGrant: true, AllowPasswordGrant: true,
}, },
Claims: v1alpha1.OIDCClaims{Groups: testGroupsClaim, Username: testUsernameClaim}, Claims: v1alpha1.OIDCClaims{Groups: testGroupsClaim, Username: testUsernameClaim},
@ -589,7 +590,7 @@ Get "` + testIssuerURL + `/valid-url-that-is-really-really-long-nananananananana
Name: testName, Name: testName,
ClientID: testClientID, ClientID: testClientID,
AuthorizationURL: *testIssuerAuthorizeURL, AuthorizationURL: *testIssuerAuthorizeURL,
Scopes: append(testExpectedScopes, "offline_access", "xyz"), // includes offline_access only once Scopes: append(testExpectedScopes, "xyz"), // includes openid only once
UsernameClaim: testUsernameClaim, UsernameClaim: testUsernameClaim,
GroupsClaim: testGroupsClaim, GroupsClaim: testGroupsClaim,
AllowPasswordGrant: true, AllowPasswordGrant: true,
@ -609,7 +610,58 @@ Get "` + testIssuerURL + `/valid-url-that-is-really-really-long-nananananananana
}}, }},
}, },
{ {
name: "existing valid upstream", name: "existing valid upstream with default authorizationConfig",
inputUpstreams: []runtime.Object{&v1alpha1.OIDCIdentityProvider{
ObjectMeta: metav1.ObjectMeta{Namespace: testNamespace, Name: testName, Generation: 1234, UID: testUID},
Spec: v1alpha1.OIDCIdentityProviderSpec{
Issuer: testIssuerURL,
TLS: &v1alpha1.TLSSpec{CertificateAuthorityData: testIssuerCABase64},
Client: v1alpha1.OIDCClient{SecretName: testSecretName},
Claims: v1alpha1.OIDCClaims{Groups: testGroupsClaim, Username: testUsernameClaim},
},
Status: v1alpha1.OIDCIdentityProviderStatus{
Phase: "Ready",
Conditions: []v1alpha1.Condition{
{Type: "ClientCredentialsValid", Status: "True", LastTransitionTime: earlier, Reason: "Success", Message: "loaded client credentials"},
{Type: "OIDCDiscoverySucceeded", Status: "True", LastTransitionTime: earlier, Reason: "Success", Message: "discovered issuer configuration"},
},
},
}},
inputSecrets: []runtime.Object{&corev1.Secret{
ObjectMeta: metav1.ObjectMeta{Namespace: testNamespace, Name: testSecretName},
Type: "secrets.pinniped.dev/oidc-client",
Data: testValidSecretData,
}},
wantLogs: []string{
`oidc-upstream-observer "level"=0 "msg"="updated condition" "name"="test-name" "namespace"="test-namespace" "message"="loaded client credentials" "reason"="Success" "status"="True" "type"="ClientCredentialsValid"`,
`oidc-upstream-observer "level"=0 "msg"="updated condition" "name"="test-name" "namespace"="test-namespace" "message"="discovered issuer configuration" "reason"="Success" "status"="True" "type"="OIDCDiscoverySucceeded"`,
},
wantResultingCache: []provider.UpstreamOIDCIdentityProviderI{
&oidctestutil.TestUpstreamOIDCIdentityProvider{
Name: testName,
ClientID: testClientID,
AuthorizationURL: *testIssuerAuthorizeURL,
Scopes: testDefaultExpectedScopes,
UsernameClaim: testUsernameClaim,
GroupsClaim: testGroupsClaim,
AllowPasswordGrant: false,
AdditionalAuthcodeParams: map[string]string{},
ResourceUID: testUID,
},
},
wantResultingUpstreams: []v1alpha1.OIDCIdentityProvider{{
ObjectMeta: metav1.ObjectMeta{Namespace: testNamespace, Name: testName, Generation: 1234, UID: testUID},
Status: v1alpha1.OIDCIdentityProviderStatus{
Phase: "Ready",
Conditions: []v1alpha1.Condition{
{Type: "ClientCredentialsValid", Status: "True", LastTransitionTime: earlier, Reason: "Success", Message: "loaded client credentials", ObservedGeneration: 1234},
{Type: "OIDCDiscoverySucceeded", Status: "True", LastTransitionTime: earlier, Reason: "Success", Message: "discovered issuer configuration", ObservedGeneration: 1234},
},
},
}},
},
{
name: "existing valid upstream with additionalScopes set to override the default",
inputUpstreams: []runtime.Object{&v1alpha1.OIDCIdentityProvider{ inputUpstreams: []runtime.Object{&v1alpha1.OIDCIdentityProvider{
ObjectMeta: metav1.ObjectMeta{Namespace: testNamespace, Name: testName, Generation: 1234, UID: testUID}, ObjectMeta: metav1.ObjectMeta{Namespace: testNamespace, Name: testName, Generation: 1234, UID: testUID},
Spec: v1alpha1.OIDCIdentityProviderSpec{ Spec: v1alpha1.OIDCIdentityProviderSpec{
@ -618,7 +670,7 @@ Get "` + testIssuerURL + `/valid-url-that-is-really-really-long-nananananananana
Client: v1alpha1.OIDCClient{SecretName: testSecretName}, Client: v1alpha1.OIDCClient{SecretName: testSecretName},
Claims: v1alpha1.OIDCClaims{Groups: testGroupsClaim, Username: testUsernameClaim}, Claims: v1alpha1.OIDCClaims{Groups: testGroupsClaim, Username: testUsernameClaim},
AuthorizationConfig: v1alpha1.OIDCAuthorizationConfig{ AuthorizationConfig: v1alpha1.OIDCAuthorizationConfig{
AdditionalScopes: testAdditionalScopes, // does not include offline_access AdditionalScopes: testAdditionalScopes,
}, },
}, },
Status: v1alpha1.OIDCIdentityProviderStatus{ Status: v1alpha1.OIDCIdentityProviderStatus{
@ -643,7 +695,7 @@ Get "` + testIssuerURL + `/valid-url-that-is-really-really-long-nananananananana
Name: testName, Name: testName,
ClientID: testClientID, ClientID: testClientID,
AuthorizationURL: *testIssuerAuthorizeURL, AuthorizationURL: *testIssuerAuthorizeURL,
Scopes: append(testExpectedScopes, "offline_access"), // gets offline_access by default Scopes: testExpectedScopes,
UsernameClaim: testUsernameClaim, UsernameClaim: testUsernameClaim,
GroupsClaim: testGroupsClaim, GroupsClaim: testGroupsClaim,
AllowPasswordGrant: false, AllowPasswordGrant: false,
@ -671,7 +723,6 @@ Get "` + testIssuerURL + `/valid-url-that-is-really-really-long-nananananananana
TLS: &v1alpha1.TLSSpec{CertificateAuthorityData: testIssuerCABase64}, TLS: &v1alpha1.TLSSpec{CertificateAuthorityData: testIssuerCABase64},
Client: v1alpha1.OIDCClient{SecretName: testSecretName}, Client: v1alpha1.OIDCClient{SecretName: testSecretName},
AuthorizationConfig: v1alpha1.OIDCAuthorizationConfig{ AuthorizationConfig: v1alpha1.OIDCAuthorizationConfig{
DoNotRequestOfflineAccess: true,
AdditionalScopes: testAdditionalScopes, AdditionalScopes: testAdditionalScopes,
AdditionalAuthorizeParameters: testAdditionalParams, AdditionalAuthorizeParameters: testAdditionalParams,
AllowPasswordGrant: true, AllowPasswordGrant: true,
@ -700,7 +751,7 @@ Get "` + testIssuerURL + `/valid-url-that-is-really-really-long-nananananananana
Name: testName, Name: testName,
ClientID: testClientID, ClientID: testClientID,
AuthorizationURL: *testIssuerAuthorizeURL, AuthorizationURL: *testIssuerAuthorizeURL,
Scopes: testExpectedScopes, // does not include offline_access Scopes: testExpectedScopes, // does not include the default scopes
UsernameClaim: testUsernameClaim, UsernameClaim: testUsernameClaim,
GroupsClaim: testGroupsClaim, GroupsClaim: testGroupsClaim,
AllowPasswordGrant: true, AllowPasswordGrant: true,
@ -737,6 +788,7 @@ Get "` + testIssuerURL + `/valid-url-that-is-really-really-long-nananananananana
{Name: "code_challenge", Value: "foo"}, {Name: "code_challenge", Value: "foo"},
{Name: "code_challenge_method", Value: "foo"}, {Name: "code_challenge_method", Value: "foo"},
{Name: "redirect_uri", Value: "foo"}, {Name: "redirect_uri", Value: "foo"},
{Name: "hd", Value: "foo"},
{Name: "this_one_is_allowed", Value: "foo"}, {Name: "this_one_is_allowed", Value: "foo"},
}, },
}, },
@ -751,8 +803,8 @@ Get "` + testIssuerURL + `/valid-url-that-is-really-really-long-nananananananana
wantLogs: []string{ wantLogs: []string{
`oidc-upstream-observer "level"=0 "msg"="updated condition" "name"="test-name" "namespace"="test-namespace" "message"="loaded client credentials" "reason"="Success" "status"="True" "type"="ClientCredentialsValid"`, `oidc-upstream-observer "level"=0 "msg"="updated condition" "name"="test-name" "namespace"="test-namespace" "message"="loaded client credentials" "reason"="Success" "status"="True" "type"="ClientCredentialsValid"`,
`oidc-upstream-observer "level"=0 "msg"="updated condition" "name"="test-name" "namespace"="test-namespace" "message"="discovered issuer configuration" "reason"="Success" "status"="True" "type"="OIDCDiscoverySucceeded"`, `oidc-upstream-observer "level"=0 "msg"="updated condition" "name"="test-name" "namespace"="test-namespace" "message"="discovered issuer configuration" "reason"="Success" "status"="True" "type"="OIDCDiscoverySucceeded"`,
`oidc-upstream-observer "level"=0 "msg"="updated condition" "name"="test-name" "namespace"="test-namespace" "message"="the following additionalAuthorizeParameters are not allowed: response_type,scope,client_id,state,nonce,code_challenge,code_challenge_method,redirect_uri" "reason"="DisallowedParameterName" "status"="False" "type"="AdditionalAuthorizeParametersValid"`, `oidc-upstream-observer "level"=0 "msg"="updated condition" "name"="test-name" "namespace"="test-namespace" "message"="the following additionalAuthorizeParameters are not allowed: response_type,scope,client_id,state,nonce,code_challenge,code_challenge_method,redirect_uri,hd" "reason"="DisallowedParameterName" "status"="False" "type"="AdditionalAuthorizeParametersValid"`,
`oidc-upstream-observer "msg"="found failing condition" "error"="OIDCIdentityProvider has a failing condition" "message"="the following additionalAuthorizeParameters are not allowed: response_type,scope,client_id,state,nonce,code_challenge,code_challenge_method,redirect_uri" "name"="test-name" "namespace"="test-namespace" "reason"="DisallowedParameterName" "type"="AdditionalAuthorizeParametersValid"`, `oidc-upstream-observer "msg"="found failing condition" "error"="OIDCIdentityProvider has a failing condition" "message"="the following additionalAuthorizeParameters are not allowed: response_type,scope,client_id,state,nonce,code_challenge,code_challenge_method,redirect_uri,hd" "name"="test-name" "namespace"="test-namespace" "reason"="DisallowedParameterName" "type"="AdditionalAuthorizeParametersValid"`,
}, },
wantResultingCache: []provider.UpstreamOIDCIdentityProviderI{}, wantResultingCache: []provider.UpstreamOIDCIdentityProviderI{},
wantResultingUpstreams: []v1alpha1.OIDCIdentityProvider{{ wantResultingUpstreams: []v1alpha1.OIDCIdentityProvider{{
@ -762,7 +814,7 @@ Get "` + testIssuerURL + `/valid-url-that-is-really-really-long-nananananananana
Conditions: []v1alpha1.Condition{ Conditions: []v1alpha1.Condition{
{Type: "AdditionalAuthorizeParametersValid", Status: "False", LastTransitionTime: now, Reason: "DisallowedParameterName", {Type: "AdditionalAuthorizeParametersValid", Status: "False", LastTransitionTime: now, Reason: "DisallowedParameterName",
Message: "the following additionalAuthorizeParameters are not allowed: " + Message: "the following additionalAuthorizeParameters are not allowed: " +
"response_type,scope,client_id,state,nonce,code_challenge,code_challenge_method,redirect_uri", ObservedGeneration: 1234}, "response_type,scope,client_id,state,nonce,code_challenge,code_challenge_method,redirect_uri,hd", ObservedGeneration: 1234},
{Type: "ClientCredentialsValid", Status: "True", LastTransitionTime: now, Reason: "Success", Message: "loaded client credentials", ObservedGeneration: 1234}, {Type: "ClientCredentialsValid", Status: "True", LastTransitionTime: now, Reason: "Success", Message: "loaded client credentials", ObservedGeneration: 1234},
{Type: "OIDCDiscoverySucceeded", Status: "True", LastTransitionTime: now, Reason: "Success", Message: "discovered issuer configuration", ObservedGeneration: 1234}, {Type: "OIDCDiscoverySucceeded", Status: "True", LastTransitionTime: now, Reason: "Success", Message: "discovered issuer configuration", ObservedGeneration: 1234},
}, },
@ -770,11 +822,11 @@ Get "` + testIssuerURL + `/valid-url-that-is-really-really-long-nananananananana
}}, }},
}, },
{ {
name: "issuer is invalid URL, missing trailing slash", name: "issuer is invalid URL, missing trailing slash when the OIDC discovery endpoint returns the URL with a trailing slash",
inputUpstreams: []runtime.Object{&v1alpha1.OIDCIdentityProvider{ inputUpstreams: []runtime.Object{&v1alpha1.OIDCIdentityProvider{
ObjectMeta: metav1.ObjectMeta{Namespace: testNamespace, Name: testName}, ObjectMeta: metav1.ObjectMeta{Namespace: testNamespace, Name: testName},
Spec: v1alpha1.OIDCIdentityProviderSpec{ Spec: v1alpha1.OIDCIdentityProviderSpec{
Issuer: testIssuerURL + "/ends-with-slash", Issuer: testIssuerURL + "/ends-with-slash", // this does not end with slash when it should, thus this is an error case
TLS: &v1alpha1.TLSSpec{CertificateAuthorityData: testIssuerCABase64}, TLS: &v1alpha1.TLSSpec{CertificateAuthorityData: testIssuerCABase64},
Client: v1alpha1.OIDCClient{SecretName: testSecretName}, Client: v1alpha1.OIDCClient{SecretName: testSecretName},
}, },