Fine-grained authorization as a service with relationship-based access control in multi-tenant systems

Abstract

The authorization system provides authorization services to multiple tenant organizations. Authorization is performed based on standardized data types (authorization model and relationship tuples) that are applicable across different organizations. Each organization specifies its own authorization model (representing the types of objects that can exist in the organization and what types of relationships those objects can have) and relationship tuples (representing existing user / object relationships in the organization). When an organization submits an authorization query to determine whether a given user and a given object are in a given type of relationship in a given organization, the system analyzes the authorization model and relationship tuples to make the determination. Query response latency can be reduced by techniques such as geographically distributing servers and sharding data so that data for a given query can be found in the same shard.

Description

[Technical field]

[0001] cross reference

[0001] This patent application is assigned to the assignee of the present specification and claims the benefit of U.S. patent application Ser. No. 17 / 733,644 by Schenkelman et al., filed on April 29, 2022, and entitled "Fine-Grained Authorization as a Service with Relationship-Based Access Control in Multi-Tenant Systems."

[0002]

[0001] TECHNICAL FIELD The present disclosure relates generally to the field of software systems, and more specifically to a system for determining authorization for users and objects in a multi-tenant system. [Background technology]

[0003] background

[0003] The authorization process determines whether a user is authorized to perform a given action on an object. Authorization logic is traditionally hand coded for each individual application or system for which authorization is desired, and the logic that makes the authorization decisions typically shares both code and data stores with the rest of the application's logic, which is time consuming, error prone, and not useful across different systems. Summary of the Invention [Means for solving the problem]

[0004] overview

[0004] The authorization system provides authorization services to multiple tenants / organizations. Authorization is performed based on standardized data types (authorization model and relationship tuples) that are applicable across different organizations. Each organization that wants to use the system for authorization creates one or more tenants. In each tenant, they specify their own authorization model (representing the types of objects that can exist in the organization's system and what types of relationships those objects can have with users and each other) and relationship tuples (representing existing user / object and object / object relationships in the organization's system). When an organization submits an authorization query to determine whether a given user and a given object have a given type of relationship in a given organization (e.g., whether a user can perform a certain action on an object), the system analyzes the authorization model and relationship tuples to determine whether a relationship exists between the user and the object, and makes inferences according to the rules of the authorization model.

[0005]

[0005] In some embodiments, the authorization model is specified using a Domain Specific Language (DSL) that uses Boolean operators, such as the "or" disjunction, to specify which kinds of relationships imply which other kinds of relationships. The DSL simplifies the task of defining the authorization model in a given domain and reduces the burden on users of the authorization system to specify those relationships.

[0006]

[0006] In some embodiments, an organization may use multiple approval models (e.g., different versions of a particular domain model) and the approval system may compare query results using identifiers of the different approval models as input, such as for gradual rollout / rollback of approval logic.

[0007]

[0007] Various relational tuples may be created by software designed to be compatible with the authorization system in response to various user actions, such as creating a document, specifying a user membership in a particular user group, etc. In some embodiments, the relational tuples are distributed across database shards, such that the data required to evaluate a given database query required to respond to an authorization query is available within a single shard, thereby improving computational parallelism and reducing query processing time.

[0008]

[0008] In some embodiments, the DSL can specify the conditions under which a given user of an organization's system (rather than a user of the authorization system itself) may be permitted to create relationship tuples. For example, a particular organization may use the DSL to specify that one of the organization's users who has a certain relationship to an object is permitted to create other relationship tuples that relate to that object.

[0009]

[0009] The features and advantages described herein are not all-inclusive, and many additional features and advantages will become apparent to those skilled in the art, especially in light of the drawings, the specification, and the claims. Furthermore, it should be noted that the language used in this specification has been selected primarily for ease of reading and for explanatory purposes, and may not have been selected to define or limit the content of the invention. [Brief description of the drawings]

[0010] BRIEF DESCRIPTION OF THE DRAWINGS [Figure 1]

[0010] According to one embodiment, an environment is illustrated in which a variety of different organizations use a multi-tenant system to determine whether a particular action of a particular user is approved for that organization. [Diagram 2]

[0011] FIG. 2 is a high-level block diagram illustrating the physical components of a computer used as part or all of the multi-tenant system, client device, or resource server of FIG. 1, according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011]

[0012] The drawings depict embodiments of the present invention for purposes of illustration only, and those skilled in the art will readily appreciate from the following description that alternative embodiments of the structures and methods shown herein may be employed without departing from the principles of the invention described herein.

[0012] Detailed Description

[0013] FIG. 1 illustrates an environment in which various different organizations use a multi-tenant system to determine whether a particular action of a particular user is approved for that organization, according to one embodiment. Each organization 120 provides an application 108. The application 108 is used by a number of client devices 110 that are used by various users 129 of the organization (e.g., if the application is a document authoring application, the users of the application can be direct consumers, as in a business-to-consumer ("B2C") scenario, or employees of a company that is a customer of the application, as in a business-to-business ("B2B") scenario). The users 129 use the client devices 110 to perform various actions, such as using specific applications of the organizations 120 and acting on specific resources within those applications 108. For example, in the case of a document sharing application, users can create and delete documents and folders and share them with other users. In the case of a social network, users can post photos and see photos of their friends. As part of processing a device request, the organization system 120 must make a decision as to whether a user's 129 action is authorized (or more broadly, whether a given relationship exists between two entities, such as a user and an object), which typically occurs at an "enforcement point" 125. An enforcement point 125 is a component in the system that enforces authorization decisions, rejecting requests that are not authorized, and routing / passing through requests that are authorized. A user's client device 121 makes a request to the organization system, and when the request reaches the enforcement point 125, the enforcement point makes a request to the multi-tenant system 100, which provides an authorization decision service. The authorization module 102 responds to the authorization enforcement point 125 with a decision as to whether the action is authorized, and the authorization enforcement point 125 (or other software component that uses it) can take action in accordance with the authorization decision, such as by allowing the user to continue using the application. These aspects are discussed in more detail below.

[0013]

[0014] An organization 120 is an entity such as a business, school, government agency, etc. that has many associated users 129, such as employees, consumers, or employees of the organization's customers. For simplicity, only a single user 129 and client device 121 are shown in FIG. 1, but there may be any number of either.

[0014]

[0015] The client device 121 is a computing device such as a smartphone, a laptop computer, a desktop computer, or any other device that can perform or make a network request (e.g., as part of using a browser) to software that requires an authorization decision.

[0015]

[0016] The resources accessed by users 129 may include resources external to organization 120 itself. For example, resource server 130 may provide access to resources such as web-based applications (e.g., MICROSOFT OFFICE 365™), services, databases, documents, etc.

[0016]

[0017] The organization system 120 may store user data 101, which includes a set of identities of known users associated with the organization. The user data 101 may include one type of identity on the organization system 120, such as a username, as well as other credential data associated with the user, such as a user password and / or information derived therefrom (such as an encrypted form of the password). The user data 101 may also include many other kinds of data about the user, such as the user's role or group within the organization 120 (e.g., "Engineering," "Legal," "Manager 2," "Director," etc.). Some or all of the user data 101 may be stored in addition to or alternatively as part of a relationship tuple 106, which is described in more detail below.

[0017]

[0018] An organization 120 may have a set of applications 108 available to its users. The applications 108 may populate the relationship tuples 106 with information about their respective domains, as described in more detail below.

[0018]

[0019] As mentioned above, the multi-tenant system 100 provides authorization services to different organizations 120 that are tenants of the system. Since each organization 120 may have its own rules and facts for determining whether a particular action or relationship is authorized for that organization, the multi-tenant system 100 stores a set of organization-specific data for each organization 120 that is a tenant. For example, FIG. 1 shows that the multi-tenant system 100 stores an authorization model 104 and a relationship tuple 106 on behalf of each organization 120 for which it provides authorization services. The authorization model 104 defines the types of objects that may exist within the organization 120 and the types of relationships those objects may have with users or other objects. The relationship tuple 106 serves as a "fact" that determines (when querying the system) whether a user has a particular relationship to an object based on the authorization model 104. The authorization model 104 and the relationship tuple together represent a particular domain within which an authorization request can be parsed. The authorization model 104 and the relationship tuple 106 are now described in more detail.

[0019]

[0020] The authorization model 104 represents what kinds of objects can exist in a given tenant / organization system 120 and what kinds of "relationships" they can have, as well as what kinds of relationships imply what other kinds of relationships, which are defined based on the organization's system. A "relationship" is a particular semantic association between two entities in the system, such as ownership, view or print rights, usage rights, the fact that one user "manages" another user, etc. An entity can represent a user 129 of the system, or a non-user object, including an aggregation, such as a group of users or objects.

[0020]

[0021] In one embodiment, the authorization model 104 is specified using a domain-specific language ("DSL"). The DSL defines the types of objects that the tenant's authorization module 102 can reason over, and also represents the types of relationships that those types of objects can have with users or other objects. In one embodiment, the DSL uses Boolean operators such as "or", "and", and "but not" to represent which relationships are inferred by which other relationships. The primary users of the DSL are developers working at each organization. In a multi-tenant system, it is fundamental to simplify the development of authorization models and minimize errors, so that every organization can autonomously and reliably define its own authorization model. A small surface area (e.g., low keyword) DSL that relies on a structural syntax (Boolean operators) familiar to developers when defining relationships is a key element that makes the multi-tenant system 100 valuable.

[0021]

[0022] Listing 1 below provides a specific (albeit intentionally simplified) example of expressing part of an authorization model 104 using such a DSL:

number

[0022]

[0023] In this example, the line "type doc:" specifies that "doc" is a type of object (e.g., representing a document) that can exist in the organizational system 120 associated with the authorization model 104. The lines that follow indicate that the types of relationships a "doc" object can have with a user include "creator", "writer", and "reader" (e.g., representing that a particular user is the creator of a document, can write to a document, or can read from a document, respectively). The DSL keyword "self" implies that a user has a relationship with an object when there is a tuple that directly implies a relationship. For example, given the line "define creator as self" and the tuple (user: "jane", relation: "creator", object: "doc:roadmap"), Jane has a relationship of "creator" to the "roadmap" document. Relationships without self can be defined, e.g., define write as edit. This is useful for relationships that are automatically implied, such as in the case of aliases. In this example, even though the tuple (user:"john", relation:"write", object:"doc:slides") exists, user John does not have a "write" relationship to doc:slides when querying the system for an approval decision because he only has a "write" relationship by having an "edit" relationship. Conceptually, this makes the relationship that defines "self" assignable by the tuple. The "x from y" operator refers to the set of users that have relationship x with object y. The relationship definition "type t define z as x from y" says that a user has relationship z with an object of type t if he has relationship x with an object that has relationship y with an object of type t.For example, given the tuples (user:"folder:root", relation:"parent", object:"doc:slides") and (user:"john", relation:"reader", object:"folder:root") and the previous example, "john" has a relationship of "reader" to "folder:root", "folder:root" has a relationship of "parent" to "doc:slides", and the type "doc" is defined as "define reader as self or writer or reader from parent", so that user "john" has a relationship of "reader" to object "doc:slides", and therefore readers of the folder which is the parent of the document can read the document.

[0023]

[0024] The relationship tuples 106 represent "facts" about user / object relationships within the relevant organizations 120 and form the factual basis for determining whether a given relationship holds. <user> , <relationship> , <object>), which represents the fact that a given user has a relationship with a given object. For example, one relationship tuple for a particular organization might be (user1234, canUse, applicationABC), indicating that a user with unique ID "user1234" has a relationship of "canUse" to an object with unique identifier "applicationABC" (e.g., the user is authorized to use that particular application). As another example, another relationship tuple might be (user1234, creator, documentXYZ), indicating that user "user1234" is the creator of document "documentABC."

[0024]

[0025] In some embodiments, <user>can specify a group of users, such as all members of the "finance" group. <user>The syntax for a tuple component is <object># <relation>For example, group:managers#member specifies the set of all users that have a membership relationship to the "group:managers" object.

[0025]

[0026] The relational tuples 106 may be created by a software component (e.g., application 108) that has knowledge of the domain represented by the authorization model 104. Continuing with the above example of a domain that includes documents and access to documents, a user “u 1 Document for "d 1 A software component that creates (or observes the creation of) a relational tuple (u 1 , creator, doc:d 1 As another example, you can create a user "u 1 A software component that observes that " was added to a group named "accounting" in organization 120 will generate a relational tuple (u 1 , member, group:accounting). In this manner, the software used by the organization 120 is responsible for creating the relationship tuples 106 that are later used to evaluate the authorization request.

[0026]

[0027] In some embodiments, the DSL includes predefined names for relations (e.g., "$tupleReader", "$tupleWriter") that specify the ability of a user of the organizational system 120 (rather than a user of the authorization system 100) to read and write tuples to the relational tuples 106 of the user's organization 120. For example, if Listing 1 above includes the line "define $tupleWriter as creator", that line is used by user u 2 is a document with which it has a creator relationship (i.e. "u 2 has a creator relationship to object d? 1, The authorization system returns true for a query asking for the creator, d) of a document, d). In this case, the client device directly reads and writes to the multi-tenant system 100 to obtain the necessary permissions to perform the action. 2 The organization 120 can pass authorization credentials that the multi-tenant system uses to determine whether the organization has a relationship to the multi-tenant system. The benefit to developers of the organization's system is that they do not need to develop and maintain back-end components for certain use cases, but can instead read and write directly to the multi-tenant system. This allows the organization 120 to specify through its authorization model 104 that users of the organization's system are allowed to write tuples for given objects (e.g., documents) to the relationship tuples 106 if they have certain specified relationships (e.g., "creator") to those objects.

[0027]

[0028] The multi-tenant system 100 has an authorization module 102 that accepts authorization queries originating from users 129 and responds with a determination whether the relationship specified by the query is in fact authorized according to a given authorization model 104 and relationship tuple 106 for the organization. <authmodel> , <user> , <relationship> , <object>), where <user> 、 <relationship>, and <object>constitutes the relationship in respect of which recognition is determined; <authmodel>represents the approval model 104 according to which the decision is made. <authmodel>is one of the authorization models 104 of the organization 120 to which the querying user 129 belongs.

[0028]

[0029] Continuing with the example in Listing 1, user 129 uses his client device 121 to access document d 1 The client device 121 (or the document 1 A server (m) or another system (m) that knows about this attempt, such as the server where m resides or the authorization enforcement point 125, sends a corresponding authorization query to the authorization module 102 on the multi-tenant system 100. In the previous example, the authorization query is 1 , u 1 , writer, d 1 ), m 1 is one of the authorization models 104 of the organization 120 to which the user 129 belongs, and u 1 is a unique identifier for a user 129 within an organization 120, "writer" represents the ability to write documents, and d 1 is the document to be written. In different embodiments, the exact form and content of the query may vary. For example, rather than sending an identifier for an authorization model 104, the component sending the authorization query could simply send an identifier for an organization 120 and leave it to the authorization module 102 to determine which authorization model 104 to use for that organization.

[0029]

[0030] Specific<user, relation, object> To determine if a tuple represents an approved activity, the authorization module 102 traverses (recursively) each relationship definition and evaluates the set of users that have a relationship with the object by considering both Boolean operators and user sets as described above. The response to the query is true if the user is part of the set of users that have a relationship with the object, and false otherwise. Appendix A below specifies pseudocode for making this determination according to some embodiments.

[0030]

[0031] In some embodiments, the multi-tenant system 100 can store multiple authorization models 104 for a single organization 120. There may be separate versions of a single conceptual authorization model, such as a current stable authorization model used in production, and a new authorization model that extends, simplifies, or amends the existing model for a different version, but has not yet been fully tested. In embodiments that allow separate versions of the same conceptual authorization model 104, the model analysis module 103 compares the various versions of the model to determine whether or how the versions lead to different results. This comparison can be used for purposes such as change management and auditing, performing "what if" analysis to evaluate how a particular authorization request would be processed using different models, and / or for purposes such as rolling out changes to authorization policies in a phased manner, evaluating the impact of those changes, and rolling back the changes if they lead to inaccuracies or other undesirable results.

[0031]

[0032] In some embodiments, the multi-tenant system 100 splits data (such as relation tuples 106) into multiple shards that are distributed across various servers. Each shard can be assigned one or more predefined shard keys, each of which consists of the ID of a particular tenant organization 120, a user type (a single user or a collection of users, as discussed above), a relation ID, and an object ID. Thus, as part of the recursive resolution discussed above, when the authorization module 102 needs to query a relation tuple from the database, it computes shardKey = f(tenant, user, relation, object) and all data to resolve the query can be found in the shard with the ID of the shardKey. This not only reduces the time and processing it takes to find data to resolve an authorization query, but also improves parallelization and overall throughput by distributing shards across various servers.

[0032]

[0033] Network 140 may be any suitable communications network for data transmission. In an embodiment such as that shown in Figure 1, network 140 uses standard communications technologies and / or protocols and may include the Internet. In another embodiment, the entities use custom and / or proprietary data communications technologies.

[0033]

[0034] Although the multi-tenant system 100 is illustrated in FIG. 1 as a single entity, it may in fact be comprised of multiple server systems, routers, load balancers, etc. Additionally, in some embodiments, the multi-tenant system 100 is comprised of servers distributed across several different geographic zones (e.g., two in North America, three in Europe, four in Asia, two in Africa, etc.) and configured to route traffic from clients to the closest zone (where "closest" is determined with respect to network speed), thereby minimizing network latency when communicating with organizations' systems 120 in various geographic regions compared to having a single centralized system, while also increasing availability through redundancy in case of failure of a single region. In scenarios where data location is a concern for privacy and / or compliance reasons, the multi-tenant system may be deployed in specific selected geographic zones (e.g., four in Europe).

[0034]

[0035] The multi-tenant system 100 can store detailed logs of all operations performed that can be used by organizations for a variety of purposes, including audit trails and export for security analysis, among others. Log entries include relationship tuple changes, authorization model changes, and each authorization query to see if a user has access.

[0035]

[0036] 2 is a high-level block diagram illustrating the physical components of a computer 200 used as part or all of the multi-tenant system 100, client device 121, or resource server 130 of FIG. 1, according to one embodiment. Shown is at least one processor 202 coupled to a chipset 204. Also coupled to the chipset 204 are memory 206, storage 208, a graphics adapter 212, and a network adapter 216. Coupled to the graphics adapter 212 is a display 218. In one embodiment, the functionality of the chipset 204 is provided by a memory controller hub 220 and an I / O controller hub 222. In another embodiment, memory 206 is coupled directly to the processor 202 instead of the chipset 204.

[0036]

[0037] Storage device 208 is any non-transitory computer-readable storage medium, such as a hard drive, compact disc read only memory (CD-ROM), DVD, or solid-state memory device. Memory 206 holds instructions and data used by processor 202. Graphics adapter 212 displays images and other information on display 218. Network adapter 216 couples computer 200 to a local or wide area network. Keyboard 210 and pointing device 214 allow a user to manually provide input. Audio input (e.g., microphone) 224 and output (e.g., built-in or external speakers) 226 provide the capability to obtain audio input (e.g., for voice recognition) and provide audio output.

[0037]

[0038] As is known in the art, computer 200 may have different and / or other components than those shown in FIG. 2. Additionally, computer 200 may lack certain components shown. In one embodiment, computer 200 operating as a server (e.g., a server of multi-tenant system 100) may lack graphics adapter 212 and / or display 218, as well as keyboard 210, pointing device 214, and / or audio input 224 and output 226. Additionally, storage device 208 may be local and / or remote (such as embodied in a storage area network (SAN)) from computer 200.

[0038]

[0039] As is known in the art, computer 200 is adapted to execute computer program modules for providing the functionality described herein. As used herein, the term "module" refers to computer program logic utilized to provide a specified functionality. Thus, a module may be implemented by hardware, firmware, and / or software. In one embodiment, the program modules are stored on storage device 208, loaded into memory 206, and executed by processor 202.

[0039]

[0040] Implementations of the entities described herein may include other and / or different modules than those described herein. Additionally, in other embodiments, functionality attributed to a module may be performed by other or different modules. Furthermore, this specification may omit the term "module" for clarity and convenience.

[0040] Other considerations

[0041] One possible embodiment has been described herein. Those skilled in the art will appreciate that other embodiments may be practiced as well. First, the specific naming of components and variables, capitalization of terms, attributes, data structures, or any other programming or structural aspect is not required or important, and the mechanisms described may have different names, formats, or protocols. Furthermore, the specific division of functionality between various system components described herein is for illustrative purposes only and is not required, and functionality performed by a single system component may instead be performed by multiple components, and functionality performed by multiple components may instead be performed by a single component.

[0041]

[0042] Some of the above descriptions have presented features of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. While these operations have been described in functional or logical terms, it will be understood that they are implemented by computer programs. Further, it has proven convenient at times, without loss of generality, to refer to the arrangement of these operations as modules or by functional names.

[0042]

[0043] Unless otherwise specified, as is apparent from the above discussion, the discussion utilizing terms such as "determining" or "displaying" throughout the description will be understood to refer to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's memory or registers or other such information storage, transmission, or display devices.

[0043]

[0044] Certain aspects described herein include process steps and instructions in the form of an algorithm. It should be noted that the process steps and instructions may be embodied in software, firmware, or hardware, and if embodied in software, may be downloaded to reside on and be operated from different platforms used by a real-time network operating system.

[0044]

[0045] The concepts described herein also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes or may include a general purpose computer selectively activated or reconfigured by a computer program stored on a computer-readable medium accessible by the computer. Such a computer program may be stored in a non-transitory computer-readable storage medium, such as, but not limited to, a floppy disk, an optical disk, a CD-ROM, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic or optical card, an application specific integrated circuit (ASIC), or any type of computer-readable storage medium suitable for storing electronic instructions and each coupled to a computer system bus. Furthermore, the computers referred to herein may include a single processor or may be architectures employing designs including multiple processors to increase computing power.

[0045]

[0046] The algorithms and operations presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems can also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems, along with equivalent variations, will be apparent to those skilled in the art. Additionally, the concepts described herein are not described in reference to any particular programming language. It will be understood that a wide variety of programming languages ​​can be used to implement the teachings described herein, and any reference to a specific language is made for purposes of enablement and best mode.

[0046]

[0047] The concepts described herein are well suited to a wide variety of computer network systems across numerous topologies, including the configuration and management of large networks including storage devices and computers communicatively coupled to disparate computers and storage devices over networks such as the Internet.

[0047]

[0048] Finally, it should be noted that the language used herein has been chosen primarily for ease of reading and for explanatory purposes, and may not have been chosen to define or limit the subject matter of the invention. Accordingly, the present disclosure is intended to be illustrative, but not limiting, of the scope of the concepts described herein as set forth in the appended claims.

[0048] Appendix A The pseudocode function "check" below, given a tuple (u, r, o), returns true if user u has a relationship with object o and r (i.e., the user belongs to the set of users who have that relationship), and false otherwise. Clients are instructed to interpret true as the user being authorized to perform operations on the object that the relationship grants permission to, and false as not being authorized. Boolean operators in the DSL are translated into set-theoretic operators before parsing the query. - "define x as a or b" means that a user has relationship x with that type of object if he belongs to a set of users that is part of the "union" of sets a and b, where a and b are sets of users that have a / b relationship with that type of object. - "define x as a and b" means that a user has relationship x with that type of object if he belongs to a set of users that is part of the "intersection" of sets a and b, where a and b are sets of users that have a / b relationship with that type of object. - "define x as a but not b" ​​means that a user has a relationship of x with that type of object if he belongs to a set of users that is part of the "difference" of sets a and b, where a and b are the sets of users that have a relationship of a / b with that type of object. The "x from y" operator is handled internally as the "tuple to userset" case.

number

number

Claims

1. 1. A computer-implemented method for authorizing a user in a cloud-based multi-tenant system, comprising: receiving, from an administrator of a first tenant of the multi-tenant system, an authorization model indicating object types of the first tenant and types of relationships those object types may have with users of the first tenant, the authorization model being expressed in a declarative domain-specific language that uses Boolean OR operators; receiving a relationship tuple indicating a particular relationship between a particular user and a particular object; receiving a request to determine whether a first user of the first tenant is authorized to perform a first action on a first object; using the authorization model and inferences from the relationship tuples to determine whether the first user is authorized; and Responding to the request with the determination whether the first user is authorized.

4. A computer-implemented method comprising:

2. receiving a revised authorization model that differs from the authorization model; and comparing the approval decision of the approval model with the approval decision of the revised approval model to identify inconsistencies; The computer-implemented method of claim 1 , further comprising:

3. 2. The computer-implemented method of claim 1, wherein the received authorization model includes rules that allow a user having a given relationship with an object to add / remove a relationship tuple that references the object to the relationship tuple or read a relationship tuple that references the object.

4. The computer-implemented method of claim 1 , wherein the relationship tuple is received in response to an action associated with a user of the first tenant from a software component designed to operate in the multi-tenant system.

5. The computer-implemented method of claim 1 , further comprising logging the requests and the responses to the requests in persistent storage.

6. When executed by a computer processor, receiving, from an administrator of a first tenant of a multi-tenant system, an authorization model indicating object types of the first tenant and types of relationships those object types may have with users of the first tenant, the authorization model being expressed in a declarative domain-specific language that uses Boolean OR operators; receiving a relationship tuple indicating a particular relationship between a particular user and a particular object; receiving a request to determine whether a first user of the first tenant is authorized to perform a first action on a first object; using the authorization model and inferences from the relationship tuples to determine whether the first user is authorized; and Responding to the request with the determination whether the first user is authorized.

16. A computer-readable storage medium storing instructions for performing actions including:

7. The action is receiving a revised authorization model that differs from the authorization model; and comparing the approval decision of the approval model with the approval decision of the revised approval model to identify inconsistencies; The computer-readable storage medium of claim 6 , further comprising:

8. 7. The computer-readable storage medium of claim 6, wherein the received authorization model includes rules that allow a user having a given relationship with an object to add / remove a relationship tuple that references the object to the relationship tuple or to read a relationship tuple that references the object.

9. 7. The computer-readable storage medium of claim 6, wherein the relationship tuple is received in response to an action associated with a user of the first tenant from a software component designed to operate in the multi-tenant system.

10. The computer-readable storage medium of claim 6 , wherein the actions further comprise logging the request and the response to the request in persistent storage.

11. A computer processor; When executed by a computer processor, receiving, from an administrator of a first tenant of a multi-tenant system, an authorization model indicating object types of the first tenant and types of relationships those object types may have with users of the first tenant, the authorization model being expressed in a declarative domain-specific language that uses Boolean OR operators; receiving a relationship tuple indicating a particular relationship between a particular user and a particular object; receiving a request to determine whether a first user of the first tenant is authorized to perform a first action on a first object; using the authorization model and inferences from the relationship tuples to determine whether the first user is authorized; and Responding to the request with the determination whether the first user is authorized. A computer-readable storage medium storing instructions for performing actions including: A multi-tenant computer system comprising:

12. The action is receiving a revised authorization model that differs from the authorization model; and comparing the approval decision of the approval model with the approval decision of the revised approval model to identify inconsistencies; The multi-tenant computer system of claim 11 further comprising:

13. 12. The multi-tenant computer system of claim 11, wherein the received authorization model includes rules that allow a user having a given relationship with an object to add / remove a relationship tuple that references the object from the relationship tuple or to read a relationship tuple that references the object.

14. 12. The multi-tenant computer system of claim 11, wherein the relationship tuple is received in response to an action associated with a user of the first tenant from a software component designed to operate in the multi-tenant system.

15. The multi-tenant computer system of claim 11 , wherein the actions further include logging the request and the response to the request in persistent storage.

Images