In this scenario, a client has three alternative ways to communicate with an agency. The first way is to interact with an agency directly using the web site of this agency and second way is the usage of the e-government portal for finding the web site of an agency. The other alternative solution is the e-service registry use for discovering the web services given by the agency.
In the first way, if the client knows the internet address of an agency then he/she can use the browser based solutions (web page browser) and interact with an agency directly. The Figure 4.1 illustrates this type of interaction.
Client
Security Policies
Figure 4.1 Client-Agency Interactions
In Figure 4.1, client (e-citizen) requests specific type on information like TCKIMLINO or VERGINO from an agency web site using his/her browser and this service offered by a web service in an agency Y. For this operation, the web service needs some demographic information (name, surname, birth date, and birthplace) of e-citizen. After the e-citizen submits his/her demographic information, then the information sent to the data is encrypted using 128-bit SSL encryption procedure. By this approach, data/information becomes unreadable form against the illegal operations like hacking or sniffing attacks.
Data Encryption Authorization / Authentication Firewall AGENCY Y Web Service DBMS i n t e r f a c e B R O W S E R
SSL Client (e-citizen) SSL Server (agency) I II III IV
Figure 4.2 SSL and Certification Mechanism
Encrypted and compressed
Figure 4.2 illustrates how a security handshake establishes a secure connection between the client and agency. Once the handshake completes, the server and client have a common secret key with which data is encrypted and decrypted. In other words, SSL uses the public key(s) to encrypt exchanges for generating the shared
Handshake Start Client Random
Supported Cipher Suites
Supported Compression Algorithms
Server Random Decided Cipher Suite
Decided Compression Algorithm
Server Certificate and Server Public Key
Client Certificate Client Public Key
Encrypted Premaster Secret Handshake Finished
Handshake Finished
combines them. It does so because the public key encryption system takes more time to encrypt and decrypt messages than the secret key encryption system. Thus, the combination used by SSL takes advantage of both the easy maintenance of public key encryption and the quicker operating speed of secret key encryption.
In Figure 4.3, at phase I, the client starts the handshake, and then sends a random number, a list of supported ciphers, and compression algorithms. At phase II, the server selects a cipher and a compression algorithm and notifies the client. Then it sends another random number and a server certificate (which includes a public key). At phase III, the client sends a pre-master secret to the server, encrypting it with the server public key. Finally, the client might send a client certificate. Now the handshake is completed. The server and the client each generate a master secret key by combining the random number that the server sent, the random number that the client sent, and the pre-master secret. Several secret keys are created from the master secret. For example, one is used for encrypting transmitted data, and another is used for calculating digest value of the date for integrity. SSL ensures authentication (by verifying the certificates), confidentiality (by encrypting the data with a secret key), and integrity (by digesting the data).
Some information or data accessing operations at the agency side can be arranged according to authentication policy. In this case, the e-citizen should need to be authenticated in order to access some specific type of data by using his/her unique identifiers like username/password pair or TCKIMLIKNO (login procedure). Figure 4.4 illustrates the authentication procedure that happens when the e-citizen attempted to access special data/information over the government network.
Web Browser Web Server
GET /protected/index.html HTTP/1.0
HTTP/1.0 401 Unauthorized WWW-Authenticate:
Basic realm=”Basic Authentication Area”
Input password
GET /protected/index.html HTTP/1.0
Authorization: Basic U2htdkshd7s7s8m2lkhsd8sn3ksns
HTTP/1.0 200 OK
Figure 4.3 Authentication Mechanism
When the web browser sends an HTTP request to access a protected Web resource, the Web server returns an HTTP response, which includes the error code "401 Unauthorized" and the following HTTP header: WWW-Authenticate: Basic realm=”Realm Name”. Realm is a name given to a set of Web resources, and it is a unit to be protected. Basic in front of realm indicates a type of authentication—in this case, BASIC-AUTH. Based on this information, the Web browser shows a login dialog
to the user. Then, the Web browser sends an HTTP request again including the following HTTP header: Authorization: Basic credential. Although the credential looks like encrypted text, it is logically plain text because its format is simply UserName:Password encoded with Base64, for example, U2thdGVib. The Web
credential. If the given user ID and password are wrong, "401 Unauthorized" is returned. Moreover, the Web server has an access control list that specifies who can access what and checks whether the authenticated user can access the web resource. If the check succeeds, then "200 OK" is returned; otherwise, "401 Unauthorized" is returned.
The agency has also firewall mechanism for preventing the incoming requests from unsecured area. By using the firewall mechanism, agencies can arrange the trusted or not trusted areas by filtering the IP numbers. Thus, agency users or software programs used at the agency side cannot reach the unsecured regions on the web.
The data/information exchanging between the client browser and agency is in the form of XML by means of SOAP request and SOAP response. The client and agency communicated with each other using the SOAP technology. The Table 4.4 and 4.5 illustrate important parts of the client’s SOAP request and the web service’s SOAP response that are produced due to client’s TCKIMLIKNO request from the web service. <soap:Body> <SearchMernisData xmlns=”http://tempuri.org/”> <ad xsi:type="xsd:string>ozgur</ad> <soyad xsi:type="xsd:string>ozturk</soyad > <anaadi xsi:type="xsd:string>minor</anaadi > < babaadi xsi:type="xsd:string>bahattin</babaadi> <dogumyeri xsi:type="xsd:string>uskudar</dogumyeri> <dogumtarihi xsi:type="xsd:string>17.08.1979</dogumtarihi> <SearchMernisData> </soap:Body>
<soap: Body> <SearchMernisData> <SearchMernisDataResult xsi:type="xsd:string">321321</SearchMernisDataResult> </SearchMernisData> </soap: Body>
Table 4.5 SOAP Response
The SOAP request includes the value of the parameters, which are required by web service function SearchMernisData. It is important that, the data types of these parameters are also included in SOAP request. By this way, the client says that, “I am sending these parameters, their types and their values, so, give me a return value of the function, give me a result”. After that, web service function SearchMernisData (See the implementation of the SearchMernisData in Appendix B) takes these parameters, processing them and produce the result. The type of the return value of the function is string and its value is “321321”. By the SOAP response, server says that, “I received parameters that you sent, and now I am sending the result value 321321 whose type is string”. Both the request and response are in the form of XML, therefore, this information can be exchanged between different platforms. Another security policy is XML encryption that can be applied during this SOAP communication between client and server.
In the second way, a client may not know the exact internet address of the agency. In this case, e-government portal shown in Figure 3.1 can be used. A government web portal should have consistent interfaces that are easy to use. Further, the portal content should be accessible to all state constituents. Unlike private companies, which can develop their web portals to meet the needs of a carefully defined target audience, states must develop their web portals to provide equal access for all state constituents [32]. The e-government portal covers the access points to the agencies web sites. By this approach, client can visit the government portal and find the desired agency. The Figure 3.3 demonstrates the second way.
ASK
Client
Figure 4.4 Portal Usage
According to Figure 4.4, the e-government portal is an easy way for locating government agencies’ web sites from one place and this situation facilitates the client operations while he/she searching the agencies internet address. People also use government Web sites to complete transactions. According to an IRS news release of April 26, 2002, 39.5 million Americans filed their 2001 income taxes electronically in 2002, 6.6 million of these used home computers—a one-third jump from the previous year. People apply for passports and various licenses (for example, many states allow driver’s license renewals via the Internet), and businesses apply for patents and permits, and supply wage reports and other required information to government agencies [7].
The other alternative way to reach the agency or its web services is the e- service registry (UDDI registry) use. This structure is located in the IF and it helps clients to search and locate the web services. The e-service registry is the mandatory for those who do not know the web services locations. The Figure 4.5 illustrates the e-citizen-registry-agency relation.
3 1
2
Figure 4.5 E-service Registry Usage e-government web
PORTAL
agency X URL agency Y URL
... Agency X Web Page
Agency Y Web Page
E-service registry Agency X
In Figure 4.5, it is assumed that, the e-citizen does not know the location of the web service SearchMernisData that is responsible for querying the TCKIMLIKNO of individuals. The e-service registry includes the “meta service” for locating web services by enabling robust queries against rich metadata. In step1, e-citizen interacts with the e-service registry interface and uses a meta services. In step 2, the e-service registry returns the location information of web service back to the client. The answer of e-service registry consists of web services list, which are responsible for querying SearchMernisData and the internet address of the web services. In this case, the registry returns the SearchMernisData and its provider address (agency X). In step3, client can easily locate the web service location and access it. As a technical level, the web service registry contains programmatically accessible descriptions of businesses and the services they support. It can also include references to industry- specific specifications that a web service might support and identification systems (used for meaningful identification of businesses).
Figure 4.6 shows the technical relation between client-registry-service providers. The e-service registry built on the data provided by its customers. There are several steps to make data useful in this registry. Publishing useful information to the registry begins when software companies and standards bodies define specifications relevant to an industry or business, which they register in registry. The web service registry keeps track of all these entities by assigning each one a programmatically unique identifier, known as a Unique Universal Identifier (UUID) key. This key is guaranteed to be unique and never changes within a registry. These keys look like a formatted random hexadecimal string (for example, C0B9FE13- 179F-413D-8A5B-5004DB8E5BB2). They may be used to reference the entity with which they are associated. UUID keys created in a registry are only meaningful within the context of that registry. Other clients, such as search engines, and business applications, use a UDDI registry to discover services of interest. In turn, other businesses may invoke these services.
Figure 4.6 Message Flow between Client, Registry and Provider
All exchanged messages in Figure 4.6 are in the form of XML documents. The following lines explain the message flow in Figure 4.6
The Service Provider: E-government agency Directory : The UDDI Registry Service Consumer : The any types of client
1. A service provider describes its service using WSDL. This definition published to a directory of services. The directory can use Universal Description, Discovery, and Integration (UDDI).
2. A service consumer issues one or more queries to the directory to locate a service and determine how to communicate with that service.
3. Part of the WSDL provided by the service provider passed to the service consumer. This tells the service consumer what the requests and responses are for the service provider.
4. The service consumer uses the WSDL to send a request to the service provider.