Manage security profile access

You can create multiple security profiles tailored to different use cases and assign role-level rights to each profile. A common approach is to create separate READ and WRITE profiles, then allocate data access to specific roles within these profiles. For example, you might let the European Controller role read all entities in the READ profile. You can also limit write access to entities within the European Division in the WRITE profile.

To manage security profiles, navigate to the Security module and select the Security Profile Access tab.

Before you start creating security profiles, define the security policy you want to implement. Find the areas you need to limit, such as access to entities or cost centers, by drawing a diagram, chart, or table. For example, create a table listing each entity along with the roles that should have read-only or write permissions before you build the security profile. Understanding your security policy helps you determine the roles you need to create. If you're following an entity-based security policy, you'll likely need to create a role for each entity or group of entities. For example: 

To create a security profile:

• Create user roles based on your security policy.
• Create a new profile. Review the Create a security profile section below for more information.
• Define dimensions and hierarchies for member access restrictions by role.
• Assign roles to each hierarchy that require access to definitions.
• Specify members to include and exclude for each role.
• Assign roles and specify members for each hierarchy and role combination.

Typically, there'll be two profiles that need to be created and configured: Read and Write. You can create more profiles as needed. To manage metadata security effectively, follow these important rules:

When creating security profiles, you must specify which dimensions you want to control. Define hierarchies in the dimension within the Metadata editor first. If you don't explicitly define a hierarchy in a profile, all users will have access to every member in that hierarchy. For example, if you don't include the Account hierarchy in the profile, all users can access all accounts. 

If you define a hierarchy in a profile, roles without data access rules will have no access to any members in that hierarchy. This means you need to set up data access rules for each role carefully.

There are different elements of security in the system:

• Security Profile Permissions: control access to specific data members.
• File System Security: determines what objects users can access in the Explorer.
• Role Authorizations: grant access to specific tasks and functions within the application.

Permissions are applied one after another. This allows you to grant broad access initially and then restrict it in subsequent permissions. For example, you can give access to all members in a sub-hierarchy in one permission and then deny access to specific members afterward.

If a user has multiple roles, their authorizations are combined. This means that if any of their roles grant access to a particular member, they'll have access to it.

By understanding and applying these rules, you can effectively manage metadata security in your system. You can:

• Create a security profile
• Update ‌profile name
• Update a role assigned to a security profile
• Update member access
• Copy member access from one role to another role
• Copy a security profile
• Import security profiles