Table of Contents

Search

  1. Preface
  2. Overview, Downloading, and Installing
  3. Administration API
  4. Identity Service API
  5. Screenflow Programming and SDK
  6. ActiveVOS WSHT API
  7. Embedding Request Forms in Standalone Web Pages
  8. XML-JSON for Process Central

7. APIs, SDKs, and Services

7. APIs, SDKs, and Services

Authentication and Use of the Process Server Identity Service For Authorization

Authentication and Use of the Process Server Identity Service For Authorization

There are 4 basic components involved when interacting with tasks on the Process Server via service located at API endpoint
http://.../active-bpel/services/AeB4PTaskClient-taskOperations
.
[Client: accesses /services/AeB4PTaskClient-taskOperations with username and password] --> ----> [Web Application Container: checks if user has access to resources] --> ----> [ActiveVOS engine: execution of tasks and API] --> ----> [Identity Service: checks if user has access to tasks]
A Task Client is any application that wants to access the API via a web service call. The Inbox application is one such implementation. All clients access the WSHT API at the service endpoint located at
http://.../active-bpel/services/AeB4PTaskClient-taskOperations
.
The API service endpoint (
/services/AeB4PTaskClient-taskOperations
) is normally secured using standard Java servlet security. By default, this service is secured to provide access to a user with the role of
abTaskClient
. This security constraint is defined in the
active-bpel.war
web.xml
file. Anyone wishing to access this endpoint must provide authentication credentials and have the
abTaskClient
role.
It is the responsibility of the web application container (such as Tomcat) to make sure that the client accessing the service endpoint has proper credentials. As mentioned previously, any principal with role of
abTaskClient
(as defined in the
web.xml
) should have access to the resources (service). If the credentials are not provided or incorrect, the web container normally responds with HTTP 401 (unauthorized).
Once access to service endpoint is granted (by the web container), the request along with the principal's username is passed into the Process Server engine's task client API implementation. At this point, the engine consults a ACL and the Identity Service to see which tasks the principal has access to. The principal must have a role associated with the tasks (generic human role such as a potential owner, business administrator) in order to view or manipulate tasks.
Note: The user credentials (such as via HTTP BASIC authentication and session cookies thereafter) are required for every web service request. Otherwise you will get an empty response (same as an anonymous user would obtain). In most cases, this is the reason for getting empty responses (as evidenced by a lack of task in the Process Central's Inbox task list). Another reason could be that the task has been escalated and assigned to another user/admin and therefore not accessible to this user.
In summary, the web container is responsible for authentication and authorizing access only to the service endpoint. The Identity Service is then used to determine what tasks (if any) the user is authorized to view and or modify.