Permissions in Flux

With JAAS as its base, Flux uses a system of permissions to enable users different privileges based on variables such as group, namespace, or message publisher. This article will briefly discuss the use and implementation of each of the permissions within Flux.

Editing Permissions in the Operations Console

Permissions can be edited using the Flux Operations Console. First you must log in as a user with sufficient privileges to edit other users. Select the “Security” tab at the top, and then “All Users.” You will be presented with a list of users, click on the name of the person or role you want to the edit the permissions on. Information about the user/role will be presented, with the “Permissions” box being the place where we will doing most of our work. Select “Edit” in the Permissions subsection. The rest of the guide assumes you have come this far.

If you are using an unsecured engine, you will not be able to have any security settings including permissions, users, roles, and groups.

Editing Permissions in Code

You will need to obtain a User or Role object to manage the permissions when working in code. The method for doing so is either using the User/Role object given when you create a new one, or the obtaining an existing User/Role from the SecurityAdministrator object for your engine. To do either, you must first log in with the appropriate user. Consider the following code for an example of both.

		Factory factory = Factory.makeInstance();
		Configuration config = factory.makeConfiguration();
		config.setSecurityEnabled(true);
		
		Engine engine = factory.makeEngine(config);
		LocalSecurity lSecurity = factory.makeLocalSecurity();
		lSecurity.login(engine, "admin", "admin");
		SecurityAdministrator sAdmin = engine.getSecurityAdministrator();
		SecurityHelper sHelper = factory.makeEngineHelper().makeSecurityHelper();
	
		// Make a user
		User newUser = sHelper.makeUser();
		// Get a user
		User myUser = sAdmin.getUser("admin");

Permissions

Administrator Permission

The administrator permission grants the user absolute control over everything in Flux. Doing such, it should be granted and used with extreme caution. The user with administrator permission will be able to initiate and contribute to all BPM flows, manage flow charts, and even manipulate other users.

No parameters need to be specified, but the administrator permission can only be given by another administrator. To grant this permission in the Operations Console, log in as a user with the Administrator Permission already given (the admin user by default), select “Add new” when editing permission, and then “Administrator Permission” from the select box.

In code, this can be specified by simply creating a new AdministratorPermission and adding it to your user’s set of Permissions:

Permission adminPer = new AdministratorPermission();
Set permissions = new HashSet();
permissions.add(permissions);
myUser.setPermissions(permissions);

Group Administrator Permission

Flux security is divided into a hierarchy of groups, roles, and users. Groups are an over arching collection of roles and users that can be as broad as an entire company or section of a company; for example “Flux.” Within the groups, there are various roles, or tasks users can participate in – the case of our company example, suppose our “Flux” group has “Development”, “Support”, and “Sales” roles within the company. Obviously people working within the Sales role should be in no way able to influence any of the tasks assigned to Development, so different roles are instated to keep sections of the company in check.

However, the company president should be able to contribute to every aspect to the company groups actions. This is where the group administrator permission is of use. The only parameter that needs to be given to a GroupAdministratorPermission instance is the name of the group you want to assign full access to. In the designer, select GroupAdministratorPermission from the drop box, and the fill in the group name in the textbox that appears. In code, you can do this in a similar fashion to the following:

Permission groupPermission = new GroupAdministratorPermission("flux");
Set permissions = new HashSet();
permissions.add(permissions);
myUser.setPermissions(permissions);

Namespace Permission

Flow charts can be managed based on the namespace they’re placed in. By default all flow charts are placed into the “/” namespace. Namespaces can be used to indicate and define many different scopes – such as “/windows/” can indicate flow charts that are designed to run on only Windows machines and “/sales/” can indicate flow charts that are pertinent to the sales in some way. Namespace permissions are mostly used for defining the scope in which Roles work, which are then assigned to users, but can be can used to directly define the scope of the user.

To assign a namespace permission, select the “Namespace Permission” option from the drop box, click the “read” and “write” checkboxes depending on what kind of access you want to give to the namespace, and then enter a namespace into the textbox.

In code, you can do the following:

		Role myRole =sAdmin.getRole("role1", "flux");
		Set permissions = new HashSet();
		Permission namespacePermission = new NamespacePermission("/", "READ, WRITE");
		permissions.add(namespacePermission);
		myRole.setPermissions(permissions);

Message Administrator Permission

Messaging is an often under utilized, but extremely useful tool in Flux that allows work flows to the report in on their progress and receive information. Messaging consists of a system of Publishers, Message Triggers (which await a message sent out from the publisher), and Checkpoints (that send information to the publisher). Permissions can be given to users and roles that allow reading and writing messages to/from a certain publisher, or all publishers using the Message Administrator permission.

You can specify three parameters when making creating a message administrator permission – reading, writing, and the publisher the permission is germane to. In the Operations Console select “Message Administrator Permission” from the drop box, check the “Read” and “Write” boxes for whether you want reading or writing enabled in the permission, and then enter the name of the publisher you want the permission for in the “Publisher” text box with “*” denoting all publishers.

In code, you can do the following:

		Role myRole =sAdmin.getRole("role1", "flux");
		Set permissions = new HashSet();
Permission messageAdminPermission = new MessageAdministratorPermission("*", "READ, WRITE"); //Read and Write access to all publishers
		permissions.add(messageAdminPermission);
		myRole.setPermissions(permissions);

Publisher Administrator Permission

The publisher administrator permission is similar to message administrator permission, only it deals with publishers directly and not messages. With this permission you will be able to read the properties, edit, create or delete one or more publishers.

Similar again to the message administrator permission, there are the three parameters you can specify – reading, writing, and the publisher (or all publishers indicated by “*”). In the operations console select “Publisher Administrator Permission” from the drop box, check the “read” and “write” checkboxes according to your prerogative, and then fill out the publisher text box.

In code, your implementation should look similar to:

		Set permissions = new HashSet();
		Permission publisherAdminPermission = new PublisherAdministratorPermission("*", "READ, WRITE");
		permissions.add(publisherAdminPermission);
		myRole.setPermissions(permissions);

Variable Permission

Restricting writing abilities via the namespace permission can severely limit use and construction of flow charts with regards to security. If you want to have a single or set of variables accessible by a role or user, you will want to use the Variable Permission.

Variable Permissions parameters change whether the object in question is an action property (like the “Time Expression” option on a Timer Trigger) or just a user defined flow chart variable. When specifying an action property variable permission, you will need to provide the action, the action property, and the namespace; when only defining a flow chart variable permission you will only need to specify the variable name and namespace. In the operations console, select “Variable” from the permissions drop box; then select either Action Variable or Flow Chart Variable from the drop box that appears below, enter the name of the variable in the text box to the right; if you are making an Action Property, you will need to select either “All Actions” or “One Action” from the subsequent drop box that appears – if you select “One Action,” you will need to specify the name of the Action that the permission is germane to. Finally, fill out the name space in the last text box on the bottom and click Add.

In code, consider the following:

		Permission variablePermission = 
new VariablePermission("/", "date"); // Flow Chart variable
		Permission variableActionPermission =
 new VariablePermission("/", "Timer Trigger", "time expression"); // Action Property Variable.
		Set permissions = new HashSet();
		permissions.add(variablePermission);
		permissions.add(variableActionPermission);
		myRole.setPermissions(permissions);

The variable permission only works if writing is not enabled via a namespace permission