diff --git a/security/v1/request_authentication.pb.go b/security/v1/request_authentication.pb.go index 9375f6117a3..ce45f54d0e4 100644 --- a/security/v1/request_authentication.pb.go +++ b/security/v1/request_authentication.pb.go @@ -366,8 +366,10 @@ const ( // is now supported. A prefix '@' is used to denote a match against internal metadata instead of the headers in the request. // Currently this feature is only supported for the following metadata: // -// - `request.auth.claims.{claim-name}[.{sub-claim}]*` which are extracted from validated JWT tokens. The claim name -// currently does not support the `.` character. Examples: `request.auth.claims.sub` and `request.auth.claims.name.givenName`. +// - `request.auth.claims.{claim-name}[.{nested-claim}]*` which are extracted from validated JWT tokens. +// Use the `.` or `[]` as a separator for nested claim names. +// Examples: `request.auth.claims.sub`, `request.auth.claims.name.givenName` and `request.auth.claims[foo.com/name]`. +// For more information, see [JWT claim based routing](https://istio.io/latest/docs/tasks/security/authentication/jwt-route/). // // The use of matches against JWT claim metadata is only supported in Gateways. The following example shows: // diff --git a/security/v1/request_authentication.proto b/security/v1/request_authentication.proto index 633c48f08a9..8f40f36dca7 100644 --- a/security/v1/request_authentication.proto +++ b/security/v1/request_authentication.proto @@ -295,8 +295,10 @@ option go_package="istio.io/api/security/v1"; // is now supported. A prefix '@' is used to denote a match against internal metadata instead of the headers in the request. // Currently this feature is only supported for the following metadata: // -// - `request.auth.claims.{claim-name}[.{sub-claim}]*` which are extracted from validated JWT tokens. The claim name -// currently does not support the `.` character. Examples: `request.auth.claims.sub` and `request.auth.claims.name.givenName`. +// - `request.auth.claims.{claim-name}[.{nested-claim}]*` which are extracted from validated JWT tokens. +// Use the `.` or `[]` as a separator for nested claim names. +// Examples: `request.auth.claims.sub`, `request.auth.claims.name.givenName` and `request.auth.claims[foo.com/name]`. +// For more information, see [JWT claim based routing](https://istio.io/latest/docs/tasks/security/authentication/jwt-route/). // // The use of matches against JWT claim metadata is only supported in Gateways. The following example shows: // diff --git a/security/v1beta1/request_authentication.pb.go b/security/v1beta1/request_authentication.pb.go index 5a9d3c9a76c..3ff6fa3091f 100644 --- a/security/v1beta1/request_authentication.pb.go +++ b/security/v1beta1/request_authentication.pb.go @@ -364,8 +364,10 @@ const ( // is now supported. A prefix '@' is used to denote a match against internal metadata instead of the headers in the request. // Currently this feature is only supported for the following metadata: // -// - `request.auth.claims.{claim-name}[.{sub-claim}]*` which are extracted from validated JWT tokens. The claim name -// currently does not support the `.` character. Examples: `request.auth.claims.sub` and `request.auth.claims.name.givenName`. +// - `request.auth.claims.{claim-name}[.{nested-claim}]*` which are extracted from validated JWT tokens. +// Use the `.` or `[]` as a separator for nested claim names. +// Examples: `request.auth.claims.sub`, `request.auth.claims.name.givenName` and `request.auth.claims[foo.com/name]`. +// For more information, see [JWT claim based routing](https://istio.io/latest/docs/tasks/security/authentication/jwt-route/). // // The use of matches against JWT claim metadata is only supported in Gateways. The following example shows: // diff --git a/security/v1beta1/request_authentication.pb.html b/security/v1beta1/request_authentication.pb.html index 48c7b872435..3af5ca6183a 100644 --- a/security/v1beta1/request_authentication.pb.html +++ b/security/v1beta1/request_authentication.pb.html @@ -264,8 +264,10 @@

RequestAuthentication

is now supported. A prefix ‘@’ is used to denote a match against internal metadata instead of the headers in the request. Currently this feature is only supported for the following metadata:

The use of matches against JWT claim metadata is only supported in Gateways. The following example shows: