Sterling Managed File Transfer

 
Introduction/Feature

Permissions in SI are coarse in granularity.  Users with a permission to a page/function have all actions (view, edit, delete) on that page/function.  As a way to provide more granularity, the deny/negative permissions provides a way to disallow specific actions on an exception basis.

For example, the system allows users with UI BP Manager permission to view that wizard and take actions such as execute a BP, create or edit a BP, or check in a new version. You may want user to be able to access the BP Manager to view, but you may want some of those users to not have permissions to execute BPs. You can accomplish this by creating a second group with the "deny" permission, and assigning users who should have view but not execute needs to both groups.

Actions eligible for deny permissions:

• View page
• Add/check-in new resource
• Edit resource
• Delete resource
• Check out resource (locks the resource)
• Execute resource, i.e., run a business process
• Context specific, i.e., evaluate a mailbox routing rule

 

Details

To take advantage of this feature, permissions must be added to SI via the permission page in the admin UI.  Permission names must use the following format:

_DENY_<permissionName>_<action>_specificationparm

• permissionName = name of the permission you specifically created applicable to the resource, i.e. "BPMANAGE"
• action = any action you can initiate from that page., i.e. "ADD"
• specificationparm = additional parameter that confirms the resource (This is in case the UI page for the resource allowed operations on more than one resource type.)

Alternatively, you may use a format that specifies the SI resource name instead of explicitly creating a custom permission:

_DENY_<resourcename>_<action>_specificationparm

• resourcename = name of the resource, i.e. UI page or servlet name
• action = any action you can initiate from that page., i.e. a CRUD operation
• specificationparm = additional parameter that confirms the resource (This is in case the UI page for the resource allowed operations on more than one resource type.)

Example

_DENY_BPMANAGE_ADD

By assigning this permission to a user that also has the BPMANAGE permission, it would allow the user to view the BP Manager page and take other actions, but prevent that user from creating a new process.

Note, DENY permissions do NOT apply to admin users.

Steps and Priority

The system steps in permission checking:

1. Request to use a resource is made.
2. The system checks that the user making the request has permissions to the resource as part of their user account or as part of a group.
3. If the user passes this check, then the system proceeds to look for any exclusions.
4. The system checks to see that the user permission is not individually, or as part of a group, specifically excluded from accessing the requested resource or requested action for the resource.
5. If the the user is excluded from the specific resource, or the requested action, then the system denies the request; otherwise, the requested permission is granted.

Permissions to SI UI pages and actions are open by default.  If you assign a user a deny permission to one or more actions on a page, then only those actions are denied. Actions not specifically excluded are still allowed.

Out of the Box Permissions

Already existing out of the box "_DENY..." permissions that can be seen in the UI are:

Restricting Access to Business Process Documents

1) If the user is given the "Deny UI Access to Document" permission, they will not be able to access Document content from search screens. 2) If the user is given the "Deny UI Access to Document Listing" permission they will not be able to access a Document listing. Document listings show up when you have, for instance, more than one document in a step for a BP.

As a result, the Document link via each BP step will present a message "You do not have the appropriate permissions to access this area" which will disallow a view of the document contents.

As a result, the Document link via each BP step will present a message "You do not have the appropriate permissions to access this area" which will disallow a view of the document contents.

Restricting Access to Virtual Roots and Routing Rules

• The addition of two permissions "Deny UI Access to Mailbox Routing Rules" and "Deny UI Access to Mailbox Virtual Roots" will enable access restrictions to the Routing Rules and Virtual Roots menu items. When attempting access, the user will be presented with the message "You do not have the appropriate permissions to access this area".

Restricting access to mailbox configurations and messages

• The new "Mailbox Access Limited to User" permission will limit the UI view to specific mailboxes. For example if we add the permission "Mailbox Access Limited to User", "/EDIInboundCollection" and "/EDIInboundExtraction". The new user will only be able to configure and search the mailboxes "EDIInboundCollection" and "EDIInboundExtraction". Sample of the restricted configuration to see 2 mailboxes "EDIInboundCollection" and "EDIInboundExtraction"
• The result will limit both searches are to the mailbox view to only those that the user has been permitted to see.

Restricting Access to Code Lists

• The addition of permission "_DENY_CODELISTS"  will enable access restrictions to the Trading Partner > Code Lists UI.  You will need to manually create this permission. When attempting access, the user will be presented with the message "You do not have the appropriate permissions to access this area".

Additional Permissions

This same format may be used to create additional permission exclusions. You will need to know the exact name of the action or page to which you wish to deny permissions.

Permission names can be found in the page.properties file for UI pages, and in the admin/WEB-INF/web.xml for servlets. These permissions are configurable.

Tip: One way to discover the correct syntax for the action or page you wish to deny is to set the SI ui.log to debug mode, and access the page and/or action you wish to set a deny permission on. In the log, you will be able to view the name of the resource the system attempted to access. Using this name with the formatted string as above will allow you to create the necessary exclusion.

Note: Accessing the resource through the specific permission (upper case), rather than the servlet (lower case) is the preferred method. Grayed out servlet examples are for illustration only to see the difference between the servlet and permission name.

Any UI page deny permissions may be accessed using the permission name that can be found in the pages.properties file. Note that any permissions using the appended string "_ACCESS" are only used for backwards compatibility.