Hello,
We are trying to alter default security setting for role owners such that they will see role related pages only in "read-only" mode. For this purpose we have create below SecurityContext.csv file and uploaded it from the UI. However, role owners still have edit privileges on roles.
Are we missing any step?
When a security context file is uploaded using the UI interface, the entitlements defined in it do not override what is defined in the default SecurityContext.csv file. The UI interface can only be used to add additional user entitlements.. For example, to grant View/Edit privilege on roles to a user defined by custom user attribute on the role.
If the privileges granted by default security context need to be restricted, the only way that can be done is by changing the SecurityContext.csv file that exists in WEB-INF folder.
Hello,
- Below files are modified;
1 - /home/oracle/Aveksa_7.0.0_P02/aveksa.ear/aveksa.war/WEB-INF/SecurityContext.csv
2 - /home/oracle/wildfly-8.2.0.Final/standalone/tmp/vfs/temp/tempcc6562348db18980/content-e5d1e3484ea9804f/contents/aveksa.war/WEB-INF/SecurityContext.csv
We know 2nd path is a temporary one which is regenerated everytime the server is restarted
- Server is restarted
We observed SecurityContext.csv is copied to another temporary folder under /home/oracle/wildfly-8.2.0.Final/standalone/tmp/vfs/temp/.. but the files still have the old values. And Role Owners can still modify roles.
- I checked from linux shell as well but could not find any other instance of SecurityContext.csv file anywhere.
What is that we are missing here?
Though changing SecurityContext.csv seem to be the only way to properly achieve your requirement, changing that directly is not suggested. I think it gets overwritten when a patch is applied or on a upgrade for example.
In the case, the issue is with how the wildfly works. Wildfly deploys the ear everytime it starts into the temporary folders you described. So, it is the securityContext.csv file in the ear file that gets deploed to temp folder everytime server is restarted.
With wildfly, the ear needs to be updated and redeployed to make sure the changes do not get blown off. This is however not suggested as the file can get overwritten as described above (and will need to be overwritten in some case where the list of default user entitlements have changed.)
One solution would be to not collect role owner attribute and instead collect the owner as some custom user attribute on the role. In the way, the custom user can easily be granted view privileges by using your initial recommended approach (uploading context file from UI). This however will not work if you absolutely need to collect role owner for other reasons.
Hello,
We aware the fact that default SecurityContext.csv can be overridden with patch upgrade and we still want to overwrite it.
However editing file under EAR (/home/oracle/Aveksa_7.0.0_P02/aveksa.ear/aveksa.war/WEB-INF/) is not reflected to the final location that wildfly puts into after each restart.
What is that we are missing here? Is there another file in another location?
You need to modify the actually deployed ear file using the script /home/oracle/deploy/customizeACM.sh. Details of usage can be found in the Via L&G v7 install guide under "Customize RSA Via L&G"
You say: "entitlements defined in it [securitycontext.csv] do not override what is defined in the default SecurityContext.csv file". This is different from the perceptions some customer have. Customers want to modify the existing entitlements, and I have seen customers import a full copy of the default file in an attempt to accomplish this. The user interface does not prevent this import but this creates duplicate security entries which leads to indeterminate behavior. We need to warn customers against this practice. Mostafa is recommending replacing the default file, which appears to work, but is this a supportable solution?
Couple of more general questions on this topic ...
When a security context file is uploaded using the UI interface, the entitlements defined in it do not override what is defined in the default SecurityContext.csv file. The UI interface can only be used to add additional user entitlements.. For example, to grant View/Edit privilege on roles to a user defined by custom user attribute on the role.
If the privileges granted by default security context need to be restricted, the only way that can be done is by changing the SecurityContext.csv file that exists in WEB-INF folder.