Re-engineering of Web Reverse Proxy with ...

Re-engineering of Web Reverse Proxy with Shibboleth Authentication Galoh Rashidah Haron, Dharmadharshni Maniam, Vijayakumari Sadasivam, Wong Hon Loon Information System Security Lab MIMOS, Kuala Lumpur, Malaysia Abstract— Majority of web authentication is implemented using username and password mechanism. How about leveraging the Shibboleth authentication advantages as an alternative to username and password based authentication to access a live web site? This challenge is trivial if, the codes that built the external web sites are permissible to be modified. In a case where no access on the codes is available, we introduce a reverse proxy as a middleware between the Shibboleth and the web sites. As part of the solution, we re-engineer the existing web reverse proxy and create Java classes that manage and perform automated authentication to access the web site. We share the development experiences in completing the challenge which is assisted by the open source development efforts. Keywords— Web proxy; Security Assertion Markup Language (SAML); Shibboleth; Single Sign-On (SSO)

I. INTRODUCTION Username and password is becoming a de facto standard in web authentication. It can be implemented using HTML (Hypertext Markup Language) form with input text fields to perform the authentication challenge and be part of user identification for a system. The idea is to provide unique identity to represent user to the system, as such only the user is indeed, the user claims to be. As the authentication evolve with software and hardware method such as one-time passwords (OTP), mobile and token based authentication, researchers introduce a wider scope of authentication, i.e. Shibboleth [3]. The main features offering by Shibboleth are (i) single sign-on where user can access multiple applications with user’s unique identity (ii) multiple factors of authentication (iii) enables secure access control based on Security Assertion Markup Language (SAML) and (iv) protect user’s data and privacy by performing authorization without releasing any user identities. For running web sites that has already implemented with username and password authentication mechanism, the transformation to Shibboleth authentication is possible. A developer is required to deface the web site authentication page, get access and disable section of the authentication codes, and update the authorization codes in order to allow Shibboleth integration. In this paper, we propose a solution to transform to the Shibboleth authentication without having an access and modification of the application web site’s codes. For the transformation to occur, Shibboleth is required to be set up in order to perform single sign on application. In addition, the following three modules are required:

A. Reverse Proxy Reverse Proxy is a middleware module that acts as a mirror to access to a particular web site. User will access the web site transparently via the reverse proxy, without missing any functions offered by the original web site. The reverse proxy must have capability to manage the Shibboleth protocol and cookies which is used to maintain authentication state between users and web sites. B. Authentication Authentication module will perform an automated authentication from reverse proxy module to the original web application site. It will basically imitate the authentication in the original web site by running series of HTTP (Hypertext Transfer Protocol) request and response for authentication. This module invokes in the reverse proxy and intercepts the authentication of the original application web site. It is also responsible in performing static and dynamic post variable for authentication. C. Registration User will be required to register user’s credential information i.e. username and password to the registration module. The user’s credential submitted is the credential that user entered to access the application web site. With the credential information that is specific per application, the authentication module will acquire the credential accordance to the application and perform the automate authentication on behalf of user. The use case of the system is a user is presented with a Shibboleth authentication as a front channel in accessing the original web site. User shall access the web site via reverse proxy server with web browser. Then user shall receive the Shibboleth authentication page. Next, user shall submit the relevant credential information. Upon successful authentication, user will be redirected to the web site via the proxy. Prior to that, user is required to register user’s credential associated to the original web site. This paper is organised as follows. Section II will describe the related works of Shibboleth authentication and reverse proxy. Section III explains the proposed architecture to deliver the system as per our objective. The reverse proxy from the open source community is evaluated and discussion on the installation and configuration is shared in section IV. The section V provides the details communication of the modules in the built system. Section V will discuss on performance of the system and the implementation limitation. Finally, we conclude and brief the future work in section VI.

II. RELATED WORK Efforts to leverage the capabilities of Shibboleth framework for authentication and authorisation purpose were attempted by many researchers. The integration challenge is to find mechanism to propagate user credentials and information in a secure manner from Shibboleth to the intended application. Groeper et al. has proposed linking web-based Shibboleth federations with the X.509 certificate-based grid security infrastructure by using a short lived certificate service as a trust-proxy [2]. It allows user credentials being securely exchanged and propagated from one virtual organization to another virtual organization in a grid environment. Takaaki et al. has proposed a web forward proxy to propagate user credential from Shibboleth to access an external web site. The web forward proxy requires some modification to recognize Shibboleth protocol and session cookies, then forward all request from the browser to the origin server [1]. With the selection of forward proxy, the supports covered for HTTP access only. To overcome the problem, the authors recommend implementing reverse proxy in the future work. Our solution implements reverse proxy, simply because we required to enable the HTTP(s) protocol and to support server load balancing. In contrast with Takaaki solution, adoption of reverse proxy will require no manual set up of proxy configuration in the web browser. Another important feature driven by reverse proxy is, it enables the rewrite of URL (Uniform Resource Locator).This allows changes made to the URL in the web site to properly link to the proxy web site instead of linking to the page or image that is broken. III. PROPOSED ARCHITECTURE

To provide Shibboleth features in 3PW without any access to 3PW’s code and modification, a Reverse Proxy (RP) is introduced. RP is a middleware that manage all the HTTP communications between SP to the external web site. The communication flow is listed as below. 1. 2. 3. 4.

5. 6.

7. 8.

User will request a connection to 3PW through SP via web browser. If user is not authenticated, SP will redirect user to IdP via web browser. The information to authenticate user is forwarded to IdP via web browser. User will receive an authentication page. User will provide user’s credential information to authenticate to IdP. In a traditional Shibboleth authentication flow, upon user successful authentication, user will be redirected to the 3PW. SP will identify user has been authenticated and redirect the user to the RP with persistent identifiers information. RP will receive the persistent identifiers information from a REMOTE_USER environment variable and map the user credentials for the 3PW in reverse proxy database. Reverse proxy performs an automatic login on behalf of user based on extracted user credentials information. If user is authenticated, the 3PW web content is delivered to user. IV. GETTING HELP

For a quick prototype, we seek for open source solution that is ready to be deployed. These are among the open source efforts listed that will deliver the project as the intended solution. To develop the proposed system we require an open source solution that provides reverse proxy functionality and supports Shibboleth authentication module. A. WebProxy Portlet (WPP) The project provides a Java solution to incorporate arbitrary web content as an active component (portlets) in a web site (portals) [4]. It is built in with Shibboleth integration. It basically transforms any web applications and represents the web content in a new interface which is to be embedded in a new web site. The portlet behave in a similar manner to a reverse proxy, where it provides user a browser to access any web site from external network and display the web content inside the portlets. It provides configurable clipping technology, where it allows users to extract, modify and display part of the web site content.

Figure 1. Single Sign-On System Architecture

As depicted in Figure 1, we propose a solution to enable single sign on (SSO) and multiple factor authentication features into an external third party web site (3PW). The prototype of SSO features is implemented via Shibboleth authentication service. The service provider (SP) and identity provider (IdP) are the basic structure for the Shibboleth system. 3PW is the web site, origins with a form based authentication.

To display and interact with the original authentication application web site, the portlets provide multi type of authentication features. It supports basic, form, NTLM (NT LAN Manager) and Shibboleth authentication method. For the WebProxy portlet, user is able to configure the target web site address for the GET, POST, and PUT authentication request. B. Web Integration Portlet (WIP) The project provides a Java solution of a web proxy portlet to integrate any web content in a portal regardless of the technology adopted in the web content [4], similar as WPP. It is built as Java EE portlet and performs reverse proxy on the targeted web content. It is positioned between the portal and

application with clipping technology. It currently supports Lightweight Third-Party Authentication (LTPA), SSO as an authentication method. C. jEasy Extensible Proxy (J2EP) The project provides a Java solution of a reverse proxy running in any J2EE container [6]. It is able to extract and display any web content transparently. However, it does not support any authentication. So the authentication modules are required to be developed independently. The development approach towards this challenge is to segregate the experimental tasks into the following segments. (1) To setup a reverse proxy as a communication bridge to the web application (2) To imitate automated authentication to the web application (3) To test the reverse proxy over a Shibboleth system and making an authentication request to the web sites via reverse proxy. WPP is being analysed as the best matching solution to complete all the three tasks. It has the ability being a reverse proxy server and it does support Shibboleth authentication. Some general configurations are required such as BASE URL which is a starting point of the proxied application for the user after the authentication. For one month man effort of installation and configurations, we completed the task 1. We made trials and errors of configuring and trying to understand the concept of reverse proxy and found out there is limitation to proxy web content via the portlet technology. It has difficulties in displaying the web content that has the tag. Figure 2 shows the original HTML page with the tag before the proxy occurs. Figure 3 shows the HTML page after proxy is successful. The process of proxy made the original HTML page being wrapped inside the tag of the portal page, as per the addition of line 1 to 5 and 17 to 18 as in Figure 3. The problem rise when in HTML page, the behaviour of a frameset cannot be emulated within the body tag of a page. That is the reason why it is failed to display the proxied page.

Figure 2. An Original HTML page

Figure 3. A Proxied HTML page

The solution towards the problem, is to perform re-writing of the tag to tag. The reason being, tag can work inside the tag. However the solution adds extra performance for the proxy server. For WIP, despite of presenting different techniques for processing reverse proxy and rendering the HTML to WPP, we encounter similar problem as WPP. We also realized the learning curve for reverse proxy via portlet technology is high and defeat the purpose for a quick prototype solution. First, we need to understand how the proxy gets the content from the web site. We need to cater the configuration re-writing relevant URL link and how to manage CSS (Cascading Style Sheets) or JavaScript to proxy the web site as it is streaming from the original site. In addition, the coverage of HTML tags supported to be proxy is different based on project implementation. Since Shibboleth authentication involved session cookies, then testing on the proxy for the supported session cookies is vital. From this point, we decide to move on to the reverse proxy that is not built by portlet technology. On the first overview of J2EP is, it may not be the solution that we asked. It does perform reverse proxy functionalities, but it has no support for configurable authentication. Added, the support of SSL connection is in the author’s wish list for the J2EP in the future. It means we required extra development time to manage the HTTP(s) authentication request and response in order to support Shibboleth authentication. However, the J2EP provides an advantage where user can utilize the original web browser to have direct access to the web site without any portal technology. This feature is important to avoid decreasing of user’s convenience. The first change that we made is to support additional HTML, CSS and Java Script tags and enable the rewriting of URL. In order to support the SSL connection, we are required to rewrite any absolute path with HTTP(s) protocol and the J2EP must be prepared for SSL environment. We also encounter encoding issue. It occurs on certain re-writing pages and there seems to be an automatic insertion of

“\uFEFF”, the Byte Order Mark (BOM) characters. At first, the solution is to detect any BOM characters in the re-writing page and remove it using a substring function. But this is not a right solution as we are blocking the performance of the J2EP server. Reading on Java technology on how to handle unicode characters, we change the line of writing the original stream as getBytes operation. The operation allows to encodes string into a sequence of bytes using platform’s default character set, UTF-8. Next task is to handle the current authentication for the web site inside the J2EP and performing an automatic login for the web site. We analyze the HTTP request and response for the dedicated web site to be proxied, and create a method to perform automated login. The methods involved extracting the original authentication request, getting information on valid user of Shibboleth and intercepting the J2EP codes to post new authentication request to the web site. V. IMPLEMENTATION To build the proposed system, we constructed a RP prototype system over a Shibboleth system. This system has one SP, one IdP, one RP and an access to a 3PW. The implemented system is evaluated by accessing to a 3PW. The HTTP request and response for the proposed system is depicted in Figure 4. It shows an example of Shibboleth authentication process integrated to a username and password based authentication with reverse proxy technology. The first step is for user to access a proxy site of the third party web application through a SSL/TLS secure channel (Step 1). The web server SP receives the request and redirects the request to the IdP to perform SSO service in order to perform the Shibboleth authentication. SP will first check whether valid Shibboleth session cookie exists. If Shibboleth session cookie is valid, it will go directly to the RP. Otherwise it will ask for user identity at IdP.The web server will issues a GET request to the SSO service at the identity provider with a SAML tag of SAMLRequest value as base64-encoding of a (Step 2, 3). After the success of the Shibboleth authentication, IdP will generate persistent identifiers and redirects to SP, the reverse proxy will relay the HTTP requests and responses to the actual 3PW site (Step 4). The map from Shibboleth authentication integration to the authentication from original site of 3PW is by assigning user persistent identifiers to the user identity and password (Step 5, 6). The re-engineer to the J2EP is highlighted in steps 6 and 7. This includes a preparation of a reverse proxy that able to fully proxy the application site regardless of its built technology. To integrate SP and RP we required to manage the Shibboleth session cookies. In our implementation we segregate the function of reverse proxy to a dedicated server for performance and ease of maintenance. In steps 3 and 4, we perform extra steps to lean the multi factor authentication service to user. Multi factor authentication is an authentication method wherein several different factors are used in conjunction to authenticate a user. The implementation is based on Shibboleth SP 2.3.1 and Apache http 2.2.21 running on Debian Lenny release 5.0.4. Table I shows the changes required to the line of J2EP codes

to build the proposed system. It is about adding up 792 lines, which is written in Java language. TABLE I.

Module J2EP Registration Authentication Total LOC

LINE OF CODE (LOC) CHANGES

Original Code

Update Code

2840 0 0 2840

3149 160 323 3632

VI. DISCUSSION We did a brief analysis on the system performance in a production environment for both of the authentication systems based on time in milliseconds (ms). The first performance (S1) is the original username and password authentication system without the reverse proxy. User access the 3PW system from web browser by typing http://www.3pw.com.my directly. The second performance (S2) is the integration of Shibboleth authentication and the original username and password authentication system with reverse proxy. User access the 3PW system from web browser via Shibboleth by typing http://www.sp.com.my/3pw/. The experiments are conducted with no cache option in the web browser for every connection. Based on Table II, M1 is a measurement of user clicking the login button to submit user’s credential and get access to the landing page after a successful login. M2 is a measurement of the complete communication cycle of user identification as in the previous Figure 4. This includes user gets access to the web browser, receives a form based pages for authentication, submits the user credentials and receive the landing page after a successful login. TABLE II.

BRIEF SYSTEM ANALYSIS ON S1 AND S1

Operation

S1 (ms)

S2 (ms)

M1 M2

255.7 825.6

2473.3 3179.2

The value for S2 is expected to be larger than S1 in M2 operation. The reason is the process involves two operations; i.e. Shibboleth authentication and reverse proxy. We notify that the larger amount of time is dedicated to proxy the CSS and JSP (Java Server Pages) type of file by about 5s on average. Table III shows the authentication analysis for S1 and S2 for M2 operation. For a username and password authentication S1, the time to perform a complete authentication is 0.04 seconds. For Shibboleth authentication, which includes the times for SP to perform redirection, IdP to complete user identification and a complete cycle of SAML request and response take about 0.18 seconds. So 0.14 seconds difference for authentication performance between S1 and S2 is acceptable in terms of user experience. Based on Nielsen [8], 0.1 seconds is the ideal response time where user does not sense any interruption.

Figure 4. HTTP Request and Response for the Proposed Architecture

The total difference of 2.4 seconds between S1 and S2, to load the page after the successful login is consider acceptable response time. User will notice the delay, but the user experience is uninterrupted. TABLE III.

DETAIL SYSTEM ANALYSIS ON S1 AND S1

Operation

S1 (ms)

S2 (ms)

Redirect to proxy page SAML request time Multi login page load time Redirect to login page Login page load time Authentication time SAML response time After login page load time Total

0 0 0 0 569.9 41.7 0 214 825.6

1271 95 196 32.7 70.1 184.6 116.8 1213 3179.2

The implementation of the proposed architecture has limitation due to the nature of proxy functionalities. The following are the description of reverse proxy limitation. 1) Collecting of private information The proposed architecture leads to a collection of username and password to grant access to the third party web site. User is required to enter user’s credential including password for each of the applications to another machine, i.e. RP in the registration module in order to achieve a single sign on feature. The user’s private information collections if it is not being hardened, may invites attackers to the system. Without proper setting of security, privileges and roles for user histories information is scattered in the RP that may lead to a broken trust system [9]. 2) Authentication Technology The process of reverse proxy to a particular 3PW is not a straight forward operation. An investigation is required to handle the authentication technology adopted by the 3PW. Based on our experiment, we encounter dynamic post variables request. Example, the __VIEWSTATE variable which represents the state of the page when it was later processed on the server [7]. We handle it by creating a pre class for the specific web site. In the pre class, we reconstruct the dynamic post, username and password variables. 3) Hidden HTTP Operations For a 3PW which the HTTP(s) header, GET or POST operations are unable to be tracked or hidden due to the various adopted technology, the RP is unable to simulate the HTTP request and response. As a result no interception of authentication protocol can be made inside the RP. There is a possibility that web site enforce the block of proxy connection to the server. VII. CONCLUSION This paper shows the mechanism to adopt reverse proxy and Shibboleth authentication as an alternative to username and password based authentication in an application web site. The reverse proxy approach is the driven technology behind the transformation. It acts as a middleware to decouple the

current authentication in the web site without setting any changes in user’s web browser (client) and no efforts on codes modification in the web server programs (server). The motivation behind the transformation is to enable single sign on feature and to support multiple authentication mechanism where user authentication is no longer limited to username and password based authentication. The prototype is now ready for the future improvements. The next challenge is to harden the reverse proxy server with proper security mechanism to the user registration process flow and to protect the storage of username and password collection. Another important matter is to improve the measurement of authentication performance under hood Shibboleth and reverse proxy system. Further experiments to investigate the scalability and performance of the proposed architecture are required. The result of optimization and enhancement will ensure that the authentication usage is practical in the user’s environment. ACKNOWLEDGMENT We acknowledge the support provided by the Ministry of Science, Technology and Innovation (MOSTI) in funding the Unified Authentication Platform (UAP) project through the Tenth Malaysia Plan (10MP). The completion of the project allows the delivery of a centralized authentication infrastructural platform for web applications. REFERENCES [1]

[2]

[3] [4] [5] [6] [7] [8]

[9]

Zhang, N.; Yao, L.; Chin, J.; Shi, Q.; Nenadic, A.; McNab, A.; Rector, A.; Goble, C.; , "Plugging a scalable authentication framework into Shibboleth," Enabling Technologies: Infrastructure for Collaborative Enterprise, 2005. 14th IEEE International Workshops on , vol., no., pp. 271- 276, 13-15 June 2005 Groeper, R.; Grimm, C.; Piger, S.; Wiebelitz, J.; , "An Architecture for Authorization in Grids using Shibboleth and VOMS," Software Engineering and Advanced Applications, 2007. 33rd EUROMICRO Conference on , vol., no., pp.367-374, 28-31 Aug. 2007 Shibboleth, “Shibboleth documentation”, https://wiki.shibboleth.net (Accessed Date: June 2011) Unicon, WebProxy-Portlets – Jasig Wiki, https://wiki.jasig.org/display/PLT/WebProxy (Accessed Date: September 2011) Ippon Technologies, ippontech/wip · GitHub, https://github.com/ippontech/wip (Accessed Date: September 2011) Anders Nyman, J2EP, http://j2ep.sourceforge.net (Accessed Date: October 2011) Microsoft, “Cutting Edge: The ASP.NET View State”, http://msdn.microsoft.com/en-us/magazine/cc188774.aspx (Accessed Date: July 2012) Nielsen, Jakob (from Miller 1968; Card et al. 1991) (1994). http://www.useit.com/papers/responsetime.html. Usability Engineering: Response Times: The Three Important Limits. Morgan Kaufmann. Retrieved April 27, 2012. Jourdan, G.-V.; , "Centralized Web Proxy Services: Security and Privacy Considerations," Internet Computing, IEEE , vol.11, no.6, pp.46-52, Nov.-Dec. 2007