Why do we use Authorities instead of Roles

[DanielOber]

Can we change the the preAuthorize from authorities to roles. Are there any advantages? If we want to keep the authorities we cannot use the Keycloak migration, because it does not support authorities. #184

[DanielOber]

@rowe42 @darenegade whats your opinion about that.

[darenegade]

@DanielOber This is a discussion that we had for a long time when we introduced the Keycloak. The plugins that we deploy are also based on this and I'm not sure to what extent they continue to fulfill their purpose with roles.

In principle, roles would be easier to use from my point of view, but I don't have a complete overview here.

We would have to revisit the topic together with @rowe42

[eidottermihi]

I think the main reason behind using a roles and authorities approach, where the application uses only authorities to check authorization, is the possibility to change or add roles withouth needing to change the application. (as this can be done by solely changing the authorization settings in the keycloak client)

If the application uses just roles for authorization checks the introduction of a new role would need changes in the source code.

[darenegade]

Have you ever needed to introduce a new role that simply merges existing permissions without modifying the application?

In classic RefArch, permissions were managed in a very granular way, e.g. a read and write permission for each entity. However, this had the disadvantage that the keycloak settings had to be adjusted if the data model or similar was changed. In general, you don't want the keycloak settings to be tied to the application design in this way. Especially when the combination of simple roles is an easier way to achieve the same goal.

But this is exactly the old discussion that went on for quite some time. In my opinion, we have gained enough experience over the last few years to re-evaluate the issue. And I don't see the use case for such fine-grained permissions anymore. The application should handle the supported use cases and which simple roles are allowed to do them. If the keycloak wildly reassembles basic permissions, the application may not work as intended.

[eidottermihi]

@darenegade Totally agree, and the "example code" of classic RefArch that had WRITE_ / READ_ / DELETE_ authorities for the sample entity lead many devs to the conclusions, that this is the way it had to be done.

In the end it's a matter of what requirements there are: if there are only a few user roles that also are not very likely to change in terms of permissions (e.g ROLE_USER and ROLE_ADMIN) there is no need to make it overly complicated by authorizing based on authorities.

So IMO if refarch-template includes a "example" use case with just a simple role-based authorization (without authorities), there should be e.g. a link to documentation (maybe with examples), that describes where this approach is totally fine and that also contains examples where using a role-and-authorities based authorization should be considered.

[devtobi]

An internal decision was made to provide role based authorization by default. However we do not enforce this way and thus still have to provide documentation for the other ways of handling authorization concepts. Those are:

• Roles only
• Use-Case roles
• Roles and authorities (the "old" way)