Oracle Business Activity Monitoring (BAM) 12c comes with Oracle SOA Suite and BPM, and it is a very powerful tool that should be used on most projects.  Organizations are using it successfully today to graphically visualize trends in their data to make operational decisions and to send alerts before issues occur. 

One of the difficulties organizations initially have after installing Oracle BAM 12c is determining how to define the security levels and permissions for its different types of users.  Oracle BAM has both coarse grained security defined at the application role level down to very fine grained security defined at individual BAM artifact and data object row levels.

BAM Coarse Grained Security – BAM Application Roles

For many organizations today, different parts of the organization will each access and share the same BAM domain. For some, the coarse grained predefined BAM security groups and roles assignments will suffice. When left to the default coarse grained security, these three types of BAM users will exist:

  1. BAM Administrators in an organization are able to access and edit any data object, EMS, or projects that other teams have created
  2. BAM Designers in an organization can access and edit any BAM project and their queries, views, dashboards and alerts that other teams have created
  3. BAM End Users in an organization can view any dashboard as long as they know the URL for the dashboard

BAM comes installed with BAM application roles already created. The five predefined application roles these three types of BAM users are given are:

  1. BAMUsers – At a minimum, this group should be given to every person using any aspect of BAM.  If this is the only group added, end users are only able to log into BAM and its home page and see nothing once they have logged in.  If users are not given the BAMUsers group, they get a 403 error when attempting to access BAM or one of the dashboards. 
  2. BAMContentViewer – This allows users to view any dashboard and the alert history (on the BAM home page). In addition to the BAMUsers group, this is normally given to BAM end users.
  3. BAMContentCreator – This gives users BAMContentViewer permissions, but also allows them to view any data objects and the data in them. Significantly, they can create and edit projects and add any of the artifacts found on the BAM Designer page. This is normally given to BAM Designers who create the BAM project queries, views, dashboards and alerts.
  4. BAMArchitect – This gives users gives users the ability to create and edit data objects and any artifacts on the BAM Administrator page. This role is not sufficient to allow a user to view or edit artifacts on the Designer page and is therefore not normally used.
  5. BAMAdminstrator – This gives users all of the above roles.

When setting up access to BAM, ensure that these application roles are assigned to corresponding BAM groups. For example, the Weblogic security realm is installed with these roles and

  • The BAMAdministrator application role should be assigned to a corresponding BAMAdministrator group defined in LDAP
  • The BAMArchitect application role should be assigned to a corresponding BAMArchitect group defined in LDAP
  • The BAMContentCreator application role should be assigned to a corresponding WebLogic BAMContentCreator group defined in LDAP
  • The BAMContentView application role should be assigned to a corresponding BAMContentViewer group defined in LDAP

Based on their role, each of the LDAP groups should have the appropriate users assigned.

To assign an organization’s LDAP groups to these application roles in BAM, in Enterprise Manager right click the domain in WebLogic -> click Security -> click Application Roles.

The first step in assigning an LDAP group to a BAM application role

From the Application Stripe dropdown, select BAMServer (1 below) -> click the right chevron icon (2) to populate the list of roles -> to add a new group to one the roles, select the role (3) -> click the Edit button (4).

The second step in assigning LDAP groups to BAM application roles

BAM Fine Grained Capability – Permissions Granted at the Project and/or Artifact Level

BAM out of the box coarse grained security is overridden when a BAM artifact’s security is defined. This means that the permissions can be granted or denied for individual BAM projects, data objects, dashboards and alerts. Security can further be defined at the individual row level data of data objects, preventing unauthorized people for viewing data displayed in a dashboard they are not authorized to view.

Here are the permissions that can be granted or denied at the individual BAM artifact level.

a. Permissions that apply only at the Data Object level:

  • “Read” for data objects – This ensures that not all BAM Administrators can edit individual data object metadata (e.g., the data object’s columns and their properties). This does not give them the ability to view the actual rows of data stored in the data object.
  • “Write” for data objects – This gives BAM Administrators the ability to both view and edit individual data object metadata. This does not give them the ability to view, edit or delete the actual rows of data stored in the data object.
  • “Select” for data objects – Unlike “Read” access, this gives Administrators and Designers the ability to view the actual data stored in data objects. This is similar to a SELECT statement in SQL.
  • “Delete” for data objects – This gives BAM Administrators the ability to delete rows of data in data objects
  • “Update” for data objects – This gives BAM Administrators the ability to delete rows of data in data objects

b. Permissions that apply to BAM Dashboards

  • “Read” for dashboards – This ensures that not all BAM Designers assigned to the BAMContentCreator group the ability to view individual dashboards. 
  • “Write” for dashboards – This gives BAM Designers assigned to the BAMContentCreator group the ability to both view and edit individual dashboards.  If denied, the BAM Designer cannot edit the dashboard but can view it if given Read permission.
  • “Remove” for dashboards – This gives or denies users the ability to delete dashboards
  • “Security” for dashboards – This gives or denies users the ability to set these permissions for other users for the specific dashboard.

c. Permissions that apply to any BAM Artifact for BAM Administrators and Designers:

  • “Remove” for any artifact in BAM – This gives users the ability to delete individual BAM artifacts (e.g., data objects, projects, queries, views and dashboards).
  • “Security” for any artifact in BAM – This gives users the ability to set these permissions for other users.

This means that because these permissions set for individual BAM artifacts supersede any coarse grained security privileges, a BAM designer role is easily denied access to another team’s project.

 

Join the Conversation

About the Author