qbo.Security

Overview

The security module boils down to two concepts:

• • What functions can a user perform (functional security), and 

  • Which rows can a user perform these functions on (extranet security)?

Key classes are:

• • Person: represents a user

  • SystemRole: represents a group of users that share permissions (e.g. Administrators, Users, Managers, etc.)

  • SystemFunction: represents an atomic function (e.g. ContactInsert, OrganizationSearch, MessageDelete)

  • SystemPermission: maps a function to a role

  • SystemMember: maps a person to a role

  • SystemAccess: used for 1-time access (logins via GUID)

Functional Security

Functional security is maintained via Design > Security, and include build-in system functions such as:

• • Valuation Search: grants a user permission to search for valuations

  • Loan Select: grants a user permission to select (view) loans

  • Attachment Insert: grants a user permission to insert attachment (document images)

  • Message Update: grants a user permission to update existing messages

  • Calendar Delete: grants a user permissions to delete calendars (milestones)

Granting a user permission to select (view) a loan does not necessarily imply that they get to select any loan in the system; instead, they can only select those loans to which they have access via extranet security (see below).

There are typically several thousand permissions in an average QBO system. Determining precisely which functions to grant to achieve a particular business task can be overwhelming. To assist with setting up permissions, you can record permissions as follows:

• • Navigate to Design > Roles > {Some Role}

  • From the Permissions Granted tab, select Options > Record Permissions

    • this will pop up a window with Start, Stop ans Save buttons

  • Click the Start button in the popup window

  • Navigate to perform the business task

  • Click the Save button in the popup window

The role will now have all permissions 'touched' during the recording period.

Extranet Security

Once functional security has been address, one should consider which rows of data a user may perform these functions on.  For example, in a BPO system, BPO clients should typically have the right to search and select valuations, but they should be limited to search for and selecting only those valuations for which they are a client.  BPO agents should be able to select (view) and update the data associated with a BPO (valuation update), but only for those BPOs which they are the agent for.  Extranet security limits access to only those rows of data which the user has been granted access to.

Granting access to a row of data is typically done automatically by the QBO system.  For the examples above:

• • Setting Valuation.Client to 'Bank of America' will automatically grant BofA users access to that valuation

  • Setting Valuation.Broker to 'Agent, Johnny' will automatically grant Johnny Agent access to that valuation

When a BofA user navigates to a BPO Search page, and searches for all BPOs, the system will check:

• 1. Does the user have the 'valuation search' functional permission, and

  2. Does the user have access to the BPO(s) in question?

Universal Access

For many situations, users may well need to essentially view all rows in a system. The company that contracts directly with Quandis to create a QBO instance (Quandis' 'client') will typically have users that should be able to see all data, regardless of which client sent them the data, or which vendor may be fulfilling services related to the data.  Such users should be members of a 'universal access' Role.  Members of a universal access role bypass the extranet security model, but are still subject to the functional security role.

User Interface Permissions Handling

When rendering UI controls that execution functionality via AJAX (dashboards, panels, menu items, etc.), it is preferable to:

• • If the user has permission, render the UI widget,

  • If the user does not have permission:

    • disable the widget if the user should be aware that the widget exists (e.g. menu items), or

    • do not display the widget (dashboards and panels)

If a UI widget executes some method signature that the user does not have permissions for, QBO3 will render an alert in the browser stating 'You do not have permission.' This should only occur when:

• • User navigate to a URL that is not linked to by the UI,

  • Power users have mis-configured access, or

  • the UI is not configured to handle permissions correctly