We are currently using a non-keycloak based identity providers for Wildfly and are trying to use the native Elytron OIDC implementation for providing access.

Currently the format of the roles claims that could be mapped as part of processing an access token are very specific to Keycloak's JWT access token format and only controllable using either the `use-resource-role-mappings` or `use-realm-role-mappings` configuration items.

Keycloak custom role claims look something like:

{
  ...
  "realm_access": {
    "roles": [
      "default-roles-mykeycloakrealm",
      "offline_access",
      "uma_authorization"
    ]
  },
  "resource_access": {
    "myapplicationclient": {
      "roles": [
        "my_role_user",
        "my_role_admin"
      ]
    },
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
...
}

In order to allow the useful mapping of roles into an access token, we need to be able to specify either the data element to pull a list of roles from, or specify the method by which roles could be decoded for a specific access token.

A practical example is with PingFederate. PingFederate allows you to customise the claims of an access token, but does not allow complex data structures (like a hash/object) as the value of a claim so it's impossible to replicate the keycloak structure. We're able to produce access tokens that look something like

{
  ...
  "roles": [
    "my_role_user",
    "my_role_admin"
   ]
  },
  ...
}

Other OAuth2 identity providers may, or may not be able to produce similar claim structures.

In the ideal world, we would like to have control over from where and how we decode roles (similar to the capabilities of what was possible with the keycloak adaptor and a configured security domain). At a minimum we need to be able to specify the attribute to pick roles from.

Not being able to utilise roles is affecting our ability to upgrade past Wildfly v23, currently blocking a very large project, and may ultimately lead to us considering moving away from Wildfly as an application server altogether.