C Appendix: Security UI

This appendix provides details of the administration of the JET UI user access permissions.

The JET UI based security administration facility replaces the current ECHO UI Permissions spreadsheet upload, for the new JET UI based screens only.

The new model utilizes the existing method of allocating user's combinations of Authority Profiles and Roles to determine their level of access to the application’s functionality (including navigation, actions, and APIs), and its data. The permissions are defined as sets of policies in XML files rather than a spreadsheet of rules.

The core set of default system-delivered security policies can be overridden by the client, with the system administrator having access to a new maintenance facility in the Admin area.

The overrides are applied by uploading XML files containing the custom rules. The files may represent a single rule as part of a simple flat structure, or a group of rules as part of a more complex hierarchical structure.

Security Model Overview

The security rules are defined as policies and policy sets, in XML files, grouped by these policy types:

  • Tasks - for controlling access to menu options.
  • Filters - for applying filters to data.
  • Fields - for controlling access to list view columns and form fields.
  • Actions - for controlling access to list view and form actions.
  • Redactions - for forming subsets of data, such as to remove associated child data that is not required.
  • Decisions - for controlling whether a UI component is shown or hidden.

A predefined set of combining algorithms determine how the policies are applied and whether the rule is to permit or deny access:

  • PermitPreferred - If any rules in the policy generate a PERMIT result, then PERMIT is the result. If any rules in the policy generate a DENY result and no rule generates a PERMIT result, then DENY is the result. If no rules are matched, then the result is NO_MATCH. Used for Tasks and Actions.
  • DenyPreferred - If any rules in the policy generate a DENY result, then DENY is the result. If any rules in the policy generate a PERMIT result and no rule generates a DENY result, then PERMIT is the result. If no rules are matched, then the result is NO_MATCH. Used for Tasks and Actions.
  • LastMatch - The last rule to match is chosen as the result. If there are no matches, the result is NO_MATCH. Used for Tasks and Actions.
  • CombineAnd - If one rule is matched, the expression from that rule is the result in a singleton list. If multiple rules are matched, then the expressions from those rules are ANDed together as the result in a singleton list. If no matches are generated, then the result is an empty list. Used for Filters.
  • CombineOr - If one rule is matched, the expression from that rule is the result in a singleton list. If multiple rules are matched, then the expressions from those rules are ORed together as the result in a singleton list. If no matches are generated, then the result is an empty list. Used for Filters.
  • AllMatch - If any rules are matched, then all are returned as the result list. If no rules are matched, then an empty list is the result. Used for Redactions.

The Security Policy comprises a set of Policy Override records per Policy Type (so up to six sets of Policy Overrides). Each Policy Override record is associated to a single Policy Type and Combining Algorithm, and has a single XML file attachment.

This image shows the security policy flow.

Security Policies Administration

The system-delivered core rules may be overridden or extended by client administrators using the new Security Policies maintenance facility.

By default, the option is available to users with the ORACLE AUTHORIZED ADMINISTRATOR authority profile. This is one of the rules that can be overridden/supplemented in the security policy overrides, so access may therefore be granted to other authority profiles if required. It opens the Security Policies list view.

Security Policies List View

The Security Policies list view contains a single Security Policy record which may have multiple versions, of which just one is active. Alternative sets of new draft rules can be maintained, then activated when ready; prior sets of rules can be reverted to, by reactivating a deactivated set.

This image shows the Security Policies list view.

Security Policy Form

The Security Policy form comprises:

This image shows the Custom Policy view.
  • A set of fields which represent the Security Policy record. Description and Comments are mandatory, non-translatable fields, defaulting to Custom Policy.
  • A set of tabs which represent the fixed set of Policy Types: Task, Filter, Field, Action, Redaction, and Decision (an enumerated list of translatable system text literals).

  • A Combining Algorithm mandatory selector containing the options available for the policy type.

    The selections are taken from an enumerated list of translatable system text literals, which has a Boolean flag to indicate which are to be included in the picklist. The predefined set of options per Policy Type is a follows:

    Policy Type Combining Algorithms

    Action Task

    DenyPreferred

    LastMatch

    PermitPreferred

    Field Presenter

    		 LastMatch
    Filter

    CombineAnd

    CombineOr

    LastMatch
    Redaction

    AllMatch

    LastMatch
    Decision LastMatch

  • A data grid which contains the Policy Override records for the selected policy type tab. The rows are sorted in ascending Sequence order, representing the order in which they will be applied as rules.

    The maintenance behavior includes the following:

    • When creating a new Security Policy record, it must be saved before a Policy Override can be created.
    • The Export/XML File option downloads the row’s XML file.
  • The Policy Override record is a container for the override policy rules XML file. The pane contains:
    • The Policy Type based on the which tab has been selected.
    • The Sequence the rules are to be applied. A mandatory integer (must be greater than zero). In order to allow for overrides to be inserted into an already populated record, the recommendation is to use sequence intervals such as 10, 20, 30 . . ., or 100, 200, 300 . . .
    • A Reason or purpose of the override. A mandatory non-translatable text field.

    • The Policy File upload/download of a single XML file.

      The file may represent either a single rule as part of a flat structure, or a group of rules as part of a hierarchical structure. See Additional Information for further details.

Clicking OK validates that the mandatory fields are populated and that an XML file has been selected, the XML is well-formed, and the Policy Type within it matches that of the Policy Override record, before saving the Policy Override record.

Additional Information

For areas that are presented in the JET UI, user access is controlled by the new Security Policies subsystem. Any custom overrides to the core access rule, including any that have previously been applied using the ECHO Permissions spreadsheet, must be applied using the new method.

This section provides additional information on configuring custom Security Policy overrides.

Typical Override Usage

Some examples of custom Permissions overrides that are typically applied by clients are listed here.

Audits & Visits

  • Remove permissions rules, to prevent Restricted Auditor users from being able to complete Audits.
  • Add permissions, to:
    • Make the Audit Due Date field and Audit Issue Due Date read-only to supplier users.
    • Enable supplier users to complete and unlock Checklists.

Suppliers and Sites

  • Add permissions, to:
    • Hide the Details/Other field sets in Supplier and Site records from supplier users.
    • Hide the Change History and Custom Fields tabs in Supplier and Site records from supplier users.
    • Hide the Sites and Linked Sites tabs on the Supplier and Site records from Restricted Auditor users.
    • Make the Custom Fields tab in Site records read-only to supplier users.
    • Make the Name and Address fields in Supplier and Site records read-only to supplier users.

Policy File Examples

This section provides some examples of the core System Policy XML files and custom override XML files.

Core System Policy Files

The core system policy rules are dynamically applied to the system in a way that they are automatically updated as part of a release upgrade whenever the release includes a permissions update.

The current set of core system policy rules can be downloaded as a set of XML files within a ZIP file (System_Policy.zip), for reference when building custom overrides.

The root folder of the compressed file contains:

  • The XSD schema (ui-policies.xsd) which provides the full description of the structure of the policy rules XML files.
  • A set of Policy Set XML files (for example Tasks-PolicySet.xml) which define the policy rules XML files used for each of the policy types: Tasks, Filters, Presenters (Fields), Actions, Redactions, and Decisions.

  • Folders which group together the policy rules XML files by logical area or application module (for example the suppler folder may contain the supplier-filters-policy.xml and supplier-tasks-policy.xml files).

    In addition to folders for the application modules (admin, company, library, project, reports, and supplier), the following folders are included:

    • area - rules relating to Enhanced Access Control (EAC) permissions.
    • enum - rules relating to enumerated picklist values (such as User Types or News Item Priorities).
    • glossary - rules relating to individual glossaries (such as Countries or Contact Roles).
    • home - rules relating to the Home page contents (such as Announcements and Workspace KPIs).
    • manage-columns – rules relating to the presentation of columns in list views based on user type.
    • scoring – rules relating to Supplier Evaluation, dashboards, and scoring.

Some simple examples of XML policy rules for the Admin area are as follows:

admin / admin-tasks-policy.xml

Permit Configuration Editor, Oracle Authorized Administrator, and Scorecard Administrator users access to the configuration of Assessments/Scorecards.

	<Task ruleId="scorecardAdmin">
		<TaskId>Scorecard Questions</TaskId>
		<TaskId>Scorecard Templates</TaskId>
		<TaskId>Scorecard Status</TaskId>
		<Result>PERMIT</Result>
		<ActiveAuthorityProfile>
			<Profile>CONFIGURATION EDITOR</Profile>
			<Profile>ORACLE AUTHORIZED ADMINISTRATOR</Profile>
			<Profile>SCORECARD ADMINISTRATOR</Profile>
		</ActiveAuthorityProfile>
	</Task>

Permit Oracle Authorized Administrator users access to the configuration of Security Policies.

	<Task ruleId="securityPolicies">
		<TaskId>securityPolicies</TaskId>
		<Result>PERMIT</Result>
		<ActiveAuthorityProfile>
			<Profile>ORACLE AUTHORIZED ADMINISTRATOR</Profile>
		</ActiveAuthorityProfile>
    </Task>

Permit News Administrator, Oracle Authorized Administrator, Configuration Editor, and Integration Administrator users access to the configuration of the Photo Album.

	<Task ruleId="albumAdmin">
		<TaskId>albumAdmin</TaskId>
		<Result>PERMIT</Result>
		<ActiveAuthorityProfile>
			<Profile>NEWS ADMINISTRATOR</Profile>
			<Profile>ORACLE AUTHORIZED ADMINISTRATOR</Profile>
			<Profile>CONFIGURATION EDITOR</Profile>
			<Profile>INTEGRATION ADMINISTRATOR</Profile>
		</ActiveAuthorityProfile>
	 </Task>

Permit Oracle Authorized Administrator and Configuration Editor users access to the custom list view migration facility.

	<Task ruleId="userViewMigrationLog">
		<TaskId>userViewMigrationLog</TaskId>
		<Result>PERMIT</Result>
		<ActiveAuthorityProfile>
			<Profile>ORACLE AUTHORIZED ADMINISTRATOR</Profile>
			<Profile>CONFIGURATION EDITOR</Profile>
		</ActiveAuthorityProfile>
	</Task>

admin / admin-actions-policy.xml

Permit Oracle Authorized Administrator users read, create, update, and delete access to Policy Overrides.

	<Action ruleId="PolicyOverridePolicy">
		<Channel>PolicyOverridePolicy</Channel>
		<Action>createPolicyOverridePolicy</Action>
		<Action>read</Action>
		<Action>create</Action>
		<Action>update</Action>
		<Action>delete</Action>
		<ActiveAuthorityProfile>
			<Profile>ORACLE AUTHORIZED ADMINISTRATOR</Profile>
		</ActiveAuthorityProfile>
		<Result>PERMIT</Result>
	</Action>

Override System Policy Files

Custom permissions are applied by uploading rules that override the core system policy rules (as described in Security Policies Administration).

Override rules may be defined in either individual XML files per rule and/or groups of rules within a file (per policy type).

Some simple examples of typical XML override rules are as follows:

admin-tasks-override-photo.xml

Deny News Administrator users access to the configuration of the Photo Album. Policy Type is Task, Combining Algorithm is DenyPreferred.

<Policy type="Task" combiningAlgorithm="DENY_PREFERRED"
	xmlns="http://retail.oracle.com/brand-compliance/ui-policy"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://retail.oracle.com/brand-compliance/ui-policy ../ui-policies.xsd">
	<Task ruleId="albumAdmin">
		<TaskId>albumAdmin</TaskId>
		<Result>DENY</Result>
		<ActiveAuthorityProfile>
			<Profile>NEWS ADMINISTRATOR</Profile>
		</ActiveAuthorityProfile>
	</Task>
</Policy>

admin-tasks-override-migration.xml

Also permit News Administrator users access to the custom list view migration facility. Policy Type is Task, Combining Algorithm is PermitPreferred.

<Policy type="Task" combiningAlgorithm="PERMIT_PREFERRED"
	xmlns="http://retail.oracle.com/brand-compliance/ui-policy"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://retail.oracle.com/brand-compliance/ui-policy ../ui-policies.xsd">
	<!-- User View Migration Admin -->
	<Task ruleId="userViewMigrationLog">
		<TaskId>userViewMigrationLog</TaskId>
		<Result>PERMIT</Result>
		<ActiveAuthorityProfile>
			<Profile>NEWS ADMINISTRATOR</Profile>
		</ActiveAuthorityProfile>
	</Task>
</Policy>

XML File Structure

File Naming

The core system policy rules have a naming convention for the XML files, for example: supplier-tasks-policy.xml.

The custom override XML files do not need to follow a naming convention, however the client may choose to utilize their own naming convention.

File Structure

The XSD schema provides the full description of what can be placed into the Policy Override XMLs and may be leveraged by some XML editors for auto-completion and validation. The latest XSD can be found within the core System Policies ZIP file (System_Policy.zip), which can be downloaded from the list view.

The following is an example of a portion of the XSD:

     <xs:element name="ActiveAuthorityProfile" type="activeAuthorityProfileType">
        <xs:annotation>
            <xs:documentation>
            Matches on request users active authority profiles
            </xs:documentation>
        </xs:annotation>
     </xs:element>

     <xs:element name="UserMode" type="userModeType">
        <xs:annotation>
            <xs:documentation>
            Matches on request users mode - NORMAL or RESTRICTED
            </xs:documentation>
        </xs:annotation>
     </xs:element>

     <xs:element name="ArtworkEnabled" type="markerElementType">
        <xs:annotation>
                <xs:documentation>
                Matches on whether artwork is enabled in the system
          </xs:documentation>
        </xs:annotation>
     </xs:element>

     <xs:element name="UserTypes" type="userTypesType">
        <xs:annotation>
            <xs:documentation>
            Matches on request users type - RETAILER, SUPPLIER, SITE or ALLSITE
            </xs:documentation>
        </xs:annotation>
     </xs:element>

     <xs:complexType name="activeAuthorityProfileType">
        <xs:annotation>
            <xs:documentation>
            The authority profile codes to match on
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="Profile" type="xs:string" maxOccurs="unbounded"/>
        </xs:sequence>
     </xs:complexType>

     <xs:simpleType name="markerElementType">
        <xs:annotation>
            <xs:documentation>
            Matchers that do not take options or settings use this type
            </xs:documentation>
        </xs:annotation>
        <xs:restriction base="xs:string">
            <xs:maxLength value="0"/>
        </xs:restriction>
     </xs:simpleType>

     <xs:complexType name="userTypesType">
        <xs:annotation>
            <xs:documentation>
            The user types to match on
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="UserType" maxOccurs="unbounded">
                <xs:simpleType>
                    <xs:restriction base="xs:string">
                        <xs:enumeration value="RETAILER" />
                        <xs:enumeration value="SUPPLIER" />
                        <xs:enumeration value="SITE" />
                        <xs:enumeration value="ALLSITE" />
                    </xs:restriction>
                </xs:simpleType>
            </xs:element>
        </xs:sequence>
     </xs:complexType>