Certain exemplary embodiments address the problem in a dual web-site operation, for example, where access to a web application (which may or may not be provided by a second party) is made available for service delivery to a user through a service provider web portal (which may or may not be provided by a third party), for example, where the web portal enables single sign-on (SSO).
FIG. 1 shows a conventional communications network for providing user 10 access, via browser 12 and internet 14, to an application (e.g. App1, App2, App3) on back-end servers (BES) 28. Browser 12 connects via internet 14 to network switch 16, for example a Cisco ACE which provides standard functions such as load balancing and address translation. Network switch 16 is in communication with web server 40, for example a SunOne server hosting SiteMinder single sign-on web agent for a web portal. Web server 40 is connected to policy server 42 and application server 50 hosting a web portal.
In order to be able to use conventional single sign-on to access an application running on back-end servers (BES) 28, user 10 first has to be authenticated by signing-on to web portal 50 via web server 40. To allow access to an application e.g., App1 running on BES 28, following a successful sign-on, portal web server 40 displays on browser 12 a list of applications accessible by the authenticated signed-on user. Only those applications which the user is authorized to access are displayed to the user on browser 12 by the web portal on application server 50, through web server 40. A domain name server (DNS), not shown, is included in internet 14. With the single sign-on system of FIG. 1, all applications (e.g. App1, App2, App3) running on BES 28 share a single domain name server (DNS) record (e.g.: sso.<Portal DNS>). When the user, signed-on with the web portal via server 40, selects a prompt displayed on the web page displayed in browser 12 for one of the applications running on BES 28, browser 12 opens a new window and generates a request, including a URL associated in the DNS with a public IP address of portal web server 40. On receiving the request, the single sign-on web agent on portal web server 40 authenticates user 10 and, following successful authentication, portal web server 40 forwards the request to single sign-on proxy 18. Single sign-on proxy 18 is responsible, with reference to portal database 32, for authorizing requests from user 10 for access to the applications on BES 28 and is responsible for proxying user requests to BES 28.
The specific application on BES 28 that is the subject of the request is determined from the context path (comprised in the request URL). Requesting user 10 is identified from a HTTP header “SM_USER”, which is injected in the request by the single sign-on web agent on web server 40. Any other information necessary for user authorization is either supplied in the request or is obtained from portal database 32 and the user's authorization to access the requested application is validated accordingly.
If the single sign-on web agent on web server 40 authenticates—and single sign-on proxy 18 authorizes—the user to access the requested application, the user request is proxied by single sign-on proxy 18 to BES 28 in conventional manner using the Apache httpclient library. For access to applications via single sign-on, proxy 18 is responsible for sending to BES 28, in a HTTP header, any information required for authentication and authorization of requesting user 10. The response from BES 28 to the user request is processed by the single sign-on web agent on proxy web server 40 to remove any references identifying an application on BES 28, such as IP address, DNS entry and port number—so that any further requests from browser 12, to access a resource on BES 28 are addressed to single sign-on web agent on web server 40, rather than directly to BES 28. Having been suitably processed on single sign-on proxy 18, the response from BES 28 follows the return path to browser 12 via web server 40.
The conventional access system of FIG. 1 has a number of disadvantages. The performance is limited due to the inefficient authorization and communication with the back end system. The logic to authorize the request is quite complex, as identifying the application from the context in the request is complicated, requiring a lot of bespoke coding to handle the request and response when it passes through single sign-on proxy 18.
Simultaneous requests require additional threads to be created on single sign-on proxy 18. Therefore, the number of users is limited by the number of simultaneous threads the single sign-on proxy 18 can handle. The number of threads has a practical limit, as allowing a high number of threads can cause an adverse impact on the performance of the SSO proxy application server 18. The conventional access system does not support desirable features such as load balancing, support for fail-over and connection monitoring.
Certain exemplary embodiments improve upon known methods and computer networks for providing access to web applications as part of a web portal session. This is achieved, according to a first aspect, through a computer network, comprising: first and second traffic managers connected via an intermediate web server. The first traffic manager comprises interface means for receiving from the user, as part of the portal session, a request for access to the web application and for passing the request to the intermediate web server; for forwarding to the second traffic manager. The second traffic manager comprises interface means for receiving the request from the first traffic manager via the intermediate web server and for passing the received request to the web application.
The computer network advantageously achieves efficient portal session validation together with distribution of the workload between the components (i.e.: the two traffic managers and intermediate web server).
According to a second aspect, there is provided a method of validating a user as part of a web portal session. The method includes receiving from a web browser a request for access to the web application; in which the request comprises a web portal session cookie. The method includes detecting, at a first traffic manager, the web portal session cookie provided in the request and; when a web portal session cookie has been detected, checking the request for a cookie generated by the first traffic manager indicating authorization of the user to access the application. When the cookie generated by the first traffic manager is found in the request, forwarding the request via an intermediate web server to a second traffic manager; which forwards the request to the application.
According to a further aspect, on detecting a first request, the first traffic manager forwards the request to the intermediate web server for authentication and authorization, to ensure the session is valid. In order to avoid having to re-validate the session again on subsequent requests, the first traffic manager inserts special cookies in the response to the first request. These special cookies are repeated in subsequent requests issued by the same user for access to the same application in the same portal session. The presence of these special cookies in subsequent requests allows the first traffic manger to omit further validation steps.
According to a further aspect, the second traffic manager forwards the request to the application along with information provided from a database via the intermediate web server identifying the application.
According to a further aspect, the first traffic manager does not need to do any processing to ensure a session is kept alive; as this function is handled by the intermediate web server. On 1 receipt of a request from the first network traffic manager, the intermediate web server validates the portal session and keeps the portal session alive before forwarding the request.
According to a further aspect, one or more cookies generated by the application are name-spaced in which each name space corresponds to a different virtual server running on the first traffic manager. This name-spacing facilitates avoiding a clash between the names of cookies set by the back-end servers and those set by the web portal or the traffic managers.
An aspect of certain exemplary embodiments relates to a computer readable medium (e.g., a non-transitory computer readable storage medium) storing processor executable instructions for causing the methods described herein to be carried out when run on a general purpose computer.