All security settings concerning authorization are made on the role level, where end users always receive their authorization through roles. Roles are the only security level where direct access to database objects is administrated in a Foundation1 Application.
A model for a security and authorization approach is made by using rules that protect the database from being accessed by end-users, using external database tools (such as MS-Query) with their ordinary password given to the client application. The reason is to keep the database consistent, and avoid any violation against the software integrity constraints made in the business logic layer of the application.
The security model is based on server authorization concepts and there is no difference between ordinary users and ”external” users in the security and authorization point of view. The authorization methods at server-side will decide whether a method is available for a specified user or not.
Therefore, the application will behave in the same manner concerning security when being executed from a Windows client based on IFS Windows Client, or from external tools such as MS-Query or SQL*Plus.
By solving all security and authorization mechanisms in the server, it is possible and easy to add different clients (presentation layers in the OLA-section above) with strong security control on the business processes for all kind of clients.
Database reads are made by using views, which are granted (SELECT) to a role. These views should be considered as application views, but may also be used from external tools such as MS-Query.
Database writes are made by database packages (PL/SQL). The end-user will in this case not need the write privileges to the application tables. It is necessary to grant execute rights (GRANT EXECUTE) to the packaged PL/SQL that make the table manipulation through SQL.
It is also important to state that the Oracle authorization level for procedures in packages is on the package level and not on method level (see below). If a user gets EXECUTE-privileges on a package, no other grants such as table-grants or grants to packages accessed by the first package are needed.
The current version of Foundation1 is fully based upon a model of database object security where the authorizations to different objects are made in the database itself. There are no differences from the database point of view whether the application is executed from the IFS Windows Client application or through an external data browser. Therefore it is important not to make any solutions based upon ”application security” without knowing the consequences when using external data browsers.
There are several important concepts within the Oracle Server that are used by the security model of Foundation1. These concepts and how they are used are described below.
| Concept | Description |
|---|---|
| Oracle User | Mandatory identity concept when using Oracle Server. A user can be connected to several roles. A user has one or more default roles. |
| Role | Group identity. A role can be granted to several users. A role can be granted to a role. |
| View | Ordinary view concept in the relational database model. The views are used by transferring data between the presentation layer and the business logical layer of the OLA-model developed within Foundation1. |
| Package | The concept in Oracle Server to let several stored procedures and functions being grouped into a unit. The packages are used to encapsulate business rules in the business logic layer and giving the rules specific interfaces. |
| Method | Security on method level (procedures & functions) cannot be implemented by using Oracle Server. In Foundation1 environments this is solved in Base Server by using system service Security_SYS. |
| Table | Ordinary table concept in the relational database model. Table privileges to end-users are not required for Foundation1 based applications. |
Within Base Server there is a system service named Security_SYS that is involved in all security tasks in Foundation1. The most important purpose of this package is to feed the client with information regarding available packages, views and method restrictions for the current user logged on to the database.
This information is sent to the client through an out parameter in the initiation method in package General_SYS that is called from the IFS Windows Client at application startup time.
This system service does also contain interfaces to retrieve information concerning available grants for a specific user in runtime, this is intended for other type of clients than the IFS Windows Client.
Standard authorization in Oracle Server is based on packages, and security on procedure or function level is not supported. This feature is therefore added in the Foundation1 environment.
The method-level authorization model is implemented through the system service Security_SYS and the private security table SECURITY_SYS_TAB. This table stores the method restrictions for a specific role and consists of the following columns:
| Column | Description |
|---|---|
| LU_NAME | Specific logical unit containing the method restriction |
| FULLMETHOD | Method name including package for the restricted method |
Note! When a user is connected to several roles, a method restriction is not valid until all roles connected to the user are restricted from executing the specific method.
Base Server consists of several concepts related to the technical implementation made in Oracle Server. These concepts are described below:
| Concepts | Description |
|---|---|
| OLA | The client/server architecture which differentiates the implementation into presentation, business logic and data storage. |
| Logical Unit | The concept to get closer to the OO-approach. Consists
of OBJID, OBJVERSION, attributes and methods.
One logical unit consists of none, one or several views. One logical unit
consists of none, one or several packages. |
| Base methods | Specific methods for New, Modify and Remove. |
| Other methods | Common business logic operations for a specific logical unit. |
| LU-dictionary | Implemented in system service Dictionary_SYS and handles all information about logical units and their relations to the database objects. |
Security_SYS.Check_Method_Access_ used from method General_SYS.Init_Method.There are several concepts defined within IFS/Client and some of them are described below:
| Level | Description |
|---|---|
| Data source | Presentation layer connection to the business logic layer of the logical unit. |
| Data item | Presentation layer connection to a logical unit attribute. |
| IFS Navigator | Menu system used to create new instances of IFS Window Client classes. |
| Base methods | Standard client operations: New, Modify and Remove. |
| LOV | Attribute on the client field to retrieve valid data for the corresponding data column. |
| Window item | Actions |
|---|---|
| IFS Navigator element | The navigator element will not be shown if the data source (=view) is not available to the user or if the corresponding presentation object is not enabled for this user. |
| LOV button | The LOV button will be disabled if the referenced data source is not available to the user. |
| New button | The new button will be disabled if method New__
is not available to the user. |
| Modify functionality | Modifying functionality will be disabled if method
Modify__ is not available to the user. |
| Remove button | The remove button will be disabled if method Remove__
is not available to the user. |
| Pop-up menu | Items in the pop-up menu will be disabled when the corresponding method or datasource is not available to the user. |
These client facilities above will only work if:
Component.WindowRegisterSecurity.IsDataSourceAvailable
for data transfer and Security.IsMethodAvilable for database calls.
Other (rarely used) methods are also available in the Security
object. See Developers Guide for details.