You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When Webapi is setup with e.g. OIDC and a new User signs in, it defaults to the public role. Without any preparation on the database, an admin has to set the actual roles afterwards. It would be more comfortable if the default roles could be configurable, similar to the User-Import from AD via the property security.ad.default.import.group.
Define a new property security.default.roles, that sets the default roles:
// in AtlasSecurity.java@Value("${security.default.roles}#{T(java.util.Set).of('public')}")
protectedSet<String> defaultRoles;
This would apply to all authentications.
Alternative for OIDC
Allow to define a roles claim in the access token. By default Keycloak already sets this claim and pac4j parses it.
May add a property in webapi, that switches interpreting of the supplied roles. The huge advantage here is, that authorization can be managed by the IDP/Keycloak.
The text was updated successfully, but these errors were encountered:
Current Behavior
When Webapi is setup with e.g. OIDC and a new User signs in, it defaults to the
public
role. Without any preparation on the database, an admin has to set the actual roles afterwards. It would be more comfortable if the default roles could be configurable, similar to the User-Import from AD via the propertysecurity.ad.default.import.group
.The default role is hardcoded here:
WebAPI/src/main/java/org/ohdsi/webapi/shiro/management/AtlasSecurity.java
Line 79 in 3f9e90c
Proposal
Define a new property
security.default.roles
, that sets the default roles:This would apply to all authentications.
Alternative for OIDC
Allow to define a
roles
claim in the access token. By default Keycloak already sets this claim and pac4j parses it.May add a property in webapi, that switches interpreting of the supplied roles. The huge advantage here is, that authorization can be managed by the IDP/Keycloak.
The text was updated successfully, but these errors were encountered: