FOX – Security Table – The Last Line of Defence

The security table is a set of rules for overriding active modes and views set-out / menu-out

SYNTAX

• <fm:security-rule name="rule name" [privilege="user privilege" state="state" theme="entry-theme" xpath="XPath"]/>
• <fm:mode-rule namespace="namespace" operation="ENABLE | DISABLE" [privilege="user privilege" state="state" theme="entry-theme" xpath="XPath"]/>
• <fm:view-rule namespace="namespace" operation="ENABLE | DISABLE" [privilege="user privilege" state="state" theme="entry-theme" xpath="XPath"]/>

The namespace, privilege, state and theme attributes can all contain comma separated values.

CONCEPTS

Consider:

<fm:set-out match="/*/ORDER" ns1:mode="." ns2:mode="/*/ORDER/STATUS='C'"/>

Even though ns1 appears to be “on” here, the security table may force it “off” or to a view. ns2 is conditionally “off” (not affected), or “on” which may be overridden by the security table to “off” or to a view.
So, the security table has the last word when it comes to deciding whether something is shown.

THE SECURITY TABLE

We prefer the toggling (on/off/view) of display sets to be controlled by the security table:

• They are defined in one place, and therefore easy to maintain.
• Consider defining a security rule with ns:mode=”.” over using ns:mode=”xpath” conditions.  (see example below).

XPATH: <fm:set-out ns:mode=”:{user}/PORTAL_PRIVILEGES/PRIVILEGE/@NAME='PEOPLE_SEARCH'”/>
OR
RULE: <fm:mode-rule operation=”ENABLE” namespace=”ns” privilege=”PEOPLE_SEARCH”/>

The security table is a sequential list of Condition Try Rules.

IMPORTANT NOTE:

• If the namespace is specified in a rule of the security list and no rules ENABLE the namespace, then outcome is DISABLE. Thus any namespace with a rule definition in the security list must be explicitly turned on if required. (ns:mode=”.” does not imply that its 'on' if it has a security rule).
• If namespace is not specified in security table, it is ENABLE.

For each namespace that is provisionally deemed to be “on”, as per set-out / menu-out commands:

• Fox starts with the first rule in the table for that specific namespace.
• If all conditions return TRUE for a rule (using AND logic) then the operation is applied for that namespace. Operations can have OR logic in them by using a comma separated list within a particular condition for a rule. (eg. theme=”new, insert”)  This says if theme is 'new' or 'insert' then perform 'operation'.
• The operation (ENABLE/DISABLE) determines if mode is actually on or off.
• If the outcome of processing a rule is DISABLE, then the processing of rules for that namespace stops.
• If the outcome is ENABLED then the next rule for that namespace is processed.
• If any of the conditions in a rule return FALSE (using AND logic) the operation is not performed and the next rule is processed.
• If all rules return FALSE, the overall outcome is DISABLE, and the mode is “off” because the namespace was not explicitly switched on.
• However if evaluating an ENABLE rule then subsequent rules for that namespace are always considered. If a DISABLE rule is evaluated to 'true' for that namespace then no more rules will be processed and the namespace switched off.

This rule processing approach is similar to Fire Wall Rule Table processing.

NB: AND logic is across (conditions of a rule) and OR logic (for a DISABLE) is down (each rule in the list for a namespace).

Fox actually optimises processing internally to aid performance.
The rule condition attributes test the following:

• privilege – User is logged on, and has one of these named system privileges.
• theme – The module was initially entered under one of these named entry-themes.
• state – The current module state is one of these named states.
• xpath – The XPath test (run relative to root element) returns true.

Attributes namespace and operation select which namespaces to secure and rule outcome.

The fm:security-rule name=”rule_name” condition attributes… allows tests to be defined and reused using rule-ref=”rule_name” attribute on fm:mode-rule and fm:view-rule.

Lastly, when ns:mode is specified on a command, fm:view-rule can knock it back to view.

When ns:view is specified on a command, fm:mode-rule or fm:view-rule are the only ways to disable it.

That is, you never get more access than your set-out or menu-out command asked for.

NB: action=”ENABLE” when used in conjunction with a privilege will resolve to DISABLE unless a user has that privilege.

EXAMPLES

• Disable a namespace for a particulate state:

<fm:mode-rule namespace="ns1" operation="DISABLE" state="state-new"/>

• Enable a namespace for a state and privilege:

<fm:mode-rule namespace="testns" operation="ENABLE" state="state-new" privilege="WORKBASKET"/>

• A real world example:

<fm:security-list>
    <fm:mode-rule namespace="fieldSearch" operation="ENABLE" privilege="PON15D_INPUT" xpath=":{user}/ORG_INFORMATION/WOT_NAME='OIL'"/>
    <fm:mode-rule namespace="fieldSearch" operation="ENABLE" privilege="PON15D_SUBMISSION" xpath=":{user}/ORG_INFORMATION/WOT_NAME='OIL'"/>
</fm:security-list>

EXERCISES

For the following exercises, you will need to log into the Portal (http://edu-app1/portal_dev8.htm) as Colin Brown (Username: CFBROWN). The DEV8 Portal has a universal password to log into any user’s account. The password is ‘dev8dev’.

After logging in, type in the URL of your XX_EMPLOYEEMODULE and click on the :{user} DOM. Confirm that the LOGIN_ID is “CFBROWN” and not “Guest”. There should be a long list of Portal Privileges. Use the Name attribute value for privilege based rules.

Exercise 1

Practice enabling and disabling namespaces by theme, privilege (see User DOM for privileges), state and XPath (e.g. WOT_NAME in User DOM).

Exercise 2

Experiment with multiple security rules and observe the effects of changing the order of some of the rules you create – you may need to invent more namespaces to demonstrate.

Exercise 3

Use the rule-ref attribute in a view-rule to enable another namespace [e.g. the company info in the employee module].