Support CEL / template in authenticator validations

[martin31821]

Preflight checklist

• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines."
• I have discussed this feature request with the community.

Describe the background of your feature request

We're building a multi-tenant cloud application which is secured via Keycloak and we're looking into using heimdall to secure our app. Our tenants should be separated by using different keycloak realms (effectively one OpenID provider per tenant), but we do want our users to be able to login to shared services in the app using heimdall.

Describe your idea

Building upon #619, I'd like to extend the validation of authenticator with CEL.

I'm thinking of a configuration like this:

rules:
  mechanisms:
    authenticators:
    - id: keycloak
      type: oidc
      config:
        assertions:
          issuers:
          - expression: "Issuer.startsWith(\"https://${our_keycloak_url}/realms\")"
          - "${issuer_url}" # this one for backwards compatibility

Are there any workarounds or alternatives?

I have, so far not found an alternative for what I'm trying to achieve.
A workaround would be an extra service validating tokens from different realms and unifying these tokens, but I think it wouldn't be a nice solution.

Version

v0.11.0

Additional Context

No response

[dadrus]

Thank you @martin31821 for your FR. I planned the corresponding functionality for the 0.13.0-alpha release.

I personally don't see any dependency to #619.
Actually, you could achieve your goal today as well by making use of generic authenticator in combination with the cel authorizer. You can find an example on how to make use of the generic authenticator here (take a look at the Example 5). In the CEL authorizer, you would define the following expression to achieve the required issuer check: Subject.Attributes.<id of the generic authenticator>.iss.startsWith("https://${our_keycloak_url}/realms").

[dadrus]

BTW, I encourage you joining the community in Discord. That way you can directly participate in the ongoing discussions and influence the future of heimdall.
I'll introduce this FR in the community as well to see which alternative ideas are present. The best one will win ;)

[martin31821]

That's true, I think the only connection between this and #619 is, that I would require the OIDC to not run any assertions on the issuer. Then I could just have an oidc authenticator and a CEL authorizer.

Great software design!

[dadrus]

@martin31821: Is there a reason, why you closed the FR? I personally think it is a pretty good enhancement of the available functionality

[martin31821]

As you said, it's already doable with the CEL authorizer, so implementing #619 should cover it completely, but if you'd be willing to allow CEL checks in the authenticator itself, i'm happy to keep it open.

[dadrus]

The idea with #619 was related to the actual discovery of the relevant endpoints. But you're right, the same information from the discovery endpoint can also be used to assert the issuer.

I think however this FR deserves to be addressed on its own.