Patent Description:
Corporations and other entities often have a number of resources and applications that are maintained on their own private secure networks. These resources are often mission critical or have large business impact to the entity. As such these resources are protected from access through the use of authentication methods and processes. This ensures that users who wish to access them are authenticated prior to granting access to the resource.

When a user attempts to access the resource from within the secure network the resource can ensure that the user has the correct credentials to access the resource. In some instances simply being on the secure network is enough. In other cases additional authentication or pre-authentication is needed. This level of authentication can easily be handled by the resources inside the network on their own.

However, in today's world entities often want to make internal resources available to users outside of the internal network while still maintaining or even increasing the level of security required for a user to access the resource from an outside network. In order to achieve this protection the administrator of the internal network must pre-configure a gateway, such as a proxy server or firewall, with information for each resource that they wish to allow access to from the outside. This includes providing the gateway with the specific authentication requirements for the resource. A user attempting to access the resource will provide to the gateway the uniform resource locator or URL for the specific resource that they wish to access. The gateway looks for the specific URL and applies the pre-configured process to the incoming request. As each individual URL must be separately configured at the gateway the administrator is required to keep the list of resources up to date as well as the specific configurations for each resource up to date as well. This is a time consuming and burdensome process for the administrator.

Alternative solutions have been disclosed in <CIT> and in <CIT>.

The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.

The present example provides a system and method for allowing access to secure resources through a gateway without having to pre-configure the gateway with each specific URL that access is to be granted as well as maintaining the list of resources that are exposed. The gateway is configured to take incoming requests from client devices, such as the URL, and determine from the URL itself what type of authentication is required to gain access to the resource as opposed to comparing the URL with a managed list of URL's. Once the authentication process is identified by the gateway that process is implemented by for example redirecting the client to the authentication service, obtaining the authentication on behalf of the client from the authentication service (such as impersonating the service or resource), or by passing the request through to the resource. The gateway is also able to analyze the responses from there resources that may include denials from the resource to determine the authentication process to use for the user to gain access to the resource. Once the user is authenticated the communications traffic between the client/user and the resource is permitted through the gateway.

The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

When elements are referred to as being "connected" or "coupled," the elements can be directly connected or coupled together or one or more intervening elements may also be present. In contrast, when elements are referred to as being "directly connected" or "directly coupled," there are no intervening elements present.

The subject matter may be embodied as devices, systems, methods, and/or computer program products. Accordingly, some or all of the subject matter may be embodied in hardware and/or in software (including firmware, resident software, microcode, state machines, gate arrays, etc.) Furthermore, the subject matter may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

The computer-usable or computer-readable medium may be for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media.

Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and may be accessed by an instruction execution system. Note that the computer-usable or computer-readable medium can be paper or other suitable medium upon which the program is printed, as the program can be electronically captured via, for instance, optical scanning of the paper or other suitable medium, then compiled, interpreted, of otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" can be defined as a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above-mentioned should also be included within the scope of computer-readable media.

When the subject matter is embodied in the general context of computer-executable instructions, the embodiment may comprise program modules, executed by one or more systems, computers, or other devices. Generally, program modules include routines, programs, objects, components, data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.

<FIG> is a block diagram illustrating components of a security system <NUM> configured to detect automatically a scenario type for allowing traffic to pass through a gateway <NUM> such as a proxy or firewall according to one illustrative embodiment. System <NUM> includes a client device <NUM>, a gateway <NUM>, a secure resource <NUM>, a first authentication service <NUM> and a second authentication service <NUM>. In one embodiment of the system <NUM> a portion of the components are on a public or non-secure side <NUM> of the gateway <NUM> and a portion of the components are on a secure side <NUM> of the gateway <NUM>.

The secure side <NUM> of the gateway <NUM> is a network that is protected from outside access by the gateway <NUM>. Applications and documents often reside on the secure side <NUM> of the gateway <NUM> that are not intended to be accessible by the general public and may be protected by one or more authentication methods to ensure that only authorized persons are able to access the information. In one embodiment the secure side <NUM> of the gateway <NUM> represents a corporate network. Also while the terms secure side <NUM> and non-secured side are used herein, it should be noted that the secure side <NUM> could be further divided into additional levels where each level has its own gateway <NUM> separating it from the secure side <NUM>. Thus, multiple networks and gateway <NUM> may be present to control access or provide increasing levels of protection.

The non-secure side <NUM> of the gateway <NUM> is any network that has been separated from the secure side <NUM>. In one embodiment the non-secure side <NUM> is a public network such as Wi-Fi hotspot commonly found in a coffee shop or other public place. In another embodiment the non-secure side <NUM> is a home or hotel network that has devices connected to it that are not part of the secure side <NUM> of the gateway <NUM>. In another embodiment, the non-secure side <NUM> is a public cellular network with many devices connected to the network that are not authorized to access the secure side <NUM> of the gateway <NUM>. In yet another embodiment the non-secure side <NUM> of the network is a combination of different networks that all have the ability to connect to the gateway <NUM>.

The client device <NUM> is in one embodiment a portable or mobile device that is used by a user to connect back to secure components and resource <NUM> on the secure side <NUM> of the gateway <NUM> from the non-secure side <NUM> of the gateway <NUM>. Client device <NUM> can be a mobile phone, a tablet computer, a laptop computer, a desktop computer or any other computing device that can connect to a network and communicate with the gateway <NUM>. In some embodiments the client device <NUM> may be a virtual or virtualized version of the aforementioned computing devices. The client device <NUM> may include an operating system <NUM> that requires the user to provide authentication for access to the client device <NUM> or to access components of the client device <NUM>. Further, the client device <NUM> may include applications that connect to resource <NUM> on the secure side <NUM> of the gateway <NUM>. These applications can include word processing applications, spreadsheet applications, browser application or any other application that can receive data from the secure side <NUM> of the gateway <NUM> and present or consume the data on the non-secure side <NUM> of the gateway <NUM>. While only one client device <NUM> is illustrated in <FIG> it should be recognized that the present embodiments can be implemented with a plurality of devices all or some of which are connecting or attempting to connect to the secure side <NUM> through the gateway <NUM>.

The gateway <NUM> is a component of the system <NUM> that controls the flow of information between the non-secure side <NUM> and the secure side <NUM>. In one embodiment the gateway <NUM> is a proxy server. In another embodiment the gateway <NUM> is a firewall. In yet another embodiment, the gateway <NUM> is a reverse proxy such as a web application proxy. The gateway <NUM> receives requests for resource <NUM> from the client device <NUM> and functions differently based on the type of request that is received from the client device <NUM>. Upon receipt of a request from a client device <NUM> the gateway <NUM> analyzes the request to determine what type of request or scenario the request is. In one embodiment this analysis is performed by a pre-authentication rules component <NUM>. The gateway <NUM> determines, according to one illustrative embodiment, if the request is configured as a pass through request, if the request contains information in the header of the request, or if the request causes a specific response to be received back from the resource <NUM>. However, in other embodiments, depending on the scenarios supported by the gateway <NUM> other information can be used by the pre-authentication rules component <NUM> to identify the scenario associated with the request.

The pre-authentication rules component <NUM> is in one embodiment a component of the gateway <NUM> that is configured to analyze the incoming request from the client device <NUM> and determine which pre-authentication rule or procedure to apply to the request. However, in other embodiments, the pre-authentication rules component <NUM> can be a separate component or a service that the gateway <NUM> is connected with. The pre-authentication rules component <NUM> also receives communications and/or responses from the resource <NUM> that are based on the received requests. These responses from the resource <NUM> are also analyzed by the pre-authentication rules component <NUM> to determine which rules or procedures to apply to the request. The pre-authentication rules component <NUM> looks at the initial request from the client device <NUM> and determines if the request is a request for a resource <NUM> that requires pre-authentication. In some embodiments the pre-authentication rules component <NUM> can identify that the pre-authentication is required by the content of a header in the request. In these embodiments, the pre-authentication rules component <NUM> identifies in the request that a pre-authentication token or claim is required. Based on the format of the header and the location of the token or other information that describes where the token should be the rules component <NUM> access a database <NUM> or list of authentication rules and matches the token information with the rule. The associated rule is then applied to the request. Depending on the nature of the rule the rule may cause the request to be diverted to one of the authentication services either inside the secure side <NUM> of the gateway <NUM> or on the non-secure side <NUM> of the gateway <NUM>. Once the client device <NUM> has received the appropriate token for the resource <NUM> the gateway <NUM> will then allow the request to be transmitted to the resource <NUM>.

In another embodiment the pre-authentication rules component <NUM> cannot determine from the request if authentication is required by the resource <NUM>, either because the request does not indicate that authentication is required, authentication is not required, or a corresponding rule cannot be found in the database <NUM>. In this embodiment the request is simply passed on to the resource <NUM> for processing and fulfillment. However, because the resource <NUM> does require pre-authentication the resource <NUM> responds back with an error indicating that the required pre-authentication was not included with the requests. The error is received by the pre-authentication rules component <NUM> and is then compared with database <NUM> of rules to determine how the gateway <NUM> should respond. Upon finding a rule in the database <NUM> that matches the returned error, the pre-authentication rules component <NUM> provides the rule to the gateway <NUM> for the gateway <NUM> to execute. The rule may cause, in one embodiment, the gateway <NUM> to impersonate the features of the resource <NUM> to elicit responses from the client device <NUM> and perform the authentication similar to the way the resource <NUM> would perform the authentication if the gateway <NUM> were not disposed between the two. In another embodiment the rule may cause the gateway <NUM> to redirect the client device <NUM> to the appropriate authentication component to complete the authentication. Once the client device <NUM> has completed the required authentication process the gateway <NUM> processes the request to the resource <NUM> and the client device <NUM> is able to access the resource <NUM>.

Through the pre-authentication rules component <NUM> the gateway <NUM> is able to process requests from various client device <NUM> for various resource <NUM> that each implement different authentication and pre-authentication methods. The rules component <NUM> allows administrators to not worry or concern themselves with ensuring that the gateway <NUM> is configured to implement the authentication procedures for each site that the administrator has protected. The gateway <NUM> is configured to process each type of authentication method without having the specific resource <NUM> (or resource <NUM> location) pre-defined at the gateway <NUM>.

The secure resource <NUM> is in one embodiment a server, a service, an application, a web site, a document or any other resource <NUM> that an administrator or corporation desires to permit access to through the gateway <NUM> but enforces a security level on the resource <NUM>. The resource <NUM> may be protected by any protocol or method of securing a resource <NUM>. In some embodiments the resource <NUM> may not be protected on the secure side <NUM> of the gateway <NUM> for clients who are located on the secure side <NUM> as well, such as when the user accesses the resource <NUM> over a virtual private network or from an onsite location, but is protected when the user attempts to access the resource <NUM> from the non-secure side <NUM>. For example secure resource <NUM> could be a SharePoint site that is configured to provide information to certain users. The SharePoint site may require that the user present an authentication certificate to access the content. In another example the secure resource <NUM> could be an application such as an application from the Windows Store. In one embodiment this application may be protected or require OAuth <NUM> authentication in order for the user to gain access to the application on the secure side <NUM> of the gateway <NUM>. However, other authentication methods may be implemented. In another example the resource <NUM> is a site accessed through a browser that requires claims to be made from a token generated by a federated service, such as Active Directory, or an authentication protocol such as the protocols implemented by Integrated Windows Authentication.

First authentication service <NUM> is an authentication service that is located on the non-secure side <NUM> of the gateway <NUM> such that the client device <NUM> can access the service and receive from the service a token or other claim that can be presented to the gateway <NUM> and the secure resource <NUM> in order to gain access to the secure resource <NUM>. The first authentication service <NUM> can implement any security protocol or method available. The client device <NUM> can either directly interface with the first authentication service <NUM> or it can interface with the first authentication service <NUM> through the gateway <NUM>.

The second authentication service <NUM> is an authentication service that is located on the secure side <NUM> of the gateway <NUM> such that the client device <NUM> can only access the second authentication service <NUM> through the gateway <NUM>. Again similar to the first authentication service <NUM> the second authentication service <NUM> can implement any security protocol or method available. In one embodiment, the second authentication service <NUM> is an Active Directory Federated Service that provides credentials and tokens associated with the user of the client device <NUM>. The client device <NUM> accesses the second authentication service <NUM> as a result of the gateway <NUM> redirecting the client device <NUM> to the second authentication service <NUM>. Because the gateway <NUM> is disposed between the client device <NUM> and the second authentication service <NUM>, the client is not able to directly interact with the service. In this way the gateway <NUM> is able to limit access to the second authentication service <NUM> from the non-secure side <NUM>.

<FIG> is a flow diagram illustrating a process used by the gateway <NUM> in processing a request from a client device <NUM> for a secure resource <NUM> according to one illustrative embodiment. A user of the client device <NUM> begins the process by accessing an application, entering into a browser, opening a document or performing any action that requires the client device <NUM> to access a resource <NUM> on the secure side <NUM> of the gateway <NUM>. This is illustrated at step <NUM>.

This action of the user at step <NUM> causes the client device <NUM> to communicate with the gateway <NUM>. The client device <NUM> sends to the gateway <NUM> a uniform resource <NUM> locator (URL) or other message that indicates to the gateway <NUM> the specific resource <NUM> that the user of the client device <NUM> is attempting to access. This is illustrated at step <NUM>.

Upon receipt of the request from the client the gateway <NUM> analyzes the request. This is illustrated at step <NUM>. During this analysis the gateway <NUM> determines if the request includes information that indicates that the resource <NUM> is protected by an authentication mechanism that requires pre-authentication of the user. In contrast to typically system <NUM> where the gateway <NUM> looks up the URL in a database <NUM> to determine if the resource <NUM> requires authentication and what authentication is required, the gateway <NUM> analyzes the URL and determines if a portion of the URL includes a specific header that indicates that authentication is required. For example, a request may include an indication that the resource <NUM> requires or accepts a forms based authentication such as the MS-OFBA (Microsoft Office Forms Based Authentication). In another example the header may indicate that the desired resource <NUM> is an application that includes an authorization header and a bearer token, which may or may not be present in the request. However, other indications of the need for authentication may be a component of the URL.

If there is no indication in the header the gateway <NUM> passes the request to the resource <NUM>. This is illustrated at step <NUM>. The indication may not be detectable from the header for a number of reasons. For example the request may be for a resource <NUM> on the secure side <NUM> that is not protected or intentionally accessible from the outside such as if the resource <NUM> is a support document. These are commonly called pass-through resource <NUM>. In other examples the resource <NUM> may require authentication, but the gateway <NUM> is unable to know that it requires authentication or the method of authentication until the resource <NUM> has responded back to the client through the gateway <NUM>.

If the gateway <NUM> determines that the header includes the indication that authentication is required to access the resource <NUM>, the gateway <NUM> determines if the authentication token is present in the request or the associated communication. If the gateway <NUM> determines that the authentication token is present the request is passed through to the resource <NUM>. This is illustrated at step <NUM>.

If the authentication token is not present, the gateway <NUM> then accesses a database <NUM> of rules to determine how to respond to the client request. This is illustrated at step <NUM>. The gateway <NUM> may pass the request or the portion of the request to the pre-authentication rules component <NUM> which identifies the particular authentication method that is required for the resource <NUM>. The pre-authentication rules component <NUM> then provides back to the gateway <NUM> the process that is required for the identified authentication method. This is illustrated at step <NUM>.

The gateway <NUM> then takes the process that was provided by the pre-authentication rules component <NUM> and executes the provided process. This is illustrated at step <NUM>. Each authentication method has its own unique process that is executed to authenticate the user or device. In some instances the process will cause the gateway <NUM> to impersonate the resource <NUM> to gather the information required for the authentication. In other instances the gateway <NUM> will redirect the client device <NUM> to either the first authentication service <NUM> or the second authentication service <NUM> to receive the appropriate token or pre-authentication.

Once the authentication token has been received or the process completed the gateway <NUM> then completes the original request. This is illustrated at step <NUM>. This process may include merging the authentication token with the original request. Alternatively, the gateway <NUM> may provide the token back to the client device <NUM> and have the client device <NUM> resubmit the request with the authentication token included in the request. The request is then forwarded to the secure resource <NUM> and the client device <NUM> is able to interact with the resource <NUM> or consume the contents of the resource <NUM>.

If the gateway <NUM> was not able to determine if authentication was required at step <NUM> and forwarded the request to the resource <NUM> at step <NUM>, the gateway <NUM> does nothing more until such time as the resource <NUM> responds at step <NUM>. The resource <NUM> may respond to the request from the client device <NUM> by issuing an error that indicates that authentication that was required was not presented with the request. For example the resource <NUM> may respond to a request from a browser with an HTTP response of "<NUM>" or "<NUM>" indicating that the authentication was not present. In another example the resource <NUM> may respond with an HTTP response of "<NUM>" indicating that the request needs to be redirected to a different location. These are only examples of responses that could be received from the resource <NUM> indicating that authentication is required.

The gateway <NUM> consumes the error code that was received from the resource <NUM> at step <NUM> and determines if the error code or indication has a corresponding entry in the rules database <NUM>, such as the rules contained in the pre-authentication rules component <NUM>. This is illustrated at step <NUM>. If a match to the error code is found by the rules component <NUM> the process associated with that error code is provided to gateway <NUM>. This is illustrated at step <NUM>.

The gateway <NUM> then takes the process that was provided by the pre-authentication rules component <NUM> and executes the provided process. This is illustrated at step <NUM>. As each authentication method has its own unique process that is executed to authenticate the user or device. For example, in some embodiments, when the error code is "<NUM>" the process provided by the rules component <NUM> may instruct the redirection to the second authentication service <NUM>. However as the second authentication service <NUM> is located on the secure side <NUM> of the gateway <NUM>, the gateway <NUM> may impersonate the second authentication service <NUM> and present that information to the user of the client device <NUM>. In this way the client device <NUM> responds to the request to the gateway <NUM>, after which the gateway <NUM> interacts with the second authentication service <NUM> by presenting the information gathered from the client and then obtaining the correct token. In the example where the response from the resource <NUM> was "<NUM>" or "<NUM>" the rules component <NUM> may simply instruct the gateway <NUM> to direct the user to the corresponding authentication service to obtain the authentication token.

<FIG> illustrates a component diagram of a computing device according to one embodiment. The computing device <NUM> can be utilized to implement one or more computing devices, computer processes, or software modules described herein. In one example, the computing device <NUM> can be utilized to process calculations, execute instructions, receive and transmit digital signals. In another example, the computing device <NUM> can be utilized to process calculations, execute instructions, receive and transmit digital signals, receive and transmit search queries, and hypertext, compile computer code, as required by the system of the present embodiments. Further, computing device <NUM> can be a distributed computing device where components of computing device <NUM> are located on different computing devices that are connected to each other through network or other forms of connections. Additionally, computing device <NUM> can be a cloud based computing device.

The computing device <NUM> can be any general or special purpose computer now known or to become known capable of performing the steps and/or performing the functions described herein, either in software, hardware, firmware, or a combination thereof.

In its most basic configuration, computing device <NUM> typically includes at least one central processing unit (CPU) or processor <NUM> and memory <NUM>. Depending on the exact configuration and type of computing device, memory <NUM> may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. Additionally, computing device <NUM> may also have additional features/functionality. For example, computing device <NUM> may include multiple CPU's. The described methods may be executed in any manner by any processing unit in computing device <NUM>. For example, the described process may be executed by both multiple CPU's in parallel.

Computing device <NUM> may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in Figure <NUM> by storage <NUM>. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory <NUM> and storage <NUM> are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computing device <NUM>. Any such computer storage media may be part of computing device <NUM>.

Computing device <NUM> may also contain communications device(s) <NUM> that allow the device to communicate with other devices. Communications device(s) <NUM> is an example of communication media. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer-readable media as used herein includes both computer storage media and communication media. The described methods may be encoded in any computer-readable media in any form, such as data, computer-executable instructions, and the like.

Computing device <NUM> may also have input device(s) <NUM> such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) <NUM> such as a display, speakers, printer, etc. may also be included. All these devices are well known in the art and need not be discussed at length.

Claim 1:
A method for implementing an authentication mechanism at a gateway (<NUM>) comprising:
receiving a request for accessing a resource (<NUM>) from a client device (<NUM>) at the gateway (<NUM>);
analyzing, by the gateway (<NUM>), the request for accessing the resource (<NUM>) to determine if the request contains an indication that the resource (<NUM>) requires authentication;
when the indication is present in the request:
accessing, by the gateway (<NUM>), an authentication rules database (<NUM>) to identify a first authentication process associated with the indication from a plurality of different authentication processes; and
upon finding a match to the indication in the authentication rules database (<NUM>):
executing, by the gateway (<NUM>), the first authentication process associated with the indication; and
forwarding from the gateway (<NUM>) the request to the resource (<NUM>) following the execution of the first authentication process;
when the request does not include the indication that the resource (<NUM>) requires authentication or when no match to the indication has been found in the authentication rules database (<NUM>):
forwarding from the gateway (<NUM>) the request to the resource (<NUM>) without execution of the first authentication process; and
if the request is forwarded without execution of the first authentication process, while the resource (<NUM>) does require authentication:
receiving, by the gateway (<NUM>), a response from the resource (<NUM>) including an error code;
accessing, by the gateway (<NUM>), the authentication rules database (<NUM>) to identify a second authentication process, the second authentication process associated with the error code;
upon finding a match to the error code in the authentication rules database (<NUM>), executing, by the gateway (<NUM>), the second authentication process; and
forwarding from the gateway (<NUM>) the request to the resource (<NUM>) following the execution of the second authentication process;
wherein the preceding steps are performed by at least one processor.