Project: Gloo (Orchestration & Management / API Gateway)
File: extauth.proto.sk.md

title: "extauth.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Top-Level Resource This is the user-facing auth configuration. When processed by Gloo, certain configuration types (i.a. oauth, opa) will be translated, e.g. to resolve resource references. See the `ExtAuthConfig.AuthConfig` for the final config format that will be included in the extauth snapshot. ```yaml "namespacedStatuses": .core.solo.io.NamespacedStatuses "metadata": .core.solo.io.Metadata "configs": []enterprise.gloo.solo.io.AuthConfig.Config "booleanExpr": .google.protobuf.StringValue "failOnRedirect": bool ``` | Field | Type | Description | | -- | - | -- | | `namespacedStatuses` | | NamespacedStatuses indicates the validation status of this resource. NamespacedStatuses is read-only by clients, and set by gloo during validation. | | `metadata` | | Metadata contains the object metadata for this resource. | | `configs` | | List of auth configs to be checked for requests on a route referencing this auth config, By default, every config must be authorized for the entire request to be authorized. This behavior can be changed by defining names for each config and defining `boolean_expr` below. State is shared between successful requests on the chain, i.e., the headers returned from each successful auth service get appended into the final auth response. | | `booleanExpr` | | How to handle processing of named configs within an auth config chain. An example config might be: `( basic1 || basic2 || (oidc1 && !oidc2) )` The boolean expression is evaluated left to right but honors parenthesis and short-circuiting. | | `failOnRedirect` | `bool` | How the service should handle a redirect response from an OIDC issuer. In the default false mode, the redirect will be considered a successful response, and the client will receive a 302 with a location header. If this is set to true, the client will instead receive a 401 unauthorized response. This is useful in cases where API calls are being made or other such occurrences where the client cannot handle the redirect. | ```yaml "name": .google.protobuf.StringValue "basicAuth": .enterprise.gloo.solo.io.BasicAuth "oauth": .enterprise.gloo.solo.io.OAuth "oauth2": .enterprise.gloo.solo.io.OAuth2 "apiKeyAuth": .enterprise.gloo.solo.io.ApiKeyAuth "pluginAuth": .enterprise.gloo.solo.io.AuthPlugin "opaAuth": .enterprise.gloo.solo.io.OpaAuth "ldap": .enterprise.gloo.solo.io.Ldap "jwt": .google.protobuf.Empty "passThroughAuth": .enterprise.gloo.solo.io.PassThroughAuth "hmacAuth": .enterprise.gloo.solo.io.HmacAuth "opaServerAuth": .enterprise.gloo.solo.io.OpaServerAuth ``` | Field | Type | Description | | -- | - | -- | | `name` | | optional: used when defining complex boolean logic, if `booleanexpr` is defined below. Also used in logging. If omitted, an automatically generated name will be used (e.g. config0, of the pattern 'config$INDEXIN_CHAIN'). In the case of plugin auth, this field is ignored in favor of the name assigned on the plugin config itself. | | `basicAuth` | | Only one of `basicAuth`, `oauth`, `oauth2`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `oauth` | | Only one of `oauth`, `basicAuth`, `oauth2`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `oauth2` | | Only one of `oauth2`, `basicAuth`, `oauth`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `apiKeyAuth` | | Only one of `apiKeyAuth`, `basicAuth`, `oauth`, `oauth2`, `pluginAuth`, `opaAuth`, `ldap`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `pluginAuth` | | Only one of `pluginAuth`, `basicAuth`, `oauth`, `oauth2`, `apiKeyAuth`, `opaAuth`, `ldap`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `opaAuth` | | Only one of `opaAuth`, `basicAuth`, `oauth`, `oauth2`, `apiKeyAuth`, `pluginAuth`, `ldap`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `ldap` | | Only one of `ldap`, `basicAuth`, `oauth`, `oauth2`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be

| | `jwt` | | This is a "dummy" extauth service which can be used to support multiple auth mechanisms with JWT authentication. If Jwt authentication is to be used in the in an AuthConfig, you can use this auth config type to include Jwt as an Auth config. In addition, `allowmissingorfailedjwt` must be set on the Virtual Host or Route that uses JWT auth or else the JWT filter will short circuit this behaviour. Only one of `jwt`, `basicAuth`, `oauth`, `oauth2`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `passThroughAuth` | | Only one of `passThroughAuth`, `basicAuth`, `oauth`, `oauth2`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `jwt`, `hmacAuth`, or `opaServerAuth` can be set. | | `hmacAuth` | | Only one of `hmacAuth`, `basicAuth`, `oauth`, `oauth2`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `jwt`, `passThroughAuth`, or `opaServerAuth` can be set. | | `opaServerAuth` | | Only one of `opaServerAuth`, `basicAuth`, `oauth`, `oauth2`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `jwt`, `passThroughAuth`, or `hmacAuth` can be set. | Auth configurations defined on virtual hosts, routes, and weighted destinations will be unmarshalled to this message. ```yaml "disable": bool "configRef": .core.solo.io.ResourceRef "customAuth": .enterprise.gloo.solo.io.CustomAuth ``` | Field | Type | Description | | -- | - | -- | | `disable` | `bool` | Set to true to disable auth on the virtual host/route. Only one of `disable`, `configRef`, or `customAuth` can be set. | | `configRef` | | A reference to an AuthConfig. This is used to configure the Gloo Edge Enterprise extauth server. Only one of `configRef`, `disable`, or `customAuth` can be set. | | `customAuth` | | Use this field if you are running your own custom extauth server. Only one of `customAuth`, `disable`, or `configRef` can be set. | Global external auth settings ```yaml "extauthzServerRef": .core.solo.io.ResourceRef "httpService": .enterprise.gloo.solo.io.HttpService "grpcService": .enterprise.gloo.solo.io.GrpcService "userIdHeader": string "requestTimeout": .google.protobuf.Duration "failureModeAllow": bool "requestBody": .enterprise.gloo.solo.io.BufferSettings "clearRouteCache": bool "statusOnError": int "transportApiVersion": .enterprise.gloo.solo.io.Settings.ApiVersion "statPrefix": string ``` | Field | Type | Description | | -- | - | -- | | `extauthzServerRef` | | The upstream to ask about auth decisions. | | `httpService` | | If this is set, communication to the upstream will be via HTTP and not GRPC (default). Only one of `httpService` or `grpcService` can be set. | | `grpcService` | | Optional, if set the communication to the upstream will be via GRPC. Only one of `grpcService` or `httpService` can be set. | | `userIdHeader` | `string` | If the auth server trusted id of the user, it will be set in this header. Specifically this means that this header will be sanitized form the incoming request. | | `requestTimeout` | | Timeout for the ext auth service to respond. Defaults to 200ms. | | `failureModeAllow` | `bool` | In case of a failure or timeout querying the auth server, normally a request is denied. if this is set to true, the request will be allowed. | | `requestBody` | | Set this if you also want to send the body of the request, and not just the headers. | | `clearRouteCache` | `bool` | Clears route cache in order to allow the external authorization service to correctly affect routing decisions. Filter clears all cached routes when: 1. The field is set to true. 2. The status returned from the authorization service is a HTTP 200 or gRPC 0. 3. At least one authorization response header is added to the client request, or is used for altering another client request header. | | `statusOnError` | `int` | Sets the HTTP status that is returned to the client when there is a network error between the filter and the authorization server. The default status is HTTP 403

If set, this must be one of the following: - 100 - 200 201 202 203 204 205 206 207 208 226 - 300 301 302 303 304 305 307 308 - 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 421 422 423 424 426 428 429 431 - 500 501 502 503 504 505 506 507 508 510 511. | | `transportApiVersion` | | Determines the API version for the `extauthz` transport protocol that will be used by Envoy to communicate with the auth server. Defaults to `V2`. For more info, see the `transportapi_version` field . | | `statPrefix` | `string` | Optional additional prefix to use when emitting statistics. This allows to distinguish emitted statistics between configured ext_authz filters in an HTTP filter chain. | Describes the transport protocol version to use when connecting to the ext auth server. | Name | Description | | -- | -- | | `V3` | Use v3 API. | ```yaml "authority": string ``` | Field | Type | Description | | -- | - | -- | | `authority` | `string` | Set the authority header when calling the GRPC service. | ```yaml "pathPrefix": string "request": .enterprise.gloo.solo.io.HttpService.Request "response": .enterprise.gloo.solo.io.HttpService.Response ``` | Field | Type | Description | | -- | - | -- | | `pathPrefix` | `string` | Sets a prefix to the value of authorization request header Path. | | `request` | | | | `response` | | | ```yaml "allowedHeaders": []string "headersToAdd": map<string, string> "allowedHeadersRegex": []string ``` | Field | Type | Description | | -- | - | -- | | `allowedHeaders` | `[]string` | These headers will be copied from the incoming request to the request going to the auth server. Note that in addition to the user's supplied matchers: 1. Host, Method, Path and Content-Length are automatically included to the list. 2. Content-Length will be set to 0 and the request to the authorization service will not have a message body. | | `headersToAdd` | `map<string, string>` | These headers that will be included to the request to authorization service. Note that client request of the same key will be overridden. | | `allowedHeadersRegex` | `[]string` | Headers that match these regex patterns will be copied from the incoming request to the request going to the auth server. | ```yaml "allowedUpstreamHeaders": []string "allowedClientHeaders": []string "allowedUpstreamHeadersToAppend": []string ``` | Field | Type | Description | | -- | - | -- | | `allowedUpstreamHeaders` | `[]string` | When this is set, authorization response headers that have a header in this list will be added to the original client request and sent to the upstream. Note that coexistent headers will be overridden. | | `allowedClientHeaders` | `[]string` | When this is set, authorization response headers in this list will be added to the client's response when the auth request is denied. Note that when this list is not set, all the authorization response headers, except Authority (Host) will be in the response to the client. When a header is included in this list, Path, Status, Content-Length, WWW-Authenticate and Location are automatically added. | | `allowedUpstreamHeadersToAppend` | `[]string` | When this is set, authorization response headers that have a correspondent match will be added to the client's response. Note that coexistent headers will be appended. | Configuration for buffering the request

```yaml "maxRequestBytes": int "allowPartialMessage": bool "packAsBytes": bool ``` | Field | Type | Description | | -- | - | -- | | `maxRequestBytes` | `int` | Sets the maximum size of a message body that the filter will hold in memory. Envoy will return HTTP 413 and will not initiate the authorization process when buffer reaches the number set in this field. Note that this setting will have precedence over failuremodeallow. Defaults to 4KB. | | `allowPartialMessage` | `bool` | When this field is true, Envoy will buffer the message until max_request_bytes is reached. The authorization request will be dispatched and no 413 HTTP error will be returned by the filter. | | `packAsBytes` | `bool` | When this field is true, Envoy will send the body sent to the external authorization service with raw bytes. | Gloo is not expected to configure the ext auth server in this case. This is used with custom auth servers. ```yaml "contextExtensions": map<string, string> "name": string ``` | Field | Type | Description | | -- | - | -- | | `contextExtensions` | `map<string, string>` | When a request matches the virtual host, route, or weighted destination on which this configuration is defined, Gloo will add the given contextextensions to the request that is sent to the external authorization server. This allows the server to base the auth decision on metadata that you define on the source of the request. This attribute is analogous to Envoy's config.filter.http.extauthz.v2.CheckSettings. See the official for more details. | | `name` | `string` | [Enterprise-only] Only required in the case where multiple auth servers are configured in Settings This name must match a key in the named_extauth Settings. | ```yaml "name": string "pluginFileName": string "exportedSymbolName": string "config": .google.protobuf.Struct ``` | Field | Type | Description | | -- | - | -- | | `name` | `string` | Name of the plugin. | | `pluginFileName` | `string` | Name of the compiled plugin file. If not specified, Gloo Edge will look for an ".so" file with same name as the plugin. | | `exportedSymbolName` | `string` | Name of the exported symbol that implements the plugin interface in the plugin. If not specified, defaults to the name of the plugin. | | `config` | | | This is the legacy/simple basic auth config. It supports the APR and SHA-1 hashing algorithms. When using basic auth, requests can pass only one `Authorization` header. You cannot use basic auth config in conjunction with other auth configs that rely on the `Authorization` header as well. In case of such a conflict, use a different type of auth config or configure a different header, such as `X-Auth`. ```yaml "realm": string "apr": .enterprise.gloo.solo.io.BasicAuth.Apr "encryption": .enterprise.gloo.solo.io.BasicAuth.EncryptionType "userList": .enterprise.gloo.solo.io.BasicAuth.UserList ``` | Field | Type | Description | | -- | - | -- | | `realm` | `string` | | | `apr` | | | | `encryption` | | The encryption type to use to store the password on the server If 'encryption' is defined, 'user_source' must be defined and the top level 'apr' field must not be defined or the config will fail validation. | | `userList` | | | If 'apr' is defined, 'encryption' and 'user_source' must not be defined or the config will fail validation ```yaml "users": map<string, .enterprise.gloo.solo.io.BasicAuth.Apr.SaltedHashedPassword> ``` | Field | Type | Description | | -- | - | -- | | `users` | `map<string, .enterprise.gloo.solo.io.BasicAuth.Apr.SaltedHashedPassword>` | Map of authorized usernames to stored credentials. | Message to store the salt and salted hashed password for a user ```yaml "salt": string "hashedPassword": string ``` | Field | Type | Description | | -- | - | -- | | `salt` | `string` | Salt used with the apr algorithm for the

| | `hashedPassword` | `string` | Salted and hashed password for the user. | The encryption/hashing algorithm to use to store the password ```yaml "apr": .enterprise.gloo.solo.io.BasicAuth.EncryptionType.Apr "sha1": .enterprise.gloo.solo.io.BasicAuth.EncryptionType.Sha1 ``` | Field | Type | Description | | -- | - | -- | | `apr` | | Only one of `apr` or `sha1` can be set. | | `sha1` | | Only one of `sha1` or `apr` can be set. | Sha1 encryption type (https://datatracker.ietf.org/doc/html/rfc3174) Sha1 is considered insecure and is not recommended for production use ```yaml ``` | Field | Type | Description | | -- | - | -- | Apache specific iterated MD5 hashing: (https://httpd.apache.org/docs/2.4/misc/password_encryptions.html) ```yaml ``` | Field | Type | Description | | -- | - | -- | Message to store user data. We need the salt and salted hashed password for each user ```yaml "salt": string "hashedPassword": string ``` | Field | Type | Description | | -- | - | -- | | `salt` | `string` | Salt used with the hashing algorithm for the user. | | `hashedPassword` | `string` | Salted and hashed password for the user. | Map of valid usernames to stored credentials ```yaml "users": map<string, .enterprise.gloo.solo.io.BasicAuth.Apr.SaltedHashedPassword> ``` | Field | Type | Description | | -- | - | -- | | `users` | `map<string, .enterprise.gloo.solo.io.BasicAuth.Apr.SaltedHashedPassword>` | | HMAC is a message authentication technique that can use multiple algorithms for finding credentials and generating signed messages. It conforms to https://www.ietf.org/rfc/rfc2104.txt ```yaml "secretRefs": .enterprise.gloo.solo.io.SecretRefList "parametersInHeaders": .enterprise.gloo.solo.io.HmacParametersInHeaders ``` | Field | Type | Description | | -- | - | -- | | `secretRefs` | | | | `parametersInHeaders` | | | ```yaml "secretRefs": []core.solo.io.ResourceRef ``` | Field | Type | Description | | -- | - | -- | | `secretRefs` | | list of secrets as registered with the issuer. | Extract the HMAC parameters from the HTTP headers and use SHA-1 hashing ```yaml ``` | Field | Type | Description | | -- | - | -- | Deprecated: Prefer OAuth2 ```yaml "clientId": string "clientSecretRef": .core.solo.io.ResourceRef "issuerUrl": string "authEndpointQueryParams": map<string, string> "appUrl": string "callbackPath": string "scopes": []string ``` | Field | Type | Description | | -- | - | -- | | `clientId` | `string` | your client id as registered with the issuer. | | `clientSecretRef` | | your client secret as registered with the issuer. | | `issuerUrl` | `string` | The url of the issuer. We will look for OIDC information in issuerUrl+ ".well-known/openid-configuration". | | `authEndpointQueryParams` | `map<string, string>` | extra query parameters to apply to the Ext-Auth service's authorization request to the identity provider. | | `appUrl` | `string` | we to redirect after successful auth, if we can't determine the original url this should be your publicly available app url. | | `callbackPath` | `string` | a callback path relative to app url that will be used for OIDC callbacks. needs to not be used by the application. | | `scopes` | `[]string` | Scopes to request in addition to openid scope. | ```yaml "oidcAuthorizationCode": .enterprise.gloo.solo.io.OidcAuthorizationCode "accessTokenValidation": .enterprise.gloo.solo.io.AccessTokenValidation "oauth2": .enterprise.gloo.solo.io.PlainOAuth2 ``` | Field | Type | Description | | -- | - | -- | | `oidcAuthorizationCode` | | provide issuer location and let gloo handle OIDC flow for you. requests authorized by validating the contents of ID token. can also authorize the access token if configured. Only one of `oidcAuthorizationCode`, `accessTokenValidation`, or `oauth2` can be set. | | `accessTokenValidation` | | provide the access token on the request and let gloo handle authorization. according to

you can pass tokens through: - form-encoded body parameter. recommended, more likely to appear. e.g.: Authorization: Bearer mytoken123 - URI query parameter e.g. access_token=mytoken123 - and (preferably) secure cookies. Only one of `accessTokenValidation`, `oidcAuthorizationCode`, or `oauth2` can be set. | | `oauth2` | | Enterprise-Only: THIS FEATURE IS IN TECH PREVIEW. APIs are versioned as alpha and subject to change. provide issuer location and let Gloo handle Oauth2 flow for you. requests authorized by validating the contents of access token. Prefer to use OIDC for better security. Only one of `oauth2`, `oidcAuthorizationCode`, or `accessTokenValidation` can be set. | ```yaml "host": string "db": int "poolSize": int "tlsCertMountPath": string "socketType": .enterprise.gloo.solo.io.RedisOptions.SocketType ``` | Field | Type | Description | | -- | - | -- | | `host` | `string` | address of the redis. can be address:port or unix://path/to/unix.sock. | | `db` | `int` | db to use. can leave unset for db 0. | | `poolSize` | `int` | size of the connection pool. can leave unset for default. defaults to 10 connections per every CPU. | | `tlsCertMountPath` | `string` | enabled with a socket type of TLS. this is the tls cert mount path for this particular host. the generic secret can include the keys 'ca.crt', 'tls.crt', and 'tls.key'. the secret can contain the root-ca ,'ca.crt', at minimum. If a certificate is needed, both the 'tls.crt' and 'tls.key' need to be included. reference this to equal the 'mountPath' on the 'redis.certs[x].mountPath' in the helm chart values. an example of a mount path is '/certs'. | | `socketType` | | the socket type, default is TCP. | redis socket types | Name | Description | | -- | -- | | `TCP` | TCP connection socket, this is the default. | | `TLS` | TLS connection socket. | ```yaml "failOnFetchFailure": bool "cookieOptions": .enterprise.gloo.solo.io.UserSession.CookieOptions "cookie": .enterprise.gloo.solo.io.UserSession.InternalSession "redis": .enterprise.gloo.solo.io.UserSession.RedisSession "cipherConfig": .enterprise.gloo.solo.io.UserSession.CipherConfig ``` | Field | Type | Description | | -- | - | -- | | `failOnFetchFailure` | `bool` | should we fail auth flow when failing to get a session from redis, or allow it to continue, potentially starting a new auth flow and setting a new session. | | `cookieOptions` | | Set-Cookie options. | | `cookie` | | Set the tokens in the cookie itself. No need for server side state. Only one of `cookie` or `redis` can be set. | | `redis` | | Use redis to store the tokens and just store a random id in the cookie. Only one of `redis` or `cookie` can be set. | | `cipherConfig` | | the cipher config enables the symmetric key encryption of the cookie values of the user session. | ```yaml "allowRefreshing": .google.protobuf.BoolValue "keyPrefix": string "targetDomain": string ``` | Field | Type | Description | | -- | - | -- | | `allowRefreshing` | | Refresh expired id-tokens using the refresh-token. The tokens refreshes when the client issues a call. Defaults to false. To enable refreshing, set to true. | | `keyPrefix` | `string` | Prefix to append to cookie keys, such as for separate domain and subdomain prefixes. Cookie keys are stored in the form `<keyprefix><cookie_name>`. For more information, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#attributes. | | `targetDomain` | `string` | Domain used to validate against requests in order to ensure that request host name matches target domain. If the target domain is provided will prevent requests that do not match the target domain according to the domain matching specifications in RFC 6265. For more information, see https://datatracker.ietf.org/doc/html/rfc6265#section-5.1.3. | ```yaml "options": .enterprise.gloo.solo.io.RedisOptions "keyPrefix": string "cookieName": string "allowRefreshing": .google.protobuf.BoolValue "preExpiryBuffer":

"targetDomain": string "headerName": string ``` | Field | Type | Description | | -- | - | -- | | `options` | | Options to connect to redis. | | `keyPrefix` | `string` | Key prefix inside redis. | | `cookieName` | `string` | Cookie name to set and store the session id. If empty the default "session" is used. | | `allowRefreshing` | | Refresh expired id-tokens using the refresh-token. The tokens refreshes when the client issues a call. Defaults to true. To disable refreshing, set to false. | | `preExpiryBuffer` | | Specifies a time buffer in which an id-token will be refreshed prior to its actual expiration. Defaults to 2 seconds. A duration of 0 will only refresh tokens after they have already expired. To refresh tokens, you must also set 'allowRefreshing' to 'true'; otherwise, this field is ignored. | | `targetDomain` | `string` | Domain used to validate against requests in order to ensure that request host name matches target domain. If the target domain is provided will prevent requests that do not match the target domain according to the domain matching specifications in RFC 6265. For more information, see https://datatracker.ietf.org/doc/html/rfc6265#section-5.1.3. | | `headerName` | `string` | If set, the name of the header that will include the randomly generated session id This would be used as part of the code exchange with the Oauth2 token endpoint. | ```yaml "maxAge": .google.protobuf.UInt32Value "notSecure": bool "httpOnly": .google.protobuf.BoolValue "path": .google.protobuf.StringValue "sameSite": .enterprise.gloo.solo.io.UserSession.CookieOptions.SameSite "domain": string ``` | Field | Type | Description | | -- | - | -- | | `maxAge` | | Max age for the cookie. Leave unset for a default of 30 days (2592000 seconds). To disable cookie expiry, set explicitly to 0. | | `notSecure` | `bool` | Use a non-secure cookie. Note - this should only be used for testing and in trusted environments. | | `httpOnly` | | Set the cookie to be HttpOnly. defaults to true. Set explicity to false to disable. | | `path` | | Path of the cookie. If unset, defaults to "/". Set it explicitly to "" to avoid setting a path. | | `sameSite` | | Whether the cookie should be restricted to a first-party or same-site context. The default mode is LaxMode. | | `domain` | `string` | Cookie domain. | The SameSite options. The default value is LaxMode. | Name | Description | | -- | -- | | `DefaultMode` | Default Mode is the same as LaxMode but will not show up in the Cookie Header. This value is ignored. | | `LaxMode` | Cookies are not sent on normal cross-site subrequests, but are sent when navigating to the origin site. | | `StrictMode` | Only be sent in a first-party context and not be sent along with requests initiated by third party websites. | | `NoneMode` | Cookies are sent in all contexts. Cookie NotSecure must be unset. | the cipher config is used to encrypt session cookie values. This is currently only available for OIDC. ```yaml "keyRef": .core.solo.io.ResourceRef ``` | Field | Type | Description | | -- | - | -- | | `keyRef` | | The key reference used for the cipher. The reference must be a Kubernetes Secret of type `gloo.solo.io.EncryptionKeySecret`. | ```yaml "idTokenHeader": string "accessTokenHeader": string "useBearerSchemaForAuthorization": .google.protobuf.BoolValue ``` | Field | Type | Description | | -- | - | -- | | `idTokenHeader` | `string` | If set, the id token will be forward upstream using this header name. | | `accessTokenHeader` | `string` | If set, the access token will be forward upstream using this header

| | `useBearerSchemaForAuthorization` | | If true, adds the "Bearer" prefix to the upstream access token header value. | OIDC configuration is discovered at <issuerUrl>/.well-known/openid-configuration The discovery override defines any properties that should override this discovery configuration https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata ```yaml "authEndpoint": string "tokenEndpoint": string "jwksUri": string "scopes": []string "responseTypes": []string "subjects": []string "idTokenAlgs": []string "authMethods": []string "claims": []string "revocationEndpoint": string "endSessionEndpoint": string ``` | Field | Type | Description | | -- | - | -- | | `authEndpoint` | `string` | url of the provider authorization endpoint. | | `tokenEndpoint` | `string` | url of the provider token endpoint. | | `jwksUri` | `string` | url of the provider json web key set. | | `scopes` | `[]string` | list of scope values that the provider supports. | | `responseTypes` | `[]string` | list of response types that the provider supports. | | `subjects` | `[]string` | list of subject identifier types that the provider supports. | | `idTokenAlgs` | `[]string` | list of json web signature signing algorithms that the provider supports for encoding claims in a jwt. | | `authMethods` | `[]string` | list of client authentication methods supported by the provider token endpoint. | | `claims` | `[]string` | list of claim types that the provider supports. | | `revocationEndpoint` | `string` | url of the provider token revocation endpoint. | | `endSessionEndpoint` | `string` | url of the provider end session endpoint. | The json web key set (JWKS) (https://tools.ietf.org/html/rfc7517) is discovered at an interval from a remote source. When keys rotate in the remote source, there may be a delay in the local source picking up those new keys. Therefore, a user could execute a request with a token that has been signed by a key in the remote JWKS, but the local cache doesn't have the key yet. The request would fail because the key isn't contained in the local set. Since most IdPs publish key keys in their remote JWKS before they are used, this is not an issue most of the time. This policy lets you define the behavior for when a user has a token with a key not yet in the local cache. ```yaml "never": .google.protobuf.Empty "always": .google.protobuf.Empty "maxIdpReqPerPollingInterval": int ``` | Field | Type | Description | | -- | - | -- | | `never` | | Never refresh the local JWKS cache on demand. If a key is not in the cache, it is assumed to be malicious. This is the default policy since we assume that IdPs publish keys before they rotate them, and frequent polling finds the newest keys. Only one of `never`, `always`, or `maxIdpReqPerPollingInterval` can be set. | | `always` | | If a key is not in the cache, fetch the most recent keys from the IdP and update the cache. NOTE: This should only be done in trusted environments, since missing keys will each trigger a request to the IdP. Using this in an environment exposed to the internet will allow malicious agents to execute a DDoS attack by spamming protected endpoints with tokens signed by invalid keys. Only one of `always`, `never`, or `maxIdpReqPerPollingInterval` can be set. | | `maxIdpReqPerPollingInterval` | `int` | If a key is not in the cache, fetch the most recent keys from the IdP and update the cache. This value sets the number of requests to the IdP per polling interval. If that limit is exceeded, we will stop fetching from the IdP for the remainder of the polling

Only one of `maxIdpReqPerPollingInterval`, `never`, or `always` can be set. | ```yaml "namespace": string ``` | Field | Type | Description | | -- | - | -- | | `namespace` | `string` | The namespace from which to map metadata. | ```yaml "methodType": .enterprise.gloo.solo.io.EndSessionProperties.MethodType ``` | Field | Type | Description | | -- | - | -- | | `methodType` | | The method type used by the end session endpoint, defaults to GET. | The Method used to make the request. | Name | Description | | -- | -- | | `GetMethod` | Uses GET method when making the request | | `PostMethod` | Uses POST method when making the request | Map a single claim from an OAuth2 or OIDC token to a header in the request to the upstream destination. ```yaml "claim": string "header": string "append": bool ``` | Field | Type | Description | | -- | - | -- | | `claim` | `string` | The claim name from the token, such as `sub`. | | `header` | `string` | The header to copy the claim to, such as `x-sub`. | | `append` | `bool` | If the header exists, append the claim value to the header (true), or overwrite any existing value (false). The default behavior is to overwrite any existing value (false). | ```yaml "clientId": string "clientSecretRef": .core.solo.io.ResourceRef "issuerUrl": string "authEndpointQueryParams": map<string, string> "tokenEndpointQueryParams": map<string, string> "appUrl": string "callbackPath": string "logoutPath": string "afterLogoutUrl": string "scopes": []string "session": .enterprise.gloo.solo.io.UserSession "headers": .enterprise.gloo.solo.io.HeaderConfiguration "discoveryOverride": .enterprise.gloo.solo.io.DiscoveryOverride "discoveryPollInterval": .google.protobuf.Duration "jwksCacheRefreshPolicy": .enterprise.gloo.solo.io.JwksOnDemandCacheRefreshPolicy "sessionIdHeaderName": string "parseCallbackPathAsRegex": bool "autoMapFromMetadata": .enterprise.gloo.solo.io.AutoMapFromMetadata "endSessionProperties": .enterprise.gloo.solo.io.EndSessionProperties "dynamicMetadataFromClaims": map<string, string> "disableClientSecret": .google.protobuf.BoolValue "accessToken": .enterprise.gloo.solo.io.OidcAuthorizationCode.AccessToken "identityToken": .enterprise.gloo.solo.io.OidcAuthorizationCode.IdentityToken "clientAuthentication": .enterprise.gloo.solo.io.OidcAuthorizationCode.ClientAuthentication "default": .enterprise.gloo.solo.io.OidcAuthorizationCode.Default "azure": .enterprise.gloo.solo.io.OidcAuthorizationCode.Azure ``` | Field | Type | Description | | -- | - | -- | | `clientId` | `string` | your client id as registered with the issuer. | | `clientSecretRef` | | your client secret as registered with the issuer. This is required unless `disableclientsecret` is true This field has been deprecated and can be set in the clientsecret option of clientauthentication. | | `issuerUrl` | `string` | The url of the issuer. We will look for OIDC information in issuerUrl+ ".well-known/openid-configuration". | | `authEndpointQueryParams` | `map<string, string>` | extra query parameters to apply to the Ext-Auth service's authorization request to the identity provider. this can be useful for flows such as PKCE (https://www.oauth.com/oauth2-servers/pkce/authorization-request/) to set the `codechallenge` and `codechallenge_method`. | | `tokenEndpointQueryParams` | `map<string, string>` | extra query parameters to apply to the Ext-Auth service's token request to the identity provider. this can be useful for flows such as PKCE (https://www.oauth.com/oauth2-servers/pkce/authorization-request/) to set the `code_verifier`. | | `appUrl` | `string` | where to redirect after successful auth, if we can't determine the original url. this should be your publicly available app url. | | `callbackPath` | `string` | a callback path relative to app url that will be used for OIDC callbacks. should not be used by the application. | | `logoutPath` | `string` | a path relative to app url that will be used for logging out from an OIDC session. should not be used by the application. If not provided, logout functionality will be disabled. | | `afterLogoutUrl` | `string` | url to redirect to after logout. This should be a publicly available URL. If not provided, will default to the `app_url`. | | `scopes` | `[]string` | Scopes to request in addition to openid scope. | | `session` | | Configuration related to the user session. | | `headers` | | Configures headers added to requests. | | `discoveryOverride` | | OIDC configuration is discovered at

The discovery override defines any properties that should override this discovery configuration For example, the following AuthConfig CRD could be defined as: ```yaml apiVersion: enterprise.gloo.solo.io/v1 kind: AuthConfig metadata: name: google-oidc namespace: gloo-system spec: configs: - oauth: appurl: http://localhost:8080 callbackpath: /callback clientid: $CLIENTID clientsecretref: name: google namespace: gloo-system issuerurl: https://accounts.google.com discoveryoverride: token_endpoint: "https://token.url/gettoken" ``` And this will ensure that regardless of what value is discovered at <issuerUrl>/.well-known/openid-configuration, "https://token.url/gettoken" will be used as the token endpoint. | | `discoveryPollInterval` | | The interval at which OIDC configuration is discovered at <issuerUrl>/.well-known/openid-configuration If not specified, the default value is 30 minutes. | | `jwksCacheRefreshPolicy` | | If a user executes a request with a key that is not found in the JWKS, it could be that the keys have rotated on the remote source, and not yet in the local cache. This policy lets you define the behavior for how to refresh the local cache during a request where an invalid key is provided. | | `sessionIdHeaderName` | `string` | DEPRECATED: Prefer the RedisSession.HeaderName field If set, the randomly generated session id will be sent to the token endpoint as part of the code exchange The session id is used as the key for sessions in Redis. | | `parseCallbackPathAsRegex` | `bool` | If set, CallbackPath will be evaluated as a regular expression. | | `autoMapFromMetadata` | | If specified, authEndpointQueryParams and tokenEndpointQueryParams will be populated using dynamic metadata values. By default parameters will be extracted from the soloauthconfigoidc namespace this behavior can be overridden by explicitly specifying a namespace. | | `endSessionProperties` | | If specified, these are properties defined for the end session endpoint specifications. Noted in the OIDC documentation. | | `dynamicMetadataFromClaims` | `map<string, string>` | Map of metadata key to claim. Ie: dynamicmetadatafromclaims: issuer: iss email: email When specified, the matching claims from the ID token will be emitted as dynamic metadata. Note that metadata keys must be unique, and the claim names must be alphanumeric and use `-` or `` as separators. The metadata will live in a namespace specified by the canonical name of the ext auth filter (in our case `envoy.filters.http.ext_authz`), and the structure of the claim value will be preserved in the metadata struct. | | `disableClientSecret` | | If true, do not check for or use the client secret. Generally the client secret is required and AuthConfigs will be rejected if it isn't set. However certain implementations of the PKCE flow do not use a client secret (including Okta) so this setting allows configuring Oidc without a client secret. This field has been deprecated and can be set in the clientsecret option of clientauthentication. | | `accessToken` | | Optional: Configuration specific to the OAuth2 access token received and processed by the ext-auth-service. | | `identityToken` | | Optional: Configuration specific to the OIDC identity token received and processed by the ext-auth-service. | | `clientAuthentication` | | | | `default` | | Only one of `default` or `azure` can be set. | | `azure` | | Only one of `azure` or `default` can be set. | Optional: Map a single claim from an OAuth2 access token to a header in the request to the upstream destination. Gloo Mesh products only: Note that if you want to clear the route cache to force the proxy to recalculate the routing destination after adding the claims, you must create an additional JwtPolicy or TransformationPolicy, and configure the `clearRouteCache` or `recalculateRoutingDestination` options. ```yaml "claimsToHeaders":

``` | Field | Type | Description | | -- | - | -- | | `claimsToHeaders` | | A list of claims to be mapped from the JWT token received by ext-auth-service to an upstream destination. | Optional: Map a single claim from an OIDC identity token to a header in the request to the upstream destination. ```yaml "claimsToHeaders": []enterprise.gloo.solo.io.ClaimToHeader ``` | Field | Type | Description | | -- | - | -- | | `claimsToHeaders` | | A list of claims to be mapped from the JWT token received by ext-auth-service to an upstream destination. | Configuration specific to the client authentication type used to exchange the access code for the access and id tokens. ```yaml "clientSecret": .enterprise.gloo.solo.io.OidcAuthorizationCode.ClientAuthentication.ClientSecret "privateKeyJwt": .enterprise.gloo.solo.io.OidcAuthorizationCode.ClientAuthentication.PrivateKeyJwt ``` | Field | Type | Description | | -- | - | -- | | `clientSecret` | | Use the client secret method to authenticate the client. Only one of `clientSecret` or `privateKeyJwt` can be set. | | `privateKeyJwt` | | Use the private ket JWT method to authenticate the client. Only one of `privateKeyJwt` or `clientSecret` can be set. | Client Secret Authentication requires a client secret (unless it is disabled) ```yaml "clientSecretRef": .core.solo.io.ResourceRef "disableClientSecret": .google.protobuf.BoolValue ``` | Field | Type | Description | | -- | - | -- | | `clientSecretRef` | | your client secret as registered with the issuer. This is required unless `disableclientsecret` is true. | | `disableClientSecret` | | If true, do not check for or use the client secret. Generally the client secret is required and AuthConfigs will be rejected if it isn't set. However certain implementations of the PKCE flow do not use a client secret (including Okta) so this setting allows configuring Oidc without a client secret. | Private Key JWT Authentication requires a signing key for the JWT and an duration for the JWT to be valid. ```yaml "signingKeyRef": .core.solo.io.ResourceRef "validFor": .google.protobuf.Duration ``` | Field | Type | Description | | -- | - | -- | | `signingKeyRef` | | Signing key for the JWT used to authenticate the client. | | `validFor` | | Amount of time for which the JWT is valid. No maximmum is enforced, but different IDPs may impose limits on how far in the future the expiration time is allowed to be. If omitted, default is 5s. | No-op, represents default OIDC behavior ```yaml ``` | Field | Type | Description | | -- | - | -- | For apps in Microsoft Azure, configure Microsoft Entra ID as the OpenID Connect (OIDC) provider. This way, you can enable distibuted claims and caching for when users are members of more than 200 groups. ```yaml "clientId": string "tenantId": string "clientSecret": .core.solo.io.ResourceRef "claimsCachingOptions": .enterprise.gloo.solo.io.RedisOptions ``` | Field | Type | Description | | -- | - | -- | | `clientId` | `string` | The client ID for the ExtAuthService app that is registered in MS Entra, to access the Microsoft Graph API to retrieve distributed claims. This app is NOT the app that you want to configure external auth for. | | `tenantId` | `string` | The tenant ID represents the MS Entra organization ID where the ExtAuthService app is registered. This tenant ID may or may not be the same as in the top level `OidcAuthorizationCodeConfig`, depending on how your Azure account is provisioned. | | `clientSecret` | | The client secret of the ExtAuthService app that is registered with MS Entra to communciate with the MS Graph API. | | `claimsCachingOptions` | | Redis connection details to cache MS Entera claims. This way, you avoid performance issues of accessing the Microsoft Graph API too many

Note that this setting does NOT turn on Redis caching for the user session. To turn on Redis user session caching, use the `userSessionConfig` field. | ```yaml "clientId": string "clientSecretRef": .core.solo.io.ResourceRef "authEndpointQueryParams": map<string, string> "appUrl": string "callbackPath": string "scopes": []string "session": .enterprise.gloo.solo.io.UserSession "logoutPath": string "tokenEndpointQueryParams": map<string, string> "afterLogoutUrl": string "authEndpoint": string "tokenEndpoint": string "revocationEndpoint": string "disableClientSecret": .google.protobuf.BoolValue ``` | Field | Type | Description | | -- | - | -- | | `clientId` | `string` | Your client ID as registered with the issuer. | | `clientSecretRef` | | Your client secret as registered with the issuer. This is required unless `disableclientsecret` is set. | | `authEndpointQueryParams` | `map<string, string>` | Extra query parameters to apply to the Ext-Auth service's authorization request to the identity provider. These parameters can be useful for flows such as to set the `codechallenge` and `codechallenge_method`. | | `appUrl` | `string` | Where to redirect after successful auth, if Gloo can't determine the original URL. Set this field to your publicly available app URL. | | `callbackPath` | `string` | A callback path relative to the app URL to be used for OAuth2 callbacks. Do not use this path in the application itself. | | `scopes` | `[]string` | Scopes to request for. | | `session` | | Configuration related to the user session. | | `logoutPath` | `string` | A path relative to the app URL to use for logging out from an OAuth2 session. Do not use this path in the application itself. If not provided, logout functionality is disabled. | | `tokenEndpointQueryParams` | `map<string, string>` | Extra query parameters to apply to the Ext-Auth service's token request to the identity provider. These parameters can be useful for flows such as to set the `code_verifier`. | | `afterLogoutUrl` | `string` | URL to redirect to after logout. Set this field to a publicly available URL. If not provided, this value defaults to the `app_url` value. | | `authEndpoint` | `string` | The URL of the provider authorization endpoint. | | `tokenEndpoint` | `string` | The URL of the provider token endpoint. | | `revocationEndpoint` | `string` | The URL of the provider token revocation endpoint. For more information, refer to https://www.rfc-editor.org/rfc/rfc7009. | | `disableClientSecret` | | If true, do not check for or use the client secret. Generally the client secret is required and AuthConfigs will be rejected if it isn't set. However certain implementations of the PKCE flow do not use a client secret (including Okta) so this setting allows configuring Oauth2 without a client secret. | Defines how JSON Web Token (JWT) access tokens are validated. Tokens are validated using a JSON Web Key Set (as defined in ), which can be either inlined in the configuration or fetched from a remote location via HTTP. Any keys in the JWKS that are not intended for signature verification (i.e. whose is not "sig") will be ignored by the system, as will keys that do not specify a . The JWT to be validated must define non-empty "kid" and "alg" headers. The "kid" header determines which key in the JWKS will be used to verify the signature of the token; if no matching key is found, the token will be rejected. If present, the server will verify the "exp", "iat", and "nbf" standard JWT claims. Validation of the "iss" claim and of token scopes can be configured as well. If the JWT has been successfully validated, its set of claims will be added to the `AuthorizationRequest` state under the "jwtAccessToken" key. ```yaml "remoteJwks": .enterprise.gloo.solo.io.JwtValidation.RemoteJwks "localJwks":

"issuer": string ``` | Field | Type | Description | | -- | - | -- | | `remoteJwks` | | Fetches the JWKS from a remote location. Only one of `remoteJwks` or `localJwks` can be set. | | `localJwks` | | Loads the JWKS from a local data source. Only one of `localJwks` or `remoteJwks` can be set. | | `issuer` | `string` | Allow only tokens that have been issued by this principal (i.e. whose "iss" claim matches this value). If empty, issuer validation will be skipped. | Specifies how to fetch JWKS from remote and how to cache it. ```yaml "url": string "refreshInterval": .google.protobuf.Duration ``` | Field | Type | Description | | -- | - | -- | | `url` | `string` | The HTTP URI to fetch the JWKS. | | `refreshInterval` | | The frequency at which the JWKS should be refreshed. If not specified, the default value is 5 minutes. | Represents a locally available JWKS. ```yaml "inlineString": string ``` | Field | Type | Description | | -- | - | -- | | `inlineString` | `string` | JWKS is embedded as a string. | Defines how (opaque) access tokens, received from the oauth authorization endpoint, are validated If the token introspection url requires client authentication, both the clientid and clientsecret are required. Unless disableclientsecret is set, when only one is provided, the config will be rejected. These values will be encoded in a basic auth header in order to authenticate the client. ```yaml "introspectionUrl": string "clientId": string "clientSecretRef": .core.solo.io.ResourceRef "userIdAttributeName": string "disableClientSecret": .google.protobuf.BoolValue ``` | Field | Type | Description | | -- | - | -- | | `introspectionUrl` | `string` | The URL for the endpoint. If provided, the (opaque) access token provided or received from the oauth authorization endpoint will be validated against this endpoint, or locally cached responses for this access token. | | `clientId` | `string` | Your client id as registered with the issuer. Optional: Use if the token introspection url requires client authentication. | | `clientSecretRef` | | Your client secret as registered with the issuer. Optional: Use if the token introspection url requires client authentication. | | `userIdAttributeName` | `string` | The name of the attribute that contains the ID of the resource owner (e.g. `sub`, `username`). If specified, the external auth server will use the value of the attribute as the identifier of the authenticated user and add it to the request headers and/or dynamic metadata (depending on how the server is configured); if the field is set and the attribute cannot be found, the request will be denied. This field is optional and by default the server will not try to derive the user ID. | | `disableClientSecret` | | Allows setting a client id but not a client secret. | ```yaml "introspectionUrl": string "jwt": .enterprise.gloo.solo.io.JwtValidation "introspection": .enterprise.gloo.solo.io.IntrospectionValidation "userinfoUrl": string "cacheTimeout": .google.protobuf.Duration "requiredScopes": .enterprise.gloo.solo.io.AccessTokenValidation.ScopeList "dynamicMetadataFromClaims": map<string, string> ``` | Field | Type | Description | | -- | - | -- | | `introspectionUrl` | `string` | The URL for the endpoint. If provided, the (opaque) access token provided or received from the oauth authorization endpoint will be validated against this endpoint, or locally cached responses for this access token. This field is deprecated as it does not support authenticated introspection requests. Only one of `introspectionUrl`, `jwt`, or `introspection` can be set. | | `jwt` | | Validate access tokens that conform to the specification. Only one of `jwt`, `introspectionUrl`, or `introspection` can be

| | `introspection` | | Defines how (opaque) access tokens, received from the oauth authorization endpoint, are validated specification. Only one of `introspection`, `introspectionUrl`, or `jwt` can be set. | | `userinfoUrl` | `string` | The URL for the OIDC userinfo endpoint. If provided, the (opaque) access token provided or received from the oauth endpoint will be queried and the userinfo response (or cached response) will be added to the `AuthorizationRequest` state under the "introspection" key. This can be useful to leverage the userinfo response in, for example, an external auth server plugin. | | `cacheTimeout` | | How long the token introspection and userinfo endpoint response for a specific access token should be kept in the in-memory cache. The result will be invalidated at this timeout, or at "exp" time from the introspection result, whichever comes sooner. If omitted, defaults to 10 minutes. If zero, then no caching will be done. | | `requiredScopes` | | Require access token to have all of the scopes in the given list. This configuration applies to both opaque and JWT tokens. In the case of opaque tokens, this will check the scopes returned in the "scope" member of introspection response (as described in . In case of JWTs the scopes to be validated are expected to be contained in the "scope" claim of the token in the form of a space-separated string. Omitting this field means that scope validation will be skipped. | | `dynamicMetadataFromClaims` | `map<string, string>` | Map of metadata key to claim. Ie: dynamicmetadatafromclaims: issuer: iss email: email When specified, the matching claims from the access token will be emitted as dynamic metadata. Note that metadata keys must be unique, and the claim names must be alphanumeric and use `-` or `` as separators. Works when the access token is a JWT or when the access token is opaque, in which case the claims will refer to field in the response from the token introspection endpoint. The metadata will live in a namespace specified by the canonical name of the ext auth filter (in our case `envoy.filters.http.ext_authz`), and the structure of the claim value will be preserved in the metadata struct. | ```yaml "scope": []string ``` | Field | Type | Description | | -- | - | -- | | `scope` | `[]string` | | ```yaml "clientSecret": string ``` | Field | Type | Description | | -- | - | -- | | `clientSecret` | `string` | | Defines how API keys are validated. When the provided API key token has been successfully validated, it's token will be added to the `AuthorizationRequest` state under the "apikeyvalue" key name. ```yaml "labelSelector": map<string, string> "apiKeySecretRefs": []core.solo.io.ResourceRef "headerName": string "headersFromMetadata": map<string, .enterprise.gloo.solo.io.ApiKeyAuth.SecretKey> "headersFromMetadataEntry": map<string, map<string, bool>> "k8SSecretApikeyStorage": .enterprise.gloo.solo.io.K8sSecretApiKeyStorage "aerospikeApikeyStorage": .enterprise.gloo.solo.io.AerospikeApiKeyStorage ``` | Field | Type | Description | | -- | - | -- | | `labelSelector` | `map<string, string>` | DEPRECATED: use K8sSecretApiKeyStorage to configure secrets storage backend. Values here will be overwritten if values are specified in the storage backend. Identify all valid API key secrets that match the provided label selector. API key secrets must be in one of the watch namespaces for gloo to locate them. | | `apiKeySecretRefs` | | DEPRECATED: use K8sSecretApiKeyStorage to configure secrets storage backend. Values here will be overwritten if values are specified in the storage backend. A way to directly reference API key secrets. This configuration can be useful for testing, but in general the more flexible label selector should be

| | `headerName` | `string` | When receiving a request, the Gloo Edge Enterprise external auth server will look for an API key in a header with this name. This field is optional; if not provided it defaults to `api-key`. | | `headersFromMetadata` | `map<string, .enterprise.gloo.solo.io.ApiKeyAuth.SecretKey>` | DEPRECATED: use headersfrommetadata_entry. | | `headersFromMetadataEntry` | `map<string, map<string, bool>>` | API key structures might contain additional data (e.g. the ID of the user that the API key belongs to) in the form of extra fields included in the API key metadata structure. This configuration can be used to add this data to the headers of successfully authenticated requests. Each key in the map represents the name of header to be added; the corresponding value determines the key in the API key metadata structure that will be inspected to determine the value for the header. When the provided API key token has been successfully validated, and this field has been configured, then any extra API key metadata fields that were able to be discovered will be added to the `AuthorizationRequest` state under the key name that was configured. For example, using the `x-user-name` string as the header name, and referencing an existing "user-email" API key metadata entry will result in the value of this "user-email" metadata entry being accessable in other auth modules in the `AuthorizationRequest.State["x-user-name"]` key. This behavior allows other modules (e.g. OPA) to build more powerful rules to further validate the contents of the extra API key metadata than what's possible using the standalone API key module. | | `k8SSecretApikeyStorage` | | Only one of `k8sSecretApikeyStorage` or `aerospikeApikeyStorage` can be set. | | `aerospikeApikeyStorage` | | Only one of `aerospikeApikeyStorage` or `k8sSecretApikeyStorage` can be set. | DEPRECATED: use generalized MetadataEntry ```yaml "name": string "required": bool ``` | Field | Type | Description | | -- | - | -- | | `name` | `string` | DEPRECATED (Required) The key of the API key metadata entry to inspect. | | `required` | `bool` | DEPRECATED If this field is set to `true`, Gloo will reject an API key structure that does not contain data for the given key. Defaults to `false`. In this case, if an API key structure does not contain the requested data, no header will be added to the request. | For the K8s secret backend, this data is stored as key-value data in the secret itself. For the Aerospike backend, this data is stored as bins on the key's record ```yaml "name": string "required": bool ``` | Field | Type | Description | | -- | - | -- | | `name` | `string` | (Required) The key of the API key metadata entry to inspect. | | `required` | `bool` | If this field is set to `true`, Gloo will reject an API key structure that does not contain data for the given key. Defaults to `false`. In this case, if an API key structure does not contain the requested data, no header will be added to the request. | ```yaml "labelSelector": map<string, string> "apiKeySecretRefs": []core.solo.io.ResourceRef ``` | Field | Type | Description | | -- | - | -- | | `labelSelector` | `map<string, string>` | Identify all valid API key secrets that match the provided label selector.<br/> API key secrets must be in one of the watch namespaces for gloo to locate them. | | `apiKeySecretRefs` | | A way to directly reference API key secrets. This configuration can be useful for testing, but in general the more flexible label selector should be preferred. | ```yaml "hostname": string "namespace": string "set": string "port": int "batchSize": int "commitAll": int "commitMaster": int "readModeSc": .enterprise.gloo.solo.io.AerospikeApiKeyStorage.readModeSc "readModeAp":

"nodeTlsName": string "certPath": string "keyPath": string "allowInsecure": bool "rootCaPath": string "tlsVersion": string "tlsCurveGroups": []enterprise.gloo.solo.io.AerospikeApiKeyStorage.tlsCurveID "labelSelector": map<string, string> ``` | Field | Type | Description | | -- | - | -- | | `hostname` | `string` | The IP address or hostname of one of the cluster members of your Aerospike database. The address must be reachable from Gloo Edge, such as in a virtual machine with a public IP address or in a pod in the cluster. The client automatically discovers other members of the cluster after establishing a connection. | | `namespace` | `string` | The Aerospike namespace of the database. Defaults to "solo-namespace". | | `set` | `string` | The Aerospike set to use for storage of API keys. Defaults to "apikeys". | | `port` | `int` | The port on which to connect to the Aerospike server. Defaults to 3000. | | `batchSize` | `int` | The size of the batch, which is the number of keys sent in the request. Defaults to 5000. | | `commitAll` | `int` | "commit_all" indicates that the server waits until successfully committing the master and all replicas. Only one of `commitAll` or `commitMaster` can be set. | | `commitMaster` | `int` | "commit_master" indicates that the server waits until successfully committing the master only. Only one of `commitMaster` or `commitAll` can be set. | | `readModeSc` | | The read settings for strong consistency (SC). For possible values, see the . Defaults to "readmodesc_session". | | `readModeAp` | | The read settings for availability (AP). For possible values, see the . Defaults to "readmodeap_one". | | `nodeTlsName` | `string` | TLS settings to enable mutual TLS (mTLS) on the server side. These configuration options must match what you configured in your Aerospike setup. For more information, see the Aerospike and guides. The subject name of the TLS authority. For more information, see the . | | `certPath` | `string` | The path to the TLS certfiicate. | | `keyPath` | `string` | The path to the key. | | `allowInsecure` | `bool` | The TLS insecure setting. If set to `true`, the authority of the certificate on the client's end is not authenticated. You might use insecure mode in non-production environments when the certificate is not known. | | `rootCaPath` | `string` | If the root certificate authority (CA) is not set, add the system certs by default. | | `tlsVersion` | `string` | The TLS version. Versions 1.0, 1.1, 1.2, and 1.3 are supported. Defaults to 1.3. | | `tlsCurveGroups` | | The TLS identifier for an elliptic curve. For more information, see . | | `labelSelector` | `map<string, string>` | Identify the set of required labels (key/value) which an Aerospike secret must contain If a secret contains the provided set of labels, it will be considered valid when authorizing an ApiKey provided in a request. | ```yaml "readModeScSession": int "readModeScLinearize": int "readModeScReplica": int "readModeScAllowUnavailable": int ``` | Field | Type | Description | | -- | - | -- | | `readModeScSession` | `int` | The session ensures this client sees only an increasing sequence of record versions. Server reads only from master, which is the default. Only one of `readModeScSession`, `readModeScLinearize`, `readModeScReplica`, or `readModeScAllowUnavailable` can be set. | | `readModeScLinearize` | `int` | "linearize" ensures that ALL clients see only an increasing sequence of record versions. "server" reads only from master. Only one of `readModeScLinearize`, `readModeScSession`, `readModeScReplica`, or `readModeScAllowUnavailable` can be set. | | `readModeScReplica` | `int` | "replica" indicates that the server can read from master or any full (non-migrating)

An increasing sequence of record versions is not guaranteed. Only one of `readModeScReplica`, `readModeScSession`, `readModeScLinearize`, or `readModeScAllowUnavailable` can be set. | | `readModeScAllowUnavailable` | `int` | "allow_unavailable" indicates that the server can read from master or any full (non-migrating) replica or from unavailable partitions. An increasing sequence of record versions is not guaranteed. Only one of `readModeScAllowUnavailable`, `readModeScSession`, `readModeScLinearize`, or `readModeScReplica` can be set. | ```yaml "readModeApOne": int "readModeApAll": int ``` | Field | Type | Description | | -- | - | -- | | `readModeApOne` | `int` | "one" indicates that a single node is involved in the read operation. Only one of `readModeApOne` or `readModeApAll` can be set. | | `readModeApAll` | `int` | "all" indicates that all duplicate nodes are consulted in the read operation. Only one of `readModeApAll` or `readModeApOne` can be set. | ```yaml "curveP256": int "curveP384": int "curveP521": int "x25519": int ``` | Field | Type | Description | | -- | - | -- | | `curveP256` | `int` | Only one of `curveP256`, `curveP384`, `curveP521`, or `x25519` can be set. | | `curveP384` | `int` | Only one of `curveP384`, `curveP256`, `curveP521`, or `x25519` can be set. | | `curveP521` | `int` | Only one of `curveP521`, `curveP256`, `curveP384`, or `x25519` can be set. | | `x25519` | `int` | Only one of `x25519`, `curveP256`, `curveP384`, or `curveP521` can be set. | ```yaml "apiKey": string "labels": []string "metadata": map<string, bool> "uuid": string ``` | Field | Type | Description | | -- | - | -- | | `apiKey` | `string` | The string value of the API key. | | `labels` | `[]string` | A list of labels (key=value) for the apikey secret. These labels are used by the storage driver to facilitate lookups by label. | | `metadata` | `map<string, bool>` | additional data the client needs associated with this API key. | | `uuid` | `string` | Optional: Unique identifier for the API key. | DEPRECATED: use ApiKey ```yaml "apiKey": string "labels": []string "metadata": map<string, bool> ``` | Field | Type | Description | | -- | - | -- | | `apiKey` | `string` | The string value of the API key. | | `labels` | `[]string` | A list of labels (key=value) for the apikey secret. These labels are used by the storage driver to facilitate lookups by label. | | `metadata` | `map<string, bool>` | additional data the client needs associated with this API key. | Enforce Open Policy Agent (OPA) policies in Gloo Edge environments. For Gloo Platform environments, use OpaServerAuth instead. ```yaml "modules": []core.solo.io.ResourceRef "query": string "options": .enterprise.gloo.solo.io.OpaAuthOptions ``` | Field | Type | Description | | -- | - | -- | | `modules` | | An optional resource reference to config maps containing modules to assist in the resolution of `query`. | | `query` | `string` | The query that determines the auth decision. The result of this query must be either a boolean or an array with boolean as the first element. A boolean `true` value means that the request will be authorized. Any other value, or error, means that the request will be denied. | | `options` | | Additional Options for Opa Auth configuration. | ```yaml "fastInputConversion": bool "returnDecisionReason": bool ``` | Field | Type | Description | | -- | - | -- | | `fastInputConversion` | `bool` | Decreases OPA latency by speeding up conversion of input to the OPA

If this is set to true, only http_request and state fields which are a scalar, map, or string array are included in the request input. All other fields are dropped. Dropped fields will not be evaluated by the OPA engine. By default, this is set to false and all fields are evaluated by OPA. | | `returnDecisionReason` | `bool` | DEPRECATED: It's recommended to use the `dynamicmetadata` field within Rego policies to specify the decision reason. To learn more about this approach, see the . When `returnDecisionReason` is set to true, the decision reason is stored in the Envoy Dynamic Metadata and has the following properties:<ul> <li>`body` - a textual explanation of the decision</li> <li>`allowed` - whether the request was allowed or rejected</li></ul> When using OpaAuth, the `body` field must be the second parameter of the query. Both the OpaAuth and OpaServerAuth approaches use the `allowed` and `body` values from the OPA response in the decision reason. You can find the `body` and `allowed` fields in the Envoy Filter Dynamic Metadata under the `envoy.filters.http.extauthz.<authenticationstepname>.reason` section. If, however, `returnDecisionReason` is set to false, OPA's decision to allow or reject a request is made according to the Rego policy rules, and no explanation is provided. Despite of this, the `dynamic_metadata` field can still be used to convey any necessary information to the Envoy Dynamic Metadata, including the decision reason. | Enforce Open Policy Agent (OPA) policies through an OPA sidecar as part of the external auth server in Gloo Platform environments. For Gloo Edge environments, use OpaAuth instead. ```yaml "package": string "ruleName": string "serverAddr": string "options": .enterprise.gloo.solo.io.OpaAuthOptions ``` | Field | Type | Description | | -- | - | -- | | `package` | `string` | The package from your Rego policy bundle used to query the OPA data API. | | `ruleName` | `string` | The rule in your Rego policy bundle used to query the OPA data API. Supports querying subfields with a `/`. For more information, see the . | | `serverAddr` | `string` | The address of the OPA server to query, in the format `ADDRESS:PORT`. For OPA servers within the cluster, the address is the pod's service address, such as `default.svc.cluster.local:8181`. For OPA servers outside the cluster, the server must be accessible to the cluster, such as through an ExternalService. If you do not have your own OPA server instance, omit this field. When the external auth service has the OPA server sidecar enabled, the OPA server sidecar will be used instead. | | `options` | | Additional options for OPA Auth configuration. | Authenticates and authorizes requests by querying an LDAP server. Gloo makes the following assumptions: Requests provide credentials via the basic HTTP authentication header. Gloo will BIND to the LDAP server using the credentials extracted from the header. Your LDAP server is configured so that each entry you want to authorize has an attribute that indicates its group memberships. A common way of achieving this is by using the . ```yaml "address": string "userDnTemplate": string "membershipAttributeName": string "allowedGroups": []string "pool": .enterprise.gloo.solo.io.Ldap.ConnectionPool "searchFilter": string "disableGroupChecking": bool "groupLookupSettings": .enterprise.gloo.solo.io.LdapServiceAccount ``` | Field | Type | Description | | -- | - | -- | | `address` | `string` | Address of the LDAP server to query. Should be in the form ADDRESS:PORT, e.g. `ldap.default.svc.cluster.local:389`. | | `userDnTemplate` | `string` | Template to build user entry distinguished names (DN). This must contains a single occurrence of the "%s" placeholder. When processing a request, Gloo will substitute the name of the user (extracted from the auth header) for the placeholder and issue a search request with the resulting DN as baseDN (and 'base' search scope). E.g.

| | `membershipAttributeName` | `string` | Case-insensitive name of the attribute that contains the names of the groups an entry is member of. Gloo will look for attributes with the given name to determine which groups the user entry belongs to. Defaults to 'memberOf' if not provided. | | `allowedGroups` | `[]string` | In order for the request to be authenticated, the membership attribute (e.g. memberOf) on the user entry must contain at least of one of the group DNs specified via this option. E.g. []string{ "cn=managers,ou=groups,dc=solo,dc=io", "cn=developers,ou=groups,dc=solo,dc=io" }. | | `pool` | | Use this property to tune the pool of connections to the LDAP server that Gloo maintains. | | `searchFilter` | `string` | Use to set a custom filter when searching a member. Defaults to "(uid=*)". | | `disableGroupChecking` | `bool` | Disables group checking, regardless of the value for allowedGroups, and disables validation for the membership attribute of the user entry. Group checking is enabled by default. | | `groupLookupSettings` | | Settings for using a separate service account for looking up group membership To use this, you also need to configure credentials in a secret. | Configuration properties for pooling connections to the LDAP server. If the pool is exhausted when a connection is requested (meaning that all the pooled connections are in use), the connection will be created on the fly. ```yaml "maxSize": .google.protobuf.UInt32Value "initialSize": .google.protobuf.UInt32Value ``` | Field | Type | Description | | -- | - | -- | | `maxSize` | | Maximum number connections that are pooled at any give time. The default value is 5. | | `initialSize` | | Number of connections that the pool will be pre-populated with upon initialization. The default value is 2. | ```yaml "credentialsSecretRef": .core.solo.io.ResourceRef "checkGroupsWithServiceAccount": bool ``` | Field | Type | Description | | -- | - | -- | | `credentialsSecretRef` | | Reference to an AccountCredentialsSecret to use to authenticate as the service account. | | `checkGroupsWithServiceAccount` | `bool` | If true, Gloo will use the service account to check group membership. | Authorizes requests by querying a custom extauth server. ```yaml "grpc": .enterprise.gloo.solo.io.PassThroughGrpc "http": .enterprise.gloo.solo.io.PassThroughHttp "config": .google.protobuf.Struct "failureModeAllow": bool ``` | Field | Type | Description | | -- | - | -- | | `grpc` | | Only one of `grpc` or `http` can be set. | | `http` | | Only one of `http` or `grpc` can be set. | | `config` | | Custom config to be passed per request to the passthrough auth service. | | `failureModeAllow` | `bool` | If set to true, the service will accept client request even if the communication with the authorization service has failed, or if the authorization service has returned a server error. Defaults to false. | Configuration defining an exponential back off strategy. ```yaml "baseInterval": .google.protobuf.Duration "maxInterval": .google.protobuf.Duration ``` | Field | Type | Description | | -- | - | -- | | `baseInterval` | | The base interval to be used for the next back off computation. Defaults to 1000 milliseconds. | | `maxInterval` | | Specifies the maximum delay between retries. Defaults to 10 times the base interval. | The message specifies the retry policy of the external gRPC service when unable to initally connect. ```yaml "numRetries": .google.protobuf.UInt32Value "retryBackOff": .enterprise.gloo.solo.io.BackoffStrategy ``` | Field | Type | Description | | -- | - | -- | | `numRetries` | | Specifies the allowed number of retries. This parameter is optional and defaults to 1. | | `retryBackOff` | | Specifies parameters that control the backoff

This parameter is optional, in which case the default base interval is 1000 milliseconds. The default maximum interval is 10 times the base interval. | Authorizes requests by querying a custom extauth grpc server Assumes that the server implements the envoy external authorization spec: https://github.com/envoyproxy/envoy/blob/ae1ed1fa74f096dabe8dd5b19fc70333621b0309/api/envoy/service/auth/v3/external_auth.proto#L29 ```yaml "address": string "connectionTimeout": .google.protobuf.Duration "tlsConfig": .enterprise.gloo.solo.io.PassThroughGrpcTLSConfig "retryPolicy": .enterprise.gloo.solo.io.RetryPolicy ``` | Field | Type | Description | | -- | - | -- | | `address` | `string` | Address of the auth server to query. Should be in the form ADDRESS:PORT, e.g. `default.svc.cluster.local:389`. | | `connectionTimeout` | | Timeout for the auth server to respond. Defaults to 5s. | | `tlsConfig` | | TLS config for the Grpc passthrough, if not configured the connection will use insecure. | | `retryPolicy` | | Indicates the retry policy for re-establishing the gRPC stream. This field is optional and failed calls will not retry unless configured. | TLS configuration for the extauth grpc passthrough connection ```yaml ``` | Field | Type | Description | | -- | - | -- | Authorizes requests by making a POST HTTP/1 request to a custom HTTP auth server Assumes the request is authorized if the server returns a OK (200) status code, else the request is unauthorized. ```yaml "url": string "request": .enterprise.gloo.solo.io.PassThroughHttp.Request "response": .enterprise.gloo.solo.io.PassThroughHttp.Response "connectionTimeout": .google.protobuf.Duration ``` | Field | Type | Description | | -- | - | -- | | `url` | `string` | Required: URL of the passthrough http service, is a fully qualified domain name. Example: http://ext-auth-service.svc.local:9001. Path provided in the URL will be respected. To use https, provide the cert in the HTTPSPASSTHROUGHCA_CERT environment variable to the ext-auth-service pod as a base64-encoded string. | | `request` | | Pass through the incoming request body, ext auth state, and filter metadata. For more information, see the . | | `response` | | Pass through response information such as the headers and body to downstream clients. For more information, see the . | | `connectionTimeout` | | Timeout for the auth server to respond. Defaults to 5s. | The passthrough http request can be configured to pass through the incoming request body, the ext-auth state (which is shared between different auth methods within one ext-auth instance), and the The body of the passthrough auth request will be a JSON as follows: { "body" : string, "state": object (map[string]interface{}), "filterMetadata": object (map[string]protobuf.Struct), "config": object (protobuf.Struct), } `config` is the struct block specified under the passthrough auth configuration. If `passthroughbody`, `passthroughstate`, `passthroughfiltermetadata`, and `config` are all false/nil, the body of the auth request will remain empty. Setting any of these will increase latency slightly due to JSON marshalling. ```yaml "allowedHeaders": []string "headersToAdd": map<string, string> "passThroughState": bool "passThroughFilterMetadata": bool "passThroughBody": bool ``` | Field | Type | Description | | -- | - | -- | | `allowedHeaders` | `[]string` | These headers will be copied from the incoming request to the request going to the auth server. By default, no headers are copied from the incoming request. Pseudo-headers such as `:Path`, and `:Method` can not be specified here. | | `headersToAdd` | `map<string, string>` | These headers that will be included to the request to authorization service. Note that client request of the same key will be overridden. Pseudo-headers such as `:Path`, and `:Method` can not be specified here. | | `passThroughState` | `bool` | Whether or not to include the ext-auth state object in the passthrough request body. If this is set to true, it is expected that the state is returned in the HTTP response from the passthrough

The state received from the response will be the state that is shared with other ext-auth service methods. If passthroughbody, passthroughfiltermetadata and passthrough_state are false, the authorization request body will be empty. A non-empty body will increase latency times slightly, so this is set to false by default, and should only be set to to true if the extauth state is needed in the auth request. | | `passThroughFilterMetadata` | `bool` | Whether or not to include the filter metadata in the passthrough request body. If passthroughbody, passthroughfiltermetadata and passthrough_state are false, the authorization request body will be empty. A non-empty body will increase latency times slightly, so this is set to false by default, and should only be set to to true if the filter metadata is needed in the auth request. | | `passThroughBody` | `bool` | Whether or not to include the body in the passthrough request body. In order for this to work, the settings.extauth.requestBody must be set in the Gloo Edge Settings CRD so that the request body is buffered and sent to the ext-auth service. If passthroughbody, passthroughfiltermetadata and passthrough_state are false, the authorization request body will be empty. A non-empty body will increase latency times slightly, so this is set to false by default, and should only be set to to true if the request body is needed in the auth request. | ```yaml "allowedUpstreamHeaders": []string "allowedClientHeadersOnDenied": []string "readStateFromResponse": bool "allowedUpstreamHeadersToOverwrite": []string ``` | Field | Type | Description | | -- | - | -- | | `allowedUpstreamHeaders` | `[]string` | When this is set, authorization response headers that have a header in this list will be added to the original client request and sent to the upstream when the auth request is successful. These will be appended to any request headers that already exist. If this and allowedupstreamheaderstooverwrite are empty, by default, no authorization response headers will be added to the upstream request. Header names may not be included in both allowedupstreamheaders and allowedupstreamheaderstooverwrite. | | `allowedClientHeadersOnDenied` | `[]string` | When this is set, authorization response headers in this list will be added to the response to the downstream client when the auth request is denied. If the response header already exists, it will replace the response header. If this is empty, by default, no authorization response headers will be added to the response to the downstream client. | | `readStateFromResponse` | `bool` | If this is set to true, the body of the response from the http passthrough auth server is expected to have shape { "state": object (map[string]interface{}) } The state will be marshalled from the response body and this is the state that will be passed on to other auth configs. Because of the marshalling from JSON to Go map, this will add some latency to the request. If the marshalling fails, the authorization check will fail and the request will be unauthorized after the ext-auth-service pod logs the marshal error. | | `allowedUpstreamHeadersToOverwrite` | `[]string` | When this is set, authorization response headers that have a header in this list will be added to the original client request and sent to the upstream when the auth request is successful. These will overwrite to any request headers that already exist. If this and allowedupstreamheaders are empty, by default, no authorization response headers will be added to the upstream request. Header names may not be included in both allowedupstreamheaders and allowedupstreamheaderstooverwrite. | This is an internal API used to share configuration between gloo-ee and

Although this API is only used in gloo-ee, rules about breaking changes still apply to ensure we do not get errors during upgrade and downgrade. ```yaml "authConfigRefName": string "configs": []enterprise.gloo.solo.io.ExtAuthConfig.Config "booleanExpr": .google.protobuf.StringValue "failOnRedirect": bool ``` | Field | Type | Description | | -- | - | -- | | `authConfigRefName` | `string` | | | `configs` | | List of auth configs to be checked for requests on a route referencing this auth config, By default, every config must be authorized for the entire request to be authorized. This behavior can be changed by defining names for each config and defining `boolean_expr` below. State is shared between successful requests on the chain, i.e., the headers returned from each successful auth service get appended into the final auth response. | | `booleanExpr` | | How to handle processing of named configs within an auth config chain. An example config might be: `( basic1 || basic2 || (oidc1 && !oidc2) )` The boolean expression is evaluated left to right but honors parenthesis and short-circuiting. Defaults to an empty string, which is interpreted as `and`-ing the configs. | | `failOnRedirect` | `bool` | How the service should handle a redirect response from an OIDC issuer. In the default false mode, the redirect will be considered a successful response, and the client will receive a 302 with a location header. If this is set to true, the client will instead receive a 401 unauthorized response. This is useful in cases where API calls are being made or other such occurrences where the client cannot handle the redirect. | Message to store Basic Auth Configuration. "Internal" refers to this format allowing for selection of the hashing algorithm and user source. If only the legacy "apr" field is defined, the existing public BasicAuth configuration will continue be used. ```yaml "realm": string "encryption": .enterprise.gloo.solo.io.ExtAuthConfig.BasicAuthInternal.EncryptionType "userList": .enterprise.gloo.solo.io.ExtAuthConfig.BasicAuthInternal.UserList ``` | Field | Type | Description | | -- | - | -- | | `realm` | `string` | Realm to use in the Basic Auth challenge. | | `encryption` | | Hashing algorithm to use for password hashing. | | `userList` | | | Selection of hashing algorithms to use for password hashing. ```yaml "apr": .enterprise.gloo.solo.io.ExtAuthConfig.BasicAuthInternal.EncryptionType.Apr "sha1": .enterprise.gloo.solo.io.ExtAuthConfig.BasicAuthInternal.EncryptionType.Sha1 ``` | Field | Type | Description | | -- | - | -- | | `apr` | | Only one of `apr` or `sha1` can be set. | | `sha1` | | Only one of `sha1` or `apr` can be set. | ```yaml ``` | Field | Type | Description | | -- | - | -- | ```yaml ``` | Field | Type | Description | | -- | - | -- | To authenticate a user we need the salt and hashed password. The username is expected to be the key in a map of Users. ```yaml "salt": string "hashedPassword": string ``` | Field | Type | Description | | -- | - | -- | | `salt` | `string` | | | `hashedPassword` | `string` | | Map of valid usernames to stored credentials ```yaml "users": map<string, .enterprise.gloo.solo.io.ExtAuthConfig.BasicAuthInternal.User> ``` | Field | Type | Description | | -- | - | -- | | `users` | `map<string, .enterprise.gloo.solo.io.ExtAuthConfig.BasicAuthInternal.User>` | | Deprecated, prefer OAuth2Config ```yaml "clientId": string "clientSecret": string "issuerUrl": string "authEndpointQueryParams": map<string, string> "appUrl": string "callbackPath": string "scopes": []string ``` | Field | Type | Description | | -- | - | -- | | `clientId` | `string` | your client id as registered with the issuer. | | `clientSecret` | `string` | your client secret as registered with the

| | `issuerUrl` | `string` | The url of the issuer. We will look for OIDC information in issuerUrl+ ".well-known/openid-configuration". | | `authEndpointQueryParams` | `map<string, string>` | extra query parameters to apply to the Ext-Auth service's authorization request to the identity provider. | | `appUrl` | `string` | we to redirect after successful auth, if we can't determine the original url this should be your publicly available app url. | | `callbackPath` | `string` | a callback path relative to app url that will be used for OIDC callbacks. needs to not be used by the application. | | `scopes` | `[]string` | scopes to request in addition to the openid scope. | ```yaml "failOnFetchFailure": bool "cookieOptions": .enterprise.gloo.solo.io.UserSession.CookieOptions "cookie": .enterprise.gloo.solo.io.UserSession.InternalSession "redis": .enterprise.gloo.solo.io.UserSession.RedisSession "cipherConfig": .enterprise.gloo.solo.io.ExtAuthConfig.UserSessionConfig.CipherConfig ``` | Field | Type | Description | | -- | - | -- | | `failOnFetchFailure` | `bool` | should we fail auth flow when failing to get a session from redis, or allow it to continue, potentially starting a new auth flow and setting a new session. | | `cookieOptions` | | Set-Cookie options. | | `cookie` | | Set the tokens in the cookie itself. No need for server side state. Only one of `cookie` or `redis` can be set. | | `redis` | | Use redis to store the tokens and just store a random id in the cookie. Only one of `redis` or `cookie` can be set. | | `cipherConfig` | | the cipher config enables the symmetric key encryption of the cookie values of the user session. | ```yaml "key": string ``` | Field | Type | Description | | -- | - | -- | | `key` | `string` | to enable the cipher encryption, the key has to be present. Note that the key has to be found and 32 bytes in length for the authconfig to not be rejected. | ```yaml "clientId": string "clientSecret": string "issuerUrl": string "authEndpointQueryParams": map<string, string> "tokenEndpointQueryParams": map<string, string> "appUrl": string "callbackPath": string "logoutPath": string "afterLogoutUrl": string "scopes": []string "session": .enterprise.gloo.solo.io.UserSession "headers": .enterprise.gloo.solo.io.HeaderConfiguration "discoveryOverride": .enterprise.gloo.solo.io.DiscoveryOverride "discoveryPollInterval": .google.protobuf.Duration "jwksCacheRefreshPolicy": .enterprise.gloo.solo.io.JwksOnDemandCacheRefreshPolicy "sessionIdHeaderName": string "parseCallbackPathAsRegex": bool "autoMapFromMetadata": .enterprise.gloo.solo.io.AutoMapFromMetadata "endSessionProperties": .enterprise.gloo.solo.io.EndSessionProperties "userSession": .enterprise.gloo.solo.io.ExtAuthConfig.UserSessionConfig "pkJwtClientAuthenticationConfig": .enterprise.gloo.solo.io.ExtAuthConfig.OidcAuthorizationCodeConfig.PkJwtClientAuthenticationConfig "accessToken": .enterprise.gloo.solo.io.ExtAuthConfig.OidcAuthorizationCodeConfig.AccessToken "identityToken": .enterprise.gloo.solo.io.ExtAuthConfig.OidcAuthorizationCodeConfig.IdentityToken "default": .enterprise.gloo.solo.io.ExtAuthConfig.OidcAuthorizationCodeConfig.Default "azure": .enterprise.gloo.solo.io.ExtAuthConfig.OidcAuthorizationCodeConfig.Azure ``` | Field | Type | Description | | -- | - | -- | | `clientId` | `string` | your client id as registered with the issuer. | | `clientSecret` | `string` | your client secret as registered with the issuer. Only one of clientsecret or pkjwtclientauthenticationconfig should be set. pkjwtclientauthentication_config takes precedence. | | `issuerUrl` | `string` | The url of the issuer. We will look for OIDC information in issuerUrl+ ".well-known/openid-configuration". | | `authEndpointQueryParams` | `map<string, string>` | extra query parameters to apply to the Ext-Auth service's authorization request to the identity provider. this can be useful for flows such as PKCE (https://www.oauth.com/oauth2-servers/pkce/authorization-request/) to set the `codechallenge` and `codechallenge_method`. | | `tokenEndpointQueryParams` | `map<string, string>` | extra query parameters to apply to the Ext-Auth service's token request to the identity provider. this can be useful for flows such as PKCE (https://www.oauth.com/oauth2-servers/pkce/authorization-request/) to set the `code_verifier`. | | `appUrl` | `string` | we to redirect after successful auth, if we can't determine the original url this should be your publicly available app url. | | `callbackPath` | `string` | a callback path relative to app url that will be used for OIDC callbacks. needs to not be used by the application. | | `logoutPath` | `string` | a path relative to app url that will be used for logging out from an OIDC session. should not be used by the

If not provided, logout functionality will be disabled. | | `afterLogoutUrl` | `string` | url to redirect to after logout. This should be a publicly available URL. If not provided, will default to the `app_url`. | | `scopes` | `[]string` | scopes to request in addition to the openid scope. | | `session` | | DEPRECATED: use userSessionConfig [userSession]. | | `headers` | | Configures headers added to requests. | | `discoveryOverride` | | OIDC configuration is discovered at <issuerUrl>/.well-known/openid-configuration The configuration override defines any properties that should override this discovery configuration For example, the following AuthConfig CRD could be defined as: ```yaml apiVersion: enterprise.gloo.solo.io/v1 kind: AuthConfig metadata: name: google-oidc namespace: gloo-system spec: configs: - oauth: appurl: http://localhost:8080 callbackpath: /callback clientid: $CLIENTID clientsecretref: name: google namespace: gloo-system issuerurl: https://accounts.google.com discoveryoverride: token_endpoint: "https://token.url/gettoken" ``` And this will ensure that regardless of what value is discovered at <issuerUrl>/.well-known/openid-configuration, "https://token.url/gettoken" will be used as the token endpoint. | | `discoveryPollInterval` | | The interval at which OIDC configuration is discovered at <issuerUrl>/.well-known/openid-configuration If not specified, the default value is 30 minutes. | | `jwksCacheRefreshPolicy` | | If a user executes a request with a key that is not found in the JWKS, it could be that the keys have rotated on the remote source, and not yet in the local cache. This policy lets you define the behavior for how to refresh the local cache during a request where an invalid key is provided. | | `sessionIdHeaderName` | `string` | If set, the randomly generated session id will be sent to the token endpoint as part of the code exchange The session id is used as the key for sessions in Redis. | | `parseCallbackPathAsRegex` | `bool` | If set, CallbackPath will be evaluated as a regular expression. | | `autoMapFromMetadata` | | If specified, authEndpointQueryParams and tokenEndpointQueryParams will be populated using dynamic metadata values. By default parameters will be extracted from the soloauthconfigoidc namespace this behavior can be overridden by explicitly specifying a namespace. | | `endSessionProperties` | | If specified, these are properties defined for the end session endpoint specifications. Noted in the OIDC documentation. | | `userSession` | | Configuration related to the user session. | | `pkJwtClientAuthenticationConfig` | | Configuration for private key JWT client authentication. Only one of clientsecret or pkjwtclientauthenticationconfig should be set. pkjwtclientauthentication_config takes precedence. | | `accessToken` | | Optional: Configuration specific to the OAuth2 access token received and processed by the ext-auth-service. | | `identityToken` | | Optional: Configuration specific to the OIDC identity token received and processed by the ext-auth-service. | | `default` | | Only one of `default` or `azure` can be set. | | `azure` | | Only one of `azure` or `default` can be set. | Fields for private key JWT Client Authentication. ```yaml "signingKey": string "validFor": .google.protobuf.Duration ``` | Field | Type | Description | | -- | - | -- | | `signingKey` | `string` | Signing key for the JWT used for client authentication. | | `validFor` | | Amount of time for which the JWT is valid. No maximmum is enforced, but different IDPs may impose limits on how far in the future the expiration time is allowed to be. Defaults in 5s in front end, but expected to be set explictly here. | Map a single claim from an OAuth2 or OIDC token to a header in the request to the upstream

```yaml "claim": string "header": string "append": bool ``` | Field | Type | Description | | -- | - | -- | | `claim` | `string` | The claim name from the token, such as `sub`. | | `header` | `string` | The header to copy the claim to, such as `x-sub`. | | `append` | `bool` | If the header exists, append the claim value to the header (true), or overwrite any existing value (false). The default behavior is to overwrite any existing value (false). | Optional: Map a single claim from an OAuth2 access token to a header in the request to the upstream destination. ```yaml "claimsToHeaders": []enterprise.gloo.solo.io.ExtAuthConfig.OidcAuthorizationCodeConfig.ClaimToHeader ``` | Field | Type | Description | | -- | - | -- | | `claimsToHeaders` | | A list of claims to be mapped from the JWT token received by ext-auth-service to an upstream destination. | Optional: Map a single claim from an OIDC identity token to a header in the request to the upstream destination. ```yaml "claimsToHeaders": []enterprise.gloo.solo.io.ExtAuthConfig.OidcAuthorizationCodeConfig.ClaimToHeader ``` | Field | Type | Description | | -- | - | -- | | `claimsToHeaders` | | A list of claims to be mapped from the JWT token received by ext-auth-service to an upstream destination. | No-op, represents default OIDC behavior ```yaml ``` | Field | Type | Description | | -- | - | -- | For apps in Microsoft Azure, configure Microsoft Entra ID as the OpenID Connect (OIDC) provider. This way, you can enable distibuted claims and caching for when users are members of more than 200 groups. ```yaml "clientId": string "tenantId": string "clientSecret": string "claimsCachingOptions": .enterprise.gloo.solo.io.RedisOptions ``` | Field | Type | Description | | -- | - | -- | | `clientId` | `string` | The client ID for the ExtAuthService app that is registered in MS Entra, to access the Microsoft Graph API to retrieve distributed claims. This app is NOT the app that you want to configure external auth for. | | `tenantId` | `string` | The tenant ID represents the MS Entra organization ID where the ExtAuthService app is registered. This tenant ID may or may not be the same as in the top level `OidcAuthorizationCodeConfig`, depending on how your Azure account is provisioned. | | `clientSecret` | `string` | The client secret of the ExtAuthService app that is registered with MS Entra to communciate with the MS Graph API. | | `claimsCachingOptions` | | Redis connection details to cache MS Entera claims. This way, you avoid performance issues of accessing the Microsoft Graph API too many times. Note that this setting does NOT turn on Redis caching for the user session. To turn on Redis user session caching, use the `userSessionConfig` field. | ```yaml "introspectionUrl": string "jwt": .enterprise.gloo.solo.io.ExtAuthConfig.AccessTokenValidationConfig.JwtValidation "introspection": .enterprise.gloo.solo.io.ExtAuthConfig.AccessTokenValidationConfig.IntrospectionValidation "userinfoUrl": string "cacheTimeout": .google.protobuf.Duration "requiredScopes": .enterprise.gloo.solo.io.ExtAuthConfig.AccessTokenValidationConfig.ScopeList ``` | Field | Type | Description | | -- | - | -- | | `introspectionUrl` | `string` | The URL for the endpoint. If provided, the (opaque) access token provided or received from the oauth authorization endpoint will be validated against this endpoint, or locally cached responses for this access token. This field is deprecated as it does not support authenticated introspection requests. Only one of `introspectionUrl`, `jwt`, or `introspection` can be set. | | `jwt` | | Validate access tokens that conform to the specification. Only one of `jwt`, `introspectionUrl`, or `introspection` can be set. | | `introspection` | | Defines how (opaque) access tokens, received from the oauth authorization endpoint, are validated specification. Only one of `introspection`, `introspectionUrl`, or `jwt` can be set. | | `userinfoUrl` | `string` | The URL for the OIDC userinfo

If provided, the (opaque) access token provided or received from the oauth endpoint will be queried and the userinfo response (or cached response) will be added to the `AuthorizationRequest` state under the "introspection" key. This can be useful to leverage the userinfo response in, for example, an external auth server plugin. | | `cacheTimeout` | | How long the token introspection and userinfo endpoint response for a specific access token should be kept in the in-memory cache. The result will be invalidated at this timeout, or at "exp" time from the introspection result, whichever comes sooner. If omitted, defaults to 10 minutes. If zero, then no caching will be done. | | `requiredScopes` | | Require access token to have all of the scopes in the given list. This configuration applies to both opaque and JWT tokens. In the case of opaque tokens, this will check the scopes returned in the "scope" member of introspection response (as described in . In case of JWTs the scopes to be validated are expected to be contained in the "scope" claim of the token in the form of a space-separated string. Omitting this field means that scope validation will be skipped. | Defines how JSON Web Token (JWT) access tokens are validated. Tokens are validated using a JSON Web Key Set (as defined in ), which can be either inlined in the configuration or fetched from a remote location via HTTP. Any keys in the JWKS that are not intended for signature verification (i.e. whose is not "sig") will be ignored by the system, as will keys that do not specify a . The JWT to be validated must define non-empty "kid" and "alg" headers. The "kid" header determines which key in the JWKS will be used to verify the signature of the token; if no matching key is found, the token will be rejected. If present, the server will verify the "exp", "iat", and "nbf" standard JWT claims. Validation of the "iss" claim and of token scopes can be configured as well. If the JWT has been successfully validated, its set of claims will be added to the `AuthorizationRequest` state under the "jwtAccessToken" key. ```yaml "remoteJwks": .enterprise.gloo.solo.io.ExtAuthConfig.AccessTokenValidationConfig.JwtValidation.RemoteJwks "localJwks": .enterprise.gloo.solo.io.ExtAuthConfig.AccessTokenValidationConfig.JwtValidation.LocalJwks "issuer": string ``` | Field | Type | Description | | -- | - | -- | | `remoteJwks` | | Fetches the JWKS from a remote location. Only one of `remoteJwks` or `localJwks` can be set. | | `localJwks` | | Loads the JWKS from a local data source. Only one of `localJwks` or `remoteJwks` can be set. | | `issuer` | `string` | Allow only tokens that have been issued by this principal (i.e. whose "iss" claim matches this value). If empty, issuer validation will be skipped. | Specifies how to fetch JWKS from remote and how to cache it. ```yaml "url": string "refreshInterval": .google.protobuf.Duration ``` | Field | Type | Description | | -- | - | -- | | `url` | `string` | The HTTP URI to fetch the JWKS. | | `refreshInterval` | | The frequency at which the JWKS should be refreshed. If not specified, the default value is 5 minutes. | Represents a locally available JWKS. ```yaml "inlineString": string ``` | Field | Type | Description | | -- | - | -- | | `inlineString` | `string` | JWKS is embedded as a string. | Defines how (opaque) access tokens, received from the oauth authorization endpoint, are validated If the token introspection url requires client authentication, both the clientid and clientsecret are required. If only one is provided, the config will be

These values will be encoded in a basic auth header in order to authenticate the client. ```yaml "introspectionUrl": string "clientId": string "clientSecret": string "userIdAttributeName": string ``` | Field | Type | Description | | -- | - | -- | | `introspectionUrl` | `string` | The URL for the endpoint. If provided, the (opaque) access token provided or received from the oauth authorization endpoint will be validated against this endpoint, or locally cached responses for this access token. | | `clientId` | `string` | Your client id as registered with the issuer. Optional: Use if the token introspection url requires client authentication. | | `clientSecret` | `string` | Your client secret as registered with the issuer. Optional: Use if the token introspection url requires client authentication. | | `userIdAttributeName` | `string` | The name of the attribute that contains the ID of the resource owner (e.g. `sub`, `username`). If specified, the external auth server will use the value of the attribute as the identifier of the authenticated user and add it to the request headers and/or dynamic metadata (depending on how the server is configured); if the field is set and the attribute cannot be found, the request will be denied. This field is optional and by default the server will not try to derive the user ID. | ```yaml "scope": []string ``` | Field | Type | Description | | -- | - | -- | | `scope` | `[]string` | | ```yaml "clientId": string "clientSecret": string "authEndpointQueryParams": map<string, string> "appUrl": string "callbackPath": string "scopes": []string "session": .enterprise.gloo.solo.io.UserSession "logoutPath": string "tokenEndpointQueryParams": map<string, string> "afterLogoutUrl": string "authEndpoint": string "tokenEndpoint": string "revocationEndpoint": string "userSession": .enterprise.gloo.solo.io.ExtAuthConfig.UserSessionConfig ``` | Field | Type | Description | | -- | - | -- | | `clientId` | `string` | Your client ID as registered with the issuer. | | `clientSecret` | `string` | Your client secret as registered with the issuer. | | `authEndpointQueryParams` | `map<string, string>` | Extra query parameters to apply to the Ext-Auth service's authorization request to the identity provider. These parameters can be useful for flows such as to set the `codechallenge` and `codechallenge_method`. | | `appUrl` | `string` | Where to redirect after successful auth, if Gloo can't determine the original URL. Set this field to your publicly available app URL. | | `callbackPath` | `string` | A callback path relative to the app URL to be used for OAuth2 callbacks. Do not use this path in the application itself. | | `scopes` | `[]string` | Scopes to request for. | | `session` | | DEPRECATED: use userSessionConfig [userSession]. | | `logoutPath` | `string` | A path relative to the app URL to use for logging out from an OAuth2 session. Do not use this path in the application itself. If not provided, logout functionality is disabled. | | `tokenEndpointQueryParams` | `map<string, string>` | Extra query parameters to apply to the Ext-Auth service's token request to the identity provider. These parameters can be useful for flows such as to set the `code_verifier`. | | `afterLogoutUrl` | `string` | URL to redirect to after logout. Set this field to a publicly available URL. If not provided, this value defaults to the `app_url` value. | | `authEndpoint` | `string` | The URL of the provider authorization endpoint. | | `tokenEndpoint` | `string` | The URL of the provider token endpoint. | | `revocationEndpoint` | `string` | The URL of the provider token revocation endpoint. For more information, refer to https://www.rfc-editor.org/rfc/rfc7009. | | `userSession` | | Configuration related to the user session. | ```yaml "oidcAuthorizationCode": .enterprise.gloo.solo.io.ExtAuthConfig.OidcAuthorizationCodeConfig "accessTokenValidationConfig": .enterprise.gloo.solo.io.ExtAuthConfig.AccessTokenValidationConfig "oauth2Config":

``` | Field | Type | Description | | -- | - | -- | | `oidcAuthorizationCode` | | provide issuer location and let gloo handle OIDC flow for you. requests authorized by validating the contents of ID token. can also authorize the access token if configured. Only one of `oidcAuthorizationCode`, `accessTokenValidationConfig`, or `oauth2Config` can be set. | | `accessTokenValidationConfig` | | provide the access token on the request and let gloo handle authorization. according to https://tools.ietf.org/html/rfc6750 you can pass tokens through: - form-encoded body parameter. recommended, more likely to appear. e.g.: Authorization: Bearer mytoken123 - URI query parameter e.g. access_token=mytoken123 - and (preferably) secure cookies. Only one of `accessTokenValidationConfig`, `oidcAuthorizationCode`, or `oauth2Config` can be set. | | `oauth2Config` | | Enterprise-Only: THIS FEATURE IS IN TECH PREVIEW. APIs are versioned as alpha and subject to change. provide issuer location and let Gloo handle Oauth2 flow for you. requests authorized by validating the contents of access token. Prefer to use OIDC for better security. Only one of `oauth2Config`, `oidcAuthorizationCode`, or `accessTokenValidationConfig` can be set. | NOTE: This configuration is not user-facing and will be auto generated ```yaml "validApiKeys": map<string, .enterprise.gloo.solo.io.ExtAuthConfig.ApiKeyAuthConfig.KeyMetadata> "headerName": string "headersFromKeyMetadata": map<string, string> "k8SSecretApikeyStorage": .enterprise.gloo.solo.io.K8sSecretApiKeyStorage "aerospikeApikeyStorage": .enterprise.gloo.solo.io.AerospikeApiKeyStorage ``` | Field | Type | Description | | -- | - | -- | | `validApiKeys` | `map<string, .enterprise.gloo.solo.io.ExtAuthConfig.ApiKeyAuthConfig.KeyMetadata>` | A mapping of valid API keys to their associated metadata. This map is automatically populated with the information from the relevant `ApiKey`s. Currently this is only configured when using the k8s Secret storage backend. | | `headerName` | `string` | (Optional) When receiving a request, the Gloo Edge Enterprise external auth server will look for an API key in a header with this name. This field is optional; if not provided it defaults to `api-key`. | | `headersFromKeyMetadata` | `map<string, string>` | Determines the key metadata that will be included as headers on the upstream request. Each entry represents a header to add: the key is the name of the header, and the value is the key that will be used to look up the data entry in the key metadata. | | `k8SSecretApikeyStorage` | | Only one of `k8sSecretApikeyStorage` or `aerospikeApikeyStorage` can be set. | | `aerospikeApikeyStorage` | | Only one of `aerospikeApikeyStorage` or `k8sSecretApikeyStorage` can be set. | ```yaml "username": string "metadata": map<string, string> ``` | Field | Type | Description | | -- | - | -- | | `username` | `string` | The user is mapped as the name of `Secret` which contains the `ApiKey`. | | `metadata` | `map<string, string>` | The metadata present on the `ApiKey`. | ```yaml "modules": map<string, string> "query": string "options": .enterprise.gloo.solo.io.OpaAuthOptions ``` | Field | Type | Description | | -- | - | -- | | `modules` | `map<string, string>` | An optional modules (filename, module content) maps containing modules assist in the resolution of `query`. | | `query` | `string` | The query that determines the auth decision. The result of this query must be either a boolean or an array with boolean as the first element. A boolean `true` value means that the request will be authorized. Any other value, or error, means that the request will be denied. | | `options` | | Additional Options for Opa Auth configuration. | Enforce Open Policy Agent (OPA) policies through an OPA sidecar as part of the external auth server in Gloo Platform environments. For Gloo Edge environments, use OpaAuth instead. ```yaml "package": string "ruleName": string "serverAddr": string "options":

``` | Field | Type | Description | | -- | - | -- | | `package` | `string` | | | `ruleName` | `string` | | | `serverAddr` | `string` | | | `options` | | | ```yaml "address": string "userDnTemplate": string "membershipAttributeName": string "allowedGroups": []string "pool": .enterprise.gloo.solo.io.Ldap.ConnectionPool "searchFilter": string "disableGroupChecking": bool "groupLookupSettings": .enterprise.gloo.solo.io.ExtAuthConfig.LdapServiceAccountConfig ``` | Field | Type | Description | | -- | - | -- | | `address` | `string` | Address of the LDAP server to query. Should be in the form ADDRESS:PORT, e.g. `ldap.default.svc.cluster.local:389`. | | `userDnTemplate` | `string` | Template to build user entry distinguished names (DN). This must contains a single occurrence of the "%s" placeholder. When processing a request, Gloo will substitute the name of the user (extracted from the auth header) for the placeholder and issue a search request with the resulting DN as baseDN (and 'base' search scope). E.g. "uid=%s,ou=people,dc=solo,dc=io". | | `membershipAttributeName` | `string` | Case-insensitive name of the attribute that contains the names of the groups an entry is member of. Gloo will look for attributes with the given name to determine which groups the user entry belongs to. Defaults to 'memberOf' if not provided. | | `allowedGroups` | `[]string` | In order for the request to be authenticated, the membership attribute (e.g. memberOf) on the user entry must contain at least of one of the group DNs specified via this option. E.g. []string{ "cn=managers,ou=groups,dc=solo,dc=io", "cn=developers,ou=groups,dc=solo,dc=io" }. | | `pool` | | Use this property to tune the pool of connections to the LDAP server that Gloo maintains. | | `searchFilter` | `string` | Use to set a custom filter when searching a member. Defaults to "(uid=*)". | | `disableGroupChecking` | `bool` | Disables group checking, regardless of the value for allowedGroups, and disables validation for the membership attribute of the user entry. Group checking is enabled by default. | | `groupLookupSettings` | | Settings for using a separate service account for looking up group membership To use this, you also need to configure credentials. | ```yaml "username": string "password": string "checkGroupsWithServiceAccount": bool ``` | Field | Type | Description | | -- | - | -- | | `username` | `string` | username and password are taken from the secret during gloo-ee translation. | | `password` | `string` | | | `checkGroupsWithServiceAccount` | `bool` | If true, Gloo will use the service account to check group membership. | ```yaml "secretList": .enterprise.gloo.solo.io.ExtAuthConfig.InMemorySecretList "parametersInHeaders": .enterprise.gloo.solo.io.HmacParametersInHeaders ``` | Field | Type | Description | | -- | - | -- | | `secretList` | | | | `parametersInHeaders` | | | ```yaml "secretList": map<string, string> ``` | Field | Type | Description | | -- | - | -- | | `secretList` | `map<string, string>` | list of username/password pairs taken from secrets during gloo-ee translation. | ```yaml "name": .google.protobuf.StringValue "oauth": .enterprise.gloo.solo.io.ExtAuthConfig.OAuthConfig "oauth2": .enterprise.gloo.solo.io.ExtAuthConfig.OAuth2Config "basicAuth": .enterprise.gloo.solo.io.BasicAuth "basicAuthInternal": .enterprise.gloo.solo.io.ExtAuthConfig.BasicAuthInternal "apiKeyAuth": .enterprise.gloo.solo.io.ExtAuthConfig.ApiKeyAuthConfig "pluginAuth": .enterprise.gloo.solo.io.AuthPlugin "opaAuth": .enterprise.gloo.solo.io.ExtAuthConfig.OpaAuthConfig "ldap": .enterprise.gloo.solo.io.Ldap "ldapInternal": .enterprise.gloo.solo.io.ExtAuthConfig.LdapConfig "jwt": .google.protobuf.Empty "passThroughAuth": .enterprise.gloo.solo.io.PassThroughAuth "hmacAuth": .enterprise.gloo.solo.io.ExtAuthConfig.HmacAuthConfig "opaServerAuth": .enterprise.gloo.solo.io.ExtAuthConfig.OpaServerAuthConfig ``` | Field | Type | Description | | -- | - | -- | | `name` | | optional: used when defining complex boolean logic, if `booleanexpr` is defined below. Also used in logging. If omitted, an automatically generated name will be used (e.g. config0, of the pattern 'config$INDEXIN_CHAIN'). In the case of plugin auth, this field is ignored in favor of the name assigned on the plugin config itself. | | `oauth` | | Only one of `oauth`, `oauth2`, `basicAuth`, `basicAuthInternal`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `ldapInternal`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be

| | `oauth2` | | Only one of `oauth2`, `oauth`, `basicAuth`, `basicAuthInternal`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `ldapInternal`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `basicAuth` | | Only one of `basicAuth`, `oauth`, `oauth2`, `basicAuthInternal`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `ldapInternal`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `basicAuthInternal` | | Only one of `basicAuthInternal`, `oauth`, `oauth2`, `basicAuth`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `ldapInternal`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `apiKeyAuth` | | Only one of `apiKeyAuth`, `oauth`, `oauth2`, `basicAuth`, `basicAuthInternal`, `pluginAuth`, `opaAuth`, `ldap`, `ldapInternal`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `pluginAuth` | | Only one of `pluginAuth`, `oauth`, `oauth2`, `basicAuth`, `basicAuthInternal`, `apiKeyAuth`, `opaAuth`, `ldap`, `ldapInternal`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `opaAuth` | | Only one of `opaAuth`, `oauth`, `oauth2`, `basicAuth`, `basicAuthInternal`, `apiKeyAuth`, `pluginAuth`, `ldap`, `ldapInternal`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `ldap` | | Only one of `ldap`, `oauth`, `oauth2`, `basicAuth`, `basicAuthInternal`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldapInternal`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `ldapInternal` | | Used for LDAP configurations that need service account credentials saved in a secret. Only one of `ldapInternal`, `oauth`, `oauth2`, `basicAuth`, `basicAuthInternal`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `jwt`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `jwt` | | This is a "dummy" extauth service which can be used to support multiple auth mechanisms with JWT authentication. If Jwt authentication is to be used in the in an AuthConfig, you can use this auth config type to include Jwt as an Auth config. In addition, `allowmissingorfailedjwt` must be set on the Virtual Host or Route that uses JWT auth or else the JWT filter will short circuit this behaviour. Only one of `jwt`, `oauth`, `oauth2`, `basicAuth`, `basicAuthInternal`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `ldapInternal`, `passThroughAuth`, `hmacAuth`, or `opaServerAuth` can be set. | | `passThroughAuth` | | Only one of `passThroughAuth`, `oauth`, `oauth2`, `basicAuth`, `basicAuthInternal`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `ldapInternal`, `jwt`, `hmacAuth`, or `opaServerAuth` can be set. | | `hmacAuth` | | Only one of `hmacAuth`, `oauth`, `oauth2`, `basicAuth`, `basicAuthInternal`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `ldapInternal`, `jwt`, `passThroughAuth`, or `opaServerAuth` can be set. | | `opaServerAuth` | | Only one of `opaServerAuth`, `oauth`, `oauth2`, `basicAuth`, `basicAuthInternal`, `apiKeyAuth`, `pluginAuth`, `opaAuth`, `ldap`, `ldapInternal`, `jwt`, `passThroughAuth`, or `hmacAuth` can be set. | ```yaml "apiKeys": []enterprise.gloo.solo.io.ApiKey "rawApiKeys": []string ``` | Field | Type | Description | | -- | - | -- | | `apiKeys` | | | | `rawApiKeys` | `[]string` | | ```yaml "apiKeys": []enterprise.gloo.solo.io.ApiKey ``` | Field | Type | Description | | -- | - | -- | | `apiKeys` | | | ```yaml "rawApiKeys": []string "labels": []string ``` | Field | Type | Description | | -- | - | -- | | `rawApiKeys` | `[]string` | | | `labels` | `[]string` | | ```yaml "apiKeys": []enterprise.gloo.solo.io.ApiKey ``` | Field | Type | Description | | -- | - | -- | | `apiKeys` | | | ```yaml "upsert": bool "apiKeys": []enterprise.gloo.solo.io.ApiKey "rawApiKeys": []string ``` | Field | Type | Description | | -- | - | -- | | `upsert` | `bool` | | | `apiKeys` | | | | `rawApiKeys` | `[]string` | | ```yaml "apiKeys": []enterprise.gloo.solo.io.ApiKey ``` | Field | Type | Description | | -- | - | -- | | `apiKeys` | | | ```yaml "rawApiKeys": []string "labels": []string ``` | Field | Type | Description | | -- | - | -- | | `rawApiKeys` | `[]string` | | | `labels` | `[]string` | | ```yaml ``` | Field | Type | Description | | -- | -