We introduced a flexible mechanism to configure access groups and permissions. That is currently configured via access-control-schema.xml. However, for authorization in our code we use @RolesAllowed, etc. and need to reference permissions declared in the XML file. Therefore we introduced some generation of code artifacts declaring these as Java constants.
In the end there is no value in using XML for this at all. Instead we should introduce a new mechanism as alternative to declare these constants as code with the following benefits:
no technology gap (Java vs. XML) - just one language, no context switching, direct references, refactoring, debugging down to the root, etc.
directly reference the permission constants from the root source code
no intermediate code generation or duplication needed
freedom to choose project specific names (if you have many OASP apps in one IDE you currently end up with many files of the name access-control-schema.xml - instead you could have app specific prefixes or suffixes for Java files).
config as simple spring-bean (declare your specific access control schema config in your spring-boot app package so it will be scanned and therefore found and can be injected into oasp4j-security component).
In order to keep the java class replacing access-control-schema.xml as simple as possible we should introduce an abstract super-class that declares according (helper) methods as a kind of DSL.
Finally, it is important to keep compatibility so the access-control-schema.xml is still supported (as legacy) so that existing projects are not affected and will not break in any way.
We introduced a flexible mechanism to configure access groups and permissions. That is currently configured via
access-control-schema.xml
. However, for authorization in our code we use@RolesAllowed
, etc. and need to reference permissions declared in the XML file. Therefore we introduced some generation of code artifacts declaring these as Java constants. In the end there is no value in using XML for this at all. Instead we should introduce a new mechanism as alternative to declare these constants as code with the following benefits:access-control-schema.xml
- instead you could have app specific prefixes or suffixes for Java files).oasp4j-security
component).In order to keep the java class replacing
access-control-schema.xml
as simple as possible we should introduce an abstract super-class that declares according (helper) methods as a kind of DSL.Finally, it is important to keep compatibility so the
access-control-schema.xml
is still supported (as legacy) so that existing projects are not affected and will not break in any way.