Quarkus: Cannot use runtime quarkus.security.users.file.* config

Created on 24 Oct 2019  路  6Comments  路  Source: quarkusio/quarkus

Describe the bug
I have successfully setup quarkus.security.users.file.* (enabled, users, roles, realm-name) config but the only place where I can have it to work is inside the application.properties file. I think this whould be overridable at startup using java -Dquarkus.security...... options.

Expected behavior
These configuration properties are marked as "Configuration property fixed at build time" in the Quarkus all-config page but in my opinion, this should be overridableat runtime, and my users / groups / passwords files could be generated by the people I distribute the app to, I would not be forced to ask them for their passwords / hashes/ users, in order to build them in.

Actual behavior
Configuration properties not being taken into account at startup

To Reproduce
Steps to reproduce the behavior:

  1. Use
    quarkus.security.users.file.enabled=true
    In application.properties
  2. Launch the app using
  3. Get an exception :
    java.lang.IllegalStateException: No PropertiesRealmConfig users/roles settings found. Configure the quarkus.security.file.{enabled,users,roles,authMechanism,realmName} properties
    at io.quarkus.elytron.security.runtime.ElytronPropertiesFileRecorder$1.run(ElytronPropertiesFileRecorder.java:68)
    at io.quarkus.elytron.security.runtime.ElytronRecorder.runLoadTask(ElytronRecorder.java:31)
    at io.quarkus.deployment.steps.ElytronDeploymentProcessor$loadRealm15.deploy_0(ElytronDeploymentProcessor$loadRealm15.zig:70)
    at io.quarkus.deployment.steps.ElytronDeploymentProcessor$loadRealm15.deploy(ElytronDeploymentProcessor$loadRealm15.zig:36)
    at io.quarkus.runner.ApplicationImpl1.doStart(ApplicationImpl1.zig:105)
    at io.quarkus.runtime.Application.start(Application.java:93)
    at io.quarkus.runtime.Application.run(Application.java:213)
    at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:34)

Configuration

 Configuration file
# key = value

quarkus.http.port=8080
quarkus.http.ssl-port=443
quarkus.http.ssl.certificate.key-store-file=keystore.jks
quarkus.http.ssl.certificate.key-store-password=mypasswd

quarkus.security.users.file.enabled=true

Screenshots
NA

Environment (please complete the following information):

  • Output of uname -a or ver: Linux raspberrypi 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l GNU/Linux
  • Output of java -version: openjdk version "1.8.0_212"
    OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1+rpi1-b01)
    OpenJDK Client VM (build 25.212-b01, mixed mode)
  • GraalVM version (if different from Java):
  • Quarkus version or git rev: 0.24.0

Additional context
Zulip description here : https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/Option.20quarkus.2Esecurity.2Eusers.2Efile.2Eenabled

kinbug

All 6 comments

  • Since 0.24.0 keycloak adapter is obsolete and i used it to authenticate to different realms using KeycloakConfigResolver 0.23.2 keycloak guide multitenancy.
  • But with the oidc i cant use this feature though i understand oidc does not have to use keycloak spesific mechanism. Basically i want to change the realm before oidc provider auth.

@sberyozkin and @geoand might have an opinion regarding this?

@sberyozkin is the expert here :)

We should allow these to be externalised from the application, at the moment it only loads from the ClassLoader. It should be changed to allow them to load from the file system as well, and make this modifiable at runtime time.

@geoand Hey Georgios, the noisy person (myself) is here :-). Let me just add +1 to what Stuart said :-). I propose we try to fix it for the next version following 0.27.0
By the way, @mazegreg, I'd also encourage you to look at the Vault extension.

@slymnshn @mazegreg Please watch https://github.com/quarkusio/quarkus/issues/4448 (re the multitenancy)

Was this page helpful?
0 / 5 - 0 ratings