Common User Provisioning in Oracle DRM

1. Overview

Common User Provisioning (CUP) is a DRM feature introduced in version 11.1.2.4.340 that allows individuals to be provisioned access in DRM by joining a group, rather than being given access one by one by a DRM administrator.

  • Instead, the DRM application administrator determines in advance that various subsets of users have the same access requirements
  • Sets up groups for each of those subsets and assigns the appropriate security settings to the groups.
  • Then, when an individual joins the appropriate group or groups, that person automatically gets the correct access to DRM/DRG application.

CUP is not required, rather, it is an option that can be enabled individually per DRM application. CUP works with groups managed by Hyperion Shared Services (HSS), which can either be local HSS user groups (Native Groups) or external directory user groups (CUP cannot control the security provisioning for users set up directly in DRM with internal authentication.) By integrating more closely with HSS, a DRM application with CUP enabled becomes more consistent with the rest of the Hyperion EPM suite, which also uses HSS for user provisioning.

2. Provisioning Security Access for a User

The easiest way to understand how CUP provides security provisioning is to compare how a user gets created and assigned DRM security access without CUP and with CUP. There are three kinds of security-related information that make up the definition of a user’s security access in DRM, once the user has been created. For each kind of information, the user is assigned a list of items of that kind that determine what they can see and do:

  • Roles: Controls what DRM features can be accessed
  • Node Access Groups: Controls what hierarchies and nodes can be viewed and/or changed as well as access to DRG workflows
  • Property Categories: Controls which properties can be viewed and/or changed

 

  Without CUP With CUP
Create User Created using DRM Administer tool. User created in DRM automatically by CUP based on user membership in groups provisioned with a DRM role (see next row).

Note that the groups themselves do not appear in DRM in the list of users. CUP simply automates the process of creating individual users in DRM.

Role Individual roles added/removed for specific user by editing user using DRM Administer tool. One or more DRM roles added/removed for group using HSS. Only groups that have one or more DRM roles assigned by HSS will cause DRM users to be created or be available for Node Access Group or Property Category association (see next two rows).
Node Access Group (NAG) One of two ways, both using DRM Administer tool:

1) Edit user and pick one or more from list of available NAGs

2) Edit NAG and pick one or more from list of available users

One way: edit NAG using DRM Administer tool and pick at most one external group to associate with the NAG

Only groups that have at least one DRM role assigned by HSS will appear in the group list to pick from.

All the users that are part of that external group associated with the NAG will get access to that NAG

Property Category (PC) One of two ways, both using DRM Administer tool:

1) Edit user and pick one or more from list of available PCs,

choose Read or Edit access for each PC

2) Edit PC and pick one or more from list of available users,

choose Read or Edit access

One way: edit PC using DRM Administer tool and pick at most one external group for Read access and one for Edit access to the properties in the category

Only groups that have at least one DRM role assigned by HSS will appear in the group lists to pick from.

All the users that are part of that external group associated with the read and edit access of the PC will get access to that PC with corresponding Read/Edit Access

 3. Group Design

CUP has two restrictions related to how it applies security settings that have an impact on setting up user groups and converting from a non-CUP application to a CUP-enabled one. The restrictions are:

  • If a Node Access Group or Property Category is connected to a group, it cannot also be connected to any individual user (Internally Authenticated Users)
  • A Node Access Group or Property Category access level can be connected to at most one group

These two restrictions imply the following:

  • If CUP is enabled, all existing users must become members of a group or groups and get their security via CUP. This means a conversion process for all existing users of an application that is to have CUP enabled.
  • Unless an application’s security requirements are extremely simple for all users, a nested user group structure will be required to support the variety of security configurations needed.

The following diagram represents generically how to set up groups to support CUP.

CUP

The basic approach to CUP group design is as follows:

  • Create one group within HSS for each Node Access Group and each Property Category/access level combination
  • Within DRM, associate the object to its corresponding HSS group
  • Determine the types of user access required, namely, unique combinations of Roles, Node Access Groups, and Property Categories with associated access levels (think of these as personas like Administrators, Data Stewards, Read Only Users etc.)
  • Create one Directory group for each of these types of access
  • Assign the appropriate DRM role(s) to each Directory Group
  • Add the Directory groups as members of the appropriate Native HSS groups, depending on the object access needed by each Directory Group
  • All users join the Directory groups that give them the access they need

Note: The Access to Stats and SharedInfo property category is mapped via 2 system preferences namely ExternalGroupForSharedInfoCategory and ExternalGroupForStatsCategory

Two additional factors should be considered in addition to the basic approach:

  • The complexity of the design will depend on the number of unique ‘personas’ that need to be supported, however the aim should be reduce the number of personas in effort to simplify the design. For Ex. The property category access can be provisioned via 2 groups (read only and edit access) that will give users access to all property categories.
  • Node Access Groups associated with DRG workflows need to be considered when determining security personas. It is likely there will be more security personas required and therefore more Directory Groups required.

4. CUP Synchronization

The following describes the internal processes CUP uses to update DRM users and their security configuration:

  • The DRM application needs to be synchronized with HSS to enable the provisioning changes made in HSS to reflect in DRM
  • The synchronization is of two types Full Sync and Partial Sync
    • Full sync can be triggered two ways – Manual Sync and Scheduled Sync
    • The following information is synced when a full sync is triggered
    • Add or update users (User name, Full name, Email address, Assign roles to users)
    • Assign users to node access groups
    • Assign users to property categories
    • Remove user roles (if de-provisioned in Shared Services)
  • Partial, real-time sync is performed automatically in following scenarios for users and groups managed in HSS
    • When a user attempts to log in to DRM, provisioning information for the individual user being authenticated is automatically synchronized before a session is created.
    • Node Access Group Membership: User membership for an individual node access group is automatically synchronized when the group is saved.
    • Property Category Membership: User membership for an individual property category is automatically synchronized when the category is saved.

5. Current Issues Associated with CUP

  • CUP doesn’t have the Anonymous User Role; the most basic role available in CUP is Interactive User.
  • DRM stores the user groups associated with Property Categories and Node Access Groups at the Node Access Group and Property Category Level hence this data is also exported when an object extract is taken for NAG and PC via the DRM migration utility. Care should be taken while migrating the NAGs and PCs to different environment or else the incorrect user group association might break security.

By Sumit Kumar, Oracle DRM Developer

1 Comment

  1. Nice, Post.. I would like to share some ideas regarding CUP restrictions on Anonymous role. I think DRM Anonymous role was restricted on CSS/HSS intentionally due to their licensing model, Interactive role can do the trick and serve well when you combine it with a read NAG..process is pretty straight forward
    Step 1) Create an Interactive Node Access Group
    Step 2) Assign that NAG with ‘Read’ level access on the hierarchy[s)
    Step3) Provision the Native/AD group on HSS with Interactive role , then sync. down and align that group with read NAG you created on step 1.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s