It's currently not possible to configure a role decoder for a virtual security domain. The original reasoning behind this was that OIDC is meant to be used for authentication purposes and authorization isn't part of the spec. So we originally just supported the same role structure for access tokens as the previous Keycloak adapter.

That being said, we have seen requests to be able to make use of roles from other access token claims so it does sound like this is something that would be good to address.

One option would be to add a new attribute to the elytron-oidc-client subsystem secure-deployment resource to indicate the name of the claim from the access token to attempt to get the roles from. This would work for simple role formats.

Another option would be to add the ability to configure a role-decoder for virtual security domains. This would allow more complex role structures to be supported since a custom role decoder could be used. This would need to follow up on some other work we are doing where we are planning on adding a new virtual-security-domain resource that will make it possible to configure some other attributes for virtual security domains (see WFLY-16793 for more details on that).

Given the info from ELY-2488 about access token implementations for common OpenID providers, the second option is likely the way to go since it would allow for the most flexibility.