In this blog, I have tried to cover the concept of Hyperion Security. Application security forms the nervous system of any Hyperion Application & must be designed in the most efficient manner, without missing out on any requirement from the Business User.
Application Security is a vast concept & this blog intends to provide in-depth knowledge for anyone ready to take the challenge of designing the security.
Hyperion security spans across below mentioned modules:
Oracle Shared Services Console
Oracle HFM
Essbase & Planning
and FDMEE.
All of these leverage the Shared Services for their maintenance.
An organization would normally have several small entities. The financials will more likely be accurate if users are assigned appropriate security so that it prevents them from making unintentional or accidental errors by only having the minimum access required to perform their specific job roles.
There are two layers in the Security Design:
1. Application Roles - would define what all actions a user can perform in different applications.
2. Metadata Roles - would define, the members in metadata to which a user will have access & the type of access as well. Every member in all dimensions have a property called SecurityClass. This property is used to group dimension members for access to data. Although every metadata member has the SecurityClass property, security is usually applied only on the Entity dimension.
Security is a double edged sword, fine grained security will require more security administrator effort.
Windows active directory groups are often used to group users. The advantage of group users is that more than one user will have access in case of vacations or someone's absence
1. Oracle Shared Services Console:
Central Module to perform every kind of security detailing for any Hyperion Application. The module would contain a list of all available roles from registered products.
2. Provision:
EPM System predefines tasks or collections of tasks into Roles.
3. EPMA Dimension Management:
To manage security for EPMA Dimension Library, all users can be granted 'Dimension Editor' role & individual dimension can be managed from "System" Menu in Dimension Library
4. Calc Manager:
To assign access for this module, user has to be given 2 roles in HFM : Rules Designer & Viewer, & then in Shared Services, one per product.
5. Provisioning Manager:
This role would enable users to grant or revoke the role access or class access for other users, however, they would not be able to perform similar action for their own id, unless they are assigned Shared Services Administrator role.
6. Reporting & Analysis Roles:
Almost all the roles correspond to Interactive Reporting / Production Reporting
7. FR Role Recommendation:
- Administrator can do anything except provision other users
- User with "Report Designer" role would need to install Studio client.
- "Explorer" role issues read access for all the reports.
8. HFM Roles:
- "Administrator" role allows every task to be performed except managing Provisioning.
Group Based Model or User Based Model?
- Best practice would be to create groups in Native Directory, & assign them roles and Security Class Access.
- The assign the users to the relevant groups.
- However, this approach is not very efficient if number of groups becomes more than number of users.
Native Directory or Windows Active Directory?
- Make use of security policies from external providers (MSAD/LDAP), since Native Directory does not reinforce any password management policy on its own.
- Allows IT security to control users
- Hyperion admins are best suited to control access
- Auditing Reports for every application can be retrieved from the Shared Services Console.