|
|
|
|
|
Security Restrictions and Access to Data
This
section describes the effects of applying security restrictions. Using a system
of certification of Callista functions, it provides the information required
by system administrators to ensure that security restrictions applied to users
have a predictable, required effect.
The
purpose of this section is:
- to advise security administrators with regard to the application
of security restrictions to users
- to advise subsystem administrators about the access end users may
have to those subsystems
In
this section:
- General Considerations
- Correspondence Type Restrictions
- Organisational Unit Restrictions
General Considerations
Security restrictions and data access tools
Security
restrictions act to limit the 'select' and 'operational' (update, insert,
delete) access of users, to particular sets of data. The set of data is the
data related to values for which restrictions have been granted. For example,
a user may be restricted to data for a particular organisational unit (org
unit) or a particular correspondence type.
Security
restrictions are applied at the database level, to tables and views. They
restrict 'select' and 'operational' access of users accessing data in those
tables and views, through forms. Importantly, they also restrict access to
data by other means, including by data query tools such as SQL Plus, SQL Navigator
and Oracle Browser.
Expected error messages
Users
may encounter security restriction related error messages when they execute
a query within a form. This may occur when the query returns records containing
data drawn from database tables to which a security restriction applies, and
that data relates to a security restriction for which the user does not have
the appropriate restriction grants.
For example, consider a user with an org unit restriction of 'restricted select'
for org unit '04' only. If the user executes a query in CRSF2120 (Maintain
Unit Categories) which retrieves a unit category with category member units
owned (teaching responsibility org unit) by org units other than '04', the
unit codes are displayed but the unit short titles of those units are not.
An error message ' Error: This Unit Code, version Number does not exist' is
displayed. This occurs because while there is no org unit restriction security
over the table containing unit categorisations (UNIT_CATEGORISATION), there
is org unit restriction security over the table containing the unit
short titles (UNIT_VERSION).
Expected
Error Messages
|
|
|
Expected Error Message |
Interpretation |
|
This
Course Code, Version Number does not exist This
Unit Code, Version Number does not exist This
Responsible OU does not exist This Responsible OU, Responsible OU Start DT does not exist |
This error displays when records are returned and a component of the record is sourced from a different database table that is affected by the user's security restriction. For example, when navigating to the Course Award Inquiry block of CRSF1190 (Maintain Awards), a query is performed to return all courses associated with a particular award. If any of these courses is 'owned' by an org unit for which the user does not have an org unit restriction, their title will not display. This is because the table from which the course title is sourced (COURSE_VERSION) is affected by org unit restrictions. Wherever possible users should be given 'restricted select' access to all org units they are likely to encounter. |
|
You have attempted an operation for which you do not have the appropriate privileges. Restricted by Organisational Unit. |
Users with 'restricted select' access only for an org unit restriction may invoke this error whenever they try to update, insert or delete a record related to that org unit. If the user should be able to operate on records for the org unit, their org unit restriction must be updated to include insert, update and delete functions. |
Users
with correctly granted security restrictions and with access to only certified
functions will rarely encounter these errors. Users should be educated about
when expected error and warning messages will be encountered and either how
to interpret those messages or who to contact for assistance.
Dealing with shared ownership
Forms
such as CRSF1220 (Maintain Course Ownership) can be used to apportion ownership
or responsibility across more than one org unit. A user with the restriction,
'restricted select' for org unit '04' only, can enter this form in the context
of a course version record for which 04 is responsible. The course version
may be jointly owned by 04 and another org unit. The user can see both owning
organisational units because, depending on the context of the data, some forms
have had the normal organisational unit security on 'select' operation overridden.
Security restrictions and audit forms
No
restriction views have been created on the underlying audit database tables.
This means that no audit forms are certified. (Refer to Organisational
Unit Restriction Certification)
Restricted users should not be granted any audit forms. Granting the Course
version audit form (AUDF3126) to a restricted user would allow the user access
to all course version data.
Correspondence Type Restrictions
Details
regarding the operation of correspondence type restrictions are contained
in documentation for the Maintain Correspondence Type Security form (SECF0033).
No
functions have been 'certified' for correspondence type restrictions. The
section Organisational Unit Restriction Certification
details the specifics of org unit restriction certification and these are
equally applicable to correspondence type restrictions.
Organisational Unit Restrictions
Impact of Organisational Unit Restrictions
Users
may access organisational unit (org unit) related data in a number of ways,
including:
- selecting/inserting records which include an org unit as a data element.
E.g. adding a new course version in CRSF1210, where Responsible Org Unit
is part of each course version record.
- selecting/inserting org unit related children records of parent records
for which the user has org unit access. E.g. selecting a course version
record for an org unit to which access is granted (CRSF1210) and then selecting
the course version's course award/award ownership records in CRSF1250. Course
award records may have owning org units to which the user does not have
org unit restriction access.
- seeing org unit related data in lists of values (LOV). E.g. when
assigning courses to a course category (in CRSF1130), the Course Code LOV
displays records which have responsible org unit as an element, although
the org unit itself is not displayed.
- retrieving org unit related data via Callista reports - Note: no reports are certified.
- retrieving org unit related data via an ad-hoc report/query tool.
Organisational
unit restrictions are used to restrict the select and operation (insert, update,
delete) access of users, to data related to specific org units. For example,
a faculty officer might be restricted to selecting and updating data for their
faculty and its related schools only. In some specific contexts, organisational
unit security may have been overridden. For example, in the second dot point
above, a user can see course award records for org units for which
they have an org unit restriction. The org unit restrictions on the award
ownership data in the same form are overridden to allow the user to see award
ownership records for org units to which they do not have security access.
The
documentation for the Maintain Organisational Unit User Restrictions form
(SECF0032) describes
this functionality in more detail.
Note:
Not all org unit related data is subject to org unit restrictions. Restrictions
are applied, at the database level, to individual tables and views. Users
are restricted only when using data in these tables/views. Refer to the Security
Technical Documentation for further information and a complete list of tables
and views to which restrictions apply.
Organisational Unit Restriction Certification
The
impacts of org unit restrictions are system wide. To ensure that these impacts
are predictable, a system of certification has been introduced to guide Security
and subsystem specialists in the application of org unit restrictions to users.
The intention is that org unit restrictions should only be applied to users
of the certified functions. Application of org unit restrictions to users
of non-certified functions may produce the desired effects. It may also produce
unpredictable effects and will result in error messages being displayed which
may be difficult to interpret outside the documentation for certified functions.
Certification
involves analysis of existing interaction between specific functions and org
unit restrictions, and design enhancements to ensure that the effects of a
restriction are exactly as required. Extensive testing ensures the correct
results. Certification is an ongoing process that commenced (Release 2.0)
with the Course Structure and Planning and Inquiry subsystems.
Org Unit Restriction Certified Functions
The
following table lists all org unit restriction certified functions
as at Release 3.1.2. Presently, this consists of Course Structure and Planning,
the Inquiry subsystem and Enrolment forms only.
About
this table
Restricted
Select column
Entries
in the restricted select column indicate whether or not an organisational
unit 'select' restriction, applied to a user, affects the user's ability to
select data in that form or block. For example, if a user has been granted
restricted select access to org unit '04' and to no other org units, 'yes'
in the Restricted Select column of this table indicates that the user is restricted
to selecting data related to org unit 04 only. Where 'yes' is recorded, the
impact of the restriction is noted (in brackets). These impacts are:
- <data element> not displayed - this occurs when data elements related to the
displayed record are 'looked up' in tables to which org unit restrictions
apply. For example, querying course categories in CRSF1130 displays course
categories and the courses belonging to those categories. The course codes
of courses belonging to a course category are stored in the COURSE_CATEGORISATION
table, which has no data restrictions on it. The descriptions of the courses
are stored in the COURSE_VERSION table. Org unit restrictions apply to this
table. When the user from the previous example retrieves course categorisations
which include courses owned by org units other than '04', the course codes
are displayed but their descriptions are not, and an error message is displayed.
- retrieves only courses/units/org units for which user has org unit
select restriction - when a user
performs a query, the displayed data contains only those records directly
related to the org unit for which the user has been granted restricted select.
The Restricted By column indicates which aspect of the data the org unit
restriction is acting on. Users with no restricted select grants will see
all data returned by their query, regardless of the org units to which the
data is related.
- this form is always entered in context from/via <form name>
where restricted select applies
- by entering the form in context, any restrictions have already been applied,
in a previous form, to the context record.
Restrictions
in LOV column
Entries
in this column indicate the name of the field adjacent to an LOV where the
records in the LOV are restricted by the user's org unit restricted select
grant(s). For example, CRSF1130 has an LOV adjacent to the Course Code field
which displays a set of course versions limited by a user's restricted select
grants. The Restricted By column indicates which aspect of the LOV data the
org unit restriction is acting on.
Restricted
By column
Indicates
the aspect of the data on which the org unit restriction acts. This may not
be in the database table to which the restriction applies, but will be in
a closely related table. For example, 'unit attempt - course attempt - course
version - responsible org unit' indicates the data element (responsible org
unit) which is tested against a user's org unit restriction(s) when unit attempt
information is retrieved in INQF1200, and the pathway followed.
Operation
Restrictions column
This
column contains either 'yes' or 'no', indicating whether or not operation
restrictions (insert/update/delete) apply within that form/block to users
with org unit operation restrictions. For example, if a user has an 'update'
restriction for org unit 04 (but not insert or delete), they will only be
able to modify existing records related to org unit 04 and will be unable
to insert new records or delete existing records relating to that org unit.
Last
Modified on 11 March 2002