A method and apparatus for authorizing an access requester to access a data communication network is provided. A determination is made that a threshold access control server cannot process an access request associated with the access requester. access requester history data, or data that describes the access history for an access requester, is analyzed to obtain a threshold access level. A threshold access level is an expression of how likely that a particular access requester is a legitimate access requester. A session profile is selected for the access requester based on the threshold access level. The session profile indicates one or more actions the access requester is authorized to perform in the network. The session profile may subsequently be transmitted to the access requester to allow the access requester access to the network to the extent appropriate in view of the access requester history data.
|
1. A method, comprising:
receiving, from an access requester that does not have access to a data communication network, a request to access the data communication network;
the access control server attempting to obtain assistance from an external validation server that normally handles one or more credentials used for authentication to process the request;
storing and maintaining, separate from the external validation server, access requester history data for the access requester, wherein the access requester history data comprises one or more of a location of validation of one or more prior access requests, a length of time since a last successful access request from the access requester, a length of time that an account associated with the access requester has existed, a type of credential associated with the access request, a group membership associated with the access requester, a mac address or other unique identifier associated with the access request, or a status credential that represents a security configuration of a device associated with the assess requester;
determining that an access control server cannot process the access request associated with the access requester, wherein said determining that the access control server cannot process the access request includes failing to obtain the assistance from the external validation server; and
in response to failing to obtain the assistance from the external validation server:
the access control server analyzing the access requester history data to determine a threshold access level for the access requester,
wherein the access requester history data describes a history of attempts to access resources by a set of users, wherein the set of users includes the access requester, and
wherein the threshold access level is an expression of how likely the access requester is a legitimate access requester;
the access control server selecting a session profile for the access requester based on the threshold access level for the access requester, wherein the session profile indicates one or more actions the access requester is authorized to perform in the network; and
based on the session profile, the access control server authorizing, without accessing one or more external servers to authenticate the one or more credentials that are normally handled by the one or more external servers, the access requester to perform one or more actions in the network.
23. An apparatus for authorizing an access requester to access a data communication network, comprising:
means for receiving, from an access requester that does not have access to a data communication network, a request to access the data communication network;
means for the access control server attempting to obtain assistance from an external validation server that normally handles one or more credentials used for authentication to process the request;
means for storing and maintaining, separate from the external validation server, access requester history data for the access requester, wherein the access requester history data comprises one or more of a location of validation of one or more prior access requests, a length of time since a last successful access request from the access requester, a length of time that an account associated with the access requester has existed, a type of credential associated with the access request, a group membership associated with the access requester, a mac address or other unique identifier associated with the access request, or a status credential that represents a security configuration of a device associated with the assess requester;
means for determining that an access control server cannot process the access request associated with the access requester, wherein said means for determining that the access control server cannot process the access request includes means for determining a failure to obtain the assistance from the external validation server;
means, responsive to the means for determining that the access control server cannot process the access request, for the access control server analyzing access requester history data to determine a threshold access level for the access requester,
wherein the access requester history data describes a history of attempts to access resources by a set of users, wherein the set of users includes the access requester, and
wherein the threshold access level is an expression of how likely the access requester is a legitimate access requester;
means for the access control server selecting a session profile for the access requester based on the threshold access level for the access requester, wherein the session profile indicates one or more actions the access requester is authorized to perform in the network; and
means, based on the session profile, for the access control server authorizing, without accessing one or more external servers to authenticate credentials that are normally handled by the one or more external servers, the access requester to perform one or more actions in the network.
12. An apparatus for authorizing an access requester to access a data communication network, comprising:
one or more processors; and
a machine-readable medium carrying one or more sequences of instructions, which when executed by the one or more processors, causes:
receiving, from an access requester that does not have access to a data communication network, a request to access the data communication network;
the access control server attempting to obtain assistance from an external validation server that normally handles one or more credentials used for authentication to process the request;
storing and maintaining, separate from the external validation server, access requester history data for the access requester, wherein the access requester history data comprises one or more of a location of validation of one or more prior access requests, a length of time since a last successful access request from the access requester, a length of time that an account associated with the access requester has existed, a type of credential associated with the access request, a group membership associated with the access requester, a mac address or other unique identifier associated with the access request, or a status credential that represents a security configuration of a device associated with the assess requester;
determining that an access control server cannot process the access request associated with the access requester, wherein said determining that the access control server cannot process the access request includes failing to obtain the assistance from the external validation server; and
in response to failing to obtain the assistance from the external validation server:
the access control server analyzing access requester history data to determine a threshold access level for the access requester,
wherein the access requester history data describes a history of attempts to access resources by a set of users, wherein the set of users includes the access requester, and
wherein the threshold access level is an expression of how likely the access requester is a legitimate access requester;
the access control server selecting a session profile for the access requester based on the threshold access level for the access requester, wherein the session profile indicates one or more actions the access requester is authorized to perform in the network; and
based on the session profile, the access control server authorizing, without accessing one or more external servers to authenticate credentials that are normally handled by the one or more external servers, the access requester to perform one or more actions in the network.
2. The method of
3. The method of
4. The method of
5. The method of
prior to analyzing the access requester history data, storing the access requester history data, for the access requester, at a client of the access control server.
6. The method of
prior to analyzing the analyzing access requester history data, storing the access requester history data, for the access requester, at the access control server.
7. The method of
prior to analyzing the access requester history data, storing the access requester history data for the access requester, wherein the access requester history data is imported, and wherein the access requester history data describes activity for the access requester prior to the importation.
8. The method of
9. The method of
requesting the access requester to supply additional authentication or access control information;
analyzing the additional authentication or access control information with the access requester history data to determine the threshold access level.
10. The method of
storing local accounting data that includes information about the session profile assigned to the access requester.
11. The method of
periodically querying the access control server to determine a status of the access control server until the status indicates that the access control server is able to process future access requests; and
in response to determining that the status indicates that the access control server is able to process future access requests, updating the access control server with the local accounting data.
13. The apparatus of
14. The apparatus of
15. The apparatus of
16. The apparatus of
prior to analyzing the access requester history data, storing the access requester history data, for the access requester, at a client of the access control server.
17. The apparatus of
prior to analyzing the access requester history data, storing the access requester history data, for the access requester, at the access control server.
18. The apparatus of
prior to analyzing the access requester history data, storing the access requester history data for the access requester, wherein the access requester history data is imported, and wherein the access requester history data describes activity for the access requester prior to the importation.
19. The apparatus of
20. The apparatus of
requesting the access requester to supply additional authentication or access control information;
analyzing the additional authentication or access control information with the access requester history data to determine the threshold access level.
21. The apparatus of
storing local accounting data that includes information about the session profile assigned to the access requester.
22. The apparatus of
periodically querying the access control server to determine a status of the access control server until the status indicates that the access control server is able to process future access requests; and
in response to determining that the status indicates that the access control server is able to process future access requests, updating the access control server with the local accounting data.
24. The apparatus of
25. The apparatus of
26. The apparatus of
27. The apparatus of
means for, prior to analyzing the access requester history data, storing the access requester history data, for the access requester, at a client of the access control server.
28. The apparatus of
means for, prior to analyzing the access requester history data, storing the access requester history data, for the access requester, at the access control server.
29. The apparatus of
means for, prior to analyzing the access requester history data, storing the access requester history data for the access requester, wherein the access requester history data is imported, and wherein the access requester history data describes activity for the access requester prior to the importation.
30. The apparatus of
31. The apparatus of
means for requesting the access requester to supply additional authentication or access control information; and
means for analyzing the additional authentication or access control information with the access requester history data to determine the threshold access level.
32. The apparatus of
means for storing local accounting data that includes information about the session profile assigned to the access requester.
33. The apparatus of
means for periodically querying the access control server to determine a status of the access control server until the status indicates that the access control server is able to process future access requests; and
in response to determining that the status indicates that the access control server is able to process future access requests, updating the access control server with the local accounting data.
|
|||||||||||||||||||||||||
The present invention generally relates to providing access to requesters of network resources. The invention more particularly relates to providing threshold network access to requesters of network resources based upon historical analysis of stored credentials.
Access control servers, as broadly used herein, provide the ability to block illegitimate access requests for computer network resources, while providing legitimate requesters the appropriate access to network resources. Access control servers may respond to access requests from users, devices (such as routers, firewalls, access points, and dial gateways) and processes that request access to network resources. As broadly used herein, the term ‘access requester’ shall be used to describe any entity that issues an access request that may be serviced by an access control server. As broadly used herein, the term ‘access request’ shall be used to describe any request for a network resource, including a user transit session or a request to perform administration changes to a device. An access request may span several discrete network connections, devices, software servers, and in general, must be available and operational for a successful access request. A commercial example of an access server is Cisco Secure Access Control Server 3.0, available from Cisco Systems, Inc. of San Jose, Calif.
Access control servers perform authentication, authorization, and accounting for access requesters. Initially, in processing an access request, an access control server authenticates the access request. Authentication is the validation of credentials presented by the access requester. Next, the access control server typically authorizes the access requester. Authorization is the determination of what actions the access requester is permitted to perform. After an access requester has been authorized, an access control server may transmit information, called a session profile, which provisions various network session attributes and indicates the set of allowable actions that the access requester may perform. Examples of session profile attributes include rate limiting and quota restrictions, MPLS and VRF tunneling, VLAN and SSID segmentations, security and dynamic Access Control Lists (ACLs), security settings for IPSec or SSL tunnel establishment, and QOS parameters. Thereafter, the access control server performs accounting functionality for the access requester. Accounting is the creating and storing of records that describe what actions the access requester has performed.
In authenticating access requesters, access control servers may use a variety of different types of credentials. As used herein, a credential is any evidence that may be used by an access control server to accurately identify the identity or status of the access requester associated with the credential. A credential may be, although it need not be, a set of information stored electronically. A credential may include, e.g., a usernames and password combination, a single-use token password that is uniquely generated every minute, public and private keys as used in public key encryption, etc. An access control server may also perform authentication using a biometric credential, which is evidence that identifies a set of personally unique physical characteristics for a person, such as a fingerprint, a voice pattern, or a retinal scan.
In performing authentication, the access control server may either validate the requester's credentials locally, or the access control server may consult one or more external entities (“an external validation server”) to assist in the authentication of the access requester's credentials. For example, a particular access control server may consult with an external validation server to validate a person's username and password combination. An LDAP directory server or similar repository is an example of an external validation server.
Additionally, even if the access control server performs authentication locally, in the authentication step the access control server may consult one or more external validation servers in the performance of additional access or security functionality, e.g., to perform a determination that the access request from the access requester does not contain any computer viruses. In this fashion, even if the access requester's credentials are authenticated locally to the access control server, the access control server may still need to reach one or more external validation servers to authenticate the access requester.
Unfortunately, however, occasionally the external validation server may become inaccessible to the access control server. The external validation server may become inaccessible for a variety of reasons, e.g., problems with the external validation server or the network connection between the external validation server and the access control server. When the external validation server becomes inaccessible, then the access control server is unable to authenticate any credentials normally handled by the inaccessible external validation server. As the access control server is unable to authenticate the access requester's credentials, the access control server must deny access to the access requester. This is undesirable and can be a source of user frustration and unnecessary network downtime.
Similarly, occasionally the access control server itself may become inaccessible to a client of the access control server. The access control server may become inaccessible for a variety of reasons, e.g., problems with the access control server or the network connection between the access control server and the client. As the access control server is unable to authenticate the access requester's credentials, the access requester associated with the client is unable to gain access to the desired network resources because the access control server was unable to provide the required session profile to the client.
If an access requester's request is denied, the access requester is typically completely denied access; in other words, since the access control server may respond to an access request only by either completely granting the desired access or completely denying the access request, any problem the access control server encounters that prevents the granting of the access request results in complete denial of the access request.
Some access control servers, however, may issue “guest status” to certain access requesters, instead of completely denying their access request when problems reaching an external validation server arise, by providing the access requester with a default session profile that allows the access requester to access a scope of network resources commensurate with a “guest.” However, this is far from a satisfactory solution, because the scope of the access to network resources afforded to guests is traditionally relatively small and restricted to non-essential network resources, otherwise the security of the network may be compromised. Restricting the scope of access afforded to guests is necessary to maintain control over who is accessing network resources. As a result, if a legitimate access requester is denied access and merely granted guest status, typically the access requester is prohibited from performing the tasks on the network that the legitimate access requester would like to perform.
To avoid the undesirable implications of denying access to legitimate access requesters, some access control servers may use a form of caching. When either the access control server or a required external validation server is inaccessible, a session profile that is stored in a cache at the client of the access control server (when the access control server is inaccessible) or stored in the cache at the access control server (when a required external validation server is inaccessible) may be used.
This approach of using a simple cache to supply the session profile is problematic because caches, by their very nature, are not as secure as a centralized access control server, which may be deployed securely within the network. Additionally, the distribution of valid session profiles to a variety of locations increases the security risk to the network because control over the session profiles is decreased. Any latency between the removal of user account access provided by the access control server and the removal of access in each of the distributed caches raises an additional security risk that illegitimate access can be obtained. Moreover, blind reliance on the existence of a session profile in a cache may introduce unacceptable risk to the security of the network.
Since denying access to legitimate access requesters is clearly an undesirable result, it is desirable to improve the ability of an access control server to grant access to legitimate access requesters in balance with the concern of preventing illegitimate access requesters entry to the network and access to network resources. Currently, however, there is no effective mechanism for doing so.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
A method and apparatus for authorizing a user to access a data communication network is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
Various aspects of the invention are described hereinafter in the following sections:
I. Architecture Overview
II. Functional Overview
III. Authorizing an Access Requester Using Threshold Access
IV. Implementing Mechanisms
I. Architecture Overview
Threshold access control server 110 is any access control server capable of performing the functional steps illustrated in
Client 120 is any functional component capable of issuing an access request to threshold access control server 110. For example, client 120 may be an access router, firewall, PC, workstation, etc. A client 120 may be implemented in hardware or software, and client 120 may service one or more other clients. While only one client 120 is shown in
One or more access requesters may be associated with client 120. For example, if client 120 is embodied in a web browser, then multiple individuals may use the web browser to issue access requests. Client 120 may also, itself, be an access requestor. For example, if client 120 is a computerized device configured to request access, then client 120 is also the access requester. For ease of explanation in the following description, a single access requester shall be assumed to be associated with client 120, wherein the access requester issues an access request through client 120 to threshold access control server 110.
External Validation Server 130 is any server that is accessible by threshold access control server 110, and assists threshold access control server 110 in validation of credentials or in performance of access or security functionality. For example, external validation server 130A may be configured to assist threshold access control server 110 with the validation of credentials, external validation server 130B may be configured to assist threshold access control server 110 by verifying that an access requester has installed or is using a virus checker, and external validation server 130C may be configured to assist threshold access control server 110 by verifying that an access request originates from a legitimate client 120. While external validations server 130A, 130B are shown in
Communication links 140-143 may be implemented by any medium or mechanism that provides for the exchange of data between threshold access control server 110, client 120, and external validation server 130A-C. Examples of communications links 140-143 include, without limitation, a network such as a Local Area Network (LAN), Wide Area Network (WAN), Ethernet or the Internet, or one or more terrestrial, satellite or wireless links. Communication links 140-143 may employ a variety of authentication protocols, such as, e.g., PAP, RADIUS, LDAP, CHAP, and NIS.
II. Functional Overview
In step 202, a determination is made that the threshold access control server cannot process an access request associated with the access requester. For example, the determination of block 202 may occur when the external validation server is unavailable or unreachable. As a result, the threshold access control server attempts an alternative processing approach. In step 204, access requester history data is analyzed to determine a threshold access level. Access requestor history data may comprise data stored by the threshold access control server and relating to prior successful accesses of the same access requestor to the same or similar network resources. In step 206, a session profile is selected for the access requester based on the threshold access level. The session profile indicates one or more actions the access requester is authorized to perform in the network. The session profile may be stored in any appropriate repository with other profiles.
III. Authorizing an Access Requester Using Threshold Access
Authorizing an access requester using threshold access is now described in further detail with reference to flow-chart 300 of
In step 310, access requester history data is stored and maintained. Access requester history data is data that describes the access history for an access requester. For example, each access requester of threshold access control server 110 may have a unique set of access requester history data 146 that describes prior access actions for that particular access requester. Access requester history data 146 may be stored in a non-volatile storage medium at threshold access control server 110, as depicted in
Access requester history data may include any type of information that describes the access history for an access requester. For example, access requester history data may include, although it need not include, information about one or more of the following:
Access requester history data may be recorded in real time contemporaneously with the occurrence of the activity by the access requester.
An administrator of threshold access control system 100 may employ an access requester history data manager 148 to manage the access requester history data. In an embodiment, the access requester history data manager 148 provides an interface through which the administrator may perform functions of managing the access requester history data 146, viewing the access requester history data, purging and/or deleting access requester history data, importing access requester history data, replicating access requester history data, and achieving the access requester history data. Access requester history data manager 148 is located locally to the access request history data 146; consequently, access requester history data manager 148 may be located at threshold access control server 110, as depicted in
The administrator may use the access requester history data manager 148 to import access requester history data 146 to the location where it is being stored. The imported access requester history data may describe activity for the access requester prior to the importation. In this fashion, the administrator may create any desired state of access requester history data for an access requester without requiring the access requester to perform the particular set of activities described in the imported access requester history data. For example, if the access requester is a newly hired CEO of a company, the administrator may configure the CEO's access requester history data 146 to indicate a high level of trust, even if activities described in the access requester history data 146 that give rise to the high level of trust never occurred. Thus, access requester history data 146 may include one or more synthetic records.
The administrator may also use the access requester history data manager 148 to access and configure configuration data that describes the operation of the access requester history data manager. In particular, the administrator may configure the access requester history data manager 148, using the configuration data, to perform functionality according to the rules or instructions configured in the configuration data. In such a way, the administrator may configure the configuration data such that the access requester history data manager 148 may perform scheduled tasks, e.g., periodic purging of access requester history data or periodic archival of the access requester history data 146, or to establish TTL (time to live parameters) for any particular element of the access requester history file 146.
In step 320, in response to determining that threshold access control server 110 or external validation server 130 is unable to process an access request from an access requester, access requester history data 146 is retrieved. External validation server 130 may be unable to process an access request for a variety of reasons, e.g., a problem with processing the access request arising internally to access control server 110. Threshold access control server 110 may be unable to process an access request for a variety of reasons, e.g., a problem with processing the access request arising internally to access control server 110 or a problem with an external validation server 130 that is required to assist threshold access control server 110 in processing the access request.
While access requester history data may be stored for many access requesters, only the access requester history data for the access requester whose access request is unable to be processed is retrieved in step 320.
In steps 330, the retrieved access requester history data 146 is analyzed to obtain a threshold access level for the access requester. A threshold access level is an expression of how likely that a particular access requester is a legitimate access requester. A threshold access level may be based upon the business and security policies of threshold access control server 110. Embodiments of the invention may employ threshold access levels that not only express how likely that a particular access requester is a legitimate access requester, but more particularly express how likely that the alleged identity of a particular access requester is the correct identity of the particular access requester. The analysis performed in determining the threshold access level includes considering how likely the access request is from the purported access requester based upon the access requester history data.
Threshold filters may be used to consider any number of configurable rules used to interpret access requester history data. For example, in step 404A, a threshold filter may consider how many previous successful access requests are described by the access requester history data. In such a case, an access requester may obtain a threshold access level with a greater degree of trust if the access requester has had a long history of successful access requests. Further, a threshold filter may detect variances from an established pattern of access. For example, in step 404B, if the access requester history data indicates that the access requester has always requested access only during the daytime on Monday-Friday, then an access requester may obtain a threshold access level with a lesser degree of trust if the access requester issues the access request during the weekend or at night. In step 404C, additional business logic may be applied using one or more threshold filters, e.g., threshold access level with a greater degree of trust may be obtained for an access requester who has previously successfully obtained access using a smart card or biometric credential, because those types of credentials are more difficult to forge than a username/password credential. Steps 404A, 404B, and 404C are non-limiting examples of a threshold filter that may be applied. Accordingly, the one or more threshold filters applied to the access requester history data 146 may include any number of steps 404A, 404B, and 404C, as well as any other potential threshold filter.
The threshold filters that are applied to the access requester history data in obtaining a threshold access level may be arbitrarily complex in their operation and number. For example, a particular threshold filter may determine the threshold access level, or the particular threshold filter may merely add a configurable amount of weight towards the level of trust expressed by the threshold access level.
In an embodiment wherein threshold filters add a configurable amount of weight towards the level of trust expressed by the threshold access level, the application of a particular threshold filter may yield a certain weighted score value, which may be positive or negative, after analyzing the access requester history data, such as illustrated in steps 406A and 406B. In step 408, the threshold access level is calculated by blending all the values associated with each threshold filters. Other embodiments may use similar weighted factors to measure the result of applying the threshold filters to the access requester history data to obtain the threshold access level.
In step 410, additional information may be considered in determining the threshold access level. In an embodiment, as part of access requestor history data evaluation performed in step 330 the access requester may be queried in real time to supply additional information for use in determining the threshold access level. The additional information obtained from the access requester may be directed towards any subject that would assist the process of determining the threshold access level, including information directed towards authentication or access control. Such an embodiment may be advantageous when analyzing the access requester history data does not yield a threshold access level with sufficient clarity or confidence. For example, an access requester may be queried for additional information, such as his or her mother's maiden name, or other identifying information or credentials known to the access requester but not to the general public. One or more threshold filters may be used to analyze the additional information, along with the access requester history data, to determine the threshold access level.
Once a threshold access level is determined, in step 332, a session profile is selected based on the threshold access level. A session profile is a profile associated with an access requester that indicates one or more actions that the access requester is authorized to perform in the network. For example, a session profile may provision any number of parameters of a particular network session. The session profile provides threshold access to the access requester in accordance with the access requester's past behavior. Selection in step 332 may involve a table lookup or mapping, e.g., the access requester has threshold access level 22, which corresponds to the network session attributes of VLAN 10, ACL Marketing, and a session length of 2 hours.
The session profile may limit the access requester's action on the network to an extent commensurate with the access requester history data. The session profile may limit the access granted to the access requester based upon the level of trust afforded to the access requester expressed in the threshold access level. For example, the session profile may provide a more limited access connection to the access requester such that access is only granted for a period of minutes or hours, only certain network resources are available to the access requester, quota and/or rate limiting restrictions are provided to limit network resource consumption by the access requester, and a limited service connection is provided using Quality of Service (QOS) when using a session profile based upon a threshold access level.
In an embodiment, the session profile is selection by mapping the threshold access level to obtain the session profile for the access requester. For example, the threshold access level may be mapped to a table of session profiles to determine the session profile. A set of threshold access levels may map to the same session profile.
Once the session profile is selected, the session profile may be transmitted or made available to client 120 associated with the access requester. For example, the session profile may be transmitted over communication link 140 to client 120 if the session profile is determined in step 320 at threshold access server 110. Once the session profile is received by client 120, the access requester is authorized to perform any action authorized by the session profile.
In step 340, local accounting is performed. Local accounting involves recording information about the activity performed by the access requester, such as, e.g., the session profile assigned to the access requester in step 330, information about any unsuccessful access requests made by the access requester, and information about network resources accessed by the access requester. Thus, the local accounting of step 340 may record information about the activity of an access requester prior to any successful access request, as well as information about the activity of an access requester during and subsequent to any successful access request. The information about the activity performed by the access requester that is recorded in step 340 is called local accounting data.
Local accounting may be performed at any level of granularity. In an embodiment, local accounting data is collected and stored at a level of granularity commensurate with the level of granularity of the access requester history data. The local accounting of step 340 is performed locally to the access requester history data 146; consequently, local accounting may be performed at threshold access control server 110 or at client 120. Additionally, local accounting information may also be stored in access requester history data, thereby affecting future decisions based on the access requester history data.
In step 350, external validation server 130 or threshold access control server 110 is periodically queried to determine the status of external validation server 130 or threshold access control server 110, i.e., whether external validation server 130 or threshold access control server 110 is able or unable to process an access request from an access requester. The component (external validation server 130 or threshold access control server 110) queried in step 350 is the same component that was unable to process an access request in step 320. The amount of time between queries to external validation server 130 or threshold access control server 110 to determine its status may be configurable. The purpose of such queries is to enable threshold access control server 110 to being processing access requests using external validation servers as soon as possible if external validation server 130 was unable to process an access request in step 320, or to enable client 120 to successfully process an access request using threshold access control server 110 as soon as possible if threshold access control server 110 was unable to process an access request in step 320.
In step 360, local accounting data is updated. Specifically, (a) in response to determining that external validation server 130 is able to process an access request from an access requester, external validation server 130 is updated with the local accounting data, and (b) in response to determining that threshold access control server 110 is able to process an access request from an access requester, threshold access control server 110 is updated with the local accounting data. The determination that external validation server 130 or threshold access control server 110 is able to process an access request from an access requester may be based upon the status of external validation server 130 obtained in step 350A.
The functional steps described according to the embodiment depicted in flow-chart 300 have been described sequentially, but other embodiments may perform the steps described in flow-chart 300 in a different order, or in parallel with one another. Other steps described with reference to flow-chart 300 may be performed continuously. For example, steps 310, 340 and 350 each may be done over a continuous period in parallel with one another. Accordingly, embodiments are not limited any particular order of the functional steps illustrated in flow-chart 300.
IV. Implementation Mechanisms
Computer system 500 may be coupled via bus 502 to a display 512, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 514, including alphanumeric and other keys, is coupled to bus 502 for communicating information and command selections to processor 504. Another type of user input device is cursor control 516, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 504 and for controlling cursor movement on display 512. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
The invention is related to the use of computer system 500 for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506. Such instructions may be read into main memory 506 from another computer-readable medium, such as storage device 510. Execution of the sequences of instructions contained in main memory 506 causes processor 504 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 504 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 510. Volatile media includes dynamic memory, such as main memory 506. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 502. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 504 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 500 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 502. Bus 502 carries the data to main memory 506, from which processor 504 retrieves and executes the instructions. The instructions received by main memory 506 may optionally be stored on storage device 510 either before or after execution by processor 504.
Computer system 500 also includes a communication interface 518 coupled to bus 502. Communication interface 518 provides a two-way data communication coupling to a network link 520 that is connected to a local network 522. For example, communication interface 518 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 518 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 518 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 520 typically provides data communication through one or more networks to other data devices. For example, network link 520 may provide a connection through local network 522 to a host computer 524 or to data equipment operated by an Internet Service Provider (ISP) 526. ISP 526 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 528. Local network 522 and Internet 528 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 520 and through communication interface 518, which carry the digital data to and from computer system 500, are exemplary forms of carrier waves transporting the information.
Computer system 500 can send messages and receive data, including program code, through the network(s), network link 520 and communication interface 518. In the Internet example, a server 530 might transmit a requested code for an application program through Internet 528, ISP 526, local network 522 and communication interface 518. The received code may be executed by processor 504 as it is received, and/or stored in storage device 510, or other non-volatile storage for later execution. In this manner, computer system 500 may obtain application code in the form of a carrier wave.
In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
| Patent | Priority | Assignee | Title |
| 10073984, | Aug 02 2011 | API MARKET, INC | Rights based system |
| 10142114, | Feb 15 2006 | NEC Corporation | ID system and program, and ID method |
| 10149126, | Jul 12 2006 | AT&T Intellectual Property I, L.P. | Pico-cell extension for cellular network |
| 10192234, | Nov 15 2006 | API MARKET, INC | Title materials embedded within media formats and related applications |
| 10198719, | Dec 29 2005 | API MARKET, INC | Software, systems, and methods for processing digital bearer instruments |
| 10225733, | May 13 2008 | AT&T MOBILITY II LLC | Exchange of access control lists to manage femto cell coverage |
| 10230711, | Aug 08 2016 | MasterCard International Incorporated | System and methods for enhancing authentication procedures in an anti-fraud environment |
| 10255429, | Oct 03 2014 | WELLS FARGO BANK, N A | Setting an authorization level at enrollment |
| 10311432, | Oct 01 2014 | Wells Fargo Bank, N.A. | Intelligent authentication |
| 10313335, | Dec 28 2007 | PAYPAL, INC. | Server and/or client device authentication |
| 10313353, | Oct 13 2014 | ADVANCED NEW TECHNOLOGIES CO , LTD | Method, device, terminal, and server for verifying security of service operation |
| 10380621, | Nov 15 2006 | API MARKET, INC | Title-acceptance and processing architecture |
| 10467606, | Apr 29 2006 | API MARKET, INC | Enhanced title processing arrangement |
| 10499247, | May 13 2008 | AT&T MOBILITY II LLC | Administration of access lists for femtocell service |
| 10645582, | Oct 15 2009 | AT&T Intellectual Property I, L.P. | Management of access to service in an access point |
| 10679211, | Oct 01 2014 | Wells Fargo Bank, N.A. | Intelligent authentication |
| 10706168, | Aug 02 2011 | API Market, Inc. | Rights-based system |
| 10999094, | Apr 29 2006 | API MARKET, INC | Title-enabled networking |
| 11064090, | Mar 02 2006 | Ricoh Company, Ltd. | Management apparatus, image forming apparatus management system for managing usage of the image forming apparatus |
| 11240231, | Dec 28 2007 | PAYPAL, INC. | Server and/or client device authentication |
| 11256794, | Feb 03 2019 | FMR LLC | Systems and methods for securely authenticating a caller over a voice channel |
| 11348102, | Oct 01 2014 | Wells Fargo Bank, N.A. | Intelligent authentication |
| 11423137, | Oct 03 2014 | Wells Fargo Bank, N.A. | Setting an authorization level at enrollment |
| 11494801, | Nov 15 2006 | API Market, Inc. | Methods and medium for title materials embedded within media formats and related applications |
| 11599657, | Aug 02 2011 | API Market, Inc. | Rights-based system |
| 11855985, | Jun 28 2018 | CALLFIRE, INC. | Protected user information verification system |
| 11863579, | Mar 20 2012 | United Services Automobile Association (USAA) | Dynamic risk engine |
| 11875349, | Jun 22 2018 | MasterCard International Incorporated | Systems and methods for authenticating online users with an access control server |
| 7912787, | Dec 10 2007 | Fujitsu Limited | Information processing apparatus and license distribution system |
| 8140853, | Jul 01 2008 | TAASERA LICENSING LLC | Mutually excluded security managers |
| 8326296, | Jul 12 2006 | AT&T Intellectual Property I, L.P.; Bellsouth Intellectual Property Corporation | Pico-cell extension for cellular network |
| 8331228, | May 13 2008 | AT&T MOBILITY II LLC | Exchange of access control lists to manage femto cell coverage |
| 8424057, | Dec 28 2007 | PayPal, Inc | Mobile anti-phishing |
| 8463296, | May 13 2008 | AT&T MOBILITY II LLC | Location-based services in a femtocell network |
| 8490156, | May 13 2008 | AT&T MOBILITY II LLC | Interface for access management of FEMTO cell coverage |
| 8504032, | Jun 12 2008 | AT&T Intellectual Property I, L P | Femtocell service registration, activation, and provisioning |
| 8510801, | Oct 15 2009 | AT&T Intellectual Property I, L.P. | Management of access to service in an access point |
| 8522312, | May 13 2008 | AT&T MOBILITY II LLC | Access control lists and profiles to manage femto cell coverage |
| 8571992, | May 15 2002 | API MARKET, INC | Methods and apparatus for title structure and management |
| 8626223, | May 07 2008 | AT&T MOBILITY II LLC; Microsoft Corporation | Femto cell signaling gating |
| 8650550, | Jun 07 2011 | Malikie Innovations Limited | Methods and devices for controlling access to computing resources |
| 8655361, | Jun 12 2008 | AT&T MOBILITY II LLC; AT&T Intellectual Property I, L.P. | Femtocell service registration, activation, and provisioning |
| 8656459, | Dec 28 2007 | PayPal, Inc | Mobile anti-phishing |
| 8719420, | May 13 2008 | AT&T MOBILITY II LLC | Administration of access lists for femtocell service |
| 8738457, | May 15 2002 | API MARKET, INC | Methods of facilitating merchant transactions using a computerized system including a set of titles |
| 8743776, | Jun 12 2008 | AT&T MOBILITY II LLC; AT&T Intellectual Property I, L P | Point of sales and customer support for femtocell service and equipment |
| 8755820, | May 13 2008 | AT&T MOBILITY II LLC | Location-based services in a femtocell network |
| 8763080, | Jun 07 2011 | Malikie Innovations Limited | Method and devices for managing permission requests to allow access to a computing resource |
| 8763082, | May 13 2008 | AT&T MOBILITY II LLC | Interactive client management of an access control list |
| 8769272, | Apr 02 2008 | Protegrity Corporation | Differential encryption utilizing trust modes |
| 8787342, | May 13 2008 | AT&T MOBILITY II LLC | Intra-premises content and equipment management in a femtocell network |
| 8812049, | May 07 2008 | AT&T MOBILITY II LLC | Femto cell signaling gating |
| 8850048, | May 13 2008 | AT&T MOBILITY II LLC | Reciprocal addition of attribute fields in access control lists and profiles for femto cell coverage management |
| 8856878, | Oct 15 2009 | AT&T Intellectual Property I, L.P | Management of access to service in an access point |
| 8863235, | May 13 2008 | AT&T MOBILITY II LLC | Time-dependent white list generation |
| 8897752, | Jul 12 2006 | AT&T Intellectual Property I, L.P. | Pico-cell extension for cellular network |
| 8904496, | Mar 30 2012 | EMC IP HOLDING COMPANY LLC | Authentication based on a current location of a communications device associated with an entity |
| 8942180, | Jun 12 2008 | AT&T MOBILITY II LLC; AT&T Intellectual Property I, L.P. | Point of sales and customer support for femtocell service and equipment |
| 9019819, | May 13 2008 | AT&T MOBILITY II LLC | Exchange of access control lists to manage femto cell coverage |
| 9043883, | Dec 13 2004 | Meta Platforms, Inc | Secure authentication advertisement protocol |
| 9053337, | Jun 07 2011 | Malikie Innovations Limited | Methods and devices for controlling access to a computing resource by applications executable on a computing device |
| 9094891, | May 13 2008 | AT&T MOBILITY II LLC | Location-based services in a femtocell network |
| 9112705, | Feb 15 2006 | NEC Corporation | ID system and program, and ID method |
| 9112866, | Jun 07 2011 | Malikie Innovations Limited | Methods and devices for controlling access to computing resources |
| 9155022, | May 13 2008 | AT&T MOBILITY II LLC | Interface for access management of FEMTO cell coverage |
| 9177338, | Dec 29 2005 | API MARKET, INC | Software, systems, and methods for processing digital bearer instruments |
| 9197634, | Dec 28 2007 | PayPal, Inc | Server and/or client device authentication |
| 9246759, | Jun 12 2008 | AT&T MOBILITY II LLC; AT&T Intellectual Property I, L.P. | Point of sales and customer support for femtocell service and equipment |
| 9253636, | Aug 15 2012 | Cisco Technology, Inc.; Cisco Technology, Inc | Wireless roaming and authentication |
| 9301113, | Jul 12 2006 | AT&T Intellectual Property I, L.P. | Pico-cell extension for cellular network |
| 9319964, | May 13 2008 | AT&T MOBILITY II LLC | Exchange of access control lists to manage femto cell coverage |
| 9336324, | Nov 01 2011 | Microsoft Technology Licensing, LLC | Intelligent caching for security trimming |
| 9369876, | May 13 2008 | AT&T MOBILITY II LLC | Location-based services in a femtocell network |
| 9392461, | May 13 2008 | AT&T MOBILITY II LLC | Access control lists and profiles to manage femto cell coverage |
| 9503457, | May 13 2008 | AT&T MOBILITY II LLC | Administration of access lists for femtocell service |
| 9509701, | Oct 15 2009 | AT&T Intellectual Property I, L.P. | Management of access to service in an access point |
| 9509704, | Aug 02 2011 | API MARKET, INC | Rights-based system |
| 9538383, | May 13 2008 | AT&T MOBILITY II LLC | Interface for access management of femto cell coverage |
| 9584984, | May 13 2008 | AT&T MOBILITY II LLC | Reciprocal addition of attribute fields in access control lists and profiles for femto cell coverage management |
| 9591486, | May 13 2008 | AT&T MOBILITY II LLC | Intra-premises content and equipment management in a femtocell network |
| 9621372, | Apr 29 2006 | API MARKET, INC | Title-enabled networking |
| 9674679, | Jul 12 2006 | AT&T Intellectual Property I, L.P. | Pico-cell extension for cellular network |
| 9763101, | Feb 10 2012 | Apple Inc. | Methods and apparatus for correcting error events associated with identity provisioning |
| 9775036, | May 13 2008 | AT&T MOBILITY II LLC | Access control lists and profiles to manage femto cell coverage |
| 9775037, | May 13 2008 | AT&T MOBILITY II LLC | Intra-premises content and equipment management in a femtocell network |
| 9860244, | Dec 28 2007 | PAYPAL, INC. | Server and/or client device authentication |
| 9877195, | May 13 2008 | AT&T MOBILITY II LLC | Location-based services in a femtocell network |
| 9930526, | May 13 2008 | AT&T MOBILITY II LLC | Interface for access management of femto cell coverage |
| Patent | Priority | Assignee | Title |
| 6070244, | Nov 10 1997 | JPMORGAN CHASE BANK, N A | Computer network security management system |
| 6141778, | Jun 29 1998 | Verizon Patent and Licensing Inc | Method and apparatus for automating security functions in a computer system |
| 6189104, | Aug 01 1996 | Harris Corporation | Integrated network security access control system |
| 6314425, | Apr 07 1999 | Microsoft Technology Licensing, LLC | Apparatus and methods for use of access tokens in an internet document management system |
| 6487600, | Sep 12 1998 | Xylon LLC | System and method for supporting multimedia communications upon a dynamically configured member network |
| 6611881, | Mar 15 2000 | Personal Data Network Corporation | Method and system of providing credit card user with barcode purchase data and recommendation automatically on their personal computer |
| 6823401, | Jan 15 2003 | Hewlett Packard Enterprise Development LP | Monitor for obtaining device state by intelligent sampling |
| 6986161, | Aug 12 2002 | STINGRAY IP SOLUTIONS LLC | Mobile ad-hoc network with intrusion detection features and related methods |
| 7032241, | Feb 22 2000 | Microsoft Technology Licensing, LLC | Methods and systems for accessing networks, methods and systems for accessing the internet |
| 7243369, | Aug 06 2001 | Oracle America, Inc | Uniform resource locator access management and control system and method |
| 20030154406, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Apr 01 2003 | STIEGLITZ, JEREMY | Cisco Technology, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 013941 | /0301 | |
| Apr 02 2003 | Cisco Technology, Inc. | (assignment on the face of the patent) | / |
| Date | Maintenance Fee Events |
| Mar 18 2013 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| May 03 2017 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Apr 26 2021 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
| Date | Maintenance Schedule |
| Nov 03 2012 | 4 years fee payment window open |
| May 03 2013 | 6 months grace period start (w surcharge) |
| Nov 03 2013 | patent expiry (for year 4) |
| Nov 03 2015 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Nov 03 2016 | 8 years fee payment window open |
| May 03 2017 | 6 months grace period start (w surcharge) |
| Nov 03 2017 | patent expiry (for year 8) |
| Nov 03 2019 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Nov 03 2020 | 12 years fee payment window open |
| May 03 2021 | 6 months grace period start (w surcharge) |
| Nov 03 2021 | patent expiry (for year 12) |
| Nov 03 2023 | 2 years to revive unintentionally abandoned end. (for year 12) |