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 –
Above are the information
which BPM needs to perform effective process and task management.
How BPM gets these
Following are the two
services which BPM uses to get these information –
How LDAP,BPM,OPSS and Verification service are
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
OPSS - OPSS service is used across all the FMW. OPSS is -
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
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.
Following diagram enlist the service offered by verification
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
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.
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
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
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