I'm trying to redesign a provisioning application that administrates other application through their REST API.
The application is quite simple, we have groups, we have users and roles and we have a list of software to provision.
We are giving access to some software to groups and we are applying different strategies to these groups. These strategies are tightly coupled to the software we provision, they are just a list of operations that will be executed using the REST API. For example we have a strategy to create the group in the application, we have another to create the component A with the configuration X, we have another to create the component B with the configuration Y...
These strategies are executed at the creation / update of the group through a message sent to our message broker. The message contains all the relevant data (related to the group) to configure the provisioned application.
We have a similar approach for users. When we add a user to a group that has access to the application X, we are sending a message to the message broker to create it in the application X. When we are giving him a role, we have the corresponding role the the application and are giving him the role with the same process.
It works pretty well, however the main problem is that these strategies only exists in the code and we need to create a new class for each strategy we want to create. It is the same for roles, if we introduce a new role we need to give it an equivalent in the distant applications.
What we'd like to do is to bring these information in the database. We could register allowed operation for each application and let every administrator of every group create their own strategies instead of relying on us, same thing for roles. The role X could have a different meaning for different groups.
Is there some kind of pattern to help us design the database ? Have you heard of existing software having this kind of workflow ?
Because we really have trouble translating our current process into what we are aiming for and maybe it needs to be rethought instead of simply trying to reproduce it.