System and method to provide a network-based service

A method of providing a network-based service can include receiving a request for a service at a proxy server, wherein the request identifies a user. The method can also include identifying an application associated with the service based on the request and identifying a user data element required by the application for the user to access the application. The method can also include creating an application request element that includes the identified data element and proxying the request to the application using the created application request element.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to communications networks, and more particularly relates to systems and methods to provide a network-based service.

BACKGROUND

An enterprise can provide various services via a network portal. Online services, for example, can enable customers to engage in self-service activities that reduce support staff for the enterprise. As the enterprise offers services to an increasing population, the enterprise may offer applications to the general public that were classically offered to a more limited set of users.

DETAILED DESCRIPTION OF THE DRAWINGS

In the description below, a flow-charted technique may be described in a series of sequential actions. The sequence of the actions and the party performing the steps may be freely changed without departing from the scope of the teachings. Actions may be added, deleted, or altered in several ways. Similarly, the actions may be re-ordered or looped. Further, although processes, methods, algorithms or the like may be described in a sequential order, such processes, methods, algorithms, or any combination thereof may be operable to be performed in alternative orders. Further, some actions within a process, method, or algorithm may be performed simultaneously during at least a point in time (e.g., actions performed in parallel), can also be performed in whole, in part, or any combination thereof.

Also, the use of “a” or “an” is employed to describe elements and components described herein. This is done merely for convenience and to give a general sense of the scope of the invention.

FIG. 1illustrates a particular embodiment of a system to provide a network-based service. The system100includes a user-based reverse proxy server (UBRP)102that communicates with an enterprise portal104. The institutional portal104is accessible to a user device106via a network, such as the Internet108or another local area or wide area network. The UBRP102also communicates with an application server, such as the application servers112and114, which can be adapted to provide legacy applications associated with a network-based service.

In a particular illustrative embodiment, the UBRP102is adapted to receive a request for a network-based service from the enterprise portal104. The UBRP102can receive the request, for example, from the user device106via the Internet108. The UBRP102can be adapted to identify an application associated with the network-based service. In one example, the request can include a user id, such as a user login string, a cookie, another identifier of the user, or any combination thereof, and the UBRP102can be adapted to identify the application based on the user id. In another embodiment, the UBRP102can be adapted to identify the application based on the requested service, the user id, other information, or any combination thereof.

The UBRP102can be adapted to retrieve a user file that includes user data elements related to a user that is associated with the request. The user file can include user data elements related to the user that is associated with the request, another user, or any combination thereof. In one example, the user file can include data elements with a header line or can be in XML format. The user file can be stored at the UBRP102, or at a data store110that is accessible to the UBRP102.

Further, the UBRP102can be adapted to retrieve an action file associated with the identified application. The action file indicates types of user data elements required for users to access the application. The action file can be stored at the UBRP102or at the data store110. The UBRP102can be adapted to identify, from the action file, a type of user data element that is required for the user associated with the request to access the application.

The UBRP102can be adapted to retrieve the required user data element from the user file and to use the required user data element to create a cookie, a URL, another proxy request element, or any combination thereof, to proxy the request to the identified application. For example, a URL required for a particular user to access the identified application can be “http://www.application1/service12/id=^SSN^,” which can be stored at the UBRP102in the action file corresponding to the identified application. The UBRP102can be adapted to retrieve a social security number value from the user file and to place the value in the SSN field of the URL. Any number of data fields can be included in the URL.

In another example, a cookie required for a particular user to access the identified application can be “COOKIE name:app1;domain:att.com;path/value=^APPID^,” which can be stored in the action file. The cookie specifies that a cookie named app1must be set to the requesting user's APPID value from the corresponding user file. The UBRP102can be adapted to retrieve the user's APPID and insert it into the cookie before transmitting the created cookie to the identified application.

The UBRP102is adapted to proxy the request for the network-based service to the identified application by sending the created proxy request element to an application server associated with the application, such as the application server112. The UBRP102can be adapted to determine whether the user is logged in to the application after proxying the request to the application and to proxy communication between the requesting device and the identified application after the user is logged in. The UBRP102can continue proxying communication between the requesting device and the identified application until the user session has ended.

In a particular embodiment, the UBRP102can be adapted to receive a request to add a user. The UBRP102can add a user data element related to the user to a user file stored at the UBRP102. Additionally, as a new application is integrated to the system100, a directory, an action file, or any combination thereof, can be created for the application at the UBRP102.

In another particular illustrative embodiment, the UBRP102can be adapted to receive a request for a network-based service from the enterprise portal104, where the request includes a URL submitted by the user device106to the enterprise portal104. The UBRP102can be adapted to examine a URL included with the request, in order to identify a requested application. For example, the URL https://www.att.com/application1 can be received with a request at the UBRP102via the enterprise portal104. The UBRP102can be adapted to identify “application1” as the requested application. Each application can have its own directory.

The UBRP102can be adapted to retrieve a user id from a cookie received with the request and to retrieve a user file based on the user id. Further, UBRP102can be adapted to open an action file associated with the requested application. The UBRP102can be adapted to identify, from the action file, a user data element that is required for the user associated with the request to access the application.

The UBRP102can be adapted to retrieve from the user file a user data element that is required for the user associated with the request to access the application. In addition, the UBRP102can be adapted to use the required user data element to create another URL including the retrieved user data element. The UBRP102can be adapted to redirect the request for the network-based service to the identified application by sending the created URL to an application server associated with the application. The UBRP102can be adapted to proxy communication between the requesting device and the application until a session ends.

In a particular embodiment, the UBRP102can be adapted to determine an access level for a user associated with the user. For instance, the user may only be allowed to access certain aspects of an application, such as particular information associated with the user, particular functions of the application that are accessible to the user (e.g., an administrator or non-administrator employee of a company), another aspect of the application, or any combination thereof. Other characteristics of a request, such as system views previously granted to the user and specific data elements required by applications can be stored at the UBRP102. The UBRP102can present these characteristics to the application with a proxied request.

In an illustrative, non-limiting embodiment, the UBRP102can include hardware, processing logic, such as a processor (not shown), memory (not shown) that includes instructions that are readable and executable by the processing logic, or any combination thereof, to perform one or more functions of the UBRP102with respect to providing a network-based service. In one example, the UBRP102can include a Java servlet.

FIG. 2illustrates a particular embodiment of a method of providing a network-based service. At block200, a UBRP receives a request for a network-based service from an enterprise portal. The request can be received, for example, from a requesting device associated with a user. Moving to block202, the UBRP identifies an application associated with the network-based service. In one example, the request can include a user id, such as a user login string, a cookie, another identifier of the user, or any combination thereof, and the UBRP can identify the application based on the user id.

Proceeding to block204, the UBRP retrieves a user file that includes user data elements related to a user that is associated with the request. Continuing to block206, the UBRP retrieves an action file associated with the identified application. The action file indicates user data elements required for users to access the application. Advancing to block208, the UBRP identifies from the action file a user data element that is required for the user associated with the request to access the application.

At block210, the UBRP uses the required user data element to create a cookie, a URL, another proxy request element, or any combination thereof. Moving to block212, the UBRP proxies the request for the network-based service to the identified application by sending the created proxy request element to an application server associated with the application. Proceeding to decision node214, the UBRP can determine whether the user is logged in to the application after proxying the request to the application. If the user is not logged in, the method can continue to block215, and the UBRP can return an error message to the requesting device via the enterprise portal.

Conversely, if the user is logged in, the method can advance to block216, and the UBRP proxies communication between the requesting device and the identified application. At decision node218, the UBRP can determine whether a user session has ended. The UBRP can continue proxying communication between the requesting device and the application until the user session has ended. The method terminates at220.

FIG. 3is a flow diagram illustrating another particular embodiment of a method of providing a network-based service. At block300, a request for a network-based service is received from an enterprise portal via a Java servlet at a UBRP. Moving to block302, the Java servlet examines a URL included with the request to identify a requested application and an access level corresponding to the user for the application. Proceeding to block304, the Java servlet retrieves a user id from a cookie received with the request. Continuing to block306, the Java servlet opens an action file associated with the requested application. Advancing to block308, the Java servlet identifies from the action file a user data element that is required for the user associated with the request to access the application.

At block310, Java servlet retrieves from the user file a user data element that is required for the user associated with the request to access the application. At block312, the Java servlet uses the required user data element to create another URL including the retrieved user data element. Moving to block314, the Java servlet redirects the request for the network-based service to the identified application by sending the created URL to an application server associated with the application. Proceeding to block316, the Java servlet proxies communication between the requesting device and the application until a session ends. The method terminates at318.

FIG. 4shows an illustrative embodiment of a general computer400including a set of instructions that can be executed to cause the computer system to perform any one or more of the methods or computer based functions disclosed herein. The computer system400may operate as a standalone device or may be connected, such as using a network, to other computer systems or peripheral devices. In an illustrative embodiment, such standalone and peripheral devices can include, for example, servers, databases, other network elements, or any combination thereof, as illustrated inFIG. 1.

The computer system400may include a processor402, such as a central processing unit (CPU), a graphics processing unit (GPU), or both. Moreover, the computer system400can include a main memory404and a static memory406that can communicate with each other via a bus408. As shown, the computer system400may further include a video display unit410, such as a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid state display, or a cathode ray tube (CRT). Additionally, the computer system400may include an input device412, such as a keyboard, and a cursor control device414, such as a mouse. The computer system400can also include a disk drive unit416, a signal generation device418, such as a speaker or remote control, and a network interface device420.

In a particular embodiment as depicted inFIG. 4, the disk drive unit416may include a computer-readable medium422in which one or more sets of instructions424, e.g. software, can be embedded. Further, the instructions424may embody one or more of the methods or logic as described herein. In a particular embodiment, the instructions424may reside completely, or at least partially, within the main memory404, the static memory406, and/or within the processor402during execution by the computer system400. The main memory404and the processor402also may include computer-readable media. The network interface device420can provide connectivity to a network426, such as a wide area network (WAN), a local area network (LAN), or other network.

The present disclosure contemplates a computer-readable medium that includes instructions424or receives and executes instructions424responsive to a propagated signal, so that a device connected to a network426can communicate voice, video or data over the network426. Further, the instructions424may be transmitted or received over the network426via the network interface device420.

In accordance with the embodiments disclosed herein, a system and method to provide a network-based service are provided. Enterprise portals can rely on legacy systems historically used internally within the enterprise. Legacy systems providing the services may be costly to modify, in terms of cost and time, in order to accommodate requests from the enterprise portal. As organizations struggle to bring more services online, a user-based reverse proxy (UBRP) can integrate applications historically considered back-end to the enterprise portal. Classic reverse proxies provide access to services uniformly, such that all users requesting a service access the service in the same manner with the same characteristics. Thus, an enterprise providing a service is often required to vary the service depending on who is making a request.

Seamlessly integrating legacy systems into an enterprise portal with a single sign-in mechanism can improve the user's experience. The enterprise portal typically does not contain data elements required for systems providing services intended for public offering, particularly systems associated with legacy applications historically offered internally. Nonetheless, in order to offer services to a wide population, additional data elements beyond those contained in the original request must often be assembled and presented to the application on behalf of the requesting user. Thus, in order to be effective, a request to an application via an enterprise portal must be combined with other knowledge, such as knowledge of what application is being requested, who is making the request, what system is receiving the request on behalf of the proxy, where the application resides, and what data elements are required to identify the user to the application.

In a particular embodiment, a user-based reverse proxy (UBRP) receives requests for services from an enterprise portal. The UBRP is an expandable, flexible, easily administrable mechanism that permits quickly bringing services online that require user data beyond that which might be housed in the enterprise portal. The UBRP can store knowledge of all supported services, each service's required data elements, a network location for each service (such as a URL for an application server), user data elements for each user, or any combination thereof. Based on a user identifier transmitted with the request for a service, the UBRP can determine the application supporting the service, gather required data element(s) for the application, and can proxy the request from the enterprise portal to the application, using the required data element(s).

In an illustrative embodiment, the UBRP can examine data made with a request in order to determine whether a user has access rights to an application and what access rights the user has. Other characteristics of a request, such as system views previously granted to the user and specific data elements required by applications can be stored at the UBRP. These characteristics can be presented to the application by the UBRP with a proxied request.

Many different aspects and embodiments are possible. Some of those aspects and embodiments are described below. After reading this specification, skilled artisans will appreciate that those aspects and embodiments are only illustrative and do not limit the scope of the present invention.

According to a first aspect, a method of providing a network-based service can include receiving a request for a service at a proxy server, where the request identifies a user. The method can also include identifying an application associated with the service based on the request and identifying a user data element required by the application for the user to access the application. The method can also include creating an application request element the includes the identified data element and proxying the request to the application using the created application request element.

In an embodiment of the first aspect, the proxy server can include a reverse proxy.

In another embodiment of the first aspect, the application request element can include a cookie, a uniform resource locator (URL), or a combination thereof, which includes the user data element. Proxying the request can include transmitting the URL, the cookie, or a combination thereof, to an application server associated with the application.

In a further embodiment of the first aspect, the method can include retrieving the user data element from a user file stored at the proxy server. The user data element can be accessible via a header of the user file, via extensible markup language (XML) data within the user file, or a combination thereof.

In another embodiment of the first aspect, identifying the required user data element can include accessing an action file associated with the application. The action file is stored at the proxy server and wherein the action file indicates that the user data element is required for the user to access the application.

In still another embodiment of the first aspect, the method can include determining an access level associated with the user before creating the application request element. The access level can indicate a portion of the application that is accessible to the user.

In yet another embodiment of the first aspect, the method can include determining whether the application has granted access to the user after proxying the request to the application and proxying communication between a requesting device associated with the user and the application after the application has granted access to the user.

In a further embodiment of the first aspect, the application can be identified based on a user id received with the request. For example, the user id is included in a cookie received with the request.

According to a second aspect, a system to provide a network-based service can include a user-based reverse proxy (UBRP) device adapted to receive a request for a service at a proxy server, where the request identifies a user. The user-based reverse proxy (UBRP) device can also be adapted to identify an application associated with the service based on the request. The user-based reverse proxy (UBRP) device can also be adapted to identify a user data element required by the application for the user to access the application. The user-based reverse proxy (UBRP) device can also be adapted to create an application request element using the identified data element and proxy the request to the application using the created application request element.

In an embodiment of the second aspect, the request for the service can be received at the UBRP device from an enterprise portal. The UBRP can be accessible to the user over the Internet via the enterprise portal.

In another embodiment of the second aspect, the UBRP can be adapted to proxy communication between a requesting device associated with the user and the application after the application has granted access to the user.

According to a third aspect, a computer-readable medium can include processor-readable instructions that are executable by a processor to perform a method. The method can include receiving a request for a service at a proxy server, where the request identifies a user. The method can also include identifying an application associated with the service based on the request and identifying a user data element required by the application for the user to access the application. The method can also include creating an application request element using the identified data element and proxying the request to the application using the created application request element.

In an embodiment of the third aspect, the method includes proxying communication between a requesting device associated with the user and the application after the application has granted access to the user.

In another embodiment of the third aspect, the processor-readable instructions comprise a Java servlet.

In another embodiment of the third aspect, the method can include receiving data indicating a new application accessible to the UBRP. The method can also include creating a directory related to the new application, creating an action file including a data element required to access the new application, or any combination thereof.

In another embodiment of the third aspect, the method can include receiving data indicating a new user data element related to the new application and adding the new user element to a user file that includes the user data element.

The above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments which fall within the true spirit and scope of the present disclosed subject matter. Thus, to the maximum extent allowed by law, the scope of the present disclosed subject matter is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description.