.png)
Throughout my career as a consultant, clients frequently brought up the requirement of using custom security configurations and moving those custom security roles across environments – especially in industries with tight regulations/policies on segregation of duties. That said, I want to share how easy it is to manage security configurations across environments for the support department.
Requirement: A support department worker needs the ability to add and test custom security roles in a TST instance and move approved security custom security roles to PROD.
Possible solution Approach: 1. Development in Visual Studio vs. 2. Configuration on runtime and leveraging 1. deployable packages vs. 2. Export/Import functionality on Security configurations form.
As the requirement specifically addresses the need for a support department worker to add/test/move custom security role configurations, I will address this specific topic in detail today.
A) Custom Security Role Configuration
Navigation path: System administration/Security/Security configurations
Here under Roles, we have now 2 ways to create a new custom security role:
a) Leveraging +New to create a new role and associating all necessary duties and privileges manually/from scratch.
b) Leveraging +Duplicate, copying an existing role and simply adding/removing duties and privileges needed/not needed.
As a first rule, I personally always recommend not to touch/adjust OTB security roles. Also, as I personally consider efficiency quite important I usually have conversation with the client up front to determine if the needed custom security role comes close to an out of the box role. If not, I would recommend going with a) above and create a security role from scratch. However, for the majority of cases the security need came close to an OTB role. Respectively, I advised to duplicate an existing role and perform necessary adjustments from here. (b) above) This does not only save work efforts as many roles have multiple duties and privileges associated but is also cleaner.
For this post, we will assume the security need comes close to an OTB role (E.g. the Accounting Manager Security Role). Assuming my client is “Segurado Industries”, I would leverage the ability to create a unique identifier/naming for the custom security role for this specific client. I usually recommend using a company prefix and adding the OTB name. For example, here: “Segurado Industries Accounting Manager”.
After confirming, the OTB has been duplicated under the new name above. We have now the ability to remove duties and privileges that were copied form the OTB role. By leveraging the add references functionality, I am also able now to add duties and privileges to the newly created custom security role.
Let’s assume the accounting manager should be able to maintain purchase orders. The OTB does not allow to execute this action. Well, you may wonder now what is the correct security duty to assign now? Let me aid you here. We are navigating to the form where the action is to be performed. Here: Procurement and Sourcing/Purchase orders/All Purchase Orders.
On this form, we are performing security diagnostics to identify all roles, duties and privileges that are associated with this form and give view and/or edit rights. As a general rule, “inquire” duties only provide view access while “maintain” duties provide edit capabilities. That said, as we want to equip our “Segurado Industries Accounting Manager” with edit rights for purchase orders, we can identified now that the “Maintain purchase order” duty is to be assigned.
After performing the security analysis, we now can add the “Maintain purchase orders” duty as a new reference to my prior created custom security role.
You may be wondering now are we done yet? No, we are not yet. We still need to publish the security adjustments. We can execute this task in the same form under unpublished objects.
The custom security role is now ready to be assigned to your user and to be tested. We will navigate to: System administration/Users/Users. For this example, April is the lucky one to chosen for security role testing. After drilling down in her UserID, I am now able to assign the newly created security role to April’s UserID by leveraging +Assign roles. As a rule for security role testing and to avoid any conflicting impact from other security roles assigned, I recommend removing all other existing security roles from your user but the custom security role that is to be tested. Also, please make sure to execute positive (=Yes – I can perform a specific task as expected/wanted) as well as negative testing (=No – I can’t perform another specific task as expected/wanted). Thorough testing with positive and negative scenarios is key and prevents rework here. That said, it makes sense to note down all possible scenarios with expected results prior to starting the testing phase.
April – It’s all yours now. Let the testing begin.
B) Move security between environments
In the above, after publishing the changes, the security objects are changed on the runtime only. In order to move the from April tested and approved custom security configurations now from the TST environment to any other instance, we still need to export/import the changes from A (TST) to B (PROD).
Navigation path: System administration/Security/Security configurations
We are leveraging the export/import data functionality to extract all published security configurations in TST and import those in PROD.
The extracted xml file from TST would looks like the below and contains all published security configurations.
After the import in PROD is completed, you are ready to go to assign the security role to the appropriate users. Voila!
Additionally you can also leverage DMF and the following entities to extract custom security configurations from environment 1 and reimport into environment 2:
Security role metadata customizations entity
Security duty metadata customizations entity
Security privilege metadata customizations entity
Additional Information
a) Note that the name of roles is a GUID ID. This GUID ID is the primary key and dictates if a new role should be created or if an existing role should be modified. That said, all custom/newly created security objects do have such a GUID ID where objects created in Visual Studio would have a readable object name.
b) Security configurations should be treated as code and should run through multiple testing cycles before being promoted to the next instance. E.g. 1. Creation and first testing in DEV box 2. Promote/import security adjustments to TST and test 3. Promote/import security adjustments to PROD.
c) If you would perform security adjustments through Visual Studio, the security data is stored in XML format within the project folder under the AosService/PackagesLocalDirectory folder and are categorized by the security layer type. 1. Roles – axsecurityrole; 2.Duties – axsecurityduty; 3.Privilege – AxSecurityPrivilege
d) If you create/adjust a security role, duty, or privilege from the UI, the security data is stored in the database as actual data within tables categorized by the security layer type. 1. Roles – SecurityRoleCustomizeDiskObject; 2. Duties – SecurityDutyCustomizeDiskObject; 3. Privileges -SecurityPrivilegeCustomizeDiskObject
e) Please note that when modifying the security lawyers not just deltas but the entire XML object is stored in the data column. Also, as soon as a security customization is published in the UI, it doesn’t matter what change is made in the AOT, the UI version will override it and take precedence.
f) In case you perform security adjustments in the AOT, security is basically treated as code. That said, you can export the security data with the deployable packages functionality if needed.
Thank you for your read and I hope you zap in soon again! Please let me know your thoughts and feel free to subscribe and share. 🙂
Comments