initial authentication infrastructure - #274
Conversation
willr3
left a comment
willr3
left a comment
There was a problem hiding this comment.
How are we / users going to specify the auth-server-url?
|
|
||
| # OIDC - disabled by default (enable via environment for service deployments) | ||
| quarkus.oidc.tenant-enabled=false | ||
| quarkus.oidc.auth-server-url=${OIDC_AUTH_SERVER_URL:} |
There was a problem hiding this comment.
Does removing quarkus.oidc.auth-server-url=${OIDC_AUTH_SERVER_URL:} mean the quarkus.oidc.auth-server-url property must be in either a -D command line argument or in the .env when running h5m?
There was a problem hiding this comment.
yes. in a production setting the quarkus.oidc.auth-server-url for the provider will be specified, along with client-id + credentials-secret and others, using one of the several methods available to specify / override properties.
I see no point in having an alias, when the original quarkus properties are available and are well documented.
There was a problem hiding this comment.
Would it be helpful to keep those properties in application.properties (possibly without values) so we know they must be defined / overridden when deploying h5m?
The oidc-proxy exposes a /q/oidc discovery endpoint so the frontend OIDC client can discover the identity provider through the backend. Dev profile auto-starts a OIDC lightweight server with test users (alice, bob) — roles are assigned by h5m on first login. remove principal-claim override (default sub)
- UserEntity: add optional sub/iss columns with unique constraint for OIDC identity - UserServiceInterface: add bySub(sub, iss) lookup and create overload with sub/iss - OidcUserProvisioner: pattern-match on JsonWebToken to extract sub/iss/username from JWT - H5mRolesAugmentor/UserResource: dispatch user lookup by principal type (JWT vs username) - application.properties: enable OIDC in test mode - AutoProvisioningTest: add OIDC provisioning test with TestJwt - pom.xml: add quarkus-test-security-oidc test dependency
Frontend: AuthorizationContext/Provider wires OIDC tokens into the Axios client via interceptor, fetches the user role, and exposes isAdmin/isAuthenticated. create AuthActions with login/logout actions with token renewal and notifications.
2 participants
Summary
quarkus-oidc-proxyextension to expose a/q/oidcdiscovery endpoint, allowing the frontend OIDC client to discover the identity provider through the backend. Dev profile auto-starts an OIDC server with test users (roles are assigned by h5m on first login).subandissclaims inUserEntityas stable identity. The provisioner and roles augmentor pattern-match on principal type (JsonWebTokenvs plain principal) to dispatch user lookup accordingly.AuthorizationContext/Providerinjects OIDC tokens into Axios via interceptor, fetches the user role from/api/user/role, and exposesisAdmin/isAuthenticated.AuthActionscomponent provides login/logout with token renewal and notifications.Test plan
ADMINrole, subsequent users getUSERroleAutoProvisioningTestcovers OIDC provisioning withsub/issand the username-based path