Close popover

Table of Contents

Configuring security settings for an access group

Version:

You can define settings for an access group that are related to authentication, security, connectivity, and accessibility for users and other requestors who reference the access group.

You must complete one of the following tasks before defining access control for an access group:
  • Create an access group as described in Creating an access group.
  • Open an existing instance from the navigation panel by clicking Records Security Access Group and selecting an instance.

To configure access control for an access group, click the Advanced tab and navigate to the Access Control section. Choose any of the following options.

  • In the Authentication timeout field, describe the number of seconds after which the system challenges idle browser sessions by asking users to re-enter their operator ID and password.

    This time-out event does not cause session context or clipboard contents to be lost.

    If users respond to the challenge and are reauthenticated, they can usually continue processing where they left off, unless the system released locks that they held in the meantime or the system was stopped and restarted.

    This setting is also taken into account in an offline-enabled application that is either online or offline. When the time-out value is reached, users are automatically logged out when they perform any action and the login screen is displayed.

    This authentication time-out is not related to the timeout/browser value in the prconfig.xml file or dynamic system settings, which control the time-out for passivation to occur.
  • In the HTTP/HTTPS home directory field, accept the default of /webwb.

    Directories within this directory hold important static XML forms, JavaScript, style sheets, and images. If you changed the name of this directory, enter the new directory name in this field.

  • In the Rule security mode field, select whether and how the system executes rules accessed.

    In Pega Platform, rules can be made to require privileges in two ways:

    • By an administrator explicitly editing the rule's Security tab (where such a tab is available).
    • By a Pega Platform activity, pyRuleExecutionMessagesLogged, that automatically generates privileges and adds them to roles that access rules that require privileges.
    • Allow [default] – The system allows users that belong to the access group to execute a rule that has no privilege defined, or to execute a privileged rule for which the user has the appropriate privilege. This includes privileges predefined for standard roles, set by an administrator, or generated by Pega Platform. This is the default and recommended setting.

      A best practice is to use this mode, and to use the Access Manager to configure authorization for rules. When more specific security is needed for an individual rule, specify a privilege for the rule. For more information, see Specifying privileges for an Access of Role to Object rule. If you want to specify privileges for all rules and users and you have sufficient time and resources to perform a system-wide exercise including all expected users, see Setting role privileges automatically for access group Deny mode on Pega Community.

    • Deny – The system checks for either of these conditions:
      • The user has an explicit privilege or a generated privilege for the rule. If the user has either privilege, the system executes the rule. If the user has neither privilege, the system denies execution of the rule and logs an error message in the PegaRULES log.
      • The user has the generated privilege. If the user lacks the generated privilege, the system denies execution and writes an error message to the PegaRULES log.
    • Warn – The system performs the same checking as in Deny mode, but performs logging only when no privilege has been specified for the rule or the user role:
      • If a privilege has been specified for the rule, the system checks whether the user has an explicit or a generated privilege for the rule. If the user has neither privilege, the system denies execution of the rule.
      • If no privilege has been specified for the rule, the system checks whether the user has a generated privilege. If the user lacks the privilege, the system allows execution and writes a warning message to the PegaRULES log. Warning messages are used to generate privileges with pyRuleExecutionMessagesLogged.

      Use the Warn mode only when you want to identify rules for which users need generated privileges to execute. You can then use the Pega Platform activity to generate missing privileges and add them to roles where needed. For more information, see Setting role privileges automatically for access group Deny mode on Pega Community.

  • Learning about access groups

    An access group is a group of permissions within an application. Pega Platform uses these permissions for operators, external system access, and background processes. You define an access group for operators who have similar responsibilities. For example, most applications allow case managers to do actions that are different from the actions of regular operators, so case managers and regular operators belong to different access groups.

  • Creating an access group

    An access group is a group of application permissions that are used by an operator, external system, or background process. Create an access group to define the actions that are allowed when such an entity uses an application.

Suggest Edit

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.