The various account types described above are assigned different authorization roles. These roles limit the methods that can be invoked. No additional permissions should be granted to UA authorization roles except for Linked accounts, which use the LINKEDCITIZENROLE. If adding additional custom methods to citizen account, additional permissions will be required. This is explained in the chapter regarding the customisation of citizen account.
If only a subset of the functionality offered by UA is being used, permission to invoke the unused methods should be removed from the database. For example, if citizen account is not being used, the LINKEDCITIZENROLE and other related authorization artifacts should be removed, as they are not needed. Projects not using citizen account should also consider the deployment implications. This is discussed in the chapter that discusses citizen account customisation.
Authorization roles should be configured only for the areas of functionality that are actually being used. It is recommended that unused SIDs should be removed from the database. For example, if citizen account is not being used, the LINKEDCITIZENROLE and other related authorization artifacts should be removed, as they are not needed. Projects not using citizen account should also consider the deployment implications. Please see the Citizen Account - Security Considerations section for more information.
Proper use of the UA Authorization Roles and Groups will ensure that no user can access functions for which they have no permission. It will not however, prevent users from using these functions to access data belonging to user users. This is the preserve of Data-based Security. UA provides a framework for Data-based Security and all customizations should use this framework. Please refer to the Citizen Account - Security Considerations section for more information.