A General Interoperability Architecture for e ...

Download PDF
3 downloads 5448 Views 209KB Size Report
Comment
Many of the security issues found in digital world have no match in face-to-face .... process identification, the time stamp, the requester signature, etc. At a given ...
A General Interoperability Architecture for e-Government based on Agents and Web Services Fábio Marques1,4, Gonçalo Paiva Dias1,3, André Zúquete2,4 ESTGA1, DETI2, GOVCOPP3, IEETA4 University of Aveiro Aveiro, Portugal [email protected], [email protected], [email protected]

Abstract—As Information and Communication Technologies are constantly evolving, governments should embrace this evolution to provide more efficient and effective around-the-clock services. The need to deliver services that gather information from several Public Administration branches turns interoperability architectures an essential tool for e-government. However, this service provisioning is complex and brings a set of new concerns that are nonexistent in the traditional way of delivering public services, mainly security related. Security is one of the key points for determining the success or failure of an e-government application. In this paper we present a generic interoperability architecture for e-government based on Software Agents and Web Services where the main objective is to provide a secure way for delivering integrated services from the client’s (citizens, businesses or Public Administration) perspective. Interoperability; e-Government; Web agents; Security; Trust; interoperability

I.

Services;

Software

INTRODUCTION

“The use of Information and Communication Technologies on government activities” is the definition of e-government given by the Organization for Economic Co-operation and Development (OECD)[1]. The use of Information and Communication Technologies (ICT) to support the delivery of services within the Public Administration has a number of advantages, amongst them: the improvement of the quality of service delivery; the reduction of exploitation costs; and the increase of productivity. The clients (citizens, businesses, government branches, etc.) of the Public Administration also benefit. The trade between the endless waiting in line for being attended and the availability of services through a wide range of channels 24 hours a day 7 days a week brings closer the government and its clients. Nowadays, Public Administration clients are demanding a new set of life event services[2] that may require communication between several public administration branches. Why should clients request a service only with the intention to get the certificates that allows them to request a second service? Because data is already in the possession of the Public Administration, it should be automatically made available to the office that needs it: this is an interoperability problem. The need for more complex services and the need to deliver services (simple or complex) in a more effective and

efficient way led governments and institutions to encourage research and development, through funding, towards presenting solutions for the interoperability problem. This problem has no easy solution: legal, social and technical aspects must be taken into consideration. Interoperability architectures are complex by nature. The systems that communicate through the architecture are usually heterogeneous: they have different purposes, different data models, and their policies diverge. There are several architecture frameworks, to name a few: Dias and Rafael (D&R) [3], Access-eGov [4] and Secure Electronic Contracts (SeCO) Container [5]. The approaches to the interoperability problem diverge, as well as their solutions. From our point of view, the ideal approach to the problem is to have an application or a set of applications in the architecture that make decisions related to the workflow of a process based on a set of criteria. We define software agent as an application that has autonomy, is reactive and proactive and is able to communicate with other software agents. This definition is based on one given by Michael Luck et al.[6]. With this definition and bearing in mind that the Public Administration is made of a set of heterogeneous entities with heterogeneous systems, that, in many situations, overlap service delivery, we argue that the natural choice for an interoperability architecture for e-government is an agent-based architecture. Security is one of the most important aspects of egovernment systems. It is often referred as a critical aspect to determine the success or failure of e-government initiatives[3]. Many of the security issues found in digital world have no match in face-to-face delivery of Public Administration services. Security issues like trust, authentication and access control must be dealt very carefully. Security assurance in interoperability architectures is complex due to the heterogeneity and different data models, security requirements and profiles of the systems that must interoperate. Adding to this, the complexity of the interoperability architectures and related security issues increases by the fact that they should not be limited to services provided directly by the government, they could be used by private entities to deliver their own services.

CISTI 2011 | 338

In this paper, we will present a secure interoperability architecture for e-government. The architecture is supported by software agents and Web Services. The basic principle of architecture is quite simple: it consists of agents that publish services and that work together, requesting and providing services, to fulfill more complex services. As it will be seen in the last section, the main advantages of this architecture are its inherent dynamism, mutability, adaptability, versatility and tolerance to faults. The only restriction to the agents’ implementation is that they should respect a number of welldefined base characteristics. The paper is organized as follows: in the first section a brief introduction to the problem is made; in the second section we define the base requirements for interoperability architectures; the base concepts as well as the detailed description of the agent-based interoperability architecture are addressed in the third section; the paper ends with a discussion of the architecture on section four and with the conclusions and future work on section five. II.

REQUIREMENTS

Before presenting our proposal, we will start by addressing the set of core requirements that, in our perspective, should be observed by any interoperability architecture for e-government. A. Mutable and Adaptable Usually, there are a wide number of services provided by each of the several Public Administration branches. In order to achieve a fully online government, all these services should be made available online. This is not feasible in a short period. There are several kinds of services with different complexities, security restrictions or even with some legal restrictions that hinder the service publication. Nevertheless, the offer of services should increase with time. Furthermore, the Public Administration is not a static entity. It changes over time. New laws are created, and consequently old services cease to exist while new ones become available. These dynamics should be reflected in the architecture with the removal of obsolete services and the publishing of new ones. With these flexibility requirements, interoperability architectures for e-government should be mutable and adaptable to enable not only the addition and removal of services but also the addition and removal of service providing entities. B. Versatile Several Public Administration offices may provide the same services (e.g. local government services); it would be normal, then, to reflect this multiplicity on the architecture. In other words we may have different agents providing the same service. Moreover, there are several private entities that provide similar semi-public services, such as notary firms or private health clinics. These entities should also be able to publish their services in the architecture. Therefore, the architecture should be able to find different paths to provide a service, meaning that if the same service is requested by two different clients the service may be addressed and provided in completely different ways and be concluded with the exact same outcome.

C. Secure As mentioned earlier, security is pivotal in determining the success or failure of an e-Government application. From our point of view, this is a critical requirement. The authors of [3], [7], [8], [9] identified a set of security requirements that should be respected in e-government. We have chosen a set with the six most representative requirements: authentication; authorization; confidentiality; traceability; integrity; and, nonrepudiation. III.

THE AGENT-BASED ARCHITECTURE

As argued in Section I, we believe that software agents are the natural choice for setting up an interoperability architecture for e-government. In this section, we describe the proposed architecture. We will start by introducing the base concepts that will support our description. Afterwards, we provide an introductory description of the architecture and its agents. Next, we present a description of the messages exchanged between agents and some complementary information related to the use of Web Services and of a built-in Private Key Infrastructure (PKI). Finally, we briefly present the support services of the architecture. A. Concepts In this subsection we present the base concepts that are inherent to the proposed architecture. 1) Workflow and Types of Service Delivery We assume that a requested service can be decomposed in simpler services that are delivered by several Public Administration branches. All services (simple or complex) are

Figure 1. Workflow approaches: (a) the service provider B manages the workflow and sends feedback to the requester A; or (b) the service provider B handles part of the workflow and delegates another part of it to other agents (D, in the example)

CISTI 2011 | 339

assumed to be delivered by agents. We call the process of delivering a service a workflow. The delivery of a composed service may have two approaches (see Figure 1); both of them will be used in the architecture: (a) the agent providing the service (agent B) receives the request, decomposes the service, processes it and sends the feedback to the agent (agent A) that requested the service; (b) the agent providing the service (agent B) receives the request, decomposes the service, processes it and delegates the remaining of the service delivery to other agent (agent D). Notice that workflows may be dynamically composed in both cases. In the first approach (a) agent B has a pseudo full control of the workflow process. It is a pseudo full control since it is not aware of how agents C and D will deliver their part of the service. However, the addressee of the result is agent A, the one that requested it. In the second approach (ii) the responsibility of delivering a service is shared amongst agents. Notice that in the second case, the addressee may or may not be the agent that requested the service (agent A). 2) Forward and Backward Trust One of the security measures that will be presented is related to the trust assessment of other agents by a given agent. This is done in two different situations and with different objectives. Bearing in mind that a set of entities will contribute to provide a service, we adapted the trust concept to two different contexts:

B. General description As previously mentioned, the architecture is based on software agents and Web Services’ technology. In we have a very simple representation of the architecture. Although simple, this representation is enough to observe how the architecture will be used to encompass several Information Systems from different branches of the Public Administration. In only the main message exchanges are represented. The remaining messages are omitted for sake of legibility. A representation of the communication messages exchanged between agents will be addressed later. Some of the ideas presented in this section were originally proposed by Dias and Rafael [3] in their interoperability architecture. 1) Agents A brief analysis of the base architecture (see Figure 2) allows us to identify all the architecture constituents. The key components are the agents. As defined earlier a software agent is an autonomous, reactive and proactive application that is able to communicate with other software agents. In this particular case, the software agent is an application that provides services and takes its decisions based on a defined set of criteria. Two typical types of behavior exist: (i) the agent acts as broker for the Local Information System (LIS), Agents A and C; (ii) the agent acts as an aggregator of services, Agent B, and uses the agents that can provide the results to fulfill the service request. Notice that any agent can have both behaviors.

Backward Trust – It is performed by an agent to assess trust on all the agents that participated previously in the workflow of a process for which it receives a request. In other words, the agent assess if the data that it will consume to deliver the service is trustworthy; Forward Trust – It is performed by an agent to assess trust on another agent that requests a result that was previously produced in the scope of a given workflow. This means that an agent assess the trustworthiness of the peer to whom it will deliver the produced data. Both these concepts are of extreme importance to the architecture. The Backward Trust assessment will prevent the delivery of services based on unreliable data, which it is a risk due to the inherent architecture dynamism. The Forward Trust assessment will prevent the access to the produced results by agents that are not trusted or authorized to do so. 3) Synchronous and Asynchronous Service Delivery The synchrony of the services provided by the architecture may depend upon a number of factors: if they require human intervention, if the necessary information is immediately available, if a software agent that should continue the workflow is online, etc. This is a limitation and an added complexity that should be handled by the architecture. The architecture was conceived to tackle all service requests in an asynchronous fashion. However, there are some exceptions since there are some special requests that must be processed synchronously, such as data and time stamping requests.

Figure 2. Basic architecture and generic service delivery representation

2) Communication All the communication inside the architecture happens between agents. An individual LIS can only access the architecture through its agent. The communications between agents are made over HTTP, for addressing portability and heterogeneity support, and SSL/TLS, for addressing confidentiality, integrity control and source/data authentication. Agents publish their services on the Service Repositories; those services are invoked through the use of Web Services. The invocation of a service originates standard message exchanges between agents. These messages are independent of the agents. Four types of messages are defined and described: Service Request; Result Request; Notification; Result Delivery. The fifth type of message (Acknowledge) is omitted since it is

CISTI 2011 | 340

used by the architecture as a mean to acknowledge the reception of a message.

information about the service, the agent that is responsible for providing the service and the updated information.

Figure 3 represents the typical sequence of messages, the order in which they will be performed and the corresponding responses. The communication between two agents starts by a request for a service. This service request can originate a set of notifications that give notice of state changes in the service request, availability of results or even that the service cannot be delivered. Both these types of message (Service Request and

3) Result Request This type of message can only be used when a service has already been executed. The requested result is identified through the use of an URI. Information about the request that originated the Result Request and about the applicant of the Result Request are also part of this message type. 4) Result Delivery This message is generated as a reply for a Result Request. The Result Delivery is composed of information relating the service requested, the agent that provided the service and the results of the service delivered. D. Complementary data In order to deliver the services in a secure way and to locate the services available throughout the architecture other data structures are needed. In this subsection we present these data structures.

Figure 3. Typical message sequence

Notification) correspond to asynchronous services. Finally, the Result Request and the Result Delivery messages correspond to a synchronous service of requesting the result of a service already performed. Thus, results are only transmitted when explicitly requested by an agent. This is essential in the architecture, since the concrete addressee of the result may not be known when the result is produced, due to the fact that the workflow is dynamically composed, and results must be encrypted with the public key of that addressee. Information about previously produced results, and not the results themselves, is included in the Service Request. C. Messages In this subsection we present the types of messages that are exchange between agents. 1) Service Request This type of message supports all the information required to request a service. The Service Request is composed of the data associated with the service to be requested such as the process identification, the time stamp, the requester signature, etc. At a given point in the service delivery process, messages of this type can have information about several services (resulting from service composition). This type of message also contains information about the requester and the addressee. In some cases, the outcome of a service request is returned in the form of a Notification and it is added to the message. 2) Notification This type of message is used to notify an agent that a change of state in the process or an error occurred. It contains

1) Service Description In order to be discovered and used, the software agents must publish their services in the service repositories. These service repositories respect the Universal Description, Discovery and Integration (UDDI) standard. The Service Description is based on the Web Services Description Language (WSDL) specification. This structure stores all the necessary information to be used in the architecture. It includes the identification of the service provider, as well as relevant information regarding the service delivery, such as data required and the service outcome. 2) Certificates The certificates are a very important piece in the architecture; they hold the information that allows the agents to determine if an intervenient in the process is to be trusted or if it is authorized to perform an action. The scheme of the certificate structure is based on the RFC 5280. We added extensions that allow an agent to determine if another agent is authorized to access a service or its data or if it is trustworthy in order to take the best decisions in the name of the client. 3) Certification Authority This data structure represents the Certification Authority relationship with the pair {entity, service} and is achieved with a certificate. This allows a Certification Authority to certify an Entity as a provider of several services. An {entity, service} pair may have several certificates, which indicate that an entity could be multi-certified to provide a service. E. Support Services In this subsection we present the services that support the architecture. 1) Certification Service This service main function is the issuing of certificates and revocation lists. With the inclusion of this service, we intent for the architecture to be self-contained, which means that the architecture provides every service it needs to operate. The issuing of a certificate is pivotal for an agent to become a valid

CISTI 2011 | 341

member of the architecture, as only certified agents would be able to provide services.

the less expensive paths, or the ones with the less time consumption, adapting the service delivery to the client needs.

2) Time-stamping Service All the messages exchanged within the architecture are time stamped; this allows a temporal placement of the message generation and consequent traceability of the services requested. The Time-stamping service provides time stamps and keep a record of the time when the time stamp service was requested. This requires synchronization between the applications that provide this service and high levels of performance and availability.

One of our main concerns is security; this can be seen in the way messages are protected with SSL/TLS. Nevertheless, all the messages that are exchanged are encrypted with the public key of the addressee. This means that only the addressee agent can interpret it. The trust assessment in the architecture is another of the positive aspects since it allows to determine if the data produced until one point in time is acceptable, rejecting any data generated by untrusted agents, hence denying the service delivery.

3) Service Repositories These repositories contain the description of the services provided by the agents. In fact, they are the faithful keepers of the Service Description data, resulting from the service publication by the agents.

Another added value is the fact that private vendors and Public Administration IT departments could develop their own version of the agents. Though, they must respect the basic conceptualization of the agents’ architecture. This can allow a faster availability of online services. Furthermore, it opens up a new business opportunity allowing developers to implement their own workflows in order to provide better and faster services.

IV.

DISCUSSION

In this section we make an approach to some of the most relevant aspects of the proposed architecture. A. Known limitations The architecture has some limitations, namely the lack of synchronous service delivery and the disperse history of a service request.

C. Fulfillment of the requirements Previously we have established a set of requirements that we believe are fundamental to interoperability architectures for e-Government: mutability, adaptability, versatility and security. In this subsection we will demonstrate that the proposed architecture meats these requirements.

The lack of synchronous service delivery means that even the services that could be provided instantaneously will have a delay until being delivered. In these cases, this delay should be insignificant; however, the necessary time and resources are nonetheless greater. On the other hand, the availability of synchronous services would increase the complexity of the architecture, which is not desirable.

The architecture is by design mutable and adaptable since it allows the addition/removal of services by publishing/unpublishing them in the Service Repositories. Furthermore, the agents are added to the architecture through the publishing of at least one accredit service or are removed as a consequence of unpublishing all its accredited services from the Service Repositories.

The last limitation is the disperse history of a service request; this is so since only the relevant messages to an agent are sent to it. Thus, each agent that participated in the delivery of a service will only have a partitioned view of the service delivery history. However, this limitation can be circumvented by explicitly requesting this data.

Every Public Administration branch or private entity that wishes to publish a service in the architecture is allowed to do so. The usage of the service is dependent upon the certification of the pair {service, entity}. As shown throughout the description, the agents take their decisions independently of the agents that provide the service, because they are solely dependent on the workflow that should be followed. The choice of the agents that would give sequence to the service provision is only dependent on the criteria defined by the requesting agent or client. This allows the creation of different paths towards the delivery of two exactly alike services.

B. Relevant Positive Aspects The exposed interoperability architecture has some limitations, as described earlier. Nonetheless it also has many strengths that should be highlighted. One of them comes from the fact that Public Administration agents or LIS can be temporarily unavailable. When this occurs, the architecture is able to determine the situation and act accordingly: it finds another agent that provides the same service and sends the request to this new agent. In other words, the platform has some time-limited resilience to faults of agents or LIS.

Security is without doubt the main feature of this architecture; let us analyze each of the six requirements identified previously:

Another strength of the architecture is its inherent dynamism: two exactly alike services can be delivered by different service providers with equivalent results. This can occur since agents are autonomous and, although they may have static workflows, the choice for providers is conducted in accordance with criteria defined by the requesting agent and/or by the customer. This dynamism allows the agents to choose

CISTI 2011 | 342

Authentication – this requirement is fulfilled partly outside the architecture with the authentication of the client by the LIS that passes this information to the associated agent. Additionally, agents and service repositories are also authenticated. This is accomplished in the beginning of the communication between two agents where they trade digitally signed and encrypted messages that can only be interpreted by the participant agents.

Authorization – this requirement is accomplished by two agent components that provide authorization and trust assessment. One assesses both trust and authorization of all actors involved in the process until that point; the other assesses the trust and authorization of the agent that requests the data. Agents should respect authorization restrictions before transferring requests to the LIS or processing them in any way. Since each LIS has its own specific authorization requirements, this is a very macro validation. The micro validation should be made by the associated LIS by imposing their specific security requirements. Trust is also assessed in the referred agent components. Only if the participants in a given service delivery respect the trust restrictions imposed by the service, the data they produce is trusted. Another point that deserves reference is the fact that the results of a given service do not circulate over the network unless explicitly requested (Result Request) and access to data will only be granted if the requester is authorized and trusted. Confidentiality – as previously mentioned, the communication is made over HTTP and SSL/TLS, which assures the confidentiality of eavesdroppers on the network. However, this does not assure that agents cannot access data that is not meant for them. To resolve this issue, messages’ items are also encrypted, which is done through the use of the public key of the recipient agent. Traceability – as stated previously the traceability of a given service is assured, although the relevant data is scattered throughout the agents that participated in the service delivery. The time stamps also have a critical part in the fulfillment of this requirement, they allow the temporal placement of each state change of the service delivery. Integrity and Non-Repudiation – these requirements are assured by digital signatures; each message is digitally signed. Furthermore, there are message items that must also be digitally signed. In one hand, the digital signature makes it easy to determine if a message was tampered with, on the other hand it assures that the data was generated by the entity that signed it.

The architecture has a set of identified limitations. The lack of synchronous service delivery may have impact in the time spend before the service being delivered. However, we estimate that the extra time can be neglected and that the gain in simplicity can recoup the added time. The dispersion of the service provision history is another of the limitations, because the participating agents only have access to the information that is relevant to them. Nevertheless, this data can be explicit requested to the participating agents, allowing the reconstruction of the service history when necessary. This design will allow the creation of agents by different vendors, Public Administration branches, private entities, etc. This allows a rapid development and availability of new services and the presence of new entities in the architecture. The usage of Web standards allows a rapid dissemination and facilitates the communication between agents. One of the main advantages of the architecture is the built-in PKI. On one hand, this facilitates the access to the set of Certification Authorities that collaborate to deliver the certification service and that allow the insertion of new entities and services in the framework. On the other hand, this certification can be done in a rigorous way, assuring that agents and their respective entities are validated before being certified. The proposed architecture fulfills all the addressed requirements. In the future we intend to further validate the proposed architecture by implementing a prototype using an existing platform of agents and by simulating a set of use cases collected for this purpose. REFERENCES [1]

[2] [3]

[4]

[5]

[6]

V. CONCLUSIONS AND FUTURE WORK One of the main objectives of the proposed architecture was the provisioning of integrated services in a secure way. It was also our intention to define an architecture that could evaluate the trust in all the agents that participate in the generation of the data in the scope of a given service request. The architecture also implements added security measures, namely the fact that the results generated do not automatically leave the agent/LIS that generated them. Instead, this data can be obtained through an explicit request. This request is, nevertheless, submitted to an authorization and trust assessment before being satisfied.

[7]

[8]

[9]

Public Management Service, “E-Government: Analysis framework and methodology”, Organization for Economic Co-Operation and Development Website, 2001. D. Holmes, eGov: E-Business Strategies for Government, London: Nicholas Brealey, 2001. G. P. Dias, and J. A. Rafael, “A simple model and a distributed architecture for realizing one-stop e-Government”, Electronic Commerce and Applications, vol. 6, no. 1, 2007, pp. 81-90. J. Kolter, R. Schillinger, W. Dobmeier, and G. Pernul, “An architecture integrating semantic e-Government services”, in Proceedings of 5th International eGovernment Conference, Krakow, Poland, Trauner Druck, 2006. M. Greunz, B. Schopp, and K. Stanoevska-Slabeva, “Supporting market transaction through XML contracting containers”, in Proceedings of 6th Americas Conference on Information Systems, Long Beach, 2000. M. Luck, R. Ashri and M. D’Inverno, Agent-Based Software Development.Norwood, MA: Artech House, 2004. F. Arcieri, F. Fioravanti, E. Nardelli, and M. Talamo, “A layered IT infrastructure for secure interoperability in personal data registry digital government services”, in Proceedings of 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications, New York, 2004, pp. 95-102. M. Caloyannides, D. R. Copeland, G. H. Datesman Jr., and D. S. Weitzel, “US – e-government authentication framework and programs”, IT Professional, vol. 5, no. 3, 2003, pp. 16-21. J. Joshi, A. Ghafoor, W. G. Aref, and E. H. Spafford, “Digital government security infrastructure design challenges”, vol. 34, no. 2, 2001, pp. 66-72.

CISTI 2011 | 343