## 6 Evaluation
### Evaluation of Overhead Introduced by SA-UBA
#### 6.3.2 Evaluation of Application-Access Process  
It is a typical application-access process for a Java application to access databases on the cloud platform through the Java database connectivity (JDBC) interface. Generally speaking, there are three authentication scenarios between Java applications and databases on the cloud platform:  
Figure 11: The accuracy of the original model and the improved model.  
Figure 10: The accuracy of the original model and the improved model.  
* **Scenario 1:** Java program developers directly embed authentication credentials in the source code;
* **Scenario 2:** Authentication credentials are embedded in the configuration file of the Java-based framework (such as SpringBoot, SpringMVC, etc.). The framework reads these authentication credentials and passes them to the database connection pooling (Druid [30], HikariCP, etc.). Database connection pooling creates the database connection and returns the response to the framework;
* **Scenario 3:** Authentication credentials are embedded in the configuration file of a web container. Java web applications (such as Java Servlet) are deployed in web containers (such as WebLogic, WebSphere, JBoss, Tom-cat). Web containers create the database connection and Java web applications use the connection with the Java Naming and Directory Interface (JNDI).  
In all of these three scenarios, the Privileged Account Management subsystem is used to replace the original authentication method. This subsystem eliminates the authentication credentials embedded in Java code and configuration files by building Custom Middleware, and realizes the dynamic authentication and management of applications with the Account-Password management module. In this part, we observed the Insertion, Deletion, Modification, and Query operations performed by the Java application on the database and tested the performance cost of the Privileged Account Management subsystem. In this experiment, the Java application was implemented based on JDK1.8, and MySQL5.7 was deployed on the cloud server. The performance costs in these three scenarios are shown in Figure 12, Figure 13, and Figure 14, respectively.  
Analyzing the data of the three figures, this paper draws the following conclusions:  
1. In these three scenarios, the cost ratios of adding a Privileged Account Management subsystem are 11.89%, 11.82%, and 12.54%, respectively, the cost in the third scenario is the largest but not by more than 13%;
2. When the number of operations increases, the cost ratio will decrease. Taking the Query operation of Scenario One as an example, when the number of operations is 1000, 3000, and 5000, the cost ratios are 59.9%, 12.7%, and 5.0%, respectively. This result occurs because the first authentication between the Java application and the database costs a large amount of time. When performing operations continuously, the time overhead approaches 5%;
3. For Insertion, Deletion, Modification, and Query operations, the increased computing times of the Privileged Account Management subsystem are 24.39%, 12.99%, 8.06%, and 11.34% respectively. The additional time cost of the Insertion operation is the largest. The time cost of security access is about the same (among 0.41 s and 0.53 s). The execution time of the insert operation is short, so the additional overhead takes up a larger proportion.  
To sum up, the cost ratios caused by the Privileged Account Management subsystem in the application-access process is not more than 13%. For large-scale and long-term operations, the cost ratio is smaller (about 5.0%).