Figure 5 - uploaded by Óscar Pereira
Content may be subject to copyright.
SAAM policy enforcement architecture. 

SAAM policy enforcement architecture. 

Source publication
Thesis
Full-text available
Nowadays, database application use tools like Java Database Connectivity, Hibernate or ADO.NET to access data stored in databases. These tools are designed to bring together the relational database and object-oriented programming paradigms, forsaking applied access control policies. Hence, the application developers must master the established poli...

Contexts in source publication

Context 1
... socket creation with the password-authenticated key exchange. ..................... 84 Figure 54. Signature of the RemoteCall stored procedure. ...
Context 2
... of the RemoteCall stored procedure. ........................................................... 87 Figure 55. Graph of the initialization times in Table 14, Table 15 and Table 16. ...
Context 3
... of the initialization times in Table 14, Table 15 and Table 16. .......................... 93 Figure 56. Graph of the execution times in Table 17 for the single select scenario. ...
Context 4
... of the execution times in Table 17 for the single select scenario. .................... 95 Figure 57. Graph of the execution times in Table 17 for the two selects scenario. ...
Context 5
... of the execution times in Table 17 for the two selects scenario. ...................... 95 Figure 58. Graph of the execution times in Table 17 Table 14. ...
Context 6
... the PEP-PDP architecture, where each user request to the PEP implies a verification with the PDP, or the SAAM architecture, shown in Figure 5, where such a request to the PDP is still made if the SDP cannot authorize the request, S-DRACA always decides if the user's request is allowed or not in the client side. This has several advantages over the alternatives, of which we emphasize: the decision to allow a request or not is made at the client side, which implies that the time to authorize a request is lower, the user experiences less wait time and the requests are no longer sent to a PDP in the server side, meaning that a central point of failure and a possible performance bottleneck is removed. ...
Context 7
... 17 for the two selects scenario. Figure 58. Graph of the execution times in Table 17 for the SISUS scenario. ...
Context 8
... each table with When comparing each table we can see in Figure 55 that with JDBC we take a bit more than 10 milliseconds to connect to the database. Regarding S-DRACA, the initialization process takes more than 2 seconds when TFA is not used (around 2.5 to 3 seconds). ...
Context 9
... proof of concept, which architecture is shown in Figure 59, This section is divided as follows: Section 4.6.1 presents the Policy Extractor tool, section 4.6.2 presents the S-DRACA architecture functioning through the developed applications and section 4.6.3 ...
Context 10
... seqInfo parameter has the defined sequences of Business Schemas, used to generate the "next" methods, and the seqActive parameter indicates if the sequence control mechanism is active or not. The output of the Annotation Processor can be seen in the IDE with the appearance of the "Generated Sources (ap-source-output)" folder (see Figure 65). The "BusinessInterfaces" folder contains the common interfaces to all Business Schemas, the "Classes" folder contains the data structures associated with the roles (see Figure 39) and the rest of the folders have the Business Schemas usable by the application. ...
Context 11
... demonstrate that the client applications are aware of the changes made to the policies using S-DRACA we used the Configurator to revoke the role of the user (see Figure 74). After that we can see in Figure 75 that the role disappeared from area (1) and no Business Schemas are available. The client application is able to update its graphical user interface because the Business Manager can register a listener (with the legacy name "DACAChangeListener", shown in Figure 76). ...

Citations

... This proposal emerged from the work done in (Pereira et al., 2015;Regateiro et al., 2014;Pereira et al., 2014), where a distributed access control framework allows the clients to connect to a database through runtime generated access control mechanisms. There, client applications can use an interface based on JDBC, where the methods are only implemented by the access control mechanisms to access and manipulate data stored in a database if the user has permission to use them. ...
Chapter
Database applications are a very pervasive tool that enable businesses to make the most out of the data they collect and generate. Furthermore, they can also be used to provide services on top of such data that can access, process, modify and explore it. It was argued in the work this paper extends that when client applications that access a database directly run on public or semi-public locations that are not highly secured (such as a reception desk), the database credentials used could be stolen by a malicious user. To prevent such an occurrence, solutions such as virtual private networks (VPNs) can be used to secure access to the database. However, VPNs can be bypassed by accessing the database from within the business network in an internal attack, among other problems. A methodology called Secure Proxied Database Connectivity (SPDC) is presented which aims to push the database credentials out of the client applications and divides the information required to access them between a proxy and an authentication server, while supporting existing tools and protocols that provide access to databases, such as JDBC. This approach will be shown and further detailed in this paper in terms of attack scenarios, implementation and discussion.