Top of SEC

Index

Table of Contents

Feedback

Understanding Security

The Security subsystem controls the ability of users to select, insert, update or delete information within the system.

Topics covered in this Help page:

• Security Subsystem Structure
• Introduction to Application Support Functions
• User Security Roles
• User Security Layers
• Data Security
• Granting Access to a User
• Reconciliation of Object Grants

All Security terms are defined in the Security Glossary.

Refer also to:

• Menu Administration
• Security Reports

Security Subsystem Structure

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 the technical information located in the Callista Product Centre (wiki.callista.com.au/display/CPC).

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.

Introduction to Application Support Functions

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 technical information available in the Callista Product Centre (wiki.callista.com.au/display/CPC).

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.

User Security Roles

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:

• Determine access to particular tables and views in the system
• Define what data users can see and what operations can be performed on that data
• Grant access to predetermined sets of menu structures, forms and jobs

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. The Callista Security technical information located in the Callista Product Centre (wiki.callista.com.au/display/CPC) provides more detailed information about the creation of user security roles.

User Security Layers

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:

• System users must be registered as an Active Oracle User to be able to login with a username and password.
• At least one security role must be granted to an Active Oracle User. The user inherits the access privileges associated with the role. This grants access to a set of menus, forms and jobs.
• The ability to inquire and/or operate on a limited set of data may be controlled by the application of restrictions. For example, the ability to inquire/operate on data for a particular organisational unit can be controlled.
• Access to individual menus, forms, jobs and reports can be customised for individual users.
• Some 'major' functions have additional controls over their operation. For example, the ability to update data for certain individual steps in the Direct Admissions process can be controlled for a security role (and by inheritance from a security role, for a user).
• Indirect access to data using ad-hoc query/reporting tools is controlled by the object grants (to tables and views) of the role(s) granted to a user, by controlling whether access is allowed only from within Callista or also via external, third party tools and by the user's restriction grants in the case of certified functions.

Data Security

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 the Callista Product Centre (wiki.callista.com.au/display/CPC).

Granting Access to a User

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.

Record Person in Callista

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.

Register Person as an Active Oracle User

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.

Grant One or More Security Roles to the User

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.

Apply Data Restrictions

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.

Customise Access to Menus, Forms, Jobs and Reports

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.

Reconciliation of Object Grants

Access to functionality and data within the Callista application is achieved by granting functions to rolesor users. When the final set of system menus, SSF applications, SSF menus, forms, jobs and Web Resources has been determined for the role/user, the Reconcile Object Grants process should be invoked. This ensures that the role/user has access to the underlying database objects required to successfully access the required system elements. Note: Reconciliation of object grants is not required for changes to Advanced Functions or Web Resources.

A table exists in Callista that stores the database object usages for all system elements. The Reconcile Object Grants process interrogates this table to determine the database object usages required to operate the system elements granted to the role/user and to provide access to the required data. When system Forms are granted in query only mode, only query access will be granted.

The Reconcile Object Grants process should be invoked in the following situations:

• When a system element is granted to the role/user. This is to ensure the underlying database objects required to operate the system element are granted to the role/user.
• When a system element is removed from the role/user. This is to ensure the role/user no longer has access to database objects outside of those required for the system elements that have been granted.

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 have their own system element grants.

If a user experiences unexpected errors while running a system Element that might 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 the Callista Product Centre (wiki.callista.com.au/display/CPC).

Last Modified on 17-Dec-2013 11:04 AM

History Information