RBAC: Make it possible to use regex for values

[francoisvandenplas]

• Breaking change? (if so, please describe the impact and migration path for existing application instances)

What changes did you make? (Give an overview)
Rbac now handle regex in values
Fixes #300

Is there anything you'd like reviewers to focus on?

How Has This Been Tested? (put an "x" (case-sensitive!) next to an item)

• No need to
• Manually (please, describe, if necessary)
• Unit checks
• Integration checks
• Covered by existing automation

Checklist (put an "x" (case-sensitive!) next to all the items, otherwise the build will fail)

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (e.g. ENVIRONMENT VARIABLES)
• My changes generate no new warnings (e.g. Sonar is happy)
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged

Check out Contributing and Code of Conduct

A picture of a cute animal (not mandatory but encouraged)

[callaertanthony]

Hey ! Any chance to see this PR merged ?

[Haarolean]

Hey ! Any chance to see this PR merged ?

sorry, will take a look this week

[Haarolean]

Thanks for covering this with tests, that's really helpful!
Left a few minor inline comments

[callaertanthony]

hey @Haarolean , is it possible for you to give a look again ? many thanks

[Haarolean]

@callaertanthony thank you! If you have time, could you update our docs as well? https://github.com/kafbat/ui-docs

[callaertanthony]

@Haarolean , by updating the documentation I tell myself that we are introducing a (security) breaking change.
The documentation mentions this subject :

- provider: oauth_google
  type: domain
  value: "memelord.lol"

So, if starting from now we evaluate the subject as regex, user is not directly impacted, because memelord.lol matches the regex memelord.lol, this is certainly okay for a google domain, because I think we can never receive something else than a dot at this place.
But, what about if user based subject ? (and certainly others types).
I will not go in details in each replacement possibility depending on each method, but I'm pretty sur this enables different users as the expected one without regex.

I see two options :

1. We introduce this breaking change and we MUST document it
2. We introduce another field like regexValue and user must fill value or regexValue

What do we do ?

[Haarolean]

@callaertanthony hey, good point! We've discussed this: we believe a better approach would be introducing a new boolean param like isRegex (nullable & defaults to false for back compatibility), which will indicate whether we should treat the value as regex or a string literal. This will guarantee backward compatibility AND reduce confusion if multiple fields are used instead. What do you think?

[callaertanthony]

thanks @Haarolean , @francoisvandenplas I created this pr with the change : francoisvandenplas#1

[Haarolean]

thanks @Haarolean , @francoisvandenplas I created this pr with the change : francoisvandenplas#1

could you rebase this branch instead please?

[francoisvandenplas]

Hello,
@Haarolean could you have a look ?
Thanks !