When an user attempts to access data, the process of authorization takes place. Authorization is to determine if a user is allowed to perform a certain action on the selected data. If the operation is not authorized (allowed), it is rejected.
Authorization can be broken down into data authorization and functional authorization. Functional authorization is about determining the operations, the procedures and functions, that a certain user is allowed to use. Data authorization is about determining on which data the user has permission to operate.
Foundation1 supports authorization on database views, database methods, projections and on middle-tier activities/services. End users are never granted access to database tables, nor write access to database views.
All authorization is made from within the server business logic and is independent of the client used. Because security is implemented in the servers it is never possible to bypass authorization by using a maliciously modified client or utilities such as SQL*Plus. Another benefit of this is that you only need to configure the server permissions, and they will propagate to all clients.
Authorization is implemented using a role concept. Instead of giving every user the rights to run a certain part of the application you create roles and assign various rights to the different roles. If the user changes jobs within an organization then it is relatively easy to just remove the current roles and give the individual new roles to reflect the individual's new responsibilities.
Roles may be granted other roles. This makes it possible to create user-roles from functional roles. As an example, you may create roles for entering machine data, perform daily time reporting, and request machine overhaul. If a machine operator is supposed to have all these rights, create the role Machine_Operator, grant the functional roles to Machine_Operator and only assign role Machine_Operator to machine operators.
Foundation1 supports granting and revoking read access to views. Users are never granted access to database tables, nor write access to database views.
In IFS Applications, authorization is made on the method level. This gives a very high level of authorization granularity and security can be tuned for the requirements of a specific enterprise. As an example, instead of granting permissions such as "everything related to billing", permissions such as "create a new bill" is granted. If a user with "create a new bill" permissions attempts to do another billing action, such as "approve bill", the server based authorization mechanisms will stop this action.
IFS Applications uses keyhole security model. Authorization is only performed when a client (user) calls a method or wishes to access a database view. When the called server method subsequently calls other methods or accesses a view, additional authorization is not necessary. This greatly simplifies the security configuration for system administrators since only the methods directly called by clients must be authorized.
Presentation object security is client-side authorization. This authorization checks if an end user has been granted the right to use a specific presentation object (such as a client form). If the end user has been granted a specific presentation object the end user at the same time was granted the necessary views and database methods needed by the presentation object. If using presentation object authorization you need to be granted to both the presentation object and its views and database methods.
In the end, authorization is still always enforced by the server.
Requests performed by Activities and Services does not requires any grants to database objects it is handled on the activity/service authorization level. Administrators only have to manage grants on the activity level. The internal activities AccessPlsql and PlsqlGateway using the PLSQL Gateway are exception to this. For these requests the authorization is done in the database level and grants to the database object accessed is required as described previously.
A Projection is a self-contained API which completely implements a defined business function. It may serve either a single or many business activities. It is a union of data views (Entities, Queries, Entity sets, etc.) and Operations (Functions and Actions) required for executing those tasks. IFS Aurena client uses Projections.
A Projection can only be read-authorized as a single unit. Projections can be write-authorized on individual action level (Create, Update, Delete on Entities and Custom Actions).
It is not required to grant any database objects. Security authorization is performed at the Projection level.
Application specific authorization is performed in all application modules. In some cases, i.e. HR module, this is very elaborate. In other cases, i.e. maintenance, the process is very simple. In most cases the authorization in the applications is concerned with data authorization.
Data protection is facilitated through the usage of database views. Each role gives access to certain sets of data and when data is accessed it is automatically filtered. The exact implementation of these features varies between the different modules.