Skip to Content

Everything you wanted to know about BPM security but were afraid to ask...

So mea culpa...yes I’ve done it too... spent all my effort and time in a Development environment -  where I have blanket authority  - understanding how the solution works, how to configure, enhance, extend and develop it, dealt with the challenges of changing business requirements, technology, functionality, multiple entry points, multiple user interface formats and devices... got the whole thing working nicely... and then come to cutover and been hit with the question from my thankfully friendly and very patient security administrator...  What about security and authorizations?  D’oh!
Fortunately relatively few authorizations are needed to work with BPM Processes.   While the SAP Library Help documents these authorizations fairly well there are a few traps for young players, so to hopefully save others time and effort, this blog is a short summary of the major considerations for SAP NetWeaver BPM  (Release 7.3 and above).

Starting BPM Processes

As BPM Processes are automatically deployed as web services, for everyone, except the BPM Super Administrator (who has blanket authority), the authority to start a business process is a combination of:
  • The authority to access and call whatever initiating application is used to call the web service
  • The authority to call the web service itself – managed via the web application SAP NetWeaver Administrator > SOA > Single Service Administration
  • The authority to start a BPM Process – i.e. the UME Action SAP_BPM_TRIGGER_EVENT 
What if you wanted to give access to one BPM web service and not another? You could control it via the authentication on the BPM web service, but more commonly it would be managed via the initiating application, typically by controlling access to the initiating application. For example:  you might include the initiating application in your SAP Enterprise Portal and control access to the application via the Portal Role;  or by leading people through some prequalifying questions in a mobile app.

Me, me, me

Starting a process as a named user requires that the user is named in the SAP NetWeaver BPM system itself.  Typically in a heterogeneous (mixed Java and ABAP systems) SAP landscape, SAP NetWeaver Identity Management (IDM) or Central User Administration (CUA) would be used to replicate named users from one system to another.  A workable approach here is to bring across all named users, but only targeted – and usually custom built - ABAP security roles to align Java and ABAP permissions. Typically such ABAP security roles are brought across as UME Groups, so that you can assign UME Roles with the Java permissions to the UME Groups representing the ABAP security roles that contain the ABAP permissions. 
A couple of considerations here if you want to use the named user in a subsequent part of the process:
  • It’s possible to get the initiator via the BPM Java API
  • But probably easier to just include it as one of the inputs of the process Start Event (and by implication the WSDL of the Process web service)

Guests and other nameless interlopers

If you want to start a process anonymously a Guest user is provided for this purpose.  You can, of course, also create your own Guest user and assign the SAP_BPM_TRIGGER_EVENT authority to them.  A couple of things to remember here:
  • You probably still want to identify somehow who actually started the process so consider capturing some sort of identification as an input of the process.  For instance, capturing the email address of the initiating person so that you can notify them when the process is finished
  • The formal initiator of the process will be the Guest user – so tracking options such using the standard Process List Viewer application (“Processes I have started” feature) or extracting a list of processes via the BPM Java API will be impacted

Technical users ... the GOTCHA!

You can of course use a technical user e.g. to start a process via a scheduled batch job.  This is essentially the same as starting the process as a Guest user.
However the permission that I missed on the first time round was the need to assign the SAP_BPM_TRIGGER_EVENT action to the technical user used to send/receive an intermediate message event. That is the SAP_BPM_TRIGGER_EVENT authority is also needed to resume the process on receipt of an Intermediate Message Event.

Executing BPM Tasks

Those of you with a background in SAP Business Workflow would be familiar with the calculation used to determine who can execute a work item:
Selected agents – excluded agents =recipients
Finding who can execute a SAP NetWeaver BPM Task uses much the same approach – just slightly different terminology:
Potential owners – excluded owners = nominated owners (i.e. recipients)
Like workflow, in BPM individual recipients must be named users.  In workflow named users are identified by their User ID, in BPM named users are identified as UME principals.  Typically in mixed ABAP/Java landscapes the built-in mapping function getPrincipalByUniqueName is used to convert from a ABAP user ID to a Java UME principal ID, e.g.
myUMEPrincipalID = getPrincipalByUniqueName( myABAPUserID, “user”)
Some of the differences to be aware of:
  • Workflow typically calculates selected agents using an Agent Determination Rule, usually at the workflow step level, or via a reference to a previously calculated list of agents called an expression.
    • In workflow an expression is simply a reference to a part of the context of the workflow
  • BPM typically calculates potential owners using an Expression , which can be assigned to the whole lane, to the process step, or to the task itself
    • In BPM an Expression can be not just a reference to the a variable in the process or task context but typically includes calculations as well
  • In workflow selected agents can also be expressed as Organizational Structure Positions or ABAP Security Roles and at runtime the list of named users derived from these
  • In BPM selected agents can also be expressed as UME Groups or UME Roles, and at runtime the list of named users derived from these
In both BPM and Workflow where these are not sufficient a common approach is to calculate the agents in a prior automated step and place them in the context of the process or workflow, e.g. to find the manager of the process initiator.  
Workflow also has an extra layer of complexity known as Possible Agents that is handled differently in SAP NetWeaver BPM:
  • Selected Agents (assigned at the workflow step) must also be Possible Agents (of the workflow task) before they can be a recipient.
    • BPM handles this slightly differently in that there is no equivalent restriction on the potential owners.  
  • Possible agents (of the workflow task) are used as the default recipients if selected agents were not assigned to the workflow step
    • In BPM the potential owners of the task are used as the recipients if potential owners were not assigned at the process step or lane
    • In BPM potential owner assignments at the process step override assignments at the lane and both override assignments at the task level
Of course just like with workflow the nominated owner can also be adjusted at runtime by: forwarding by a recipient (“Delegate” feature); by substitution; or by the administrator (“Nominate Owner” feature). 

Knowing I have something to do – Inbox and email notification options

How does the recipient know there is a BPM Task they need to execute?  There are 4 possible options here:
  • Default – receive tasks via the Universal Worklist Inbox (UWL) in the SAP Enterprise Portal
  • Alternatively  - receive tasks via the BPM HTML5 Worklist (release 7.3 EHP1 SP04 and above)
  • Alternatively – receive tasks via a custom worklist created using the BPM API
  • Optionally – you may also receive tasks via email notification to potential owners
    • The email provides hyperlinks to execute the task directly or via the UWL
    • The email notification can be customized at the task level  if necessary
The configurations required for these options are covered in the standard SAP Library Help.

Doing the thing- Executing the task itself

Executing a SAP NetWeaver BPM task requires the recipient to be a named user with the following permissions:
  • The authority to access the BPM task instance – this depends on the inbox and/or email notification options used
    • E.g. If a recipient accesses BPM tasks via the Universal Worklist Inbox they will need to have access to the Portal and have a Portal role that grants them access to the UWL iview
  • The authority to execute the task
    • Be a BPM end user – i.e. have the “BPEM End User” role (pcd:portal_content/  or UME action bpem.enduser
    • Be a potential, active or delegated owner of the task (and not be an excluded owner) 
  • The authority to execute the User Interface application launched by the task
    • This largely depends on the type of User Interface application used, e.g. if the User Interface application is written in ABAP Web Dynpro the recipient would typically need to be a named user in the relevant ABAP system, have Single Sign On activated between the BPM and ABAP system, and be authorized to execute that ABAP Web Dynpro application
  • Any additional permissions required by the User Interface application itself
    • These are typically custom permissions specified as part of the business requirements for the process 

Getting someone off system to do the thing - Adobe Offline forms

Usually it doesn’t make much sense to have a Guest or generic user to execute a task – after all how will you know who has impacted your system if anything goes wrong?  However occasionally you may want to have an external person, such as a customer or vendor contact, to provide some data.   Typically this is done by sending an Adobe Offline form to the nominated person.  Some considerations to be aware of:
  • The person is nominated via their email address
    • Multiple email addresses are possible and the form can also be sent to the email address of a named user
  • The Adobe Offline form is sent as an attachment to the email, and includes a “submit” button to return the form to the BPM mailbox.  The return address is added to the submit button at runtime by the BPM system when the form is sent.
    • The form must be returned by once only by one of the originally nominated email recipients
    • BPM  returns automated email responses to the sender if the form is returned multiple times or by someone who is not an original recipient
  • On receipt into the BPM mailbox, the BPMMailReader job processes the form using the special user “SAP_BPM_Service”  and this user will appear as the processor of the task on audit trails
  • Optionally the email address of the sender can be captured and stored as part of the process context
So effectively for an external person to participate in a process, they must simply have a valid email address and an inbox from which they can send and receive emails using that email address, and of course Adobe Reader installed so that they can view and enter data into the form.  There are no specific requirements on the inbox, although it’s worth making sure your offline form is not too large when completed to avoid any local inbox restrictions on the size of attachments that can be received or sent.  
There are similar considerations if you want to use the BPM Java API to provide an external user access to execute a task e.g. via a mobile app.  That is, you still need to authenticate the user somehow, if only so that you can identify which tasks are relevant for them, and you need to handle common exception scenarios such as the task is already completed.

Executing Automated Steps

Traps for Young Players

Automated steps primarily refer to SOAP-based web services. These could be provided by the local system, e.g. a web service that calls a BRM Business Rule, or an SAP system, e.g. an Enterprise Service in an ECC system, or be a non-SAP web service provided by another system entirely.
With the consolidation of PI, BPM and BRM into SAP NetWeaver Process Orchestration as of SAP NetWeaver 7.3 EHP1, increasingly a further option is to have PI provided a proxy web service in the local system, and then handle the real communication in whatever format is needed via PI’s many adapters, e.g. to call B2B, IDOC or even REST-based services.
Typically automated steps are performed by a technical user in the background.  If necessary, you can also transfer the named user of the prior process step or event via the Principal Propagation technique (for which refer to the SAP Library help).   As a default user, the SAP_BPM_Service user is used if no other user has been specified.
So far so good... but there are a couple of traps for developers new to BPM to watch out for:
  • Make sure the security and authentication requirements are matching for both the consumer and provider systems, e.g. if the provider requires Basic (user/password) authentication and the consumer is set to None then the call will obviously be blocked
  • Be clear on whether you are using Synchronous or Asynchronous communication
    • With Synchronous communication you only need to apply authorizations to the web service being called
    • With Asynchronous communication you need to check if there is also a matching Intermediate Message Event (i.e. a received web service/endpoint) in the process design which resumes the process after the web service has completed its’ work. If there is you need to authenticate both the initial web service and the intermediate message service that resumes the process
  • Intermediate message events can also be used standalone – e.g. listening for an event in another system that may impact the current process.  As mentioned previously the UME action SAP_BPM_TRIGGER_EVENT needed to resume the process needs to be assigned to the technical user sending the web service/endpoint captured via the event.
  • Make sure the runtime security and authentication settings have been applied to the design of the process via the SAP NetWeaver Administration application > SOA tab, e.g. using Application Scenario Communication > Application communication.  This is especially critical when you first cutover from a Development to a Quality/Test environment, and from Quality/Test to a Production environment.

Monitoring, Analytics, and other stuff

Tracking Processes

Tracking processes as a participant of a process is via the Process List Viewer application which uses the permissions of the BPEM End User role.  This lets a named user track processes started by them and processes in which they have participated.
Apart from the Process List Viewer application the majority of process tracking is performed via the BPM Administrator who typically has been granted the UME role and action SAP_BPM_SuperAdmin.
This is needed to access applications such as Manage Processes, Manage Tasks, Business Logs, Process Repository, etc.
The administrator also has authority to:
  • Suspend/resume/cancel processes and tasks
  • Nominate owners (i.e. forward by administrator)
  • Resend offline forms e.g. if there has been a problem sending the form at the mail server
But there are a couple of other VERY desirable permissions that may not yet have been included in the standard administrator role in your release/support pack, and that are worth adding yourself:
  • The authority to edit the context of a process or task in error, UME Action SAP_BPM_EDIT_CONTEXT
  • The authority to run the support tools in the BPM Support Toolkit provided via SAP Notes 1699955 and 1695099, i.e. UME Action BPMSupportToolkitAdministrator

Stakeholders and other Expert Users

Anyone granted the UME role and action SAP_BPM_SuperDisplay can also view processes using Manage Processes, Manage Tasks, and Business Logs.

SAP_BPM_SuperDisplay was enough in 7.30 SP5 but if you are in 7.31 instead use SAP_BPM_SuperAdmin or SAP_BPM_Navigation to nominate owners as per the help:

They can also:
  • Nominate owners (i.e. forward by administrator)
  • Resend offline forms e.g. if there has been a problem sending the form at the mail server
Additionally reports can be created in Visual Composer or in SAP Business Warehouse/SAP Business Objects.   Usually no special authority is needed to run the Visual Composer reports, but of course to run SAP Business Warehouse or SAP Business Objects reports require the relevant access to those systems as well.
There’s plenty more detail in the SAP Library Help, including special authorities for debugging and troubleshooting as a developer, and of course if you are using SAP NetWeaver BRM Business Rules in your processes you will need to consider the business rule authorizations as well.
I’m sure additional authorizations will be added over time, but hopefully the above saves you some time on your next SAP NetWeaver BPM project. I'd welcome comments and it would be great if others would share any authorizations they have found particularly helpful,.