In this chapter, we will go through the design of the security for our application, which will be used by the security administrator to assign relevant roles to users.
We will cover the following topics:
- Setting up license and configuration keys
- Designing the security structure
- Creating privileges
- Creating duties
- Creating roles
- Providing access to server methods—code permissions
- Designing and creating process cycles
- Restricting access to data using policies
These are most relevant to organizations that create solutions that are used by more than one end user organization, such as an ISV.
License keys are only available for ISVs and allow them to control access to their software. These are not relevant to users, except that we may remove a license key if a block of functionality is not required.
Configuration keys allow us to enable or disable functionality system-wide. We typically associate these keys with extended data types, tables, and menu items, and if the associated key is disabled, it will appear to the user interface as if the associated entities do not exist.
Configuration keys are sometimes used by end user organizations if they are creating a solution that is also used by sister companies, or by a VAR that creates a vertical solution for their customers. In this way, we can write an application, allowing the customer to decide which elements of the solution are available.
Configuration keys are managed by navigating to System administration | Setup | Licensing | License configuration, as shown in the following screenshot:
In the preceding example, you can see that configuration keys are nested and some of the root elements are locked. This is because the configuration key is linked directly to a license key. To disable these keys, the license code must be disabled using the neighboring License information form.
We can see this in the AOT by navigating to Data Dictionary | Configuration Keys, as shown in this screenshot:
The BankCheque, BankDeposit, and other configuration keys have the ParentKey property set to Bank, causing it to be nested in the License configuration form.
The configuration keys are then associated with extended data types, menu items, tables, and views by the element's ConfigurationKey property. Be careful! Disabled configuration keys remove data from tables, although the physical table will still exist, which is useful if we have analysis services cubes that use the tables in their data view definition.
Should a view include data from a table that is disabled through a configuration key, you will get a warning when synchronizing the database that the view cannot be created.