The Agency Side Scenario

In this scenario, the agencies (agency X, agency Y) are communicating each other as illustrated in figure 4.7 and 4.8. These agencies can interoperate each other in e-government network even if they have different types of legacy systems since the interchanged messages over the network based on the XML documents. Thus, the diverse systems can share and integrate the platform independent XML documents. In this scenario, two types of interaction may happen between the agencies. In first case, the agency users can request data/information from another agency services.

Agency X User Agency Y Server

Get outside network rights from firewall

OK/ Access to outside network

Get Agency Y electronic certification info

OK/ electronic certification acceptation state

Get data/information access rights from agency Y interface

OK/ Access to data/information

Send encrypted SOAP request

Send encrypted SOAP response

When the agency user needs to communicate with other agency, he/she should face the firewall mechanism to check the user rights for outside network. If agency user does not have permission to go outside of the agency network then this action should rejected. However, if the agency user has enough permission for outside, in this time the digital certification security policy should be applied. The two different agencies should know each other over the network by checking their electronic certificates. If a computer on the agency X network tries to reach the server of agency Y then, the agency Y should know that, this visitor computer belongs to agency X network. The digital certification security policy can be used for this checking/matching (validations of an agencies) process. If server of agency Y cannot know/define the visitor then request should automatically rejected. After the digital certificates accepted by agencies then the data communication can start. If the data/information that is to be accessed in agency Y needs the special rights, then the user in agency X need to be authenticated for this action. The incoming/outgoing data between the agencies may be confidential for the agencies; in this case, the data encryption policy should be used for data interchanging. Thus, the interchanged data/information is unreadable for not trusted networks or individuals. Some operations like confidential data modifications, private data security on the e- government network may require high-level permissions or passwords that are impossible to duplicate. In this case, more advanced secure techniques than simple password mechanisms may be required. The digital signature application should be used in such actions. If the agency user does not fail in these security levels then, the data or message flow between the agencies is identical to the client side scenario, which means the agency user makes SOAP request to the agency Y web service and web service gives SOAP response back to the agency user.

As in the second case illustrated in Figure 4.8, the web services in the agencies can communicate with each other. The security approach of such type of interaction is similar to first communication situation illustrated in Figure 4.7 (agency user-agency). As a difference, instead of checking/matching the agency user rights for accessing data, in this case the web services can be checked by agency interface mechanism during data/information access.

Security Policies

Figure 4.8 Agency-Agency Interactions

In this situation, web service X can request information (SOAP request) from the web service Y and then the web service Y can response (SOAP response) back to the web service X (same as in the tables 4.4 and 4.5) even if these web services are written in different programming languages. This situation does not create a communication problem. Because, whatever the web services’ programming language is, all of the web services produce XML document as a request/response and XML document is a platform independent technology that is readable and understandable for different programming languages in different platform. During the communication of the web services each other the firewall mechanism, digital certification system and data encryption policies must be activated.

Auth./Authorization Certification Firewall Digital Signature Encryption

Agency Y Data

DBMS Update

Agency Interface (Arrange incoming data for DBMS Y)

Web Service Y _{DBMS Y}

Agency X DBMS Update

Data

Agency Interface (Arrange incoming data for DBMS X)

Web Service X _{DBMS X}

D A T A

The agency interface approach is the other important point of this scenario. It must be clear that, in this model, the agency interface and the agency web site are completely different things. The interface mechanism considered to provide effective communication between agencies without much modification on currently used systems. Because, according to data interchange model offered by this research, the legacy systems (currently used systems in agencies) should not be wasted. According to interface mechanism, if the web service Y sends data/information to the web service X then the agency X interface should check incoming data whether it is compatible with the legacy system (DBMS X) of agency X. The interfaces of the agencies can use the XML Schema for this operation. As a sample, in figure 4.8, the in the case of web service X requests a data from the web service Y, the web service Y can retrieve this information from DBMS Y, and after that, data is sent to the web service X as a response. The web service X may need to store this data/information in DBMS X.

However, what happens if the type of data stored in DBMS Y is different from the type of data, which is stored in DBMS X? In this case, the type mismatches problems occurring during the database operations such as INSERT or UPDATE. The answer is the interface mechanism with XML Schema and its substitution property. Substitution is one of the main benefits of defining type hierarchies and it is similar to a type cast in most programming languages. XML Schema makes possible a substitution in two different types. The interface mechanism can use this property to substitute the incoming data with another, which is compatible with the DBMS. By this way, the data/information can easily flow agency to agency without huge amount of arrangements/modifications on the agencies. The figure 4.9 shows the data conversion between the agencies. In this figure, the interface mechanism of the agency Y makes incoming data compatible with its legacy system (DBMS Y) that is incompatible with the incoming data at the beginning. Therefore, the interface mechanism can be considered as a type cast level during this conversion operation.

Incoming data

(Data type is: X, value is: “12345”)

Outgoing data

(Data type is: Y, value is: “12345”)

Figure 4.9 Data Substitution

Now the XML Schema processor treats X as Y. Thus, the converted data becomes a compatible form, which may be inserted or updated in DBMS Y.