AX1849

Using product solutions to manage security for visualization reporting

Some model types control access to model data outside of the Axiom Security Manager. This mode of security works as follows:

  • Certain tables in the model are flagged as dimension tables. Model security can be defined on dimension tables. Any security defined on the dimension table applies to data in that table, and data in any tables that look up to the dimension table.

    For example, imagine the Encounter table looks up to the Entity table. The Entity table is a dimension table. You can define security on the Entity table, which controls access to the Entity table and to the Encounter table.

  • Dimension table security can be defined at the role level and at the user level. Users and roles can be granted full or filtered access to a table. If a user does not have any permissions defined for a particular dimension table (either defined for the user or inherited from a role), then that user will be unable to view data in that dimension table or any table that looks up to it.

    If a table looks up to multiple dimension tables, then the user must have access to all of the dimension tables in order to access the data in that table. The various dimension table permissions are combined using AND.

  • Subsystems do not apply to model security. Roles can only be used to define model security if the roles do not belong to a subsystem.

  • If a table is not a dimension table, and does not look up to a dimension table, then no security is applied to that table. Any user can view the data in that table.

If the model delivered by a product uses this type of security, the product will provide a utility that allows you to set permissions on dimension tables for users and roles. Please see your product documentation for information on whether this type of security applies to your model, and how to manage your security settings.

If you make changes to Axiom security that would impact your model security settings, you must process the model so that these changes are applied to visualization reporting. For example, the following changes would require the model to be processed:

  • Adding a user to a role that has model security permissions
  • Removing a user from a role that has model security permissions
  • Enabling or disabling a user