Skip to content

Default JWT claim mapper support for permissions parsing using regular expression #7560

Open
@adamko147

Description

@adamko147

Is your feature request related to a problem? Please describe.
We're currently using self hosted temporal server with custom JWT auth plugin as described at https://docs.temporal.io/self-hosted-guide/security#plugins
The only reason we need to maintain custom auth plugin is missing claim mapper configuration to parse permissions from claims. Unfortunately we don't have an option to configure JWT issuer to pass permissions in form namespace:role as expected by default JWT claim mapper.

Describe the solution you'd like
Default JWT authorization included in temporal server is almost sufficient for our use case (including issuer and audience validation), except for configuration how to parse permissions from JTW claims. An option for configuration permissionPattern in form of regular expression with named groups would cover our use case (as well as others potentially) and avoid overhead related to maintaining customer auth plugin and therefore significantly simplifying our setup.

Suggested solution
Add PermissionsPattern into Authorization Config. If configured, it would be used to parse the claim in defaultJWTClaimMapper.extractPermissions. If not configured, fall back to original code. An example of such pattern could be

  • prefix-i-cannot-change\.(?P<namespace>\w+)\.(?P<role>\w+), or
  • (?P<namespace>\w+)\.(?P<role>\w+) to use . as separator (instead of : because that character is not allowed by JWT issuer), etc...

I'm pretty ok with go and I would like to contribute by raising a PR with the new code if the owners/community agree this is viable option.

Describe alternatives you've considered
As mentioned above, authorization plugin is an alternative, but it requires maintaining custom temporal build, additional CI/CD steps to build the code, create docker image, etc...

Thank you,
Adam

PS: And yes, for our use case, I'm ok to sacrifice performance of strings.Split vs regex.FindStringSubmatch for the benefit of not maintaining our temporal build :)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions