X

Disseminating the experiments from an explorer, Exploring with Oracle Technologies, Cloud and Blockchain

  • January 21, 2016

BPM Security

Vivek Acharya
Consulting Technical Manager

BPM Security

When talking about BPM
security, you need to know the about certain set of information and where those
information will come from etc. Following are the key information you need to
know, to manage security in BPM –

  1. You need to know about users,groups,roles and permissions and user’s
    group membership
  2. You need to know about attributes, example if you don’t know the
    email attribute then BPM process would not be able to send the
    notifications. In future we will be creating parametric roles based on
    users special attribute like skills, language etc, then attributes become
    more important and must be defined for each users.
  3. You need to know the Organization structure to define the
    organization unit in BPM and then associate groups and users to those org
    units.
  4. You also need information about reporting structure. Example define
    escalation etc. BPM finds manager by navigating to the manager attribute
    of the users and then same manager has the authority to reassign task to
    his/her direct reportee. So we need to know the managerial hierarchy in
    LDAP to perform effective task management.

Above are the information
which BPM needs to perform effective process and task management.

How BPM gets these
information?

Following are the two
services which BPM uses to get these information –

  1. OPSS – Oracle Platform Security Services – it gives information
    about identities and memberships. So things like, looking up users in
    LDAP, authenticating them are done by OPSS. BPM does not directly perform
    user authentication. It’s being done by the perimeter security provided by WLS
    or the container and then BPM gets that information about the user from
    OPSS.Similarly for group and application role membership, determinations
    are made by the OPSS security service and BPM gets those information
    though a set of APIs. So information about individuals and there
    membership comes though OPSS.
  2. Verification Service – it’s part of SOA infrastructure that offers
    access to the tokens that are used to authenticate users in BPM. All of the
    APIs in BPM and Human Workflow are stateless. So when those APIs are
    invoked,consumer gets a token and when those token gets authorized, you
    can pass that token in subsequent calls. So verification service manages the
    creation of those tokens and the caching of those tokens. Also, it’s the verification
    service that determines individual access rights to processes and task
    data.

How LDAP,BPM,OPSS and Verification service are
related?

Information about users is in
LDAP. BPM runtime needs to know about the users,groups,roles and permissions to
make the task assignment decisions and to control access to task and process
instance data. Access to user attributes is needed to support – email notification, parametric roles, organization units. Information about reporting structure is
needed to define the task escalation paths and admin rights over the tasks.

BPM gets those information
via OPSS.Management and filtering of those information at rutime is performed
by the verification service. BPM runtime uses OPSS for authentication and
derivation of groups/role membership. BPM runtime uses verification service to
manage and cache context tokens and determine process and task level access
rights.

OPSS - OPSS service is used across all the FMW. OPSS is -

  • Standard-based, portable,
    integrated, enterprise-grade security framework for java applications.
  • OPSS uses java APIs for
    security and integrates those into the web logic container and adds application
    roles to grant access to resources.
  • Underlying security platform
    that provides security to Oracle Fusion Middleware including, WLS, SOA, BPM,
    Webcenter, ADF etc.
  • Abstraction layer in the
    form of standard-based programming interface (APIs) that insulate
    applications from security infrastructure.

OPSS Architecture

SPI – it’s the service provider interface that provides
services upwards to fusion middleware environment.Providers are plugged-in to the container offers services like
Authentication, Authorization, Credential Store Framework and User/Role. These services
are abstracted by OPSS and provided to FMW.

BPM and OPSS (Integration
with OPSS)

Java Platform Security Suite (JPS) section shows the core
set of services offered upward to BPM like identity store, policy store, credential
store and framework.

Identity Store - The identity store is queries to get
information about users and groups. You can also concatenate multiple sources
of users though identity store. Example you can have administrative users in embedded
LDAP and business users in external LDAP or OID. You can concatenate users from
these multiple source sung identity store.

Policy Store – Application roles are stored in policy store.
Application roles offer the ability to group users, irrespective of how users
are organized in the LDAP.

Identity Service - Identity store and policy store service
are the core services offered to BPM using identity service. Identity service
is a web service deployed on SOA servers and identity service is the service
used when people login and it also determines the authentication and
authorizations for the login user.

Verification Service – Verification service manages the
tokens and specific privileges to task data and process instances.

  • Internal Service used by
    Human Workflow (HWF) and BPM
  • Manages creation and
    validation of context objects
    • HWF and BPM APIs are
      stateless and require Context object as parameter.
    • Context encapsulates authenticated
      identity derived from Credentials, Identity Propagation, “On behalf of”
      using Admin Context.
    • Public APIs for Context
      creation are on ITaskQueryService
  • Caches Context objects
    with corresponding BPMUser object
    • BPMUser object caches
      user data including group/app role membership
  • Authorizes access to task
    data and actions
    • Uses the Context to fetch
      the BPMUser object from cache

Following diagram enlist the service offered by verification
service.

BPM and OPSS

Verification Service
in Detail

First it’s the perimeter authorization that makes sure that
user who is authenticated can get to the system. Then application roles and
groups take care of human task assignment. Then it’s the verification service
which offers granularity in terms of who can see task data and actions. Verification
service offers caching of Context tokens and authenticate. Verification service
also authorizes user’s access to user task data and actions and to BPM
processes.

  •  To configure task and action access control, use the
    human task editor’s access tab. There you can find tab for content and actions.
  • To configure access control for the process, go to
    Organization and there you can find the predefined roles for the process
    owners and process reviewers. This is how we can grant ownership to user for
    the entire process or let them just being the reviewers. These are the roles
    associated with the process. Then you can associate user, roles, and groups to
    these roles in EM or Workspace.

How it all works?

When someone login to BPM workspace, verification service goes
to the provider to get information like application role and groups. Then the information
is cached in the BPMUser object and the information is hashed and stored in the
cache by the identity context. It is this, identity context that is passed on
each of the subsequent calls made by that user. It offers the ability to no
look-up for user and his/her attributes like application role, groups,
attributes, membership etc.

Application Role

We talked about application role in the validation service
section. Let’s talk more about the application role in this section.

Application role is a powerful capability offered though
OPSS, which allows grouping of users who are not grouped in any other way. Example
you may have groups in external LDAP however you might not need to organize
users/groups in a different way. Application role allows you to create similar
to LDAP groups, it’s a container that can contain groups, users or other
application roles. You can create combination of users in an application role
and then you can assign task to application role and can assign privileges and
access to them and so on. So if your LDAP structure does not matches your work
assignment then you can use application roles to group users in a flexible way.
You can associate user in LDAP to one/more application roles. This way you can
manage groups independently without LDAP changes.

Application roles are persisted in the policy store (file
store ‘system-jazn-data.xml’ in DEV environment and DB in PROD environment). Application
roles can be made of users, groups and other application roles. You can manage
application roles via BPM studio, workspace, EM or WLST.

How it Works with
BPM?

When you model process, you define swimlanes. While defining
swimlanes you are defining the categorization of users. So when you create swimlanes,
you are defining the grouping of users by name, which will interact with the
process. Example sales-rep or executive or supervisor. These names are defined
as Swimlane roles, however at deployment time, a application role is created in
OPSS’s policy store as <Project_Name>.<Swimlane_Role_Name>, example
myBPMprocessPrj.Supervisor.

Swimlane roles are added to policy store as application
roles during the deployment.

You can define Swimlane roles assignment to groups and users
in BPM studio whoever I would recommend to define mapping in EM or Workspace or
WLST. If it’s the technical audience responsible for mappings then better to
perform in EM however if it’s the business audience responsible for mapping
then workspace can be the better choice.

Conclusion – This document covers OPSS, Integration of BM
with OPSS, BPM security for data and access and detailed analysis of
verification service.We have learn that when someone login to BPM workspace, verification
service goes to get to the provider information like application role and
groups. Then the information is cached in the BPMUser object and the
information is hashed and stored in the cache by the identity context. It is
this, identity context that is passed on each of the subsequent calls made by
that user.  Next blog post on BPM
security will cover details around configuration of LDAP providers, using
multiple LDAP providers and virtualization using libOVD. Subsequent blog will
also cover troubleshooting and performance tuning when BPM is in concert with
LDAP.

Join the discussion

Comments ( 2 )
  • Bhargav Monday, June 6, 2016

    Hi Phil,

    Great detailed information on how security is taken care by different layers.

    Thanks.


  • Salim Friday, June 1, 2018
    Good article on security layer
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.