Basic Security
- Ada atrajer
One of the important considerations for deciding on using TM1 as the database for the
ContentStore rather than a more typical choice of database for a web application (e.g. Mongo, Couch) was that using TM1 as the database makes the ContentStore accessible and relateable for TM1 Developers & Administrators. Hence you should have no difficulty in understanding how and why security is applied, and if necessary modifying and even trouble-shooting security.
Built-in roles
By default the ContentStore comes with 3 built-in user groups:
» APQ User
All users must be members of this group. (This is taken care of in the daily maintenance job and user creation processes)
This covers access to all objects required for Apliqo UX front end to function correctly
READ access to public apps
The ability to create and edit private apps
» APQ PUser
This group is for "power users" or "report authors"
Access to this group needs to be granted manually
Members of this group can be granted WRITE access to public apps, including the ability to create and delete public apps
» APQ Admin
This group is for "ContentStore Administrators" and has the ability to manage most aspects of the ContentStore (without full TM1 Admin rights)
Access to this group needs to be granted manually
Members of this group have automatic WRITE access to all public apps, including the ability to create and delete public apps
Members of this group can export and import public apps from files or the Apliqo App Mart
App security
The main security to be aware of in Apliqo UX is access to "apps". All apps (screens in the UI) are consolidations in the }APQ UX App dimension which have children being the individual views, widgets, popups, etc. Access by users to apps is managed via "plain vanilla element security".
The default setting which the ContentStore ships with is that all end users (members of the APQ
User group) have READ level access to all public apps and all report authors (members of the APQ PUser group) have WRITE access to all public apps. However, the default settings can be easily changed. In fact it is not necessary for the APQ User and APQ PUser groups to have any element security access to the }APQ UX App dimension. If more granular element security access for end users (and/or report authors) is required this can be managed via additional groups which you can create for this purpose.
Element security for }APQ UX App is managed in a purpose built cube }APQ UX App SecurityAccess
» Default element security for apps
By default members of APQ User have READ access to all public apps. This is inherited from "Main" the root node for all public apps.
In addition to }Groups and }APQ UX App the cube contains a measure dimension with input measures:
Permission Level: this is the primary input measure. The entered permission will be inherited to the descendants.
Permission Level Override: any input in this measure will be forced to the Permission Level measure and stop the inheritance (and in turn be inherited to the descendants of the inputted node).
The other measures in the cube are for informational purposes:
Permission Numeric: a numeric representation of the security level, 0=NONE, 1=READ, 2=WRITE, 3=RESERVE, 4=LOCK, 5=ADMIN
Current Permission Level: a direct feed via rule from the element security cube of the current security
Note: the other root node under public apps "Admin" contains apps which are displayed in the top right of screen in Apliqo UX, whereas the apps under "Main" are found in the App Launcher and App Bar.
» Setting more granular security
Using APQ User group we can illustrate how to set more granular security but the same can obviously be done for any group.
Clear the permission against Main
Set security access only for some apps.
We can see that the security is automatically inherited to the descendants.
Running the process }APQ.UX.Security.Dim.App.LoadAccessRights applies the element security set in the cube to the security model. This can be seen in the Current Permission Level measure.
This process is part of the daily maintenance job.
Even though the element security cube contains no rules security is still inherited dynamically as whenever new dashboards or views are created security is always inherited from the parent object so it is only really necessary to run this process when changing security settings.
Note: that no data entry is required for private apps as this is handled via rule in the }APQ UX App Security Access cube.
Object security
The built in roles also handle access requirements within the ContentStore. From an access and role perspective there is no requirement to create any additional groups and there should not be any need to modify existing role permissions which ship the the ContentStore.
The empty ContentStore installed for a new application ships with permissions for the APQ User, APQ PUser and APQ Admin groups pre-defined to grant the required access for the defined roles. Cube, dimension, process and chore security is covered in the base setup.
Unlike }APQ UX App element security no special interface is provided (or is necessary) for setting ContentStore object security.
Should you edit existing object security permissions for the APQ User, APQ PUser and APQ Admin groups then you do so at your own risk!
Removing or lowering a permission level could adversely affect normal function and cause features in Apliqo UX to no longer work. (Also during any upgrade standard permissions will be reset).
» Chore security
The ContentStore comes with 2 pre-defined scheduled chores. Both are scheduled to run 1x per day.
Only the APQ Admin role has access to manually run chores on demand. By default chores are not accessible to APQ Puser or APQ User.
» Cube security
For normal end users there are very few objects to which access is required in order for Apliqo UX to function properly. These are illustrated below.
}ElementAttributes_}APQ UX App : this is the most important cube in the ContentStore. All view definition settings are stored as attributes against the UX App elements. End users require write access to the cube in order to be able to create and edit private apps. Read (or none) access to public apps versus write access to private apps is managed via element security.
}APQ UX UserPreference : this cube stores user preferences such as display language, hompage, whether to display the favorites menu bar drawer, number & date format, ...
}APQ UX UserFavorite : users have the ability to mark screens as favorites, this cube stores the selections.
}APQ UX Settings Service UserPreference : administrators have the ability to define default members per hierarchy which are used to preset filter selections for key navigation dimensions on login. Users have the ability to override the global default with their own personal preference.
}APQ UX App Log : this cube is updated on each page navigation and keeps a record of the screens accessed by each user.
}APQ UX Connection Log : this cube is updated on login by the user and records OS, device format, browser type of the user
In addition members of the predefined role access groups have:
READ access to all dimensions for all cubes to which they have at least READ access
READ access to all attribute cubes of all dimensions to which they have READ access (unless explicit WRITE access is needed to specific attribute cubes)
You can find an explanation of the function of the additional cubes to which APQ PUser and APQ Admin users have access in the guide to ContentStore components.
» Dimension security
Members of the predefined role access groups READ access to all dimensions for all cubes to which they have at least READ access.
» Process security
For normal end users there are very few objects to which access is required in order for Apliqo UX to function properly, which are basically the processes required for managing private views. These are illustrated below.
In addition members of APQ PUser have access to processes required for managing public apps.
Members of APQ Admin in general have the ability to run all ContentStore management processes.