Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Configuring security settings for an access group

Updated on July 1, 2021

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.

Before you begin: 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 RecordsSecurityAccess 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.

    Note: 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 Access of Role to Object form - Completing the Privileges tab. 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.

  • Previous topic Configuring advanced settings for access groups
  • Next topic Defining a run-time configuration for an access group

Have a question? Get answers now.

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

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us