|
|||||
| Worklist user management | |||||
|---|---|---|---|---|---|
| Prev | Chapter 4. Configuration | Next | |||
This section details how users of the worklist are managed. You have to understand that users are not necessarily mapped one to one on workflow participants :
OpenWFE's workflow engine just cares about participants, wether they are mapped to roles or directly to users doesn't involve the engine level, it's tuned at worklist level.
Out of the box, a packaged version of OpenWFE is set up to have 4 participants (3 roles and an engine).
If you use OpenWFE out of the box (as downloaded), you probably use it through its web interface.
In order to let a user of the WUI (Web User Interface) launch a flow, you have to grant him the right on it.
To do this, you have two options, either you do it through the WUI dedicated to
user management (http://localhost:7081 login as admin) or you directly add an
entry to etc/worklist/passwd.xml.
Launch permissions can point to lists of flows like this one :
<?xml version="1.0" encoding="UTF-8"?>
<flows>
<flow>
http://localhost:7079/flow__1.0.xml
</flow>
<flow>
http://localhost:7079/launchitems/li_1.xml
</flow>
<flow>
http://localhost:7079/flow__1.4.xml
</flow>
<flow>
http://localhost:7079/launchitems/li_2.xml
</flow>
</flows>
Such lists may also contain references (URLs) to other lists. Beware not to create circular references, the LaunchPermission would then be unusable.
The directory workflow-definitions/ contains a JSP named flow-index.jsp that lists all the flows in its directory and in the sub-directories. This JSP allows you to simply drop a flow definition into the directory and any user that has a launch permission pointing to flow-index.jsp will directly have the right to launch you flow. As released, the grant 'launch.more' is configured with this launch permission (pointing to http://localhost:7079/flow-index.jsp).
This new system has considerably reduced the size of the etc/worklist/passwd.xml file. New tricks are now possible : you could implement in whatever CGI language an equivalent of flow-index.jsp that takes its list out of a database or whatever.
Scroll till the the '--Grants--' section and locate the grant named 'launch.default'. This grant is attributed to every standard user (alice, bob and charly). Therefore by adding to it a launch permission for your flow, each of these users will be entitled the right to launch 'myflow 1.0'.
In the combobox, select 'openwfe.org.worklist.auth.LaunchPermission' and then click on the [+] box beneath your selection. You'll then have to enter the URL to your flow, for instance "mainEngine::http://localhost:7099/myflow__1.0.xml" and click on submit.
'mainEngine' is the engineId, i.e. the participant name of the engine you want to run the instances of the flow. This id thus corresponds to an entry in etc/engine/participant-map.xml
Once you have added the launch permission, you can click 'commit' on the top right of the main page to let your changes be committed (behind the scene, the file etc/worklist/passwd.xml is overwritten by a new version).
By committing, your changes are also inserted into the system policy service and thus your entitled users may immediately launch the new flow (well, its workflow definition must be well-formed and contain expressions known to the engine else a launch error will occur of course)
While working with this web interface, you should note that the account 'admin' that you used to enter it is entitled an 'openwfe.org.uman.UmanPermission'. This right belongs to the 'user-management' grant and goes along with a read-write right on etc/worklist/passwd.xml
Some people / administrators like to have a direct feeling with a system and thus they prefer to tweak text configuration files.
Following this philosophy, you could directly modify etc/worklist/passwd.xml
Thus changing :
<grant
name="launch.default"
codebase="file:jars/openwfe-worklist-actions.jar"
>
<permission
name="mainEngine::http://localhost:7079/flow__1.1.xml"
class="openwfe.org.worklist.auth.LaunchPermission"
/>
(...)
<permission
name="mainEngine::http://localhost:7079/flow__1.9.xml"
class="openwfe.org.worklist.auth.LaunchPermission"
/>
</grant>
to :
<grant
name="launch.default"
codebase="file:jars/openwfe-worklist-actions.jar"
>
<permission
name="mainEngine::http://localhost:7079/flow__1.1.xml"
class="openwfe.org.worklist.auth.LaunchPermission"
/>
(...)
<permission
name="mainEngine::http://localhost:7079/flow__1.9.xml"
class="openwfe.org.worklist.auth.LaunchPermission"
/>
<permission
name="mainEngine::http://localhost:7079/myflow__1.0.xml"
class="openwfe.org.worklist.auth.LaunchPermission"
/>
</grant>
The web method might also scramble a bit the pretty pretting of passwd.xml
If you set the parameter 'refreshEachTime' to 'true' in etc/worklist/worklist-configuration.xml for the service named 'policyService', each time credentials information are requested (each time a user logs in), the file etc/worklist/passwd.xml is reloaded and reparsed. This allows a maximum of flexibility.
Future implementations may include LDAP connectors for this 'policyService' and even for the participant map itself.
For those of you interested in knowing the mechanic of it all, this policy
service is configured in etc/worklist/worklist-configuration.xml (it is named
'PolicyService').
If you don't want to use the UMAN WUI (User MANagement Web User Interface) you can comment it out from etc/worklist/worklist-configuration.xml like this :
| + <!-- | <service | name="umanSessionService" | class="openwfe.org.rmi.RemoteService" | > | <param> | <param-name>port</param-name> | <param-value>7099</param-value> | </param> | | (...) | | <param> | <param-name>policyService</param-name> | <param-value>policyService</param-value> | </param> | </service> + --> |
(OpenWFE 1.6.1preX : query stores are currently in a state of flux, an integration of JCR repositories (JSR-170) is underway. The query capabilities of those content repositories will be used for query stores as well)
Instead of having a store for each role (or even user), you can set up a query store, that gathers all the workitems for a worklist. Each user is entitled a set of queries through the etc/worklist/query-map.xml file.
(There's no more documentation on query stores. They're currently not much used : store get strategies or custom filtering of workitem stores are applied instead, but they should still benefit from the incoming JSR-170 workitem store re-implementation. It's of course not forbidden to study the files etc/worklist/query-map.xml and etc/worklist/query-config.xml to learn how they currently work)
The file passwd.xml takes its name from the famous /etc/passwd on Unix systems.
It contains user password and permissions.
This file is divided in two parts the principals part and the grants part. The principal part lists users (principals), the latter part enumerates grants which are sets of permissions. In the principals part, the users (principals) are given grants.
Here is an example of a passwd.xml file. It lists one and only one user.
The grants include one on store alpha, and one for launching flows and launchitems enumerated in http://localhost:7079/launch-default.xml. This launch permission is applicable for launching flows in the 'mainEngine' engine.
<?xml version="1.0" encoding="UTF-8"?>
<passwd>
<!-- principals -->
<principal
name="alice"
class="openwfe.org.auth.BasicPrincipal"
password="+99-124-30-78+24+75-53-11-114-52-15+12-89-90+86+60"
>
<grant name="store.alpha" />
<grant name="launch.default" />
</principal>
<!-- grants -->
<grant
name="store.alpha"
codebase="file:./jars/openwfe-worklist-actions.jar"
>
<permission
name="Store.alpha"
class="openwfe.org.worklist.auth.StorePermission"
rights="read, write, delegate"
/>
</grant>
<grant
name="launch.default"
codebase="file:jars/openwfe-worklist-actions.jar"
>
<!--
This launch permission points to a static list of flows.
By modifying this launch-default.xml file, you can add or
remove flows for the users that have the launch.default grant.
-->
<permission
name="mainEngine::http://localhost:7079/launch-default.xml"
class="openwfe.org.worklist.auth.StorePermission"
/>
</grant>
</passwd>
Since OpenWFE 1.7.1, it's possible to use regular expressions instead of plain usernames, thus defining a 'range' of users with a shared password. This technique is described in the section called “Using the strategy in conjunction with a 'regex user'” (It's not possible to use regular expressions to define password though).
SqlPasswdCodec allows the OpenWFE worklist to retrieve user information from a database instead of from etc/worklist/passwd.xml. This subservice is detailed a few sections away.