A Solutions for Authentication of Web Service Users

INTRODUCTION

Today, companies rely on thousands of different software applications each with their own role to play in running a business. To name just a few, database applications store information about customers and inventories, web applications allow customers to browse and purchase products online and sales tracking applications help business identify trends and make decisions for the future. These different software applications run on a wide range of different platforms and operating systems and they are implemented in different programming languages. As a result, it is very difficult for different applications to communicate with one another and share their resources in a coordinated way. Take, for example, a company that has its customer data stored in one application, its inventory data stored in another application and its purchasing orders from customers in a third. Until now, if this company wanted to integrate these different systems, it had to employ developers to create custom bridging software to allow the different applications to communicate with one another. However, these sorts of solutions are often piecemeal and time consuming. As soon as a change is made to one application, corresponding changes have to be made to the other applications linked to it and to the bridges that link the applications together.

To solve the problem of application-to-application communication, businesses need a standardized way for applications to communicate with one another over networks, no matter how those applications were originally implemented. Web services (Iverson, 2004; Fensel and Musen, 2001; Hendler, 2001) provide exactly this solution by providing a standardized method of communication between software applications. With a standardized method of communication in place, different applications can be integrated together in ways not possible before. Different applications can be made to call on each other’s resources easily and reliably and the different resources that applications already provide can be linked together to provide new sorts of resources and functionality. Moreover, application integration becomes much more flexible because web services provide a form of communication that is not tied to any particular platform or programming language. The interior implementation of one application can change without changing the communication channels between it and the other applications with which it is coordinated. As a summary, web services provide a standard way to expose an applications resources to the outside world so that any user can draw on the resources of the application.

Kent (1980) reported which addresses the security requirements of software vendors.

Protection from software copying and modification (e.g., the latter by physical attacks by users, or program-based attacks). Tools proposed to address these requirements include physical Tamper-Resistant Modules (TRMs) and cryptographic techniques; one approach involves using encrypted programs, with instructions decrypted immediately prior to execution. Kent also noted the dual of this problem: user requirements that externally-supplied software be confined in its access to local resources. Gosler (1985) software protection survey examines circa-1985 protection technologies including: hardware security devices (e.g., dongles), floppy disc signatures (magnetic and physical), analysis denial methods (e.g., anti-debug techniques, checksums, encrypted code) and slowing down interactive dynamic analysis. The focus is on software copy prevention, but Gosler notes that the strength of resisting copying should be balanced by the strength of resisting software analysis (e.g., reverse engineering to learn where to modify software and for protecting proprietary algorithms) and that of software modification (to bypass security checks). Useful tampering is usually preceded by reverse engineering. Gosler also notes that one should expect that an adversary can carry out dynamic analysis on the target software without detection (e.g., using in-circuit emulators and simulators) and that in such a case, as a result of repeated experiments, one should expect the adversary to win. The practical defense objective is thus to make such experiments extremely arduous. Another suggestion (Gosler, 1985) is cycling software (e.g., via some forced obsolescence) at a rate faster than an adversary can break it; this anticipates the paradigm of forced software renewal. Jakobsson and Reiter (2002) who propose discouraging pirates through forced updates and software aging. This approach is appropriate where protection from attacks for a limited time period suffices. Herzberg and Pinter (1987) consider the problem of software copy protection and propose a solution requiring CPU encryption support (which was far less feasible when proposed almost 20 years ago, circa 1984-1985). Cohen (1993) reported on software diversity and obfuscation is directly related to software protection and provides a wealth of techniques and insights. Goldreich and Ostrovsky (1996) provide one of the earliest theoretical foundation pieces. They reduce the problem of software protection-which they take to mean unauthorized software duplication-to that of efficient (in the theoretical sense) simulation on oblivious RAMs. A new issue they address is the extraction of useful information gained by an adversary examining the memory access patterns of executing programs. To address this, oblivious RAMs replace instruction fetches in the original program by sequences of fetches, effectively randomizing memory access patterns to eliminate information leakage.

In this study, the novel idea is to activate the software products by using web services, which is platform independent, on the part of the manufacturer, which offers a better control of software products licensing. Additionally, a custom solutions for authentication of web service users based on the RIJNDAEL algorithm has been proposed.

WEB SERVICE AUTHENTICATION

On web services, authentication of service user can be achieved in three different ways (Adams and Boeyen, 2002):

PLATFORM LEVEL AUTHENTICATION

Windows authentication is used in cases when you control endpoints which are in the same or trusting domain.

Basic authentication: On MS Internet Information Server, it is possible to configure authentication on web service’s virtual directory as basic authentication. In that case web service user must configure the proxy and provide credentials in the form of a user name and password. The proxy transmits the user name and password with each request towards the web service. The user name and password are transmitted in plaintext so Basic authentication is secure only if SSL is used. Code 1 shows how a web application can reach the user name and password when Basic authentication on MS IIS is in question.

Integrated windows authentication: If web service’s virtual directory on MS IIS is configured for Integrated Windows authentication (which results in Kerberos or NTLM authentication which further depends on the client and server environment). The advantage of this approach compared with basic authentication is in the fact that the user name and password are not transmitted over the network. In this case the user must explicitly configure the Credentials property on the proxy. In case the solution in which the user name and password are placed in web.config file is chosen, then they have to be encrypted by using DPAPI and not stored in plaintext.

Message level authentication: Message level authentication uses SOAP (Brose, 2003) header for passing data about the user name end password, assigned tickets and certificates. This type of authentication can be realized in several ways:

User name and password: User name and passwords can be transmitted in the SOAP header as part of his <Security> element as it follows in the Code 2.

Kerberos ticket: In code 3, an example of sending a Kerberos ticket as part of the SOAP header is given.

X.509: In order to achieve authentication of Web service, data about X.509 can be sent in the SOAP header as it follows in Code 4.

Application level authentication: Application Level Authentication, when Microsoft technologies are in question, can be realized in two ways:

WEB SERVICE AUTHORIZATION

After authentication of the Web service caller, restrictions on the level of functionality can be defined based on the identity of the caller or role memebership that he belongs to Short (2002), Kao (2001) and Raina (2004). Restricted access can be defined at the endpoint of the service (on the level of. asmx files), web methods or at the specific functionality inside the web method.

Web service endpoint authorization: If the web service is configured for integrated windows authentication, NTFS permissions can be configured (based on the security context of the original service caller) for access to it on the level of asmx files.

Web method authorization: For access to web methods that are part of web service, when individual access or access based on role membership is in question, the principal object associated with the current Web request can be used (access through HttpContext.User). The example of the code follows in Code 5.

Programmatic authorization: For more subtle authorization inside the web service method IPrincipal.IsInRole can be used (imperative permission checks or explicit role checks) as it can be seen in Code 6.

RIJNDAEL ALGORITHM

Rijndael (Murphy and Robshaw, 2000) is a symetric algorythm for encryption (Simmetric key block cipher) and it is the winner of the US Advanced Encryption Standard competition. Rijndael combination of safety, performance, efficiency, ease of implementation and flexibility make it a fine choice when custom security solutions are considered.

When web services are considered, SESO system developing team has decided to develop a custom mechanism for authentication of service users. For that purpose, a Rijndael class, that is part of Namespace System.Security.Cryptography Microsoft. NET Framework, was used. The examples of the code (C#. NET) for encryption and decryption are given in the Code 9 and Code 10. The methods given in the examples are part of the class of SESO project.

DESCRIPTION OF THE APPLICATION

SESO is a software product of the company PC which possesses the functionality of a send mail and SMS organizer and is intended for mass sale. SESO, along with the windows forms application within itself, possesses a system for licensing and application activation through web service and a system for mass sending of SMS messages through PC messages system (on the side of the customer) or through the web service of some SMS provider (Fig. 1).

Fig. 1:	The functionality of sending email and SMS messages of the application SESO

Fig. 2:	System architecture of the system for licensing and activation of the SESO

An installation version of the application has got limited functionality (working with 15 records only, the possibility of sending only 5 SMS messages and activity period of 60 days).

LICENSING AND APPLICATION ACTIVATION

The system for licensing and activation of the application SESO is based on the web service for licensing and activation (Ben-Itzhak, 2005; Wassermann and Su, 2004; Benjamin, 2005; Huang et al., 2003, 2004). It goes without saying that for performing licensing and activation, an active connection to the Internet is needed (Fig. 2).

The system for licensing and activation of the application SESO is based on a pair of numbers (Id and Key of a customer) which a customer obtains from a PC employee in direct contact (Fig. 3).

Through the user application the employee inserts data about the customer into the database and then assigns him free Id from the table with already created pairs of numbers Id and Key. Id is generated by a generator of random numbers and consists of six numbers. The number of possible combinations is 6⁶. The Key of the customer is a number of fifteen figures which is generated by an algorythm developed by PC for this purpose.

Fig. 3:	Id and Key are assigned to the customer in direct contact only

Fig. 4:	Licensing and activation of the application SESO

Values for the Id and Key of the customer are not repeated in the base. This itself indicates that the pair of numbers for the Id and Key is unique and that it denotes the customer. Every customer can buy n number of licenses (the number of licenses corresponds to the number of computers on which SESO will be installed) and the employee at PC adds them to the data base of customers through the user application.

Activation of the application SESO begins with entering a pair of numbers Id and Key in the fields on the form for activation which is a part of the application SESO. After starting the activation the Id of a customers is encrypted by the Private key (Step 1, Fig. 4). Then, all the other data are encrypted (Key of the customer, active user, computer name, domain name or work group) and are sent to the web service for activation (Step 2, Fig. 4). For encryption of these data the key of the customer is used. After establishing communication with the web service for activation, encrypted data are sent to its method (Step 3, Fig. 4). Web service method decrypts the encrypted Id of the customer with the pair of keys by which it is encrypted (Step 4, Fig. 4) and then from the data base of customers it takes its pair for the Key of the customer (Steps 5 and 6, Fig. 4).

Using the value that the Key of the customer possesses the encrypted data for the Key of the customer that the application SESO has sent is decrypted first (Step 7, Fig. 4). If the value for the Key of the customer agrees with that acquired from the data base then the status of the licenses is checked i.e., we check whether the customer has more free licenses in the data base. If the customer has some free licenses in the data base, then all the other data that the application SESO has sent are encrypted (active user, computer name, domain name, or work group) by using the data for the Key of the customer as a key, one free license of the customer is checked and the decrypted data are inserted into the data base (Step 8, Fig. 4). Then the web service method for activation returns the confirmation of activation to the application SESO (Step 9, Fig. 4) which activates and acquires its full functionality.

The Rijndael symetric algorithm for encrypting, which is part of the MS. NET Framework, is used for encryption.