|
|
|
|
|
The Security subsystem controls the ability of users to select, insert, update or delete information within the System.
In this section:
All Security terms are defined in the subsystem glossary.
Refer also to:
The maintenance of the Security subsystem involves complex concepts and processes which should be under the control of specialist staff with a thorough understanding of this subsystem and its System wide effects on user access. For detailed technical advice regarding this subsystem, refer to Technical Documentation.
In the diagram below, the security maintenance function has been split in two to reflect the expected skills and foci of the Application Support Specialist and the User Systems Administrator. Different skills distribution and/or different functional roles may alter the distribution of responsibilities.
This diagram illustrates how the various components of the security subsystem interact to create an individual's security profile.
This section is a brief introduction to the more technical aspects of security administration, performed by database administrators (DBAs) and application support specialists. Full details are provided in the Callista Technical Documentation.
Security Roles are created by a DBA/Application Support Administrator to represent various groupings of system functions. The actual functions available to a role are configurable by a User Security Administrator. For example, a security role FACULTY OFFICER could be created to represent the Callista functions available to faculty officers.
Not all of the security roles created may be applicable to a particular Callista implementation. Those that are to be available are registered against the database using SECF0011. The LOV in that form contains all of the existing roles.
Security is concerned with controlling access to database functions (forms, jobs, reports and menus) and the data accessed via these functions. Access to database functions is administered via the granting of functions to security roles and subsequently granting the security roles to users. Functions may also be granted directly to a user, however the user must be granted at least one role.
Within the access defined by function grants, users can be further restricted in the data they can access and manipulate by the application of security data restrictions.
Security Restriction Objects identify the data restrictions that may be applied to security roles and hence to users. The institution-defined name of a restriction object is recorded in SECF0012 and mapped to the restriction table where the user restrictions for the restriction object are stored (displayed in the LOV). For example, a restriction object ORGANISATIONAL UNIT could be created to identify the restriction of data by organisational unit code. This would be mapped to the table where organisational unit restrictions are stored.
The primary means of controlling user access is through user security roles. Security roles define which data users can see and what actions may be performed on the data. They are used to:
Security roles can represent the interaction of the various business functions of the institution with the System. As such, it is envisaged that the names of security roles will correspond to business functions, so that, for example, a role granted to enrolments officers might be called ENROL-OFF or something similar.
Security roles are created by an Application Support Specialist. The actual functions available to a security role are controlled, using SECF0063, by the granting of forms and jobs to the role, and the reconciliation of object grants required to perform those functions. Callista Technical Documentation provides more detailed information about the creation of user security roles.
Callista provides control over access to the system and its data in a number of ways. The controls which can be applied to users are:
Callista data restrictions use Oracle's 'Fine Grained Access Control' to limit the data able to be accessed by individual users. Fine Grained Access Control uses 'Security Policies' (functions developed by the Callista team) to dynamically attach 'Where Clauses' to all queries issued against a database table or view. The content of a Where Clause is determined by the restrictions recorded, in the database, for a particular user. Further information is available in Callista Technical Documentation.
The diagram illustrates the steps in granting Callista
access to a user. Details for each step are:
Perform a query in ADMF1213 to search Callista for the person's record, using the Find Person button to display the Find Person form where query criteria can be entered. If a record is found for the person, note their Person ID, they will need to be registered as an Active Oracle User. If no record is found, the person must be recorded in the system.
Use ADMF1213 to record personal details of the new user. Note the Person ID created when the record is saved. Use the navigation buttons in this form to add additional details about the person.
In SECF0021, perform a query using the new user's Person ID as the query criterion. Record a username and password for the person and save the record. Select the Active Oracle User checkbox.
Continue using SECF0021 and select one or more security roles (from the LOV) to grant to the user, and save. The user inherits the privileges associated with the role, and the menu structure assigned to the role. Indicate, using the Auto Enable checkbox in SECF0021, whether or not the user is allowed to access data from outside Callista, via third party tools.
The user's access to data may need to be restricted beyond the data access defined by their role grants. A user can be granted restrictions for certain pre-determined data elements. Security Restrictions and Access to Data contains details of data restrictions.
Security administration is most manageable when user access to menus, forms, jobs and reports is controlled by the granting of appropriate roles. Situations arise where an individual user requires access beyond that specified by their role grant(s) and no roles exist which would provide precisely the right access. In such cases, a user's access can be customised by individually granting access to specific menus, forms, jobs and/or reports using SECF0062. Because the user is granted the additional access outside of their role grants, they will not have inherited the required object grants for the additional functions. A reconciliation process is performed in SECF0062 (or using the batch job SECJ0070) to automatically grant any database objects required by the additional functions.
Access to functionality and data within the Callista application is achieved by granting functions (system Forms and Jobs) to roles, and in some cases system users. When the final set of system Forms and Jobs has been determined for the role/user, the process 'Reconcile Object Grants' should be invoked. This ensures that the role/user has access to the underlying database objects required to successfully operate the system Forms and Jobs.
A table exists in Callista that stores the database object usages for all system Forms and Jobs. The Reconcile Object Grants process interrogates this table to determine the database object usages required to operate the system Forms and Jobs granted to the role/user and to provide access to the required data. System Forms can be granted in query only mode. Where this is the case, only query access will be granted.
The Reconcile Object Grants process should be invoked in the following situations –
Note: Typically the Reconcile Object Grants process will only need to be invoked for Security Roles. The only time the process needs to be invoked for a person is when any of the users affected by the above situations have their own Form and Job grants.
If a user experiences unexpected errors while running a system Form or Job that appear to be related to access to the underlying database objects, then the Reconcile Object Grants process should be invoked to ensure all of the required database objects have been granted to the role/user.
The Reconcile Object Grants process can be invoked immediately using the buttons in SECF0063 Maintain Security Role Function Grants and SECF0062 Maintain Person Function Grants. Alternatively, object grants can be reconciled as an after hours batch process, using the job SECJ0070, via Job Scheduler. This would most likely be used where it is required to reconcile all roles.
Additional information is provided in Callista Technical Documentation.
Last Modified on 11 March 2002