Allow invocation from browser

Select the Allow invocation from browser check box when your activity meets one or more of the following criteria:

• You need to be able to call this activity directly from JavaScript code in a non-autogenerated Section or non-autogenerated Control or Text File rule.
• You need to be able to call this activity from a URL Mappings rule.
• You need to use the deprecated List Views or Summary Views and you need to call an Activity in the Content field. To access these deprecated views:
  • In the panel of Dev Studio, click RecordDeprecated: Summary viewFormat tab. Then, right-click Smart info settings, and then click the Content field.

For more information, see Setting a privilege to secure an activity.

One use case where you should not select the Allow invocation from browser check box is when you are configuring an external system to call this activity by URL. Instead, create a Service REST rule.

• For more information, see Creating a REST integration.

Require authentication to run

Require authentication to run is selected by default. In most cases, do not change this selection.

Clear the Require authentication to run check box to allow guest users to run this activity if they meet other security and access criteria. Guest users — unauthenticated requestors — typically have access to rules in the RuleSets in the PRPC:Unauthenticated access group. In many instances, clients overwrite this with their own unauthenticated authentication group. Therefore, your unauthenticated access group might have another name, similar to <application name>:Unauthenticated. Note: A session remains unauthenticated until the user signs in by using credentials, unless you are using an anonymous authentication service. For more information, see:

• Configuring login authentication for an anonymous operator.
• Activating your anonymous authentication service.

Note: If you clear the Require authentication to run check box and select Allow invocation from browser, any person with access to your server can execute this activity. The default Authorization model stops unauthenticated users from having read and write access, so it is important to consider if your activities do something other than read and write.

Privileges: Privilege Name and Privilege Class

Privilege inheritance simplifies the process of defining privileges and access settings that are relevant in multiple classes.

Use privileges to differentiate the capabilities of different groups of users within your application. The privilege form defines only the existence (name and Applies To class) of a new privilege. It contains no other information and conveys no capabilities by itself.

Privileges has two fields that you can enter information into, the Privilege Name field and Privilege Class field.

A privilege is an application-specific access control element associated with a class and access role. A privilege rule only names a privilege; it does not convey the privilege to anyone. A privilege has two parts: the privilege class and the privilege name.

To have access to a privilege, a requestor session must "hold," in the access role list, at least one of the access roles that grant access to the privilege. The association between access roles and privileges is defined by instances of the Rule-Access-Role-Obj rule type.

Using privilege rules in an application is optional, but they can offer finer control over access than using access roles alone.

The Privilege Class field contains the auto-generated rule classes that are associated with the privilege.

The Privilege Name field contains the auto-generated list of privilege names.

Standard privileges

The following tables list the most common end-user and administrative privileges.

Standard end-user privileges are shown in the following table.

Standard administrative privileges are shown in the following table.

Using privileges to control access

Most access control is granted through authorization, which controls many common use cases around creating, updating, and deleting cases and data. However, when using privileges, consider the following two areas:

• When to use a privilege
• Setting a privilege to secure an activity

When to use a privilege

In some cases, you must add a privilege to an activity to keep your application secure, for example:

• If an activity performs a task that only specific access groups or access roles should perform.
  • For example, a bulk processing activity for administrators should have a privilege so that users cannot run the activity.
• When Allow invocation from browser is selected, a user must have a privilege.