I'm still on the same page (http://www.openwfe.org/manual/ch04s02.html).
The section about Launch
permissions seems to be quite messed up. At least to
me. I had to read it several times before I get it.
So I would suggest some
rewriting of this section
My proposition is the following structure is:
Worklist user
management
+ X Access
permissions
+ X.1 Editing
access permissions ./etc/worklist/passwd.xml
+ X.1.1
Setting permissions to flow groups
+ X.1.2
Automatic reload of passwd.xml
+ X.1.3
regular expressions
+ X.1.4
SqlPasswdCodec
+ X.1.4
Future implementations
+ X.2 Changing
access permission through the WUI for user management
+ X.2.1 disabling
the WUI
As I didn't
understood the "Query stores" they are not in this index, but
probably should be
added.
And I would change the content into the one at the end of this mail. there are
some (?) which need to be compeleted.
Kind regards Marius
===========================================================
X Access permissions
--------------------
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.
X.1 Editing access permissions ./etc/worklist/passwd.xml
--------------------------------------------------------
The file passwd.xml takes its name from the famous
/etc/passwd on Unix systems.
It contains user password and permissions settings.
This file is for the people / administrators which like to
have a direct feeling
with a system and thus prefer to tweak text configuration
files.
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="">
<permission name="Store.alpha"
class="openwfe.org.worklist.auth.StorePermission"
rights="read, write, delegate"/>
</grant>
<grant
name="launch.default"
codebase="" style="">
<!--
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.
see
section "setting permissions to flow groups"
-->
<permission
name="mainEngine::http://localhost:7079/launch-default.xml"
class="openwfe.org.worklist.auth.StorePermission"/>
</grant>
</passwd>
X.1.1 setting permissions to flow groups
----------------------------------------
Launch permissions can point to group of flows (???and
lunchitems, what
are lunchitems???). To group flows together you need to make
an XML file
in the ./workflow-definitions directory which has the
following syntax:
<?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>
[source:
./workflow-definitions/launch-default.xml]
(??? at this point we never spoke about lunchitems and flows. So a quick introduction would be appropriate.??)
Such lists may also contain references (URLs) to other flow
groups. 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.
X.1.2 Automatic reload 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.
X.1.3 regular expressions
-------------------------
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).
X.1.4 SqlPasswdCodec
--------------------
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.
X.1.4 Future implementations
----------------------------
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').
X.2 Changing access permission through the WUI for user
management
------------------------------------------------------------------
(no changes)
X.2.1 disabling the WUI
------------------------
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>
+ -->
|
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "OpenWFE users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/openwfe-users?hl=en
-~----------~----~----~----~------~----~------~--~---
