Patent Application
20090320089
A mobile device managed by an organization is typically configured and controlled by a management service to ensure compliance. The mobile device may connect periodically over the air to the management service and send/receive management related information during a management session such as send status, send inventory, receive configuration, or receive policy. Furthermore, a number of third party applications may be loaded and executed on the mobile device that may access a number of resources managed or controlled by the management service. Thus, security decisions may need to be made when an application on the mobile device requests access to a resource.
Some security decisions cannot be made programmatically in a way that corresponds to the desired behavior of an end user because a computing application typically lacks information about the situation and the end user. This may result in scenarios where a computing device requires an end user to make authorization decisions explicitly. For example, dialog boxes may be used to ask users to decide whether or not to run a program module in conjunction with a web browser function. In some operating systems, the user with the administrative rights may be required to make some of those decisions.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended as an aid in determining the scope of the claimed subject matter.
Embodiments are directed to a User Brokered Authorization (UBA) of policy decisions. An authorization mechanism according to some embodiments interacts with an authorization layer of the operating system and enables a determination of whether an authorization decision can be made programmatically or by end user decision based on generalized device policy.
These and other features and advantages will be apparent from a reading of the following detailed description and a review of the associated drawings. It is to be understood that both the foregoing general description and the following detailed description are explanatory only and are not restrictive of aspects as claimed.
As briefly discussed above, a user brokered authorization mechanism may interact with an authorization layer of an operating system and enable a determination of whether an authorization decision can be made programmatically or by end user decision based on generalized device policy. In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustrations specific embodiments or examples. These aspects may be combined, other aspects may be utilized, and structural changes may be made without departing from the spirit or scope of the present disclosure. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims and their equivalents.
While the embodiments will be described in the general context of program modules that execute in conjunction with an application program that runs on an operating system on a personal computer, those skilled in the art will recognize that aspects may also be implemented in combination with other program modules.
Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that embodiments may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
Embodiments may be implemented as a computer process (method), a computing system, or as an article of manufacture, such as a computer program product or computer readable media. The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process.
While mobile computing devices are mentioned as an example operating environment for implementations of a policy-based user brokered authorization system, embodiments are not so limited. A User Brokered Authorization (UBA) system according to embodiments may be implemented in any networked computing device including, but not limited to, desktop computers, laptop computers, smart phone devices, networked personal assistants, smart automobile consoles, and the like using the principles described herein.
Referring to
Existing security prompting schemes generally require specific User Interface (UI) display code to be written for each prompting situation. A UBA system according to embodiments makes a determination based on policy and requires no additional code to display the prompt. Any authorization check may be allowed to become a security prompt based on policy settings. Services that perform authorization checks may be allowed to provide arbitrary context information to the UI display code so that UI elements can be configured by policy to include custom information for that type of prompt.
Computing devices managed by a system according to embodiments may communicate over a variety of networks. Such networks may include those known as cellular networks (e.g. GSM, CDMA), local or wide area networks (LAN, WAN), or the newer Unified Communication Networks (UCN), which integrate multiple communication systems (for example the Office Communication System® by MICROSOFT CORP. of Redmond, Wash.).
In the conceptual diagram 100 of
In a system according to embodiments, applications 110 may reside on the computing device 108 or be executed in a shared manner at a server and accessed by the computing device 108. Service 112 is associated with at least one resource that may be needed by the applications 110. Service 112 may also provide protection services such as checking permissions of a user/device before allowing access to a resource. Thus, service 112 may interact with policy engine 114 to determine authorization results based on existing policies.
In a system according to one embodiment, UBA policy module 116 may be placed between policy engine 114 and UBA render layer(s) 118 of a UBA prompt stack for rendering user interface elements when a user is to be prompted for authorization decision. The UBA render layer is an ‘output’ of the UBA policy module, which decides whether or not to display a prompt to the user. From this point, UBA render layer 118 is responsible for creating a prompt window, waiting for results, and signaling back to UBA policy module 116.
Through the interaction between the above described components, the results of a prompt that has been rendered may be interpreted. If the user selects a persistence option in the UI, UBA policy module is responsible for authoring rules to a policy database that suppresses future prompts. Caller hard timeouts may also be implemented. In some cases, UBA callers may specify a hard timeout within which the user must answer a prompt. This may be necessary when the user is prompted while holding a system resource. Moreover, prompts may be queued as they are issued from the policy engine 114. UBA policy module 116 may effectively act as a prompt scheduler. If two “pop-up” prompts occur at the same time, one may be blocked until the first prompt completes so as not to inundate the user. If two prompts occur for the same resource, and the first is answered with “do not ask me again”, UBA policy module may suppress the second prompt, while returning the user's decision from the first prompt to both callers.
The next component is a service protecting the resource being attempted to be accessed 224. The service/subsystem protecting the resource or providing the protected resource to the application may check a policy to determine if the application should be granted the ability to access the resource. When calling into the policy subsystem to make this check, the service may pass down context data such as ID of the calling application, network location the application is trying to access, details of the underlying network connection to be used to establish a connection to the requested network location, and the like, in step 2.
In step 3, policy subsystem 226 receives policy information from a policy information source (e.g. a database) 230 and determines what the policy outcome should be based on the context provided and. The policy subsystem 226 passes through the context data from the calling service and adds any additional context data that UBA subsystem 228 might use to UBA subsystem 228 in step 4. If the policy dictates that the user should be prompted, then the policy subsystem may call into the UBA subsystem to prompt the user.
In step 5, the UBA subsystem 228 reads additional policy information and evaluates it in concert with the context data to determine exact UI elements (e.g., icons, text, buttons, etc.) to display to the user. It then displays the UI elements to the user and updates context data to return to the service 224. If the end user decides to persist his/her decision by interacting through the UI, the UBA subsystem 228 may store the end user's decision in policy information source 230 to avoid future prompts as shown in step 6.
The UBA subsystem 228 then returns the end user's decision and context data to the policy subsystem 226 in step 7, which returns the UBA subsystem's decision and context data to the service 224. The service 224 returns the appropriate result to the application depending on the scenario and context data. The manner the result is returned to the application may vary depending on the interface between the application and the service.
Upon receiving the decision from the plug-in module, the policy engine checks to see if the decision has changed (e.g. due to an update) 344 and returns the decision to the module (or service) protecting the resource 346. The application's request to access the resource may then be carried out or cancelled depending on whether the decision was to allow or to deny access 348.
While the example components and operations in
A system according to embodiments may comprise any topology of servers, clients, Internet service providers, and communication media. Also, the system may have a static or dynamic topology. The term “client” may refer to a client application or a client device (e.g. mobile device). While a policy-based user brokered authorization system may involve many more components, typical and relevant ones are discussed in conjunction with this figure.
Mobile devices 451, 452, and 453 may participate in a managed system over at least one of the networks 460, 462, and 464. Mobile devices 451, 452, and 453 may execute applications, locally or in a distributed manner, which may require access to a resource through one of the networks. Allowing access to the requesting application may present, in some cases, a security or privacy concern and be managed by policy engine enforcing user/device authorization policies. In a system according to embodiments, a UBA policy plug-in module interacts with a policy engine and UBA render layers for user interface rendering and enables a determination of whether an authorization decision can be made programmatically or by end user decision based on generalized device policy.
While example mobile devices such as smart phones, PDAs, laptop or handheld computers, etc., have been used as illustrative examples, embodiments are not limited to those. As mentioned previously, mobile communication may be implemented in purely software form as well, such as a client application that can be executed on any computing device. Since such a client application may be installed and executed on other types of computing devices such as a smart automobile console or even a desktop computer, embodiments may be implemented in those devices and others using the principles described herein. Data associated with the system and mobile device configuration may be stored in at least one data store such as data stores 459, which may be directly accessed by the servers and/or clients of the system or managed through a database server 458. The system may also employ additional servers for performing other specific tasks such as providing applications and/or resources to the mobile device(s). Mobile devices 451, 452, and 453 provide platforms for client applications. Thus, users may access at least one communication system using a client device or at least one client application running on a client device.
Networks 460, 462, 464 may include a secure network such as an enterprise network or a cellular network, an unsecure network such as a wireless open network, or the Internet. Networks 460, 462, 464 provide communication between the nodes described herein. By way of example, and not limitation, Networks 460, 462, 464 may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.
Many other configurations of computing devices, applications, data sources, data distribution systems may be employed to implement a policy-based user brokered authorization system. Furthermore, the networked environments discussed in
Application(s) 522 are executed on computing device 500 may require to access resources such as execution of a particular module for web browsing, initiating a communication session (e.g. a phone call), and the like. Policy engine 524 may be a separate module or an integral part of the device operating system for managing user/device policies and enforcing them. Policy engine 524 may work in conjunction with a UBA policy plug-in module and enable a determination of whether an authorization decision can be made programmatically or by end user decision based on generalized device policy. This basic configuration is illustrated in
The computing device 500 may have additional features or functionality. For example, the computing device 500 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in
The computing device 500 may also contain communication connections 516 that allow the device to communicate with other computing devices 518, such as over a wireless network in a distributed computing environment, for example, an intranet or the Internet. Other computing devices 518 may include client devices of the managed network or a management server as discussed above. Communication connection 516 is one example of communication media. Communication media may typically be embodied by 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” means a signal that has at least one of its characteristic 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.
The claimed subject matter also includes methods. These methods can be implemented in any number of ways, including the structures described in this document. One such way is by machine operations, of devices of the type described in this document.
Another optional way is for at least one of the individual operations of the method to be performed in conjunction with at least one human operator performing some. These human operators need not be collocated with each other, but each can be only with a machine that performs a portion of the program.
Process 600 begins with operation 602, where a request for accessing a resource is received from an application executed on the mobile device. Processing continues to operation 604, where at least one policy is checked for authorization. The policies may dictate that a programmatic decision be made or the user to be prompted. The policies may be based on user, device, or network credentials. Processing advances to operation 606, where policy outcome is determined based on the credentials, context of the request, and so on.
Following operation 606, processing moves to decision operation 608, where a determination is made whether the user is to be prompted. If the user is to be prompted, processing continues to operation 610 where user interface elements to be used in the prompt are determined based on policy. At subsequent operation 612, the user decision is stored if the user has indicated the decision to be persisted.
Following operation 612 or a negative determination at decision operation 608, the decision and context data are returned to a service managing the protected resource at operation 614. The decision may be to allow or to deny access to the requested resource. Processing then advances to operation 616, where the appropriate result is returned from the service to the requesting application.
The operations included in process 600 are for illustration purposes. Policy-based user brokered authorization may be implemented by similar processes with fewer or additional steps, as well as in different order of operations using the principles described herein.
The above specification, examples and data provide a complete description of the manufacture and use of the composition of the embodiments. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims and embodiments.
