When an user attempts to access data, the process of authorization takes place. Authorization is to determine if a user is allowed to perform the current action on the selected data. If the operation is not authorized (allowed), it is to be rejected.
Authorization can be broke 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 he is allowed to operate.
Foundation1 supports authorization on database views, database methods and on activities/services. Users are never granted access to tables, nor write access to views.
All authorization is made in 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 rights, and they will propagate to all clients.
IFS Authorization is implemented using a role concept. Instead of giving every user the rights run a certain part of the application you create a role and assign the rights to the role. If the user changes jobs within the organization it is very easy to just remove his current roles and give him new roles that better reflects his 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 tables, nor write access to views.
In Foundation1 authorization is made on the method level. This gives a very high granularity in the granting process, 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.
Foundation1 uses a "keyhole" security model, like Oracle "definers rights". Authorization is only performed when a client (user) calls a method or access a view. When a server method calls another method or accesses a view it be allowed. The benefit of this is that administrators need only to grant methods/views that is used by clients.
Presentation object security is a authorization done by clients. This authorization checks if an end user has been granted the right to use a specific presentation object. 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.
For clients to Extended 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 by that activity/service implementation. Administrators only have to manage activity grants.
There is one exception to this rule - the PLSQL 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 applications. 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 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 applications.
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 business logic residing in Base Server. Extended Server handles all communication between IFS Web Client and Base Server.
As all grants in Foundation1 are made to roles that are connected to Foundation users it is necessary to map the user's login identity, the value of the "username" field in the login dialog, to his Foundation user.