Patent Application
20100192193
In today's world of technology, a large number of applications run over the Internet in a web browser. In such environments, there is often an external component hosted by a third party that needs to be given access to the user's account on another system in order to provide its desired functionality. An example of such an external component can be a third party chart control that displays data from a content management application in interesting ways.
In order to allow external applications to provide rich functionality in such browser applications, it is sometimes necessary to allow these external applications to operate on behalf of users. However, it can often be difficult to determine what security permissions to let the application use. If the application itself has a permission level which is used to limit its actions, then the application is limited from doing anything above that permission level. But this doesn't limit a user's ability to elevate their permission level. For example, an application might have permission to write to a list, while a user might only have permission to read the list. In this situation, the user could use the application to write to the list, thus gaining a permission they are not supposed to have.
On the other hand, if the external application is limited by the permissions of the user who is using it, the application can elevate its permissions based upon the user interacting with it. This might occur, for example, when the external application has read-only permissions but is used by a user that has write permissions. In this latter scenario, the external application could use the user's permission to write data, possibly without the user even knowing about it. Thus, any time an external application is given authority to take an action based upon either the external application's security permission or the user's security permission level, there is an opportunity for an unauthorized elevation of permissions to occur.
Various technologies and techniques are disclosed for restricting security levels that can be used with browser-based applications. When a request is received from an external application to retrieve data to be used by the external application within a client browser, an intersection is performed on a permission set of a user of the client browser and of the external application to determine a new permission set to use for retrieving the data requested by the external application.
A method for restricting operations that can be performed by an external application that is being run in a client browser is described. A request is received from a client browser to login to an original application. A session token is returned to the client browser after validating that access to the original application can be granted to the client browser. While the client browser is still logged in to the original application, a request is received from an external application to login to the original application. Validation is performed to confirm that access to the original application can be granted to the external application. A request for data is received from the external application, with the request for data containing the session token that the external application obtained from the client browser.
While the client browser and external application are both still logged in to the original application, the data requested by the external application is retrieved. In one implementation, an intersection is performed on a permission set of a user of the client browser and of the external application to determine a new permission set to use for retrieving the data requested by the external application. The data is returned to the external application.
This Summary was 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 to be used as an aid in determining the scope of the claimed subject matter.
The technologies and techniques herein may be described in the general context as an application that restricts the permission level that external applications can use when running in a client browser, but the technologies and techniques also serve other purposes in addition to these. In one implementation, one or more of the techniques described herein can be implemented as features within any other type of program or service that allows external applications to access data on behalf of a user.
In one implementation, a user account for an original application is assigned to an external application (or to the server hosting the external application, etc.) The term “original application” as used herein is meant to include any type of application that has functionality that needs to be accessed by an external application for use in a client browser. The term “external application” as used herein is meant to include an application that resides on a separate process boundary or server from the original application, such as on a third party server. The term “client browser” as used herein is meant to include a web browser that resides on a device being operated by a user.
The user account for the original application that is assigned to the external application is marked with a special indicator so that the external application will only be granted permissions to the original application if the user is also separately logged in to the original application. When the user logs in to the original application, a session token is returned back to the client browser. The term “session token” as used herein is meant to include an identifier assigned to the user's current session in the client browser. That session token is provided to the external application by the client browser. That way, when the external application makes requests for data from the original application, the original application will know what user session the application is associated with.
In one implementation, the system also performs an intersection of permissions between the user's permission level and the external application's permission level to determine a new permission set to use for any operations requested by the external application. The term “performing an intersection” or “performs an intersection” as used herein is meant to include the process of doing an AND operation on the permissions between the two accounts to determine a new permission set. In an “AND” operation, only permissions that are contained in each set of permissions will be included in the new permission set. The term “new permission set” as used herein is meant to include the list of zero or more permissions that result after performing an intersection. Several examples of performing an intersection are shown in
In one implementation, a user account for the original application 104 is assigned to the external application 106. As a few non-limiting examples, a separate user account for the external application can be assigned to each server that runs the external application, just one for the external application overall, or the user account could be shared by all applications that the server running the external application hosts. Numerous other configurations of assigning one or more user accounts for use by the external application 106 could also be used.
The user account for the original application 104 that is assigned to the external application 106 is marked with a special indicator so that the external application 106 will only be granted permissions to the original application 104 if the user is also separately logged in to the original application. When the user logs in to the original application 104 from client browser 102, a session token is returned back to the client browser. The session token can be in one of a variety of formats, and can include identifiers such as a time identifier, an application identifier, and/or a user identifier. Any data that uniquely identifier this particular session by the user could be included within the session token.
That session token is then provided to the external application by the client browser. When the client browser 102 makes the request to external application 106 to perform some functionality that requires data from original application 104, client browser 102 provides the session token to external application 106. That way, when the external application 106 makes requests for data from the original application 104, the original application 104 will know what user session the external application 106 is associated with and will only allow the requested operation to be performed if both the user and the external application are logged in and are using the same session token.
In one implementation, before any operation can be performed by the external application 106 against the original application 104, the original application 104 performs an intersection of permissions between the user's permission level from the client browser 102 and the external application's permission level 106 to determine a new permission set to use for any operations requested by the external application, such as those that retrieve data. These concepts will now be described in further detail in
Turning now to
While the client browser is still logged in to the original application, a request is also received from an external application to login to the original application (stage 206). The external application can be one of a variety of application types, but in general is a component or application that is providing some functionality to the client browser that needs to retrieve at least some of its information from the original application. The original application validates that access to the original application can be granted to the external application (stage 208), such as by confirming that a valid set of user credentials were supplied by the external application. As noted earlier, the original application can look at a special indicator that is associated with the account of the external application to see that the external application can only be allowed to access functionality of the original application if the user is separately logged in to the original application.
At some point in time after logging in, the external application then sends a request to the original application for the data that it needs to use in the client browser. That request includes the session token that was given to the external application by the client browser. The request for data is received by the original application from the external application (stage 210). The data requested by the external application is retrieved (stage 212). The original application will verify that the session token matches with the token previously supplied to the client browser before retrieving the requested data.
In another implementation, the original application will perform an intersection on the permissions of the user and the external application to generate a new permission set, and will then use the new permission set to determine what security level to use for the data retrieval operation. This process is described in more detail in
The security level associated with the new permission set is then used for the operation that retrieves the data (stage 306). This new permission set that results from the intersection will prevent an elevation of privilege by the user and the external application. In other words, neither the user nor the external application will be able to perform any operation that they are not entitled to perform. The requested data is then returned back to the external application (stage 308). As noted earlier, the external application can then further manipulate the data and display or use it in some fashion with the client browser.
Turning now to
As shown in
Additionally, device 500 may also have additional features/functionality. For example, device 500 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in
Computing device 500 includes one or more communication connections 514 that allow computing device 500 to communicate with other computers/applications 515. Device 500 may also have input device(s) 512 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 511 such as a display, speakers, printer, etc. may also be included. These devices are well known in the art and need not be discussed at length here.
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. All equivalents, changes, and modifications that come within the spirit of the implementations as described herein and/or by the following claims are desired to be protected.
For example, a person of ordinary skill in the computer software art will recognize that the examples discussed herein could be organized differently on one or more computers to include fewer or additional options or features than as portrayed in the examples.
