1

Design and Development of an Authorization and Authentication Web Service Suman Challagulla, Master of Science in Technology, Division of Computing Studies, Arizona State University, [email protected] Abstract This project introduces a Single Sign – On (SSO) Web Service as a solution to existing problems with web based authorization and authentication. It provides an aggregated Web Service on top of existing data repository systems such as databases, data warehouses or other data stores. It provides a system based on centralized access control as if each service has the ability to control access and provide service independent of others. The SSO Web Service utilizes the principles of the popular “Kerberos” ticket granting authentication and authorization system. From a programming point of view, in order to make the Web Service easily accessible, a component that encapsulates the functionality of the “Ticket Granting Service” amongst others was developed. This component also conceals from the consumer from the underlying details of exchanging secure encrypted SOAP messages back and forth from the Web Service. The SSO Web Service is itself based on a dynamic component building mechanism and provides personalized service based on the options selected by its consumer. It also provides a convenient way for new components and services to be plugged in. The SSO Web Service is designed to accommodate all the Web Service components that are invoked via the standard HTTP protocol. Sensitive data passed between the Web Service and the consumer is encrypted using shared key encryption. The consumer of this Web Service does not have to modify any of his existing applications, services or database structure in order to utilize the available features of the Single Sign – On Web Service. All the functionality is strictly in compliance with the Web Service standards. 1.

INTRODUCTION

The arrival of the World Wide Web (WWW) brought about a higher visibility of basic information/document exchange. However, it left a lot to be desired in terms of communication security. 1.1. WWW Security Issues At the time of its release however, the WWW was intentionally designed to be an "open" specification for data exchange/access. The original design specifically states that security and access controls were left out of the WWW. Increased usage of the Web for a variety of tasks that involve the sharing of data and files raised the issue of incorporating access controls and data security into the Web delivery process. WWW operates at the highest level (application) in the network model. Hence, all the security problems in the

lower levels of the network model (data link, network, and transport) are potential sources of security risk in the WWW too. 1.2 Current Situation of Web Applications Security Web application users expect seamless integration and interoperability when they use a Web site. Yet the backend systems driving the site are a conglomeration of individual server software packages [1]. For any business conducted over the web, the employees need access to a number of web applications. In this scenario, let us view the web applications as services. Only authenticated users need to be given access to the services that they are authorized for. Each of these services would have been developed over a period of time by different software developers. Without proper planning, each of these services would require a separate login for the users and may use different security approaches. The users of these applications have to remember a plethora of login information. This results in high maintenance costs, unproductive and extra effort on the programmer’s part. With the advent of networks, people acquired many computing accounts each with a username and password to be remembered. Systems like Novell Directory System (NDS) were developed to bring the problem under control and for a while many users could access all their computing resources with a single password. This was an effective solution to windows/desktop based applications. However, the rise of networked dataset providers and web applications has caused a new explosion in usernames and passwords to be managed [2]. Hence these solutions could not be applied to web based applications. 2.

PROBLEM STATEMENT

For any business that utilizes web based applications either for its internal data analysis purposes or to conduct its business online, one of the most common and important problems is to issue and maintain the different identities of each user and the login information of each individual identity [2]. This project involves the design and development of a Single Sign – On (SSO) Web Service that could be utilized by any business to serve as a common point of authentication to all its users. This means that the user would have one identity which he or she would use to login to access all the applications that he is allowed to use with the necessary access control regulations. This Web Service also enables easy integration of different applications since the programmer does not have to build separate applications that authenticate the user when he tries to access each individual application.

2 This primary intent of this project was to design and develop a Web Service that provides a seamless, easy and secure Single Sign – On experience for users. 3.

BACKGROUND AND RELATED WORK

The concept of “Single – Sign On” has been researched and implemented in a couple of different ways in the past. 3.1. SSO using “Security Assertions Markup Language (SAML)” SAML is a new standard for exchanging secure information in XML. The security information described by SAML is expressed through assertion statements about security subjects (e.g. users, machines, services etc.). SAML defines the protocol by which the service consumer issues the SAML request and the SAML authority returns the SAML response with assertions. There are three kinds of assertions: authentication, authorization and attributes [3]. This approach permits the authentication token to contain some valuable security information that allows validation without having to call the SSO server each time. The token contains the authentication or authorization information. This information is “signed” by the SSO server, so provided the token recipient trusts this server; it doesn't have to do any further verification. The described scenario is outlined in Figure 1.

Figure 1: SSO Scenario with SAML [3] 3.2. SSO Web Service Integrator – WebEntrance WebEntrance [4] provides a web aggregation service provider by providing a single login entrance for users. WebEntrance consists of: a user registration sub system, a service engine, and an administration sub system. The User Registration system coordinates user registration information with the corresponding service components. The Service Engine accepts requests from browsers and passes them to the corresponding service components, obtains responses from the components and sends them back to the browsers [4]. The Administration system manages users and Web Service components. The architecture is as shown in Figure 2.

Figure 2: WebEntrance Architecture [4] 3.3 SSO with Central Authentication Service (CAS) Protocol The CAS protocol [5] was developed by Yale University and its implementation was made open source. According to the CAS protocol; when the user attempts to access an application using its URL, the user is redirected to the CAS login URL over an HTTPS connection, passing the name of the requested service as a parameter. The user enters his authentication details and CAS attempts to authenticate the user. If authentication fails, the target application never knows about the request and user is stalled at the CAS server. If authentication succeeds, then CAS redirects the user back to the target application, appending a parameter to the URL. CAS then attempts to create a cookie that allows for automatic re authentication later on. The application then validates that the cookie represents a valid user by calling the CAS URL through a HTTPS connection and passing the information in the cookie and service name as parameters. CAS checks that the supplied cookie is valid and is associated with the requested service. If validation is successful, CAS returns the username to the application.

3 in the data access layer and uses it for necessary processing and supplies the results to the SSO Web Service. 4.4. ASP.NET & Java Clients To test the functionality of the SSO Web Service, a number of ASP.NET services (web applications) were developed. A Java client was also written to test and demonstrate interoperability. 5.

SSO ARCHITECTURE

The SSO Web Service was designed in such a way as to use the principles of Kerberos ticket granting authentication and authorization system. Figure 4.1 and Figure 4.2 explain the architecture of the entire system. The figure also depicts the process flow of the system. Figure 3: Working of the CAS Protocol [5] 4.

SSO METHODOLOGY AND SECUROTY APPROACHES

In order to create a SSO solution, the concepts of the popular and widely accepted network authentication protocol: Kerberos [6] were utilized. They were implemented in a Web Service and were made available for any web based application. The following applications were created as a part of the implementation:

4.2. SSO Client Controller In order to implement the functionality of the “Ticket Granting Ticket” service provided by Kerberos, a SSO Client Controller component was written in C#. This component can be plugged into any web based application without making absolutely any changes in the application. Once plugged in, this component authorizes the services to the client and ensures secure communication between the client web application and the SSO Web Service. 4.3. Data Access & Business Components For easy access to the user credentials, a data access layer was implemented using the best practices implementations from Microsoft .NET Application Patterns and Practices [5]. A business component was developed that uses the components

Data Access Business Logic Layer Tier 5. Custom Encrypted SOAP Response (Service Password)

Ticket Granting Ticket Service SSO Client Controller SSO Web Server

Plug-in

4.1. SSO Web Service This Web Service encapsulates the functionality of Kerberos ticket granting system. It was developed using ASP.NET and C#. The Web Service was designed to be easy to access and effective in approach. There are two reasons for choosing a Web Service to secure web application for the purposes of authentication and authorization. In a corporate intranet, existing and new web applications can utilize the methods exposed by the Web Service and secure themselves. It is also possible for web applications that exist on the internet to register themselves to the SSO Web Service and secure themselves. In the second case, the web applications would have to share the database access information with the Web Service.

SQL Server

4. Get Service Password

Login Ticket 2. {User Name, Workstation ID, Session Key} Password

1. {User Name, Service Name, Workstation ID} Figure 4.1: SSO Architecture 5.1. SSO Web Service The job of the SSO Web Service is to expose web methods that the client can use. It does not perform any real work.

4

9. Decrypt Authenticator 10. Destroy Session Key 7. Request Service Password Service

Authenticator 6. [{User Name, Workstation ID} Session Key, Session Key] Service Password

8. Get Service Password

• Database

• •

SQL Server

Account: This table has the username’s and passwords of the users. ServiceAccess: This table has a list of services that the individual users are authorized for. ServiceAuthorization: This table contains a list of service names and their passwords. Account UserID (Primary Key) Password

ServiceAccess UserID (Primary Key) ServiceNames

ServiceAuthorization ServiceName (Primary Key) ServicePassword

Figure 5: Tables

“Ticket Granting Ticket” Service

5.3. Data Access Layer The data access layer was built based on a combination of the “Microsoft .NET Patterns and Practices” and the “Factory Pattern” in Java. The “Factory Pattern” architecture is as shown in Figure 6.

Figure 4.2: SSO Architecture In each of the methods exposed by the SSO Web Service, the work is delegated another object named as the “AccountController”. This in turn handles all the requests made by and from the SSO Web Service. The “AccountController” class in turn delegates all the work to the appropriate business object in the business layer. The SSO Web Service is deployed on the “Authentication and Authorization Server” as shown in Figure 4. It exposes the following web methods: • SignIn – This web method takes the client’s login information as input, verifies his credentials and authenticates him. • CheckUserAuthorizationForService – This web method takes the user information and the service information that he is trying to access and checks the user’s credentials whether he is authorized for that service or not. 5.2. Database The database that was used for this project was Microsoft SQL Server 2000. However, the application was also tested with Microsoft Access and MySQL. If a number of services have been built and need to be secured, changing the database structure would be a time consuming activity. Keeping this in mind, the SSO Web Service was designed so as to use the consumer would have to make either very minimal or no changes to his database. The essential tables that need to be present in the database and their relationships are as shown in Figure 5.

Figure 6: Factory Pattern The different components of the data access layer are the: • Database Objects Map (DBMap): The objects in this component encapsulate the information in the database tables being used by the application. • Data Access Interfaces (IDAL): The interfaces in this component return DBMap objects to the business logic objects. • Factory (DALFactory): The objects in this component implement the interfaces in the interfaces in the IDAL component. The actual SQL queries are written in these classes and results are transformed into DBMap objects. The DALFactory object in this component creates the other objects when requested and acts as an entry point into this component. • Database Independence (DBIndependence): This component abstracts the database away from the application. It includes custom objects for SQL Server, Oracle and any other OLEDB compliant database. The appropriate object is called from the

5 DALFactory objects in order to perform execution of the queries. IDAL Data Access Interfaces

DAL Factory

Data Access Implementations

DBMap Database Mapped Objects

Database Independence SQL Server – Oracle OLEDB

Figure 7: Data Access Layer The database is specified in the web.config file in the section in the section as shown below: 5.4. Business Logic Tier The business logic tier is responsible for the actual work performed by the SSO Web Service. This layer consists of objects that accept responsibilities handed down from the “AccountController” object in the SSO Web Service and process them. In the business objects, the DBMap objects are used and processed to determine the user’s authentication and authorization credentials. Another business object called “TicketMaster” creates and issues authorization and authentication tickets. The business layer is shown in Figure 8. SSO Web (AccountController

Business Logic {Account}, {ServiceAccess}, {ServiceAuthorization},

The logging component is capable of logging information, errors and any unexpected events that take place in the application into a text file. It was designed to be thread-safe and is generic and is used extensively throughout all the components of the application. 5.6. SSO Client Controller This component was designed to be a plug-in to the client. The objects in this component are: • SSOClientManager: The SSOClientManager handles all the requests from the client to the service and the SSO Web Service. It passes all the required parameters to the necessary objects and handles the information returned from them. • TicketGrantingService: This object is in accordance with the Kerberos Ticket Granting Ticket Service. This object handles all the requests for the tickets from the client and also manages the tickets granted to the client. 6.

SSO IMPLEMENTATION & COMPARISON TO KERBEROS

Based on the architecture explained in the preceding section, the implementation was done in accordance with Kerberos concepts. The underlying features of the implementation and how the components encapsulate the functionality of each Kerberos feature are explained in this section. 6.1. Authentication The authentication system is strictly in accordance with the Kerberos system. The client supplies his username and password. The SSOClientController collects the username, the name of the service (from the web URL), the business name (for registration purposes) and the workstation ID and invokes the “SignIn” web method in the SSO Web Service. The SSO Web Service collects these parameters in the “SignIn” web method and passes the parameters to the AccountController object. The AccountController object creates a TicketMaster business object and passes the responsibility of creating the login ticket to it. The TicketMaster object creates an Account business object and gets the user’s password from the database. The TicketMaster then encrypts the user’s information using the Rijndael encryption algorithm with the user’s password to create the Login Ticket and sends it back to the Web Service in the same route. The Web Service prepares a SOAP message to transfer this ticket back to the client. The SSOClientController receives this login ticket and decrypts it using the password that the user typed in the login page. If the decryption is successful, then the user is successfully authenticated; otherwise he is directed to an error page. Hence the authentication system works in the same way that Kerberos does.

Data Access

Figure 8: Business Logic Tier 5.5. Logging

A sample SOAP request message to the SSO Web Service is as shown below:

6 string string string string A sample SOAP response that is sent back to the client is as shown below: base64Binary The actual SOAP response is as shown below: WjUyaW1vWWROczVKNitzTm5HTVVIRStlWXM4eX VZcU5HbmRkMTZXOTlmcz0= 6.2. Authorization Once a user is authenticated, he is ready to request services. The services were created in ASP.NET and C#. In a ASP.NET web page, the first method to be called before any of the processing takes place is the OnInit() method. Hence in order to authorize the user for the service, this method was overridden by the SSOClientController. The services simply inherit from this class. As soon as the user is authenticated, he is redirected to the service URL that he has requested or to the default service page. Before the service web page processing begins, the user is checked whether he is authorized for the service. As per the authorization principles of Kerberos, the “Ticket Granting Ticket” service takes care of this process and provides service tickets to the user before providing him access to the service. After the user is authenticated, a TicketGrantingService object is created by the SSOClientController object in the

OnInit() method of each service. In the default service page, his username and workstation are encrypted with the service’s password and is stored in a cookie. Kerberos provides a way to make sure that the service is actually who it claims to be. In order to do this, it is required to decrypt information using its service password. Similar to this concept, the TicketGrantingTicket Service object is required to decrypt the cookie set by the SSOClientController that is encrypted using the service’s password. In order to do this, the TicketGrantingTicket service utilizes the “GetServicePassword” web method of the SSO Web Service to get the service’s password from the database. The only parameter sent across the network to the SSO Web Service is the service name. The SSO Web Service receives the service name and calls the AccountController object which in turn delegates the responsibility to the ServiceAuthorization object that returns the password to the SSO Web Service after obtaining it through the data access layer. Here, the password must not be sent across the network in clear text format. Hence custom encryption classes for a custom encryption attribute were written and only the encrypted password was sent back to the TicketGrantingTicket object. The web method in the SSO Web Service was marked as shown below: [WebMethod] [EncryptionExtension(Encrypt=EncryptMode.Respon se)] public string GetServicePassword(string sServiceName) The sample SOAP request’s are as shown below: string The sample SOAP response is as shown below:

7 string In order to decrypt this message, the WSDL has to be modified slightly for the “GetServicePassword” web method. We make use of the custom attribute “EncryptionExtensionAttribute” class in order to achieve this. The code snippet is as shown below: [System.Web.Services.Protocols.SoapDocumentMeth odAttribute("http://tempuri.org/GetServicePassword", RequestNamespace="http://tempuri.org/", ResponseNamespace="http://tempuri.org/", Use=System.Web.Services.Description.SoapBinding Use.Literal, ParameterStyle=System.Web.Services.Protocols.Soap ParameterStyle.Wrapped)] [EncryptionExtension(Decrypt=DecryptMode.Reques t)] public string GetServicePassword(string sServiceName) After decrypting the cookie, the TicketGrantingTicket object gets the session key and for accessing the service. The concept of the session key in Kerberos is to prevent an unauthorized user to user the service while posing as a legitimate user by simulating another user’s workstation ID and username. Similarly, in this case, the session key is returned to the TicketGrantingTicket object and using this and the information in the cookie, the TicketGrantingTicket object builds what is called an “Authenticator”, in Kerberos terminology. The authenticator is built by encrypting the username and workstation ID using the session key and then again encrypting this along with the session key using the service password. Then a call to the SSO Web Service’s “CheckUserAuthorizationForService” web method to check whether the user is authorized to access the service. Only the username and the service name are sent to the Web Service as parameters in clear text. A sample SOAP request message is as shown below: SOAPAction: "http://tempuri.org/CheckUserAuthorizationForService"

string string boolean The actual SOAP response is shown below: true If it is determined that the user has access to the service requested, the TicketGrantingTicket service provides a service ticket that authorizes the user to use the service for the length of his session. Kerberos avoids round trips to the server by the use of this ticket. Similarly, in order to avoid round trips to the SSO Web Service, a cookie is set for the user to use the service for the length of his session. The cookie is encrypted with the service password and is used as the service ticket. As in Kerberos, the authenticator is destroyed after the user is authorized for the service so that the same ticket cannot be played again by another user. 6.3. Logging A logging component was written in C# for effectively determine the cause of any errors, if any and for demonstration purposes. The component is thread-safe. Logging can be

8 turned on and off and can be reconfigured without recompiling the entire application using the web.config file. The web.config file is configured as follows: Logging is provided in two levels: common information messages and error messages. This component is used extensively in the SSO Web Service, business layer, data access layer, SSOClientController and the client components. Messages are written into a text file with the time stamp as the name of the files. Session logs can be viewed in the form of services from web pages. 7.

SERVICES

Several sample test services were created for the purpose of testing the SSO Web Service. 7.1. C# Services In order to create a meaningful set of services, a web based “Data Analysis Tool Suite” was created for a hypothetical trading company named “Jekyll & Hyde”. The tool suite consisted of several web applications linked by a common user interface for the users to access. “Northwind”; a sample database provided by Microsoft along with SQL Server was used as the back – end for these services. A brief description of each service is as follows: • Categories: This service provides detailed description of the available categories of products and the current availability status of these products. • Suppliers: This service provides information about the suppliers and their products currently available in the market. • Products: This service provided information about the products available in the warehouse, stock supplies, price and re-order levels. • Orders: This service provides information about customers, their outstanding orders and the order’s pertinent details. • Customer Search: This provides the ability to search for a particular customer by their last name. Two other services that are not a part of the tool suite were also provided. The idea behind these services was to demonstrate the functionality of the SSO Web Service. • Client Log: This service displays all the activities of the user for the length of his session. All the information that is logged in the log file by the logging component for his session is displayed in the web page. • Web Service Log: This service displays all the activities performed by the SSO Web Service for the

current user for the length of his session. Similar to the Client Log service, all the information that is logged in the log file by the logging component for the user’s session on the server side is displayed in the web page. 7.2. Java Services In order to demonstrate interoperability, a simple service was written in java that authenticates the user. Other features were not developed in Java due to time constraints. 8.

CONCLUSIONS

The study successfully demonstrated how Web Services can be used to authenticate and authorize users and provide them with a single point of entry to all the services that they can access. Through the use of the SSO Web Service that was developed as a part of this study, the user can have only one identity which he or she would use to access services that he is authorized for with the necessary access control regulations. The study also showed that the SSO Web Service enables easy integration of different web applications because the developers can use the same authentication and authorization mechanism as provided by the SSO Web Service for any number of web applications (Services). Hence the SSO Web Service provides a seamless, easy and secure Single Sign – On experience for users. 9.

FUTURE WORK

The SSOClientController component can be replicated in Java to demonstrate complete interoperability. Any service written in Java can use this plug-in to completely utilize the authentication and authorization mechanisms provided by the SSO Web Service. ACKNOWLEDGEMENT I sincerely thank my advisor, Dr. Bruce Millard, for his able guidance and patient help during the course of this study. I would also like to thank my committee members Dr. Timothy Lindquist and Dr. Harry Koehnemann for their input and valuable feedback in this study. I also thank the faculty, students and staff of the Division of Computing Studies department for the numerous discussions I had on subjects related to the study. REFERENCES [1] Tim Torgenrud and Scott Brylow , “SUNet Authentication (January 1998)” Available: http://www.stanford.edu/class/ee380/9798win/lect04.html [2] Regaining Single Sign-On (September 2003) Available: http://www.brunel.ac.uk/depts/cc/papers/regaining-sso.html [3] Zrlenek Svoboda, “Securing Web Services With Single Sign – On”

9 Available: http://www.theserverside.com/articles/article.tss?l=Systinetweb-services-part-6 [4] Yan Zhao, “A Single Login Web Service Integrator – WebEntrance (February 1998)” Available: http://decweb.ethz.ch/WWW6/Posters/760/760_WEB9.htm [5] Frank Cohen, “Build and implement a single sign-on solution” Available: www-106.ibm.com/developerworks/webservices/library/wssingle/ [6] Kerberos: The Network Authentication Protocol Available: http://web.mit.edu/kerberos/www/ [7] Scott Short. Building XML Web Services for the Microsoft .NET Platform. Washington D.C: Microsoft Press, 2001. [7] Web Services Architecture (January 1999) Available: http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/att0212/HKsContribution.triangle.htm [10] Srinivasa Sivakumar et al. Professional ASP.NET Web Services. Birmingham: Wrox Press Ltd., 2002. [11] John Hunt. C# And Object Orientation. Nottingham: Springer Press, 2003. [12] Simon Robinson et al. Professional C#. Birmingham: Wrox Press Ltd., 2002.