4.2 Legacy Integration Strategy

For TAS³ architecture to be useful, it needs to be adopted. To adopt TAS³ an existing application faces some implementation choices.

Fig-31: Application Integration: PEP implemented directly in application.

Conceptually simplest, but in terms of new code to write probably most costly approach is shown in Fig-31: just build a TAS³ compliant PEP into the legacy application. This approach has the advantage of allowing full control over the enforcement process, including the inputs to the Master PDP. The disadvantage is the learning curve to learn TAS³ architecture in sufficient detail to implement it correctly and to get certified.

Fig-32: Application Integration: ADPEP implemented in application itself.

Fig-32 depicts a slightly different strategy where application only implements a simple PEP, which then communiates with the Application Indepentent PEP (AIPEP) supplied by the TAS³ Project. In this approach, the AIPEP component handles most of the TAS³ specific parts and can be an already certified component, making compliance certification easier.

However, in this model the need to communicate between AIPEP and ADPEP arises. The communication pattern could be either Encapsulating Security Layer (ESL) or Application Protocol Enhancement (APE), as described in the Section ?tas3repo-ApplicationSpecificArchitecture-ProtocolSupportforConveyanceofStickyPolicies?

Fig-33 illustrates some specific integration strategies with the intent of enabling legacy data sources that can not be modified. In (A) the SOA Gateway evolves to support TAS³ architecture, in (B) the SOA GW is frontended by the WP9 database which supports the TAS³ architecture aspects. If export of the legacy data is an option, then it may be simplest to import the data to WP9 database and dispense with the legacy data source entirely (C).

Fig-33: Application Integration using ADPEP and (A) SOA Gateway, (B) WP9 DB as frontend to SOA GW, (C) WP9 database.