Firstly, it is worth noting that users belong to user groups created by the administrator. These groups are configured in the application wic_conf and have one or more databases associated with them.

Access security is a filter that administrators may apply to a user group so that its members can or cannot view certain data. This process is carried out using wic_conf, where the administrator establishes these permissions semantically.

The full process is outlined below. The administrator must select the option “Security Roles” -> “OLAP Access” -> “Register”. Once in this area, the administrator creates a new document and enters the role, type, and name of the entity, as well as their access privileges. There are three types of access:

• None: the user cannot view any data from the cube.
• All: the user can view all data from the cube.
• Custom: the data which the user sees will be determined by the object hierarchy.

The next step in the role creation process is for the administrator to set which schema, cube, hierarchy, and members are associated with the role. Later, this will allow them to filter which data the user can view. In Section 3, Using the Tool, these objects were introduced, but we will now describe the hierarchical relationship between them:

• Schema: defines predetermined access settings for objects in a schema (none, all, custom).
• Cube: defines access settings for a particular cube (none, all, custom).
• Dimension: defines access settings for a dimension. The “all” access level signifies that all of the secondary hierarchies within the dimension will obtain inherent access. The “custom” access level signifies that the user role will not obtain inherent access to secondary hierarchies unless they are explicitly conceded to the role by using the HierarchyGrant element.
• Hierarchy: defines access settings for a hierarchy. The access attribute may be “all”, signifying that all members are visible; “none”, meaning that the existence of the hierarchy itself is hidden from the user; and “custom”.
• Member: a MemberGrant element can be defined if its included HierarchyGrant has the "custom" access level. MemberGrant for members concede (or remove) access to a specific member and all of its children.