This feature enables the administrator to define the permissions created for the destinations used by the Event Process. This allows administrators to control the set of users allowed to access destinations created/used by the components within an Event Process, ensuring that unauthorized users do not get access to these destinations.
Working of ACLs
All major actions taken by the users on an Event Process are mapped with one or more permission which determines whether the user has the permission to take that particular action or not. If the user is not allowed to take the action, the server throws a Security Exception. For an Event Process, the following ACLs control user-actions on the process.
- Application Level Permission
- Global/System Level Permission(s)
Application Level Permission
Each Event Process can be assigned an ACL that determines the set of users and actions allowed for that Event Process. These permissions, if set, override the permission set at the system level.
| Permission | Description |
|---|---|
| PERMISSION TO COMPOSE AN APPLICATION | This permission controls whether a user is allowed to compose/update/delete an Event Process from the Server repository. |
| PERMISSION TO CHANGE PROPERTIES OF AN APPLICATION | This permission controls whether a user is allowed to change the following properties of a running Event Process:
This permission thus controls run-time changes in the above properties. |
| PERMISSION TO LAUNCH AN APPLICATION | This permission controls whether a user is allowed to launch and/or synchronize the Event Process. |
| PERMISSION TO KILL AN APPLICATION | This permission controls whether a user is allowed to kill the Event Process. |
| PERMISSION TO VIEW RUNNING AND SAVED APPLICATIONS | This permission controls whether a user is allowed to view the application from the server repository. If a user tries to view an application without the appropriate permission, a Security Exception is thrown and the user is denied access to the information. |
| PERMISSION TO REMOTELY ADMINISTRATE AN APPLICATION | This permission controls the set of users who can use service instances from this Event Process as a remote service instance in their own Event Processes. By default, all users are allowed to remotely access the service instances of all Event Processes. This behavior can be controlled by the same permission as the one set at the system level (as described in the Global/System Level Permission(s) section). |
Global/System Level Permission(s)
The permissions set at system level control the overall behavior of the system. For permissions related to an Event Process, if Event Process Level permissions are not set, Global/System Level permissions govern the set of actions allowed for a user. As explained earlier, the default behavior of the Event Processes is governed by Global/System Level permissions only. The following permissions are available at this level.
| Permission | Description |
|---|---|
| ALL PERMISSIONS | This permission overrides all other permissions set at the system level. If this particular permission is granted the user/grout will be allowed to perform all actions unless the Application Level Permission specifically denies the action. |
| PERMISSION TO COMPOSE AN APPLICATION | This permission serves the same purpose as at the Application Level (see the previous section) except that it applies to all Event Processes. |
| PERMISSION TO CHANGE PROPERTIES OF AN APPLICATION | This permission serves the same purpose as at the Application Level (see the previous section) except that it applies to all Event Processes. |
| PERMISSION TO LAUNCH AN APPLICATION | This permission serves the same purpose as at the Application Level (see the previous section) except that it applies to all Event Processes. |
| PERMISSION TO KILL AN APPLICATION | This permission serves the same purpose as at the Application Level (see the previous section) except that it applies to all Event Processes. |
| PERMISSION TO VIEW RUNNING AND SAVED APPLICATIONS | This permission serves the same purpose as at the Application Level (see the previous section) except that it applies to all Event Processes. |
| PERMISSION TO CREATE OR EDIT AND REMOVE SERVICE ACL | This permission has been deprecated as it is no longer used within the system. |
| PERMISSION TO CREATE OR UPDATE AND DELETE A SERVICE | This permission controls whether a user is allowed to make modifications in a particular service e.g. adding/removing a resource to/from a service, changing an icon, adding/removing service dependencies, etc. |
| PERMISSION TO CREATE AN ACL | This permission controls whether a user is allowed to create/change a System Level or Application Level permission. |
| PERMISSION TO CREATE OR EDIT AND DELETE A PRINCIPAL | This permission controls whether a user is allowed to create/delete a user/group on the system. The permission also determines whether a user is allowed to change the password for an existing user. |
| PERMISSION TO CONFIGURE AN FPS | This permission has been deprecated as it is no longer used within the system. |
| PERMISSION TO REMOTELY ADMINISTRATE AN APPLICATION | This permission serves the same purpose as at the Application Level (see the previous section) except it applies to all Event Processes. |
| PERMISSION TO DELETE MESSAGES IN QUEUE | This permission has been deprecated as it is no longer used within the system. |
| PERMISSION TO CLEAR USER EVENTS | This permission has been deprecated as it is no longer used within the system. |
| PERMISSION TO PUSH MESSAGES IN QUEUE | This permission has been deprecated as it is no longer used within the system. |
| PERMISSION TO ADMINISTRATE A GROUP | This permission controls whether a user is allowed to add/remove members from an existing group. |
Default Allowed Set Of Users
When an Event Process is launched, ACLs will be created for all the default (i.e. system-created) destinations such that the following users can publish/subscribe/send/receive the information on these destinations.
- User launching the Application
- The set of users allowed by the permission named PERMISSION TO REMOTELY ADMINISTRATE AN APPLICATION.
All components launched as a result of an Event Process launch/synchronize action will use the credentials of the user performing the launch/synchronize operation to create all connections with the Peer Server. Similarly, all connection(s) created by routes within the Event Process to remote Peer Server(s) will be created using the credentials of the user launching/synchronizing the Event Process.
These parameters can be configured by opening the profile in Studio and navigating to Fiorano > etc > FMQConfigLoader as illustrated in the figure below. These parameters are as described below:
- CreateDefaultACL – This parameter decides whether a default ACL should be created for a newly created destination or not. The default ACL is to allow or disallow Everyone (based on the value of All Permissions parameter defined below) from accessing the destination.
- AllPermissions – This parameter determines whether the default permission created should be positive or negative.
Figure 1: Option to create Default ACL
Changing Default Permissions
Default permissions at Application Level and System Level can be changed such that only a chosen set of users are allowed to perform the desired actions on the desired set of Event Processes. These changes can be made via the Fiorano Web dashboard interface which provides an interactive UI to change these ACLs.
Changing Global Permissions
All available global permissions are listed under the Security > Global Permissions component of the Web interface. Each of these permissions, when expanded, displays a list of principals that are allowed to perform the action specified by that permission (as shown in the figure below).
Figure 2: Global Permissions section
This list of allowed principals can be modified by selecting the appropriate checkbox and clicking the View/Edit Allowed Principals button. This pops-up another window showing the list of allowed users. You can also remove selected users from the permission by clicking the Remove Principal(s) button or add new users to the permission by clicking the Add Principal(s) button as shown in the figure below.
Figure 3: Dialog box to set permission to Kill an Application
Changing Application Level Permissions
Application Level Permissions can be viewed and modified by navigating to the Security > Application Permissions panel of the Web interface. Selecting a principal and Event Process name in this view displays the set of positive and negative permissions assigned to that principal for the selected Event Process. The figure below shows that the user BOB has 3 positive and 3 negative permissions for the Event Process named BOND_TRADING.
Figure 4: Panel to set Application Permissions
The set of positive and negative permissions can be modified by clicking on the Edit Permissions button. For example, to change the type of one or more negative permissions shown in the figure above to positive permissions, first select the desired negative permissions from the set of Available Permissions; then choose GRANT option and click the Modify button. The selected principal would then be granted the permission to perform the actions represented by those permissions as shown in the figure below.
Figure 5: Selected Permission Types under Available Permissions
Principal Store Synchronization
Event Processes are entities that reside in the Enterprise Server repository while destinations used by the components are created on the Peer Server(s). To ensure that a user who has permission to launch an Event Process from the Enterprise Server also has the permission to publish/subscribe/send/receive messages onto destinations on the Peer Server, the username must be present in security data store of both the Enterprise Server and the Peer Server. This is achieved by ensuring that the User & Group Store (collectively called as Principal Store) of both the Enterprise Server and all connected Peer Servers are always in sync with each other. Any change in Principal Store of Enterprise Server is propagated to all connected Peer Servers. Whenever a new Peer Server becomes available on the Fiorano network, a complete one-way synchronization of the Principal Store of that Peer Server and the Enterprise Server will happen, where the Principal Store of Enterprise Server replaces the Principal Store of the Peer Server. The Enterprise Server is responsible for maintaining the status of synchronization with each connected Peer Server. The status of synchronization with each Peer Server can be viewed by navigating to the Security > Principal Store Sync component of Web interface as illustrated in the figure below.
Figure 6: Principal Store Synchronization status
An Event Process launch/synchronize actions will be disallowed if the Principal Stores of Enterprise Server and all running Peer servers used within the Event Process are not in sync with each other. An exception will be thrown specifying the reason due to which the stores were found to be out-of-sync. In such cases, the user will have to take corrective actions in order to launch that Event Process on problematic Peer Server(s). The Web interface provides an option to force a re-sync of Principal Store of Enterprise Server with any particular Peer Server. This is achieved by clicking on the image under the Synchronize column as shown in the figure above. The result of this operation will be displayed to the user as shown in the figure below.
Figure 7: Principal Store re-sync Status pop-up
Modifying the Principal Store of Peer Server by directly creating a connection with Peer Server is disabled. An exception will be thrown whenever a user tries to perform such an operation. Any modifications in the Principal Store of Peer Server can only be performed via the Enterprise Server connection. The figure below shows the result of an operation when a user tries to modify Principal Store of Peer Server by logging into Peer Server via Studio.
Figure 8: Exception pop-up
Custom Encryption of Passwords
To know how to use your own keys and algorithms to encrypt passwords in Event Processes, please refer to the Custom Encryption of Passwords section in Common Configurations page.