Add a corresponding global setting for the existing route-level
jwt_issuer_format option. The route-level option will take precedence
when set to a non-empty string.
Add a new Authorize Log Fields option for logging the number of groups
removed during JWT groups filtering. This will be enabled by default.
Additionally, when the log level is Debug (or more verbose), store and
log the IDs of any groups removed during JWT groups filtering.
Change the JWT groups filtering behavior:
- to filter only by group ID (not group name)
- and only for groups sourced from directory sync (groups from a
"groups" claim will not be filtered)
This avoids the need to fetch all group names up front, which should
improve performance in specific circumstances.
Add a new option for filtering to a subset of directory groups in the
Pomerium JWT and Impersonate-Group headers. Add a JWTGroupsFilter field
to both the Options struct (for a global filter) and to the Policy
struct (for per-route filter). These will be populated only from the
config protos, and not from a config file.
If either filter is set, then for each of a user's groups, the group
name or group ID will be added to the JWT groups claim only if it is an
exact string match with one of the elements of either filter.
Make sure to serialize the JWT "groups" claim as an empty list rather
than a JSON null. This matches the behavior of Pomerium v0.27.2 and
earlier, and should provide better compatibility with some third-party
libraries.
Add a new 'user_principal_name' type to the downstream mTLS
match_subject_alt_names option. This corresponds to the 'OtherName' type
with type-id 1.3.6.1.4.1.311.20.2.3 and a UTF8String value.
Add support for UserPrincipalName SAN matching to the policy evaluator.
* core/authorize: use uuid for jti, current time for iat and exp
* exclude the jtis
* Update authorize/evaluator/headers_evaluator_test.go
Co-authored-by: Kenneth Jenkins <51246568+kenjenkins@users.noreply.github.com>
---------
Co-authored-by: Kenneth Jenkins <51246568+kenjenkins@users.noreply.github.com>
Remove the deprecated set_authorization_header option entirely. Add an
entry to the removedConfigFields map with a link to the relevant
Upgrading page section.
Currently Pomerium replaces dynamic set_request_headers tokens
sequentially. As a result, if a replacement value itself contained a
supported "$pomerium" token, Pomerium may treat that as another
replacement, resulting in incorrect output.
This is unlikely to be a problem given the current set of dynamic
tokens, but if we continue to add additional tokens, this will likely
become more of a concern.
To forestall any issues, let's perform all replacements in one pass,
using the os.Expand() method. This does require a slight change to the
syntax, as tokens containing a '.' will need to be wrapped in curly
braces, e.g. ${pomerium.id_token}.
A literal dollar sign can be included by using $$ in the input.
Add a new match_subject_alt_names option to the downstream_mtls settings
group. This setting can be used to further constrain the allowed client
certificates by requiring that certificates contain a Subject
Alternative Name of a particular type, matching a particular regex.
When set, populate the corresponding match_typed_subject_alt_names
setting within Envoy, and also implement a corresponding check in the
authorize service.
Update the isValidClientCertificate() method to consider any
client-supplied intermediate certificates. Previously, in order to trust
client certificates issued by an intermediate CA, users would need to
include that intermediate CA's certificate directly in the client_ca
setting. After this change, only the trusted root CA needs to be set: as
long as the client can supply a set of certificates that chain back to
this trusted root, the client's certificate will validate successfully.
Rework the previous CRL checking logic to now consider CRLs for all
issuers in the verified chains.
Add support for a new token $pomerium.client_cert_fingerprint in the
set_request_headers option. This token will be replaced with the SHA-256
hash of the presented leaf client certificate.
Update OPA to v0.54.0, which changes the JSON serialization behavior for
large integers. Remove the formatting workaround and the unit test that
verified that the workaround was still needed.
Rego will sometimes serialize integers to JSON with a decimal point and
exponent. I don't completely understand this behavior.
Add a workaround to headers.rego to convert the JWT "iat" and "exp"
timestamps to a string and back to an integer. This appears to cause
Rego to serialize these values as plain integers.
Add a unit test to verify this behavior. Also add a unit test that will
fail if the Rego behavior changes, making this workaround unnecessary.
