Following up with the topic started on the previous post, we will keep investigating the characteristics of “Sample Dialog”. As we remember, this is a “Productivity App” that allows us to explore the different possibilities of dialog use on Oracle APEX. In the previous post we didn’t have time to analyse all elements created within our workspace after installing this application. In this post we will try to analyse one of these elements: “Authentication Scheme”
Authentication Scheme, being able of not having to remember a new password
Usually, in almost any company, there are several applications to be used by employees in order to carry out their daily tasks. Also, usually for each of those applications each employee has its own unique user and password. That could create a problem of bad password management by the employees (for example writing them down on post-its), and additionally it creates a need for the system administrators of keeping that stored passwords safe.
In order to give a solution to this situation Oracle APEX includes some different authentication methods implemented. This allows to integrate their application within any existing authentication systems and avoid the creation of new user accounts. Of course, it also allows an independent authentication system, and can work with the role and account system of APEX.
Some of the methods implemented are LDAP, Social Sign-in, Oracle SSO… But not only that, Oracle APEX also allows us to define custom authentication methods.
The offered possibilities to create our own authentication method are several: We can define a function to decide whether a session is valid thought the “Sentry Function Name”; allows us to decide what to do with non-valid sessions through “Invalid Session Procedure Name”; and allows us to define what to do when a user makes log-out. And of course, we can also define a specific authentication function on “Authentication Function Name”. It must be point out that this function must include two input parameters (p_username and p_password), still, the developer is free to decide how to use these parameters.
All the previous functions can be either a PL/SQL code contained within the DB, or to be included in a code block on the section of “Source” below the “Settings”.
Where should be include our authentication function code?
Here, once again, it applies our personal criteria at the time of deciding if we will include the functions on DB or in the code block. Taking in account that, including the code in this section allows a better understanding of the behaviour of the functions used by scheme, it also creates a code dissemination along the application, that not only prevents the re-usability of the code, but also to be able to locate the code if we want to edit it, if we haven’t specify a proper policy of code management. In the other hand, if we have several applications, each of them with their own authentication scheme, it could make code edition more difficult. Not only because sometimes we don’t have access to a rich code edition workspace to work with stored code on DB, but also because it could be confusing to determine what function belongs to which application, and we can end up editing the wrong functions. This can happen to us specially if we haven’t defined a clear policy on function name definition.