Condition match header/form to user attribute

Getting advice
1

I am trying to use keycloak to move a legacy system into something that supports OAuth/OIDC

The overhaul of our legacy system would be too much to implement in a short period of time, thus a refactoring approach is being taken.

As a result, I need to use a security style otp type of thing provided by the legacy system to validate a user is logged in etc. This can’t be changed due to how the legacy system(s) work.

My idea is that when a user logs in, we can pass this token value to the user in KC as an attribute, and update/revoke that value as necessary in our normal logic flows.

Then we can generate JWTs through KC via Direct Access Grant flow, but I need to add a check for this security value for auth purposes to ensure the account hasn’t been revoked.

Getting the user attribute into KC is easy, but I can’t seem to find a way to check a submitted value in the Auth Flow to compare a given value to a user attribute. The UserAttribute conditional seems to expect a static value, but this is more like an otp value that could change regularly.

I feel like this likely already exists, but I’m struggling to find where.

I found a github that does almost exactly the same thing as an extension

I’m wondering if I need to create my own extension and maintain it as a result. Obviously I’d prefer something out of the box, but would also like to avoid something overly hacky.

Long term goal is to kill off this security token in favor of pure OAuth - but that’s not a short term option and I’m trying to get sign off on a solution that has a more palatable refactoring process.

2

You will have to do this in a custom extension.

Hopefully you know that the “Resource Owner Passwort Grant” (in Keycloak named Direct Access Grant) and “pure OAuth” in an up-to date and secure manner doesn’t fit together. ROPC is a security risk and deprecated (“must not be used”).

3

I do know :frowning:
It’s not that I like this, it’s an issue with how to get this to work with our legacy system and provide a means of gradually moving things over, without completely redoing a custom sign in solution that has been accruing technical debt for 19 ish years.

So it’s not that I like it, it’s that this gets us a way to get JWT and OIDC working with the current system and allows for systematic rework of individual systems as we go, rather than a full overhaul, which would involve a lot of man hours (tried to get it done a couple years ago and management basically shot it down once they got the time estimate of work involved).

Thank you for the response.