Patent Application
20180295126
Aspects of the disclosure are related to the field of access control in computing environments and, in particular, dynamically authorizing access to resources in a computing environment.
Cloud computing systems and the like can use virtualized computer systems and other computing resources to provide flexible computing to end users. Cloud computing systems allow for users spread over a variety of geographic locations to access resources of such virtualized and other computer systems, such as databases, applications, web content, or other digital data, services, or content. Cloud Service Providers (CSPs) such as Amazon, Google, Rackspace, and OpenStack deploy physical hardware such as servers, network infrastructure, and connectivity for the cloud computing systems to host digital products and services from various remote locations. Cloud service customers can employ the resources provided by the various CSPs without having to purchase and maintain physical equipment.
Access to computing resources in various computing environments (e.g., cloud resources of the various CSPs) frequently is managed through permissions. These permissions can include usernames and passwords, as well as other credentialing information. However, in cloud computing environments, access control beyond initial user authorization is limited. The current access control systems lack the ability to manage access dynamically and to do so without overburdening the computing resources with additional processes related to access control.
Non-limiting examples described herein provide various systems, apparatuses, methods, and software that provide enhancements for managing resources in a computing environment by implementing dynamic computing resource access authorization. In one implementation, a method of controlling computing resource access in a computing environment includes an authentication system transmitting a token to a user in response to receiving a token request from that user. The authentication system receives a user confirmation request from a computing resource that has received an access request from the user, where the user's access request may include the token (e.g., in an HTTP header). The authentication system transmits a status confirmation to the computing resource in response to the user confirmation request. The status confirmation may indicate approval or denial of the user's access to the computing resource and/or may provide the computing resource with a permission set defining access rights for the user based on the token. Receipt and transmission of requests and other communications may be performed by an access layer associated with the computing resource, where the access layer protects the computing resource from unauthorized access.
In another implementation, a management system for controlling computing resource access in a computing environment includes one or more computer readable media. The system further includes processing instructions stored on the one or more computer readable media that, when executed by a processing system, direct the processing system to transmit a token to a user in response to that user's request for a token (and, in some implementations, in addition to and/or as part of an authentication process for authenticating the user). Thereafter, when a user confirmation request including the token is received by the management system, the management system can identify the user associated with the token and any permission(s) associated with that user. A status confirmation from the management system to the computing resource can confirm or deny the user's requested access to the computing resource and/or can provide the computing resource with a permission set for that user. In the various implementations, the user's permission(s) and/or the status confirmation may be cached for future use. Moreover, tokens used in various implementations may be time-limited so that use of the token expires after a preselected period of time.
In one other implementation a computing resource receives a user request that includes a token (e.g., a digital credential). The computing resource includes the token in a user confirmation request to an authentication service and/or management system that responds by transmitting a status confirmation to the computing resource that defines whether or not the user request should be processed by the computing resource. The computing resource can include an access layer that protects the computing resource from unauthorized access, and receives the first user access request, transmits the user confirmation request and receives the status confirmation.
Many aspects of the disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views. While several embodiments are described in connection with these drawings, the disclosure is not limited to the embodiments disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents.
Access control in a computing environment regulates access to one or more resources in the computing environment and is a key facility to providing the isolation that makes cloud computing possible. Access to cloud resources can be managed through permissions that enable operations on resources (e.g., by human and computer-controlled actors and other users). As the numbers of users and resources increase, permission management complexity likewise increases.
Access control typically is thought of with permanence; an actor or other user is assigned certain permissions (e.g., as a permission set) with regard to various resources and is thus granted continuous and ongoing access to operate on those resources (e.g., including but not limited to reading data, controlling operations, and/or modifying information).
Dynamic computing resource access authorization implementations include wrapping a computing resource (e.g., a service) with an access control layer so that an access control policy (e.g., an externally controllable, configurable, and/or auditable access control policy) can dynamically enable, limit and/or disable a user's access to the controlled computing resource. When a user transmits a request to access a computing resource, that call is intercepted by or rerouted to a dynamic traffic authorization (DTA) layer of the computing resource. The DTA layer communicates with an access authority (e.g., an authenticating service implemented using a centralized server or repository of role-based access control (RBAC), permissions, policies and the like) to find out whether the requesting user is allowed to access the computing resource as requested (e.g., in some implementations, defining and/or limiting the way(s) in which the user is allowed to interact with the called computing resource). If the user request is approved (e.g., by the access authority or after the access layer obtains the request user's permission set), the DTA access layer allows the call to pass on to the computing resource. If the call is not allowed, the DTA access layer does not pass the call on to the computing resource.
In some implementations addressing Hypertext Transfer Protocol (HTTP) communication protection, the HTTP headers are used to wrap a user call with a permission layer. In some implementations for HTTP representational state transfer (REST) services, policy rules can be implemented and be based on the HTTP endpoints (e.g., /api/info, whether exact matching or regular expression matching), or the HTTP method (e.g., GET or POST), or other properties of the call being made to the REST service.
In other implementations non-HTTP communications can be protected with various mechanisms. A generic stunnel approach can handle any arbitrary Transmission Control Protocol (TCP) and user datagram protocol (UDP) traffic between two hosts (host with any port number) and services (host+specific port number(s)). A structured approach can be implemented for well-defined remote procedure call (RPC) protocols, such as SunRPC, CORBA, Java JMI, .NET Remoting, and others wherein dynamic computing resource access authorization is configured to accommodate the specifics of those protocols and, optionally, which functions are being called and the type of operation being performed.
Referring to
User 110 sends a call (step (C)) to computing resource 130, for example using a communication network 127 (e.g., the Internet). In some implementations the call can be an HTTPS request with the user's token in the HTTPS request's authorization header. Before being delivered to the requested computing resource, such calls are evaluated by a DTA access layer 135 that acts as a gatekeeper for and wraps computing resource 130. Access layer 135 receives user 110's call and transmits an authorization request (step (D)) that includes the user token to access authority 120, for example using a communication channel 137 (while separate channels/networks are shown in
An authentication service in access authority 120 can verify a received token to obtain the user's identity and check whether the user identity linked to the token has the necessary privilege on the gatekeeper resource (i.e., does the token identify a user that possesses (is linked to) the necessary permission(s) to access and perform the requested operation on the subject computing resource). Access authority 120 can then respond (step (E)) to the request from access layer 135. In some implementations an authentication service in access authority 120 sends an HTTP status code indicating whether or not the user's call should be allowed (e.g., a status confirmation comprising a permission set defining the user's permission(s) with regard to the requested computing resource). When a user's request is cleared by access authority 120, the request is passed by access layer 135 to computing resource 130 for processing and/or other action. Any response from computing resource 130 can then by transmitted back to user 110.
In some implementations the access layer 135 can cache the status code so that verification of user 110 does not have to be performed each time a call is sent from user 110 to computing resource 130. However, if it is likely that changes might be made to a user's permissions or that they may be revoked, access layer 135 can perform its authentication process (steps (D) and (E)) for each access attempt by user 110. Moreover, the status code or other status confirmation (e.g., a verification) sent by access authority 120 may be timestamped or have other temporal indicia that limit the time period during which a given cached approval is valid for a given user, token, etc.
Initially user 110 is authenticated (operation 205) and either immediately or at a later time receives a digital credential such as a token transmitted to user 110 by access authority 120 (operation 210). User 110 then submits a user request (operation 215) requiring access to computing resource 130. The request is intercepted by access layer 135, which in turn transmits a verification request (which can include the submitted user token) to access authority 120 (operation 220). Access authority 135 processes the verification request to determine the identity of the user associated with the submitted token (operation 225), which can be used to verify the identity of the relevant user.
Once the identity of the user associated with the submitted token has been verified by access authority 120, a status message (e.g., a status confirmation) can be transmitted to access layer 135 (operation 230). That message can confirm the user's identity and permission to access computing resource 130, indicate that the submitted token is not associated with the submitting user (user 110 in this example), confirm the user's identity but deny access to the requested computing resource, and/or provide other relevant information to the access layer 135 for current or future use. In the non-limiting example of
In some implementations relevant information about the transaction can be stored for future reference, use, auditing and/or other purposes. For example, the user identity associated with the submitted token can be stored by access layer 135 (operation 250) for future use (e.g., in an access layer storage unit 138). The shelf life of such data may be limited to mitigate the risk of use of outdated access control and/or permissions. Moreover, other data about the user request and other transactions in such methods 200 can be stored by access layer in its storage unit 138. The same and/or other data may likewise be transmitted to and stored by the access authority 120 (e.g., in an access authority storage unit 128).
In a situation where the user's identity is not confirmed by access authority 120, or where user 110 requests access and interaction with computing resource 130 that is beyond user 110's permissions, appropriate action may be taken for security purposes. Moreover, an auditing or similar protocol may be in place to record and reference such denied requests to generate a log or other record of transactions between users, computing resources and/or access authorities.
Communication interface system 401 comprises components that communicate over communication links, such as network cards, ports, radio frequency (RF) transceivers, processing circuitry and software, or some other communication devices. Communication interface system 401 may be configured to communicate over metallic, wireless, or optical links Communication interface system 401 may be configured to use Time Division Multiplex (TDM), Internet Protocol (IP), Ethernet, optical networking, wireless protocols, communication signaling, or some other communication format—including combinations thereof.
User interface system 402 comprises components that permit interaction with a user (e.g., an administrator) to receive inputs and to present media and/or information (e.g., updating user permissions for access authority 120). User interface system 402 may include a speaker, microphone, buttons, lights, display screen, touch screen, touch pad, scroll wheel, communication port, or some other user input/output apparatus—including combinations thereof. One or more components of user interface system 402 may be omitted in some non-limiting examples. The entire user interface system 402 may be omitted in some non-limiting examples.
Processing circuitry 405 comprises microprocessor and other circuitry that retrieves and executes operating software 407 from memory device 406 (including, in some non-limiting examples, one or more of software 111, 121, 131 of
Operating software 407 includes identification module 408 and generate module 409, although any number of software modules may provide the same operation. Operating software 407 may further include an operating systems, virtual machine, containers, such as Docker containers, utilities, drivers, network interfaces, applications, or some other type of software. When executed by processing circuitry 405, operating software 407 directs processing system 403 to operate computing system 400 as described herein.
In particular, when computing system 400 operates as or as part of an access authority arbitrating communications between users and computing resources, operating software 407 can include an authentication module 408 (e.g., operating as software 121 in
Software 407 may also include a client module 409 that directs processing system 403 to provide client operations described herein. Similarly, a service module 411 can direct processing system 403 to provide service operations, including gatekeeper operations, described herein.
To perform as described in the noted capacities, computing system 400 may communicate with one or more agents that provide reports of the operations within the environment, and may be manually provided with information by an administrator or the like, or may receive operational information in any other manner, including combinations thereof.
The functional block diagrams, operational scenarios and sequences, and flow diagrams provided in the Figures are representative of exemplary systems, environments, and methodologies for performing novel aspects of the disclosure. For purposes of simplicity of explanation, methods included herein may be in the form of a functional diagram, operational scenario or sequence, or flow diagram, and may be described as a series of acts. It is to be understood and appreciated that the methods are not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a method could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.
The descriptions and figures included herein depict specific implementations to teach those skilled in the art how to make and use the best option. For the purpose of teaching inventive principles, some conventional aspects have been simplified or omitted. Those skilled in the art will appreciate variations from these implementations that fall within the scope of the invention. Those skilled in the art will also appreciate that the features described above can be combined in various ways to form multiple implementations. As a result, the invention is not limited to the specific implementations described above, but only by the claims and their equivalents.
This application hereby claims the benefit of and priority to U.S. Provisional Patent Application 62/221,819, entitled “DYNAMIC TRAFFIC AUTHORIZATION FOR ACCESS TO SERVICES,” filed 22 Sep. 2015, and which is hereby incorporated by reference in its entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2016/053004 | 9/22/2016 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62221819 | Sep 2015 | US |
