Contents Now Platform Administration Previous Topic Next Topic Contextual security ... SAVE AS PDF Selected Topic Topic & Subtopics All Topics in Contents Other Share Contextual security The contextual security manager provides incredible flexibility and power to protect information by controlling read/write/create/delete authorization. Key advantages Contextual security: Secure a record based on its contents Hierarchical security: Can apply security rules to any level in our object hierarchy Everything you can do with the simple security manager you can also do with the contextual security manager. Likewise, after conversion to the contextual security manager, you should not see any behavior changes in your instance. Securing Fields and Tables Under the simple security manager, you could secure fields and tables by adding roles to the appropriate dictionary entry. After installing the contextual security manager, these dictionary roles are no longer tested. Instead the system looks for ACL rules on fields and or tables. Warning: After you install the Contextual Security Manager you must secure fields and tables via ACL rules. Even if you configure the dictionary form and add roles to a dictionary entry, no change in rights occur. Granting Roles to Users Roles can still be granted to users or groups using the same logic as under the simple security manager. The one noteworthy exception is that the "roles" field on the user record is no longer checked under the contextual security manager (and should be, in fact, removed from your user and group forms upon installation). Note: To add roles to a user or group record under Contextual Security you must add them to the Roles related list instead of to the user or group record itself. Applications and Modules Applications and modules both contain lists of roles under which they can be viewed. For example, the System Definition application requires the admin role to be viewed. Security rights for Applications and Modules are still defined via these role arrays although they may be transitioned to ACLs at some future date. Catalog Items and Variables Both catalog items and catalog variables contain lists of roles under which they can be viewed. Security rights for these entities are still defined via these role arrays although they may be transitioned to ACLs at some future date. Inheritability of Group Roles Under the contextual security manager, a group still automatically inherits any role granted to the group. Note: The role's inherits flag is set to true. Plugins These plugins are automatically installed on new instances and can be activated for upgrades: Contextual Security: Provides contextual security functionality. Contextual Security: Role Management Enhancements: Eliminates duplicate inherited entries in the User Roles [sys_user_has_role] table (starting with the Geneva release) by tracking the number of times a role is inherited from another role or group. Once activated, inherited entries in the User Roles table are automatically managed and cannot be deleted directly. Instead, a containing role or group is expected to be removed from the user. Rule search orderThe system is aware of the instance object hierarchy when it tries to identify a security rule to apply to a particular entity in the contextual security model.Contextual Security: Role Management EnhancementsContextual Security: Role Management Enhancements prevents duplicate entries in the User Roles [sys_user_has_role] table. On this page Send Feedback Previous Topic Next Topic
Contextual security The contextual security manager provides incredible flexibility and power to protect information by controlling read/write/create/delete authorization. Key advantages Contextual security: Secure a record based on its contents Hierarchical security: Can apply security rules to any level in our object hierarchy Everything you can do with the simple security manager you can also do with the contextual security manager. Likewise, after conversion to the contextual security manager, you should not see any behavior changes in your instance. Securing Fields and Tables Under the simple security manager, you could secure fields and tables by adding roles to the appropriate dictionary entry. After installing the contextual security manager, these dictionary roles are no longer tested. Instead the system looks for ACL rules on fields and or tables. Warning: After you install the Contextual Security Manager you must secure fields and tables via ACL rules. Even if you configure the dictionary form and add roles to a dictionary entry, no change in rights occur. Granting Roles to Users Roles can still be granted to users or groups using the same logic as under the simple security manager. The one noteworthy exception is that the "roles" field on the user record is no longer checked under the contextual security manager (and should be, in fact, removed from your user and group forms upon installation). Note: To add roles to a user or group record under Contextual Security you must add them to the Roles related list instead of to the user or group record itself. Applications and Modules Applications and modules both contain lists of roles under which they can be viewed. For example, the System Definition application requires the admin role to be viewed. Security rights for Applications and Modules are still defined via these role arrays although they may be transitioned to ACLs at some future date. Catalog Items and Variables Both catalog items and catalog variables contain lists of roles under which they can be viewed. Security rights for these entities are still defined via these role arrays although they may be transitioned to ACLs at some future date. Inheritability of Group Roles Under the contextual security manager, a group still automatically inherits any role granted to the group. Note: The role's inherits flag is set to true. Plugins These plugins are automatically installed on new instances and can be activated for upgrades: Contextual Security: Provides contextual security functionality. Contextual Security: Role Management Enhancements: Eliminates duplicate inherited entries in the User Roles [sys_user_has_role] table (starting with the Geneva release) by tracking the number of times a role is inherited from another role or group. Once activated, inherited entries in the User Roles table are automatically managed and cannot be deleted directly. Instead, a containing role or group is expected to be removed from the user. Rule search orderThe system is aware of the instance object hierarchy when it tries to identify a security rule to apply to a particular entity in the contextual security model.Contextual Security: Role Management EnhancementsContextual Security: Role Management Enhancements prevents duplicate entries in the User Roles [sys_user_has_role] table.
Contextual security The contextual security manager provides incredible flexibility and power to protect information by controlling read/write/create/delete authorization. Key advantages Contextual security: Secure a record based on its contents Hierarchical security: Can apply security rules to any level in our object hierarchy Everything you can do with the simple security manager you can also do with the contextual security manager. Likewise, after conversion to the contextual security manager, you should not see any behavior changes in your instance. Securing Fields and Tables Under the simple security manager, you could secure fields and tables by adding roles to the appropriate dictionary entry. After installing the contextual security manager, these dictionary roles are no longer tested. Instead the system looks for ACL rules on fields and or tables. Warning: After you install the Contextual Security Manager you must secure fields and tables via ACL rules. Even if you configure the dictionary form and add roles to a dictionary entry, no change in rights occur. Granting Roles to Users Roles can still be granted to users or groups using the same logic as under the simple security manager. The one noteworthy exception is that the "roles" field on the user record is no longer checked under the contextual security manager (and should be, in fact, removed from your user and group forms upon installation). Note: To add roles to a user or group record under Contextual Security you must add them to the Roles related list instead of to the user or group record itself. Applications and Modules Applications and modules both contain lists of roles under which they can be viewed. For example, the System Definition application requires the admin role to be viewed. Security rights for Applications and Modules are still defined via these role arrays although they may be transitioned to ACLs at some future date. Catalog Items and Variables Both catalog items and catalog variables contain lists of roles under which they can be viewed. Security rights for these entities are still defined via these role arrays although they may be transitioned to ACLs at some future date. Inheritability of Group Roles Under the contextual security manager, a group still automatically inherits any role granted to the group. Note: The role's inherits flag is set to true. Plugins These plugins are automatically installed on new instances and can be activated for upgrades: Contextual Security: Provides contextual security functionality. Contextual Security: Role Management Enhancements: Eliminates duplicate inherited entries in the User Roles [sys_user_has_role] table (starting with the Geneva release) by tracking the number of times a role is inherited from another role or group. Once activated, inherited entries in the User Roles table are automatically managed and cannot be deleted directly. Instead, a containing role or group is expected to be removed from the user. Rule search orderThe system is aware of the instance object hierarchy when it tries to identify a security rule to apply to a particular entity in the contextual security model.Contextual Security: Role Management EnhancementsContextual Security: Role Management Enhancements prevents duplicate entries in the User Roles [sys_user_has_role] table.
