Access Policy Business Object

Some Business Objects (Processes, Screens, Script Functions, Resources) can be accessed in the Workspace using URLs.

Example

• The URL /script/LoadNumcomAccounts executes the Script Function with ID "LoadNumcomAccounts"

Similar URLs can be used to start Processes, display Screens, or access Resources. The following sections explain how to restrict this URL-based access using Access Policies.

Using Access Policies

In the Base Package, URL-based access can be restricted using an Access Policy. Follow these steps:

1. In the Properties of the Access Policy, define an expression which is used to evaluate whether a given user has access to the Business Objects in the Access Policy. If the expression evaluates to true, the user can access the object. If the expression evaluates to false, access is denied.
2. Double-click on the Access Policy to open the editor and drag and drop the Business Objects you want to protect.

Access Policies are Business Objects. They have all advantages of a Business Object:

• After changing an Access Policy, it has to be committed before taking effect.
• Like other Business Objects, Access Policies have incoming ("used by") and outgoing ("uses") dependencies. If you look at the incoming dependencies of e.g. a Process, you can see to which Access Policies it belongs.
• Import and Export works the same way for Access Policies like for any other Business Object.

Note: There is one difference between Access Policies and other Business Objects: While you can start or execute Processes based on uncommitted or outdated versions, evaluating access will always use the latest committed version of the Access Policies.

Expression Examples

• USERINROLE('Administrator')
• USERINGROUP('Nassau') or USERINGROUP('Monaco')

Access Policy Expressions are of course not limited to user functions. To allow users to start a Process only during 6:00 and 18:00, the following expression could be used:

NOW() > TIMEADD(TODAY(), '6h') and NOW() < TIMEADD(TODAY(), '18h')>

The following Business Objects can be added to an Access Policy (Base Package only):

• Processes
• Screens
• Script Functions
• Resources

Note: You can have different types of Business Objects in one Access Policy. nIf a Business Object is added to more than one Access Policy, all expressions must evaluate to `true`. If at least one expression evaluates to `false`, access is denied.

Default Access

If a Business Object located in the Base Package is not included in an Access Policy, a default decision is used to control access:

• For Processes, Script Functions and Screens, the user must be authenticated and a member of the role "Administrator".
• Access to Resources is restricted by default, except for 'Resource' Business Objects using the file types white-listed in the configuration property nm.workspace.resource.filetypes.anonymousaccessallowed (default value: js,css,jpg,jpeg,png,gif). Be aware that this setting applies to 'Resource' Business Objects in all Packages, not just Base. You can:
  • Add file types you do not want to protect to the configuration property.
  • Remove file types that you want to protect from the configuration property.
  • Set the configuration property to ‘*’ to grant access to all 'Resource' Business Objects (matches the default functionality in Appway 6.3 and lower).
  • Leave the value of the configuration property empty to deny access to all 'Resource' Business Objects.

Note: For 'Resource' Business Objects, Access Policies take precedence over any settings made in the configuration property.

Restrictions

Access Policies only protect URL-based access to Business Objects. If a Script Function is used as an activity within a Script component or a Screen used as an Include within another Screen, access is not protected. However, you can always use the AccessPolicyCheck function described in the next section to do your own checks based on Access Policies.

AccessPolicyCheck(...) Expression

Let's think about an example: A portal page contains links to start different Processes. Access to these Processes is restricted based on different Access Policies. If an unauthorized user tries to start a Process protected by an Access Policy, an "AccessPolicyException" occurs.

This is not ideal. It would be better to either not show the link to unauthorized users or to disable it. This can be achieved by using the expression function AccessPolicyCheck. This function has three mandatory and one optional parameter:

1. The first parameter is a user id. The function should check whether this user has access.
2. The second parameter is the type of Business Object to check for: 'Workflow', 'Screen', 'ScriptFunction' or 'Resource'.
3. The third parameter is the ID of the Business Object.
4. The fourth (optional) parameter is the default decision. If the Business Object is not protected by an Access Policy, this parameter is used to decide whether to grant or deny access.

Example

Check whether the current user has access to the Process 'AOP'. Expression: AccessPolicyCheck(USERID(),'Workflow','AOP')

This function can be used as a condition in an If component or Group component to hide parts of a Screen, e.g. a link to start a Process.