temporal icon indicating copy to clipboard operation
temporal copied to clipboard

Default JWT claim mapper support for permissions parsing using regular expression

Open adamko147 opened this issue 9 months ago • 3 comments

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 :)

adamko147 avatar Apr 03 '25 05:04 adamko147

Hi @adamko147, thanks for the proposal!

I will bring this issue to team and get relevant folks involved to review the approach described.

yycptt avatar Apr 03 '25 22:04 yycptt

Hi @adamko147, thanks for the proposal!

I will bring this issue to team and get relevant folks involved to review the approach described.

Thank you @yycptt. Meanwhile I've created #7574 with initial implementation. Early feedback from community/maintainers is very welcome! I'm also looking around the code base for places to adjust (e.g. helm charts) and trying to bring the change into our self hosted environment to verify with functional testing (in addition to unit tests included in the pull request)

adamko147 avatar Apr 04 '25 22:04 adamko147

Hi @yycptt did you have a chance to discuss this issue with team already? Thanks in advance for any update on this.

adamko147 avatar May 29 '25 17:05 adamko147