This post describes a security model for larger HFM applications (roughly more than 50 users or 50 entities). The model is probably too complex for smaller applications (roughly less than 10 users or 10 entities). However, elements of the model, for example the security class naming convention, would be useful for smaller applications. In between these sizes, the suitability of the model depends on the complexity of the security requirement.

Assigning security class

The first step is to assign security classes to the dimensions and artefacts being secured. The naming convention for security classes is:

D_M

D indicates the dimension or artefact being secured, for example:

  • A – Account
  • C1 – Custom 1
  • D – Documents
  • E – Entities

M indicates the member or artefact being secured, for example:

  • Names of base members
  • Names of parent members
  • Names of groups of members or artefacts

Examples of possible security class names are:

  • E_1002 – Class for entity 1002
  • A_GROUP – Class for accounts for group use only
  • A_CLOSED – Class to make closed accounts read only
  • D_HIDDEN – Class to attach to hidden documents

Normally each entity is given its own security class for maximum flexibility. However, this does create more administration so it may make sense to give related entities the same security class – as, for example, in this hierarchy:

3000 ABC Group
 |-3010 ABC UK Group
 |  |-3020 UK IT
 |  |-3030 UK Consulting
 |  |-3040 UK Technology
 |  `-3050 UK Overhead
 |-1002 ABC Germany GmBH
 |-1003 ABC USA Ltd
 |-1004 ABC France SA
 |-1005 ABC Italy SA
 `-1006 Consol adjustments

If the UK entities are input and managed by the same users you might give entities 3010, 3020, 3030, 3040 and 3050 the same security class of E_3010.

Provisioning by native groups

This security model provisions users with roles and classes by adding them to native groups. Users are never individually provisioned with roles and classes. Native groups are used because they can be easily managed by HFM administrators. Other directory groups can usually only be managed by the directory administrator. The benefits of this approach are:

  • Provisioning a few native groups with roles and classes and adding users to these groups is easier than individually provisioning many individual users with roles and classes.
  • If a group of users needs a new role or class this can be added once to a group instead of updating many users. For example, if input users need a new role this can be added once to the input users role group.
  • The roles and classes a user has can be seen on one screen, the user properties screen. You do not need to separately check role provisioning and class access. This saves a lot of time.
  • Users are consistently provisioned. It is impossible for a user be provisioned with an additional role or class accidentally.

Creating native groups

The next step is creating native groups. The naming convention for native groups is:

A_D_M_R

A indicates the application the group secures. If your application name has more than three characters I would recommend abbreviating it. Long group names are truncated in some version of Shared Services and it makes it quicker to filter groups using wildcards.

D indicates the dimension or artefact being secured. Suggested values are:

  • A – Account
  • C1 – Custom 1
  • D – Documents
  • E – Entities
  • R – Roles

M indicates the hierarchy or member being secured. Its name should be exactly the same as the member name in HFM. This makes it easier to relate security groups to members and hierarchies.

R indicates if access is read or all (read and write). Suggested values are:

  • R – Read access
  • A – All access

Examples of possible native groups are:

  • ABC_E_3000_A – All access to entities in the 3000 hierarchy in the ABC application.
  • ABC_C1_HDW_R – Read access to the HDW custom 1 hierarchy in the ABC application.
  • ABC_R_Input – Input roles for the ABC application.

When using groups to assign classes, the group must be given the Default role. Otherwise it is not possible to assign classes to the group.

Provisioning hierarchies

Giving users access to hierarchies is one of the major benefits of using groups. For example, ABC Group has the following entity hierarchy:

3000 ABC Group
 |-3010 ABC UK Group
 |  |-3020 UK IT
 |  |-3030 UK Consulting
 |  |-3040 UK Technology
 |  `-3050 UK Overhead
 |-1002 ABC Germany GmBH
 |-1003 ABC USA Ltd
 |-1004 ABC France SA
 |-1005 ABC Italy SA
 `-1006 Consol adjustments

Without using groups, giving UK users access to the UK hierarchy would mean having to provision every user with all the entities in the UK hierarchy and then identifying and updating them when adding a new entity. With a simple hierarchy that would be possible, but with larger hierarchies it would be difficult, time consuming and error prone.

Using a group makes this much easier. For example to create a group for the 3010 hierarchy in the above example:

  1. Create a native group ABC_E_3010_A.
  2. Give this group the Default role.
  3. Assign security classes E_3010, E_3020, E_3030, E_3040 and E_3050 to the group.
  4. Add the UK users to the group.

If you add an entity to the UK hierarchy you just add it once to the ABC_E_3010_A group and all UK users have access.

Provisioning multiple dimensions

A group should only be used to secure a single dimension, or roles. Groups should not be provisioned with member from more than one dimension, or with both dimensions and roles. This is to make it easier to understand what groups do and how users are provisioned. If a new dimension needs to be secured, new groups should be created. For example, ABC group analyses sales by product using custom 1. If you wanted to restrict users to seeing UK hardware sales it is best to use two groups

ABC_E_3000_R – Gives read access to UK entities

ABC_C1_HDW – Gives access to hardware products

This is more flexible and easier to understand than creating one group, say ABC_3000_HDW.

Role groups

The use of role groups is not recommended for the following reasons:

  • Role groups are not normally used when configuring HFM security.
  • Role groups increase complexity.
  • Roles can be grouped using native groups; role groups are not needed.
  • Using only native groups allows all user provisioning to be checked on one screen.

Groups as members of groups

Making groups members of other groups might seems like a good idea as it could reduce the repetition of configuration. However, it is very confusing and I have never found a situation where the increase in complexity is justified.

How to configure Oracle Financial Management (HFM) security