Provide new roles from imported models with "access rights"

UAA
1

Context

Our <PROJECT_NAME> projects allows to add “business applications” by uploading new A12 models at runtime into the existing A12 application.

These uploaded model may contain new “roles”, as some forms shall be presented to some users, but not to others (and vice versa).

Our problem

These new roles have got no “access rights” (as defined in roles.yaml) in a static A12 application. So we need to assign those during the runtime of the application.

Our question

How can we achieve to assign “access rights” to new roles a runtime?

(The UUA tag may be not the right one, please change to an appropriate one)

2

You might want to take a look at the Principal Extension of UAA:

UAA supports principals containing roles with ACCESS RIGHT(s) assigned to the role. The mapping between role and access right(s) can be defined in the file and it’s managed by the Principal Extension

This extension also provides a com.mgmtp.a12.uaa.authentication.principal.RoleMappingLoader<T> interface that you could implement to load your additional role access right mappings from somewhere else. For example you could store those as documents as well and load those documents. Than updating your roles access rights becomes just updating some documents.

3

Thanks.

Looks like the RoleMappingLoader is only called at system start and then again at login. How would I trigger it “on model imported” (paraphrased)?

Or can I simply overwrite the values held in my implementation of the RoleMappingLoader at runtime from another class? Or would that break things?

4

There are events triggered once models are created or updated. But listening to them might not be sufficient because that would require you to update role mappings always before updating or creating models.
If you store role mappings as documents it might be more suitable to listen to events related to those documents and reload mappings then.

But I have no experience myself with the RoleMappingLoader api.

5

Small remarks at this topic.

Allowing the user to import new roles is pretty dangerous, because it enables users to override existing a12 roles or create a12 roles that have more access then the current user. A12 roles should be a static concept how you application handles certain types of users.

In order to support dynamic user groups for dynamic “business applications” you have to create a concept how you wanna handle these. For example you have BA1 and BA2 as “business applications” and you have the roles “manager” and “officer”. Then you can design your system to reflect that by creating roles “BA1:manager”, “BA1:officer”, “BA2:manager” and “BA2:officer”. In your authenticationDefinition.json you need to reflect this by e.g. calling helper code to de-structure the role strings.

6

Yes, I’m aware of that. The current (first) implementation assigns the access rights of the “default” role “user” to newly discovered roles, as defined in our roles.yaml. However, one cannot change the permissions of any role by uploading models.
Furthermore, the user that is allowed to upload new models needs to be “admin” anyway, so that only privileged persons can “add” new roles by uploading models.

What concerns me more is, that as a consequence of implementing our own RoleMappingLoader we had to pull down the RoleMappingAutoConfiguration from A12 into our application. Which means we have to maintain it ourselves, rather than relying on A12 at this point.

But even worse is that for the latter we had to allow allow-bean-definition-overriding. Please advise how to mitigate that…