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 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 use a 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.
For clients to IFS Middleware Server, authorization is made on the activity/service level. Since an activity supports a specific business process, end users can easily be granted or revoked entire business processes such as user administration. Foundation1 uses a keyhole security model, meaning that if a user has been granted a specific activity/service, it is not necessary to also grant database views and methods used in subsequent calls by that activity/service implementation. Administrators only have to manage grants on the activity level. However, there is one exception to this rule - the PL/SQL Gateway. These two interfaces, AccessPlsql and PlsqlGateway, are not treated as normal activities/services by the authorization framework. Instead, any database access performed through these interfaces follow the database views and methods authorization mentioned above.
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.
When the user is properly authenticated Web Client sends the request to the web application modules. The processing of the request almost always results in a call to the backend database business logic. The Java Server Framework handles all communication between IFS Web Client and the database.
As all grants in Foundation1 are made to roles that are granted to Foundation users it is necessary to map the user's login identity, the value of the "username" field in the login dialog, to the corresponding Foundation1 user.