jBPM用户指南 第十七章 Security

Chapter 17. Security

 

Security features of jBPM are still in alpha stage. This chapter documents the 

pluggable authentication and authorization. And what parts of the framework are 

finished and what parts not yet.

 

17.1. Todos

 

On the framework part, we still need to define a set of permissions that are verified 

by the jbpm engine while a process is being executed. Currently you can check your 

own permissions, but there is not yet a jbpm default set of permissions.

 

Only one default authentication implementation is finished. Other authentication 

implementations are envisioned, but not yet implemented. Authorization is optional, and 

there is no authorization implementation yet. Also for authorization, there are a 

number of authorization implementations envisioned, but they are not yet worked out. 

 

But for both authentication and authorization, the framework is there to plug in your 

 

own authentication and authorization mechanism.

 

17.2. Authentication

 

Authentication is the process of knowing on who's behalf the code is running. In case 

of jBPM this information should be made available from the environment to jBPM. 

Cause jBPM is always executed in a specific environment like a webapp, an EJB, a 

swing application or some other environment, it is always the surrounding environment 

that should perform authentication.

 

In a few situations, jBPM needs to know who is running the code. E.g. to add 

authentication information in the process logs to know who did what and when. 

Another example is calculation of an actor based on the current authenticated actor.

 

In each situation where jBPM needs to know who is running the code, the central 

method org.jbpm.security.Authentication.getAuthenticatedActorId() is called. That method 

will delegate to an implementation of org.jbpm.security.authenticator.Authenticator. By 

specifying an implementation of the authenticator, you can configure how jBPM 

retrieves the currently authenticated actor from the environment. 

 

The default authenticator is org.jbpm.security.authenticator.JbpmDefaultAutenticator. 

That implementation will maintain a ThreadLocal stack of authenticated actorId's. 

 

Authenticated blocks can be marked with the methods 

 

JbpmDefaultAutenticator.pushAuthenticatedActorId(String) and 

JbpmDefaultAutenticator.popAuthenticatedActorId(). Be sure to always put these 

demarcations in a try-finally block. For the push and pop methods of this 

authenticator implementation, there are convenience methods supplied on the base 

Authentication class. The reason that the JbpmDefaultAutenticator maintains a stack 

of actorIds instead of just one actorId is simple: it allows the jBPM code to distinct 

 

between code that is executed on behalf of the user and code that is executed on 

 

behalf of the jbpm engine.

 

See the javadocs for more information.

 

17.3. Authorization

 

Authorization is validating if an authenticated user is allowed to perform a secured 

operation.

 

The jBPM engine and user code can verify if a user is allowed to perform a given 

operation with the API method 

org.jbpm.security.Authorization.checkPermission(Permission). 

 

The Authrorization class will also delegate that call to a configurable 

implementation. The interface for pluggin in different authorization strategies is 

org.jbpm.security.authorizer.Authorizer.

 

In the package org.jbpm.security.authorizer there are some examples that show 

intentions of authorizer implementations. Most are not fully implemented and none of 

 

them are tested.

 

Also still todo is the definition of a set of jBPM permissions and the verification 

of those permissions by the jBPM engine. An example could be verifying that the 

current authenticated user has sufficient privileges to end a task by calling 

Authorization.checkPermission(new TaskPermission("end", Long.toString(id))) in the 

TaskInstance.end() method.