Security improvement for Authentication and Authorization. There is a single configuration for groups to roles mappings and a single authentication provider used for both the Base API and Admin API. The default StackState roles are now always available, these could previously be overridden - stackstate-admin
, stackstate-power-user
, stackstate-guest
. Additionally, a new default role stackstate-platform-admin
has been introduced.
adminGroups = ${stackstate.authorization.adminGroups} ["custom-admin-role-from-ldap-or-oidc-or-keycloak"]
platformAdminGroups = ${stackstate.authorization.platformAdminGroups} ["custom-platform-admin-role-from-ldap-or-oidc-or-keycloak"]
powerUserGroups = ${stackstate.authorization.powerUserGroups} ["custom-power-user-role-from-ldap-or-oidc-or-keycloak"]
guestGroups = ${stackstate.authorization.guestGroups} ["custom-guest-role-from-ldap-or-oidc-or-keycloak"]
Platform management and platform content management permissions have been separated into two groups - platformAdminGroup
and adminGroup
. Users in the group platformAdminGroup
are limited to only platform management tasks, such as change database retention, clear database, clear caches and view logs. Users in the group adminGroup
no longer have platform management permissions.
How you should proceed with upgrade?
This impacts you if you have a customized authentication
section in the file application_stackstate.conf
. If your authentication
section has adminGroups
, powerUserGroups
, guestGroups
definitions like in the example below:
adminGroups = ["your-custom-oidc-or-ldap-or-keycloak-admin-role"]
powerUserGroups = ["your-custom-oidc-or-ldap-or-keycloak-power-user-role"]
guestGroups = ["your-custom-oidc-or-ldap-or-keycloak-guest-role"]
The subject-role mappings must be moved to a centralized authorization configuration using the syntax xxxGroups = ${stackstate.authorization.xxxGroups} ["custom-role"]
as shown in the example below.
adminGroups = ${stackstate.authorization.adminGroups} ["your-custom-oidc-or-ldap-or-keycloak-admin-role"]
platformAdminGroups = ${stackstate.authorization.platformAdminGroups} ["your-custom-oidc-or-ldap-or-keycloak-platform-admin-role"]
powerUserGroups = ${stackstate.authorization.powerUserGroups} ["your-custom-oidc-or-ldap-or-keycloak-power-user-role"]
guestGroups = ${stackstate.authorization.guestGroups} ["your-custom-oidc-or-ldap-or-keycloak-guest-role"]
// no subject-role mappings here
The list of roles will be extended to include the new, custom roles. The default roles will remain available (stackstate-admin, stackstate-platform-admin, stackstate-guest and stackstate-power-user).
Provider Specific Instructions
File based authentication: Use the platformadmin
username for platform management instead of admin
. The admin
user remains functional and has full content management rights as before.
External authentication (LDAP/OIDC/Keycloak): An additional role/group should be created in the external authentication system and mapped to the new StackState platformAdmin
group.
platformAdminGroups = ${stackstate.authorization.platformAdminGroups} ["your-custom-oidc-or-ldap-or-keycloak-platform-admin-role"]
Users who are assigned this group/role will get platform management permissions. If you wish for one user to manage both the content and the platform, you will still need to configure the external auth provider with two separate roles/groups and then assign both of those to a single user in the settings of the external auth provider. You should not map the same external role/group to different StackState authorization groups.