You are hereApplication User Mechansim Overview / Example: Use of Application Users in a Web-Based Environment

Example: Use of Application Users in a Web-Based Environment

Next, an example is presented giving a typical, but simplified, use of the Application User mechanism. The example models a simple Internet banking application. The only functionality of the application is to allow a customer to read their current bank balance. The security objective is to utilize the Application User mechanism to permit access to a bank balance only when the corresponding, authenticated banking customer is requesting the balance through the middleware application. The following Figure shows the architecture of the Internet banking solution.

The top of the figure shows four Internet banking customers (i.e., Application Users) and their account numbers, Bob (#1, yellow), Nancy (#2, red), John (#3, green), and Jane (#4, purple). Each customer has a color which represents the Application User’s ABAC permissions in the database. The Application Users connect to the banking application through the Internet.

The banking middleware application (e.g., Apache/PHP/ODBC application) has an Application name of BigBank in the Trusted RUBIX RDBMS. The Application Administrator is the RDBMS User BigBankAdmin. The blue color of the Application represents the ABAC permissions of the RDBMS User (i.e., the Application Administrator, BigBankAdmin) that executes the Application. This RDBMS User will connect to the Trusted RUBIX RDBMS and submit SQL operations on behalf of the Application Users.

Within the Trusted RUBIX database, shown at the bottom of the figure, is the Accounts table, with Account#, Balance, and App User columns. The Accounts table has four rows, one for each customer’s bank account balance. Note that the color of each row corresponds to the color of the corresponding customer. Also note that the App User column is used to label each row with the creating Application User.

To the left of the Accounts table are the ABAC Requirements for each row. The colors shown represent the required permissions to access the row. Note that the color blue is required for each row, indicating that the authenticated RDBMS User BigBankAdmin must submit the SQL operations. Additionally, the permissions of the corresponding Application User is also required for each row. Thus, to access the first row, the permissions of the RDBMS User BigBankAdmin (blue) and the permissions of the Application User Bob (yellow) are required. For the second row, the permissions of the RDBMS User BigBankAdmin (blue) and the permissions of the Application User Nancy (red) are required, etc.

In the figure, Application User Bob has submitted a request to read the balance for account #1. Bob submits the request by submitting the following URL to the web server:

Note that the account=1 component of the URL specifies which bank account balance is being requested. Assume that Bob has previously authenticated to the application and is set as the current Application User in the RDBMS. Following the flow of the operation down from the Application User Bob, the application accepts the operation and translates it into the corresponding SQL operation:

select Balance from Accounts where Account#=1

Because the Application User Bob and RDBMS User BigBankAdmin are authenticated and set in the database session, the SQL operation executes with the permissions of both users. This is reflected by the yellow and blue striped arrows representing the submitted SQL operation. As this matches the permissions required to select the first row in the Accounts table, the SQL operation succeeds. The account balance of $100.54 will be returned to the Application User Bob.