Security - Infor Ming.le

Security is role-based. That is, permissions are defined in roles and then users, or groups of users, are assigned to those roles. There is thus no direct mapping of users or groups to permissions. Users can be assigned to multiple roles. The assignment can be direct, or indirect - through groups that are assigned to roles.

We recommend that you adopt these best practices:

  • Do not grant privileges that users do not require. Assign the minimum number of roles that are required.
  • If a user must have all privileges, then create and grant a role that provides all privileges. Do not assign the user to all roles.
  • Keep to a minimum the number of IFS roles that are assigned to an IFS user. The more roles that an IFS user has increases the amount of data to be communicated and cached when the user signs in.

There are two types of roles: application roles and data roles.

Application roles enable you to define permissions on all three authorization levels (Global, Object, Data). Typically, application roles are used for business roles, such as Sales Manager, Controller, etc.

Data roles enable you to define permissions on the data level only

Users can be assigned to multiple roles. The assignment can be direct, or indirect - through groups that are assigned to roles.

Roles are bundles of permissions that can be assigned to users and to groups. Permissions determine what actions can be carried out by users in specific roles, on different types of object. There are these types of permission and role:

  • OLAP roles: These are bundles of OLAP permissions.
  • OLAP permissions: These are used to restrict access to OLAP data cubes, elements, and cells.
  • Repository roles. These are bundles of repository permissions.
  • Repository permissions. These provide global farm permissions.
  • Application roles. Application roles control who can view or edit reports, dashboards, and permissions within an application.
  • Application permission. These provide global application permissions such as permission to edit reports or dashboards, or the permission to administer permissions. Application permissions are also granted on the level of individual objects. For example, they determine who can see which reports, dashboards, and folders. Object permissions are defined in Application Studio reports and in dashboards.

Every application, including those that you create, has predefined system application roles, which are intended for use by system administrators.

System application roles include these roles:

  • AdministratorRole
  • DesignerRole
  • MasterRole
  • ViewRole

Each system application role has predefined application permissions. The system roles, and the permissions assigned to them, cannot be edited or deleted. Thus, you cannot, for example, remove access to a particular report from a member of a role that has permission to browse all reports and folders. We recommend, therefore, that you do not assign users to the system roles.

In addition to system roles, applications that are supplied by Infor have predefined, application-specific, roles. Like the system roles, these predefined roles cannot be edited or deleted. But, unlike system roles, the predefined roles are intended for you to use. They, and their associated permissions, are designed to avoid, as far as possible, the need for you to create roles and permissions.

If Infor EPM is running in Infor Ming.le, authentication is through Infor Federation Services. Three IFS security roles are automatically assigned as user groups in every Infor EPM application that is provisioned in Infor Ming.le. Thus, for an application that is running in Infor Ming.le, it is not usually necessary to administer user permissions in EPM Administration. The three groups are BI-Viewers, BI-PowerUsers, and BI-Administrators.