Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to configure @OpenIdAuthenticationMechanismDefinition in a dynamic way? #291

Open
rsoika opened this issue Jun 30, 2023 · 1 comment

Comments

@rsoika
Copy link

rsoika commented Jun 30, 2023

I try to find out a way to configure @OpenIdAuthenticationMechanismDefinition in a more dynamic way.

Of course you can provide the values for OPENID_PROVIDERURI, the OPENID_CLIENTID or the OPENID_CLIENTSECRET by defining the corresponding environment variables or use EL and a config CDI Bean.

But it seems that more complex params like scope or extraParameters can only be hard coded in @OpenIdAuthenticationMechanismDefinition.

This means you can't write an interoperable application using different OpenID providers. You have to implement several Beans for each Provider and encapsulate them in separate libraries which you can than bundle with your application.

https://stackoverflow.com/questions/76468527/how-to-use-el-in-extraparameters-attribute-of-the-openidauthenticationmechanism

Did I miss something here or is this an know issue?

Concrete we need to develop an application that runs in produciton with ForgeRock and in Test with Auth0. Both providers need custom configuration in the scope and extraParameters

@OndroMih
Copy link
Contributor

Hi, @rsoika , all non-String params can already be specified by an expression using their alternative attributes with the Expression suffix. scope can be defined by an EL using the scopeExpression String attribute, and extra parameters can be defined by an expression with the extraParametersExpression String attribute, like this:

@OpenIdAuthenticationMechanismDefinition(
        clientId = "${configBean.clientId}",
        clientSecret = "${configBean.clientSecret}",
        scopeExpression = "${configBean.scope}",
        extraParametersExpression = "${configBean.extraParameters}"
)
public class MyBean  {
   ...
}

All the annotations in the Security spec follow this pattern to configure everything using expressions:

  • if the attribute is of String type, an expression can be used as its value
  • if the attribute is some other type, e.g. a number or a String array, there's always a dual attribute of type String, with the Expression suffix in the name, which accepts an expression

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants