Patent Application
20110270885
Embodiments of the subject matter described herein relate generally to data processing systems and methods, such as systems and methods that use a common network-based platform to support applications executing on behalf of multiple tenants. More particularly, embodiments of the subject matter relate to security configuration systems and methods for portal users in the multi-tenant database environment.
Modern software development is evolving away from the client-server model toward network-based processing systems that provide access to data and services via the Internet or other networks. In contrast to traditional systems that host networked applications on dedicated server hardware, a “cloud” computing model allows applications to be provided over the network “as a service” supplied by an infrastructure provider. The infrastructure provider typically abstracts the underlying hardware and other resources used to deliver a customer-developed application so that the customer no longer needs to operate and support dedicated server hardware. The cloud computing model can often provide substantial cost savings to the customer over the life of the application because the customer no longer needs to provide dedicated network infrastructure, electrical and temperature controls, physical security and other logistics in support of dedicated server hardware. A customer relationship management (CRM) system is one example of an application that is suitable for deployment as a cloud-based service.
Since a cloud-based service provider stores data for a number of different clients, security is an important consideration. However, security applications may consume processing resources and adversely impact performance. Security rules may be complicated by the various types of users that the service provider accommodates, even within a single client, such as internal users within a client and portal users that are external customers of the client. As such, it may be desirable to provide techniques enabling the controlling of access to objects of the database system and/or optimizing a query to an object to improve performance and security of the database system.
A more complete understanding of the subject matter may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures.
Broadly, exemplary embodiments discussed herein provide an improved security configuration for accessing a database in multi-tenant database environment. In one exemplary embodiment, the security configuration may include separate default settings for different types of users. Internal users are typically employees of the tenants and portal users are typically customers of the tenant or otherwise external to the tenant organization. As such, the security configuration may provide separate default settings for internal users and portal users, as well as other process optimizations for such user types.
A “tenant” generally refers to a group of users that shares access to common data within the database 130. Tenants may represent customers, customer departments, business or legal organizations, and/or any other entities that maintain data for particular sets of users within the system 100. Although multiple tenants may share access to the server 102 and the database 130, the particular data and services provided from the server 102 to each tenant can be securely isolated from those provided to other tenants. The multi-tenant architecture therefore allows different sets of users to share functionality without necessarily sharing any of the data 132.
Each tenant may further be associated with both internal users and portal (or external) users. The terms internal and portal refer to the relationship of the user with respect to the tenant. As noted above, tenants are typically direct customers of the provider of the system 100, although the tenants may host applications and data on the system 100 for use by customers of the tenants. As such, the internal users are typically employees of the tenant, while portal users are typically customers, suppliers, business partners, affiliates, or other portal users external to the tenant, although the portal users have at least some access to the applications and data of the associated tenant. In
The database 130 is any sort of repository or other data storage system capable of storing and managing the data 132 associated with any number of tenants. The database 130 may be implemented using any type of conventional database server hardware. In various embodiments, the database 130 shares processing hardware 104 with the server 102. In other embodiments, the database 130 is implemented using separate physical and/or virtual database server hardware that communicates with the server 102 to perform the various functions described herein.
The data 132 may be organized and formatted in any manner to support the application platform 110. In various embodiments, the data 132 is suitably organized into a relatively small number of large data tables to maintain a semi-amorphous heap-type format. The data 132 can then be organized as needed for a particular virtual application 128. In various embodiments, conventional data relationships are established using any number of pivot tables 134 that establish indexing, uniqueness, relationships between entities, and/or other aspects of conventional database organization as desired.
Further data manipulation and report formatting is generally performed at run-time using a variety of metadata constructs. Metadata within a universal data directory (UDD) 136, for example, can be used to describe any number of forms, reports, workflows, user access privileges, business logic and other constructs that are common to multiple tenants. Tenant-specific formatting, functions and other constructs may be maintained as tenant-specific metadata 138 for each tenant, as desired. Rather than forcing the data 132 into an inflexible global structure that is common to all tenants and applications, the database 130 is organized to be relatively amorphous, with the pivot tables 134 and the metadata 138 providing additional structure on an as-needed basis. To that end, the application platform 110 suitably uses the pivot tables 134 and/or the metadata 138 to generate “virtual” components of the virtual applications 128 to logically obtain, process, and present the relatively amorphous data 132 from the database 130.
The server 102 is implemented using one or more actual and/or virtual computing systems that collectively provide the dynamic application platform 110 for generating the virtual applications 128. The server 102 operates with any sort of conventional processing hardware 104, such as a processor 105, memory 106, input/output features 107 and the like. The processor 105 may be implemented using one or more of microprocessors, microcontrollers, processing cores and/or other computing resources spread across any number of distributed or integrated systems, including any number of “cloud-based” or other virtual systems. The memory 106 represents any non-transitory short or long term storage capable of storing programming instructions for execution on the processor 105, including any sort of random access memory (RAM), read only memory (ROM), flash memory, magnetic or optical mass storage, and/or the like. The input/output features 107 represent conventional interfaces to networks (e.g., to the network 145, or any other local area, wide area or other network), mass storage, display devices, data entry devices and/or the like. In a typical embodiment, the application platform 110 gains access to processing resources, communications interfaces and other features of the processing hardware 104 using any sort of conventional or proprietary operating system 108. As noted above, the server 102 may be implemented using a cluster of actual and/or virtual servers operating in conjunction with each other, typically in association with conventional network communications, cluster management, load balancing and other features as appropriate.
The application platform 110 is any sort of software application or other data processing engine that generates the virtual applications 128 that provide data and/or services to the client devices 140 and 142. The virtual applications 128 are typically generated at run-time in response to queries received from the client devices 140 and 142. For the illustrated embodiment, the application platform 110 includes a bulk data processing engine 112, a query generator 114, a search engine 116 that provides text indexing and other search functionality, a user authorization module 118, and a runtime application generator 120. Each of these features may be implemented as a separate process or other module, and many equivalent embodiments could include different and/or additional features, components or other modules as desired.
Upon initial engagement with the application platform 110, the user authorization module 118 prompts and receives identification from the client devices 140 and 142. Such identification may include, for example, user names and passwords such that the user authorization module 118 may authorize or prevent further access by the potential user. For example, the user may authenticate his or her identity to the authorization module 118 to obtain a session identifier that identifies the user in subsequent communications with the server 102. As discussed in greater detail below, the user authorization module 118 further identifies the user as an internal user of an internal client device 140 or as a portal user of a portal client device 142. For example, the authentication module 118 may identify the user and user type by accessing a user profile associated with a user ID. Multiple user types may be configured with a variety of capabilities, including the user types used in the security configuration discussed below.
Upon authentication, the runtime application generator 120 dynamically builds and executes the virtual applications 128 in response to specific requests received from the client devices 140 and 142. The virtual applications 128 created by tenants are typically constructed in accordance with the tenant-specific metadata 138, which describes the particular tables, reports, interfaces and/or other features of the particular application. In various embodiments, each virtual application 128 generates dynamic web content that can be served to a browser or other client program 142 associated with its client device 140, as appropriate.
The runtime application generator 120 suitably interacts with the query generator 114 to efficiently obtain multi-tenant data 132 from the database 130 as needed. In a typical embodiment, the query generator 114 considers the identity of the user requesting a particular function, and then builds and executes queries to the database 130 using system-wide metadata 136, tenant specific metadata 138, pivot tables 134, and/or any other available resources. The query generator 114 in this example therefore maintains security of the common database 130 by ensuring that queries are consistent with access privileges granted to the user that initiated the request in accordance, for example, with the security configuration discussed below.
The data processing engine 112 performs bulk processing operations on the data 132 such as uploads or downloads, updates, online transaction processing, and/or the like. In many embodiments, less urgent bulk processing of the data 132 can be scheduled to occur as processing resources become available, thereby giving priority to more urgent data processing by the query generator 114, the search engine 116, the virtual applications 128, etc. In certain embodiments, the data processing engine 112 and the processor 105 cooperate in an appropriate manner to perform and manage the various data access monitoring techniques, processes, and methods described in more detail below with reference to
In operation, developers use the application platform 110 to create data-driven virtual applications 128 for the tenants that they support. Such virtual applications 128 may make use of interface features such as tenant-specific screens 124, universal screens 122 or the like. Any number of tenant-specific and/or universal objects 126 may also be available for integration into tenant-developed virtual applications 128. The data 132 associated with each virtual application 128 is provided to the database 130, as appropriate, and stored until it is requested or is otherwise needed, along with the metadata 138 that describes the particular features (e.g., reports, tables, functions, etc.) of that particular tenant-specific virtual application 128.
The data and services provided by the server 102 can be retrieved using any sort of personal computer, mobile telephone, tablet or other network-enabled client device 140 and 142 on the network 145. Typically, the user operates a conventional browser or other client program to contact the server 102 via the network 145 using, for example, the hypertext transport protocol (HTTP) or the like. When the identified user requests access to a virtual application 128, the runtime application generator 120 suitably creates the application at run time based upon the metadata 138, as appropriate. The query generator 114 suitably obtains the requested data 132 from the database 130 as needed to populate the tables, reports or other features of the particular virtual application 128. As noted above, the virtual application 128 may contain Java, ActiveX, or other content that can be presented using conventional client software running on the client device 140 and 142; other embodiments may simply provide dynamic web or other content that can be presented and viewed by the user, as desired.
In general, the security configuration 200 maintains a set of security settings for various data access requests, and the security settings may be based on the user, object, access type, or any other desired characteristic. For the most secure security setting, an individual record may only be accessible to a single user. Generally, however, the processing resources of the security configuration 200 may be optimized by collectively granting access to multiple users and thus avoiding checking the security setting of each individual record for each individual user. With this in mind, the security configuration 200 may maintain any number of security settings based on the characteristics of information (i.e., the type of object) and the characteristics of the user (i.e., certain types and/or groups of users may have access to certain types of objects), as discussed below.
The illustrated embodiment of the security configuration 200 generally includes, without limitation: a sharing provider 210, an access checker 220, an organization wide default table 230, a membership table 240, and a share table 250. These functional modules are operatively associated with one another, and may be coupled together using any suitable interconnection arrangement or architecture that accommodates data communication as needed. For example, each of the sharing provider 210 and the access checker 220 may be coupled to the membership table 240 and the share table 250. As shown, the sharing provider 210 and access checker 220 may be considered part of the authentication module 118 discussed above in reference to
The security configuration 200 will be initially introduced and additionally described in greater detail below in conjunction with
As noted above, the sharing provider 210 and access checker 220 have access to the organization wide default table 230 that, for example, may be an object table generally corresponding to any collection of data arranged into predefined categories. In general, each row or record of a table contains an instance of data for each category defined by the fields. In some multi-tenant database systems, standard object tables might be provided for use by all tenants. In the context of the system 100, each type of data object may be further associated with a number of records that represent data of a tenant and/or the overall system 100. Although only one organization wide default table 230 is shown in
The organization wide default table 230 includes one or more rows, each representing an object (e.g., ob1, ob2, ob3) identified in a first column 232. The organization wide default table 230 further includes a second column 234 and a third column 236 that identify the security setting associated with each object. As noted above, each object and record may have an associated security setting the dictates the accessibility of the object and record for each user. As shown in
For each access request, the security configuration 200 determines whether or not access should be granted based on any number of user, record, and object characteristics, including the nature of the request, default settings in the access checker 220 and sharing provider 210, the group and role memberships of the user, and down to the individual security setting for a particular record.
Generally, and as noted above, each tenant may have a number of internal users, such as employees of the tenant, and portal users, such as the customers of the tenant. Considering that each tenant may have a number of internal users, the tenant may want the default settings of certain objects to be public such that any internal user can access and certain objects as private such that access is more limited. For example, the tenant may designate that the information associated with employee salary as private except for internal users within human resources. However, other objects, such as public corporate documents or corporate directories, may be designated as public to provide any internal user with access. As noted above, the tenant may provide a default security setting for internal users in column 234. Although any suitable indicator may be used, the terms “private” and “public” are listed in table 230 to represent the security setting. The public setting may further define the nature of the public access for a particular object. For example, the tenant may designate that a user may read an object but not perform other functions. This is indicated by “Public: R” in the default table 230. Alternatively, an object that is public for both reading and updating may be indicated by “Public: R/W” in default table 230.
Each tenant may also have a number of portal users that are external to the organization. As in the above, the tenant may want certain objects to have a default setting of public across all portal users and certain objects to have a default setting of private in column 236.
The security settings in the internal columns 234 may be different from the settings in the portal column 236. For example, the tenant may want the corporate email directory to be public with respect to the internal users and private to portal users outside of the organization. Accordingly, the tenant may provide at least two different types of default security settings for two different types of users within the default table 230.
As a general matter, objects with a default security setting of public (e.g., “Public: R” or “Public: R/W”) require less processing resources for such an information request since no further access checks are required. If the security setting is private, further tables, such as the membership and share tables 240 and 250 are consulted to determine if the access request should be granted. In general, the membership and share tables 240 and 250 provide the security settings for records according to a particular user. In general, the membership table 240 lists the groups or roles of which the user is a member, and each user may be a member of any number of groups. For example, an internal user may be a member of the human resources group that has access to personnel records. The share table 250 defines, for each object, the groups that have access to records. As such, from the membership table 240 and the share table 250, the security configuration 200 indicates the availability of a requested record for a particular user. The security settings in the default table 230, the membership table 240, and the share table 250 may be adjusted as necessary or desired by the tenant to provide the desired level of security while optimizing processing resources. Although only one share table 250 is shown in
As noted above,
Referring to
If the result of step 304 is that the request is associated with an internal client device 140, the request is evaluated to determine the type of access that the user is requesting in a step 306. If the internal client device 140 is requesting access to a record to update the record or potentially update the record, such as a detail page or an API update, the system 100 consults the access checker 220, as represented in step 308. In particular, in step 310, the access checker 220 consults internal security setting in column 234 of default table 230 is consulted to determine if the designated object is public or private, and if public, the level of available access.
If the security setting for the internal user in the organization wide default table 230 is public with respect to the access request, then the method 300 proceeds from step 310 to step 312 in which the security configuration 200 enables the system 100 to provide the access information to the user, which includes a yes or no access result to the user. If the access information indicates that the user has access, the system 100 subsequently provides the record to the user. As noted above, the security setting may have a particular level of access that is public. For example, if the record is public, but only as a read operation, an access request that may update the record would not be considered public.
If, in step 310, the system 100 determines that the security setting in the internal column 234 is private, the method 300 then determines if the user has access to the requested record in steps 314 and 316. In step 314, the membership table 250 is consulted to determine the groups or roles of which the user is a member. In step 316, the system 100 also consults the share table 260 that lists the groups that have access to each object and additionally defines access to records or objects for individual users. As such, from the membership table 250 and the share table 260, security configuration 200 provides the availability of the record for the user and access request. Based on the steps 314 and 316, the method 300 proceeds to step 318 and the system 100 provides the access information to the user, which includes a yes or no access result to the user. If the access information indicates that the user has access, the system 100 subsequently provides the record to the user.
Returning to step 306, if the access request of the internal user is querying the data, such as in a search or report, the system 100 consults the sharing provider 210, as represented in step 320. In the exemplary embodiment of
In step 322, the system 100 consults the security settings in the internal column 234 in the organization wide default table 230 of the access checker 210. If the security setting in the internal column 234 in the organization wide default table 230 is public with respect to the level of access requested, then the method 300 proceeds from step 322 to step 324 in which the security configuration 200 enables the system 100 to provide access information to the user, which includes a list of accessible records for the user.
If, in step 322, the system 100 determines that the security setting in the internal column 234 is private, the method 300 then determines if the user has access to the requested record in steps 326 and 328. In step 322, the membership table 250 is consulted to determine the groups or roles of which the user is a member, and in step 324, the share table 260 is consulted to determine the groups that have access to each object. As such, from the membership table 250 and the share table 260, security configuration 200 indicates the availability of the records. Based on the steps 326 and 328, the method 300 proceeds to step 330 and the system 100 provides the access information to the user, which includes a list of accessible records for the user.
Returning to step 304, if the request is associated with portal user, such as portal client device 142, the request is evaluated in step 332 to determine the nature of the access request, which as above, may be based on the potential to update the record. As shown in step 334, if the portal client device 142 is requesting to update the record or detail page, the system 100 consults the access checker 220. Particularly, the access checker 220 consults the portal security setting listed in portal column 238 of organization wide default table 230 in the access checker 220. In step 336, the system 100 evaluates if the portal security setting is public or private as compared to the access request.
If the security setting in the internal column 236 in the organization wide default table 230 is public with respect to the access request, then the method 300 proceeds from step 336 to step 338 in which the security configuration 200 enables the system 100 to provide the access information to the user, which includes a yes or no access result. If the access information indicates that the user has access, the system 100 subsequently provides the record to the user.
If, in step 336, the system 100 determines that the portal security setting in column 238 is private, the method 300 then determines if the user has access to the requested record in steps 340 and 342. In step 310, the membership table 250 is consulted to determine the groups or roles of which the user is a member, and in step 342, the share table 260 is consulted. As such, from the membership table 250 and the share table 260, security configuration 200 indicates the availability of the record, as represented by step 344. If the access information indicates that the user has access, the system 100 subsequently provides the record to the user.
Returning to step 332, if the portal user is requesting access to the records for a list, report, query, or the like, as above, the system 100 consults the sharing provider 210, as represented in step 346, which in turn, consults the portal security setting in column 236 of the default table 230, as represented in step 348. If the security setting is public with respect to the access request, then the method 300 proceeds from step 348 to step 350 in which the security configuration 200 enables the system 100 to provide access information to the user, which includes a list of accessible records for the user.
If, in step 348, the system 100 determines that the portal security setting in the column 236 is private, the method 300 then determines if the user has access to the requested records in steps 352 and 354. In step 352, the membership table 250 is consulted to determine the groups or roles of which the user is a member, and in step 354, the share table 260 lists the accessible objects for each such group. In step 356, the system 100 provides the access information to the user, which includes a list of accessible records for the user.
Accordingly, the security configuration 200 and method 300 provide an optimized response to an access request, while still ensuring that unauthorized users cannot access the data. In one exemplary embodiment, the security configuration 200, and particularly the organization wide default table 230, provides a default level of public access for both internal users and portal users of a tenant, which reduces the processing resources utilized for many type of access requests.
As mentioned above, the various functions and features of the process 300 may be carried out with any sort of hardware, software and/or firmware logic that is stored and/or executed on any platform. For example, various functions shown in
The foregoing detailed description is merely illustrative in nature and is not intended to limit the embodiments of the subject matter or the application and uses of such embodiments. As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any implementation described herein as exemplary is not necessarily to be construed as preferred or advantageous over other implementations. Thus, although several exemplary embodiments have been presented in the foregoing description, it should be appreciated that a vast number of alternate but equivalent variations exist, and the examples presented herein are not intended to limit the scope, applicability, or configuration of the invention in any way. To the contrary, various changes may be made in the function and arrangement of the various features described herein without departing from the scope of the claims and their legal equivalents.
Techniques and technologies may be described herein in terms of functional and/or logical block components, and with reference to symbolic representations of operations, processing tasks, and functions that may be performed by various computing components or devices. Such operations, tasks, and functions are sometimes referred to as being computer-executed, computerized, software-implemented, or computer-implemented. In this regard, it should be appreciated that the various block components shown in the figures may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. For example, an embodiment of a system or a component may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, look-up tables, or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices.
When implemented in software or firmware, various elements of the systems described herein are essentially the code segments or instructions that perform the various tasks. The program or code segments can be stored in a tangible processor-readable medium, which may include any medium that can store or transfer information. Examples of the processor-readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable ROM (EROM), a floppy diskette, a CD-ROM, an optical disk, a hard disk, or the like.
While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope defined by the claims, which includes known equivalents and foreseeable equivalents at the time of filing this patent application.
This application claims the benefit of U.S. provisional patent application Ser. No. 61/329,044, filed Apr. 28, 2010, the entire content of which is incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 61329044 | Apr 2010 | US |
