Authorization policy verification

Abstract

A system and method for authorization policy verification. A verifier inputs authorization policies to be analyzed and patterns specifying entity types and attributes thereof, types of entity parents in an entity hierarchy, and which entity types can be used with which actions. The verifier checks whether the policy conforms to the pattern. If the check is passed, it is ensured that the policy has no type error and attribute access error for any input conforming to the mode.

Description

Technical Field

[0001] The present disclosure generally relates to computer security and, more particularly, to novel and useful systems and methods for authorization policy verification. Background Art

[0002] Provider network (equivalent to "cloud") computing provides on-demand access to provider network resources via the Internet or other intermediate networks. Access to resources in the provider network is secured by access control policies specified by users. An access control policy is an expressive specification of which resources can be accessed, by whom, and under what conditions. A properly configured policy is an important part of an organization's security posture.

[0003] The scale and diversity of provider network-based services are growing continuously. For example, a provider network can cover serverless computing services, stream analysis services, edge computing services, and many other possible services. Each product of the new provider network services used by an organization typically requires a different access policy configuration. As a further complication, customers combine provider network services to implement an overall application, which increases the complexity of managing access control policies. Therefore, the challenge for customers of provider networks is to reason about static access control policies for their dynamic provider network-based applications. Customers would appreciate a solution that allows them to check their policy configurations based on their security requirements. The present disclosure provides a solution to this and other needs. Brief Description of the Drawings

[0004] Various examples in accordance with the present disclosure will now be described with reference to the drawings, in which:

[0005] Figure 1 An example authorization policy language system in a provider network is shown.

[0006] Figure 2 An example authorization policy language system in a provider network is shown.

[0007] Figure 3 An example data model and semantics of an authorization policy language are shown.

[0008] Figure 4 An example syntax of an authorization policy language is shown.

[0009] Figure 5 An alternative example syntax of an authorization policy language is shown.

[0010] Figure 6 An example syntax of an authorization policy language is shown.

[0011] Figure 7 An example authorization engine in a provider network is shown.

[0012] Figure 8 Presents an authorization semantic definition.

[0013] Figure 9 Shows an example entity hierarchy.

[0014] Figure 10 Shows a system and method for differential random testing of an authorization engine.

[0015] Figure 11 Presents a satisfiability modulo theories (SMT) formula.

[0016] Figure 12 Presents an example policy language pattern.

[0017] Figure 13 Presents an example symbolic authorization request.

[0018] Figure 14 Presents an example symbolic entity store.

[0019] Figure 15 Presents an example symbolic record type.

[0020] Figure 16 Shows a satisfiability modulo theories (SMT) analysis.

[0021] Figure 17 Shows an example of a provider network environment in which the techniques disclosed herein are implemented.

[0022] Figure 18 Shows an example of an electronic device used in an implementation of the techniques disclosed herein.

[0023] It should be understood that, for simplicity or clarity of illustration, the elements shown in the figures are not necessarily drawn to scale. For example, the dimensions of an element may be exaggerated relative to another element for clarity. Additionally, where considered appropriate, reference numerals have been repeated in the figures to indicate corresponding or similar elements. Detailed Description

[0024] The following description is not intended to limit the invention to the described examples, but to enable any person skilled in the art to make and use the invention.

[0025] Overview

[0026] Systems, methods, and non-transitory computer-accessible media (collectively, the "techniques") are disclosed for an authorization policy language system and method that allow a user to manage access to application resources in a provider network. Permissions granted by a policy are based on the interaction of different statements and conditions. The policy language system and method support statements that grant access (permit statements) or deny access (forbid statements). Conditions in a statement can be based on access details such as source address, encryption, and other configuration options.

[0027] In some aspects, the techniques disclosed herein include systems and methods for authorization policy analysis. A policy analyzer answers first-order questions about an authorization policy by reducing the policy to Satisfiability Modulo Theories (SMT). The input to the analyzer includes the policy to be analyzed and the schema of the policy. If the policy passes strict validation against the schema, the analyzer symbolically evaluates the policy to encode its semantics as an SMT expression. The SMT expression is used to formulate desired queries about the behavior of the policy, e.g., to determine if there exists any input for which both policies evaluate to true. Reduction to SMT results in a quantifier-free formula in a combination of decidable theories to support large-scale deployment. This reduction is achieved by focusing the analysis on policies that pass strict validation rather than attempting to analyze arbitrary policies.

[0028] In some aspects, the techniques disclosed herein cover systems and methods for authorization policy evaluation. Authorization policies are written in a general authorization language. Application developers use an evaluation engine in a provider network to manage access within their applications based on fine-grained permissions. The policy language combines role-based and attribute-based access control elements in an intuitive syntax and an efficient evaluation policy. The policy syntax separates role-based policy expressions from attribute-based policy expressions.

[0029] In some aspects, the techniques disclosed herein cover systems and methods for authorization policy verification. A validator takes as input an authorization policy to be analyzed and a schema that specifies entity types and their attributes, the types of entity parents in an entity hierarchy, and which entity types can be used with which actions. The validator checks whether the policy conforms to the schema. If the check passes, it is guaranteed that the policy has no type errors and no attribute access errors for any input that conforms to the schema.

[0030] Policy Language Overview

[0031] The techniques cover a domain-specific policy language for authorization. The policy language system and method provide an easy-to-use syntax and semantics, a fast and secure runtime, and powerful static analysis tools. Authorization is crucial for security. Thus, the policy language system and method provide a high degree of assurance using techniques such as automated reasoning and differential testing.

[0032] Authorization is the process of determining who can access what in a multi - user system, such as a multi - user application (equivalent to a "provider network application") built using a provider network infrastructure. More specifically, authorization determines whether a principal can perform an action on a resource. For example, the principal can be a user of the provider network application. In this example, authorization can involve determining whether a user has the right to perform a specific action (e.g., view) on a resource (e.g., digital photos) managed by the application.

[0033] Although a provider network application can perform authorization itself, it is better to delegate the authorization decision to a dedicated authorization engine. To facilitate this, the authorization engine provides an application programming interface or API. The API accepts a quadruple representing an authorization request as input (equivalent to an "authorization request"). The quadruple specifies the principal, the action, the resource, and the request context. The request context contains context information about the authorization request. The context information can include information such as the network address, the current date - time stamp, a set of key - value pairs (equivalent to a set of "tags"), or any other suitable request context information.

[0034] The authorization engine processes the authorization request and returns a binary answer indicating whether the authorization request is allowed or denied. The authorization engine makes an allow or deny decision based on one or more policy sets. Each policy covers one or more statements in a policy language. These statements specify allowed and prohibited actions based on application data. For example, the application data can be the group to which a user belongs or the attributes of a resource.

[0035] Now turn to Figure 1 , which illustrates authorization through a simple example. Provider network 100 includes an authorization engine 102 and a provider network application 104. Provider network 100 is connected to a remote electronic device 106 via an intermediate network 108. Intermediate network 108 is the Internet or other intermediate data communication network. In this example, provider network application 104 is a photo - sharing application. The example of the photo - sharing application is only used to illustrate the concept of authorization. The authorization and policy language system and method are not limited to any specific provider network application.

[0036] The example photo sharing application provides features that can be expected of such an application. The features include the ability of the users of the application to organize photos into albums. The albums can be arranged hierarchically. For example, the "trips" album includes the "conference" album and the "vacation" album as descendant albums. The "art" album has no ancestor or descendant albums. In this example, the user "Jane" uploaded two photos and organized the two photos into albums. Each of the photos is labeled with the name of the photo. The "receict.jpg" photo is additionally labeled "private", and the "flower.jpg" photo is additionally labeled "nature". The "receipt.jpg" picture is grouped into the "conference" album, and the "flower.jpg" photo is grouped into the "vacation" album and the "art" album.

[0037] The features of the photo sharing application also include the ability of the users of the application to share their photos with other users of the application. The photo sharing application provides a group mechanism to facilitate photo sharing. In this example, Jane created three groups: the "team" group, the "family" group, and the "friends" group. Similar to the albums, the groups can also be arranged hierarchically. For example, the "family" group is configured as a descendant group of the "friends" group. Jane's configuration of groups, albums, and photos is part of the application data 110 of the provider network application 104. Although in this example, the application data 110 includes data about photos, albums, and photo sharing groups, depending on the particular provider network application 104 at hand, the application data 110 will vary from provider network application to provider network application. Therefore, Figure 1 the application data 110 depicted is merely an example of possible application data.

[0038] Continuing with the example of the photo sharing application, Jane uses the photo sharing application to allow anyone in Jane's group of "friends" to view any photo in Jane's "travel" album. The photo sharing application has saved Jane's preferences as example authorization policy 112. Authorization policy 112 includes statements expressing Jane's preferences in a policy language. In this example, authorization policy 112 allows all principals in Jane's group of "friends" (including all principals in any derived groups, such as the "family" group) to view any resource in Jane's "travel" album, including any derived albums (such as the "vacation" album and the "art" album). In example authorization policy 112 and other examples in this document, two-digit line numbers followed by a single colon character (":") are used as references in this description. However, line number designations may not appear in actual authorization policy data.

[0039] In addition to end-user permissions, the developers of the photo sharing application may want to configure a base or safeguard policy that applies to all users. For example, the developers may want to prevent any user of the photo sharing application from performing any action on a resource marked as "private" that the user does not own. This policy is represented by example authorization policy 114. Line 01 of authorization policy 114 is the effect of the policy "forbid". In this example, the effect of the policy does not impose any restrictions on the principal, action, or resource. Thus, authorization policy 114 applies to all authorization requests from provider network application 104. Lines 02 - 05 represent the state of policy 114. Authorization policy 114 can be interpreted as forbidding any principal from performing any action on a resource marked as private and the resource is not in the principal's account.

[0040] Given authorization policy 112, authorization policy 114, and application data 110, provider network application 104 can use authorization engine 102 to answer authorization requests and decide which end-user actions should be allowed and which should be denied. As a first example, at step "1", user "Alice" uses their remote electronic device 106 to send a request to provider network application 104 to view Jane's photo named "flower.jpg". User "Alice" can send the request using the command line interface 116, graphical user interface 118, or software development kit 120 of remote electronic device 106. In any case, the request is sent from remote electronic device 106 to provider network application 104 via intermediate network 108. For example, the request can be a Hypertext Transfer Protocol (HTTP) request or a similar request. The request is represented by the circle labeled "1". Figure 1 in the

[0041] In response to receiving Alice's request in step "1", the provider web application 104 sends an authorization request 122 to the authorization engine 102 in step "2". The authorization request 122 designates the user "Alice" as the principal, the requested action as "view", and the resource to be processed as the "flower.jpg" photo in Jane's photo album. The authorization request 122 also designates a request context, which may include context information such as the network address of the remote electronic device 106 and one or more sets of key-value pairs of the authentication session established for Alice. In this example, the authorization engine 102 will allow the authorization request 122 based on authorization policies 112 and 114 because according to authorization policy 112, Alice is permitted to view the "flower.jpg" photo, and authorization policy 114 does not prohibit Alice from performing the action on the resource. More specifically, Alice is in Jane's "Friends" group, the action is "view", and the resource requested to be viewed is in Jane's "Travel" photo album. Therefore, authorization policy 112 permits the requested action. Authorization policy 114 does not prohibit the requested action because the requested resource is not marked as private. Since the authorization request 122 is allowed, the "flower.jpg" photo is returned in step 4.

[0042] Figure 2 A case is shown where Alice requests to view Jane's "receipt.jpg" photo instead of the "flower.jpg" photo. In this case, the authorization request 222 is rejected by the authorization engine 102 because it is prohibited by authorization policy 114. Specifically, authorization policy 114 prohibits the authorization request 222 because the "receict.jpg" photo is marked as "private" and the photo is in Jane's account rather than in Alice's account. Although authorization policy 112 permits the authorization request 222, the authorization engine 102 still rejects the authorization request 222 because there is at least one authorization policy (i.e., policy 114) that prohibits the authorization request 222. In other words, by default, a policy that prohibits an authorization request overrides any policy that permits the authorization request.

[0043] The policy language strikes a balance between expressiveness, performance, and analyzability. In particular, the policy language strikes a balance between being expressive enough to allow users to express most of the policies they want to express and being restrictive enough to provide good evaluation / runtime performance and analyzability. Analyzability refers to the ability of end-users to debug their own policies written in the policy language using static analysis tools. For example, the policy language does not support loops because this would not guarantee that the evaluation of the policy would terminate, nor would it guarantee good evaluation / runtime performance. The policy language does support aggregate data types. Some examples of aggregate data types include lists, maps, and sets. Nevertheless, depending on which aggregate data types the policy language supports and which operators the policy language supports on the aggregate data types, providing precise analyzability of the policy language can become impractical. The policy language supports certain aggregate data types and certain operators on these aggregate data types without sacrificing the precise analyzability of the policies written in the policy language.

[0044] In addition, the policy language is both fast and secure. Thus, an authorization engine that evaluates whether an authorization request should be allowed or denied based on policies written in the policy language is written in a programming language that emphasizes performance, type safety, and concurrency. In addition, the programming language can support memory safety without using a garbage collector or reference counting. Instead, the programming language enforces that all references point to valid memory. For example, to enforce memory safety and prevent concurrent data races at the same time, the programming language can use a borrow checker to track the object lifetimes and variable scopes of all references in the program during compilation. For example, the programming language can be the Rust programming language, which provides a good balance between security and performance. However, programming languages other than Rust can be used as long as they are memory-efficient, fast, and memory-safe like Rust.

[0045] Users writing policies in the policy language may still make mistakes when translating their intentions into statements of the policy. For example, a user may write a policy or a set of policies that works in most cases but is too permissive in some extreme cases, resulting in security issues. As another example, a user may write a policy or a set of policies that works in most cases but is too restrictive in some extreme cases, resulting in usability issues. The techniques disclosed in this document cover a policy analysis tool that can reason about all possible requests of a policy and all possible states of the policy to detect such extreme cases.

[0046] Existing policy languages either provide high expressiveness at the cost of low performance and low analyzability, or provide high performance at the cost of low expressiveness. For example, existing policy languages provide high performance, but for many applications, their expressiveness is insufficient. Such existing languages allow policy specifications for groups, but do not allow policy specifications for resource attributes and subject attributes. In contrast, the policy language of the present disclosure allows policy specifications for groups as well as resource attributes and subject attributes, while still having performance. In other words, the policy language of the present disclosure provides an effective balance among expressiveness, performance, and analyzability that existing policy languages do not provide.

[0047] Policy languages help write policies based on the application data of provider network applications. The application data of provider network applications varies from application to application. Specifically, policy languages help write permissions based on group membership and the attributes of application-specific entities. For example, Figure 1 and Figure 2 authorization policies 112 and 114 in the example photo sharing application of

[0048] are about entities specific to the photo sharing application (such as photos, albums, shared groups). These entities are specific to photo sharing and do not necessarily involve all provider network applications.

[0049] In some cases, end users of a provider network application do not write permission policies in a policy language. Instead, the permission policies will be automatically generated by the provider network application or written by developers of the provider network application. However, in some cases, depending on the current provider network application, end users of the provider network application can directly write permission policies in the policy language. For example, in the case of a photo sharing application, the functionality of the photo sharing application pro version can allow end users (such as professional photographers) to write complex boolean permissions and conditions to protect their photos in order to allow their own customers to preview and potentially purchase the photos. To support the situation of exposing permission policies to users of the provider network application, the policy language has a simple and intuitive syntax and semantics through which permission policies can be written without studying or reading the language specification.

[0050] Policy Language Data Model and Semantics

[0051] The data model of the policy language system and method is centered around the concept of entities. Entities are grouped into hierarchies and entities have attributes. Entities can be regarded as reference values, in other words, names of objects. The name can adopt a specific format. For example, the name can include an entity type identifier and an identifier of the entity instance. The instance identifier is a globally unique identifier. Examples in this article use simple type names and instance identifiers in order to provide clear examples. However, in actual implementations, the entity type name and entity instance identifier may be more complex. For example, the entity instance identifier can be a GUID, which is a 128-bit text string that provides a unique reference value. In addition, the entity type name and entity instance identifier can be qualified within their unique namespace. For example, each provider network application can have its own namespace or set of namespaces. Therefore, it is not required that the entity type name or entity instance identifier be probabilistically unique across all time and space.

[0052] Figure 3 An example entity hierarchy 302 of an example photo sharing application is shown. Each node in the hierarchy 302 corresponds to an entity. For example, at the root node of the hierarchy 302 is a node representing the entity that is the account related to the photo sharing application for Jane. The entity name of the Jane account includes the entity type identifier "account" and the entity instance identifier of the string "Jane".

[0053] A policy language system and method represents an entity hierarchy for a provider network application as a directed acyclic graph or DAG. The DAG represents how entities are grouped in the hierarchy. The entity hierarchy can be referenced by policies written in the policy language. To support traversing the entity hierarchy in a policy, the policy language provides the IN operator. The IN operator can be used in a policy to test whether there is a path in the hierarchy between two nodes in the DAG. A policy statement A IN B (where A and B are entities in the entity hierarchy) tests whether entity A is a descendant of entity B in the DAG. For example, referring to example policy statement 304 that uses the IN operator, the evaluation of policy statement 304 by the authorization engine will return true because in the entity hierarchy 302, the Photo::"flower.jpg" entity is a descendant of the Account::"Jane" entity. In fact, in the entity hierarchy 302, there are multiple paths from the Photo::"flower.jpg" entity to the Account::"Jane" entity. On the other hand, policy statement 306 will evaluate to false because in the entity hierarchy 302, there is no path from the Photo::"flower.jpg" entity to the Album::"Jane / Conference" entity.

[0054] Determining reachability in a graph can be an inefficient operation. The authorization engine of the policy language system and method uses an index to facilitate efficient evaluation of policy statements using the IN operator. This index is referred to herein as the entity store. For each entity in the entity hierarchy, the entity store persistently stores the set of all entities in the hierarchy that are ancestors of the given entity in the hierarchy. This is referred to herein as the entity ancestor mapping. For example, an entry in the entity ancestor mapping can map the identifier of an entity to the set of entity identifiers of entities in the hierarchy that are ancestors of the given entity. For example, an entry in the entity ancestor mapping for the entity hierarchy 302 can map Photo::"flower.jpg" to the set [Album::"Jane / Vacation", Album::"Jane / Art", Album::"Jane / Trips", Account::"Jane"]. By using the entity ancestor mapping, the authorization engine can evaluate policy statements using the IN operator in constant time. For a policy statement A IN B that uses the IN operator, the authorization engine can simply retrieve the entry in the entity ancestor mapping for entity A and test whether B is a member of the set of ancestors for that entry. This is a constant time operation for the authorization engine.

[0055] An entity can have attributes. The set of attributes of an entity is sometimes referred to in this document as the attribute record of the entity or the entity's attribute record. The attribute record can be represented as a JSON object or the like. The attribute record is a mapping from string values to other values. The other values can be primitive data types such as boolean values, numerical values, string values, and entity identifiers. However, the other values can also be other records or sets of values. Since the attribute record can be represented as a JSON or similar object, it is convenient for a provider web application to provide the attributes of an entity to the provider network system and method in the form of a JSON or similar object. Since JSON and the like are common ways for a provider web application to represent its application data, this ability of the policy language system and method makes it easier for the provider web application to integrate with the policy language system and method.

[0056] The policy language supports other operators. For example, the policy language supports the dot ('.') operator. The dot operator works uniformly among entities, attribute records, and nested attribute records. For example, the example policy statement 308 refers to the value of the "aspect" attribute of the Photo::"flower.jpg" entity as a nested record and further accesses the value of the "w" attribute of the nested record. Thus, the policy language supports composing policy statements that dereference a chain of one or more entities, records, and nested records without worrying about whether it is an entity or a record that is dereferenced by a given dot operator in the chain.

[0057] The dereferenced entity or record may or may not have the specified attribute. If the entity or record does not have the specified attribute, the authorization engine will return a throw or raise an error at evaluation time. The result of the error is that the authorization engine will treat the policy as an implicit denial. The policy language provides the "has" operator. The has operator can be used in a policy statement to test at runtime whether the specified entity or record has the specified attribute before attempting to dereference the attribute using the dot operator. For example, the policy statement 310 uses the has operator or predicate to test whether the Photo::"flower.jpg" entity has the "color" attribute. Adding the evaluation time, the authorization engine will evaluate the policy statement 310 as true because the specified entity does have the specified attribute. On the other hand, the authorization engine will evaluate the policy statement 312 as false because the Photo::"flower.jpg" entity does not have the "location" attribute.

[0058] To facilitate the effective evaluation of policies written in a policy language by an authorization engine during evaluation, in addition to the entity ancestor mapping, the entity store can also store an entity attribute mapping. The entity attribute mapping maps an entity to an attribute record. For example, an entry in the entity attribute mapping can map the identifier of an entity to a JSON or similar object representing a record. During evaluation, the authorization engine can use the identifier of the entity to retrieve from the entity attribute mapping a JSON or similar object representing the entity record. The authorization engine can then continue to evaluate the policy based on the JSON object. The entity attribute mapping of the entity hierarchy facilitates constant-time lookup of the attribute record of a given entity in the entity hierarchy.

[0059] Although the policy language supports using collections as values in records, the policy language does not support lists. A list can be regarded as an ordered collection of values. The reason for not supporting lists is related to the analyzability of the policy language. In particular, no solution has been found to encode the contains operator on lists for precise SMT analysis. Examples of the contains operator on lists include A.contains(B) (Is B an element of list A?), A.containsAll(B) (Does list A contain all elements of B?), and A.containsAny(B) (Does list A contain any element of B?). However, precise SMT analysis can be performed using sets. Roughly speaking, the reason for using sets instead of lists for precise SMT analysis is that lists can contain duplicates and are sensitive to ordering, while sets are not. This is an example of how the policy language sacrifices some expressiveness but gains analyzability.

[0060] Policy language

[0061] Figure 4 An example of a typical authorization policy written in the policy language is provided. Example policy 402 includes three parts called effect 404, header 406, and optional condition 408. The effect of an authorization policy states what the effect of the policy is (e.g., allow or deny). The header of an authorization policy specifies hierarchical constraints, such as equality or IN operators on the subject, action, or resource. The condition is optional and is a boolean-valued expression on the subject, action, resource, or request context.

[0062] The head of a policy typically corresponds to Role - Based Access Control (RBAC) rules. The conditions of a policy typically correspond to Attribute - Based Access Control (ABAC) rules. The boolean expressions in the "when" clause of a condition can essentially be a pure - function subset of languages such as Java or JavaScript. For example, the "when" clause can contain any one or all of the following expressions: if - then - else expressions, short - circuit boolean operators, property access (.), property existence (has), equality (==), hierarchical constraints (in), arithmetic comparison operators (<, <=, >, >=), string wildcard matching (like), or function and method calls. For performance and analyzability purposes, the policy language does not support loops, parameterized iteration, or side - effects (mutations) in the "when" clause of a condition.

[0063] The head of a policy can test for equality (==) or hierarchical inclusion (in). The policy language restricts the head of a policy to only these two types of expressions. In addition to Figure 4 the other types of expressions listed in

[0064] Since the types of expressions permitted in the policy head are a subset of the types of expressions permitted in the policy condition, a policy can combine the head and the condition into a syntactic structure. Figure 5 Example policy 502 provides an example of policy 402 that combines head 406 and condition 408. However, for readability, the policy language syntactically and semantically distinguishes between the head and the condition. Specifically, a reader of policy 402 can quickly discern whether policy 402 is a pure role - based access control policy, a pure attribute - based access control policy, or a hybrid of role - based access control and attribute - based access control policies. Specifically, a pure role - based access control policy contains only a head and no condition. A pure attribute - based access control policy contains a condition, but its head has no membership restrictions. A policy that is a hybrid of role - based access control and attribute - based access control policies (such as policy 402) contains a head and a condition that have constraints on membership. In contrast, for Figure 5 the combined policy 502, compared to policy 402, a reader cannot quickly discern which expressions are role - based access control expressions and which are attribute - based access control expressions because the combined policy 502 syntactically mixes role - based access control expressions with attribute - based access control expressions, while policy 402 syntactically separates role - based access control permissions from attribute - based access control permissions.

[0065] Another reason for the policy language to separate the header from the condition is performance. Separating them facilitates slicing. Slicing is the ability of the authorization engine to determine whether an authorization request should be allowed or denied by evaluating only a subset of the entities, attributes, or policies that apply to the authorization request. The entity store of the provider network application can be large. There may be millions or even billions of entities, attributes, and policies. Therefore, the evaluation performance of the authorization engine for policies is crucial. For example, it may not be possible to load all the entities, attributes, and policies that apply to an authorization request into memory at the same time.

[0066] The authorization engine can remove a policy from the evaluation for an authorization request based on the header of the policy. In particular, when the header of a policy imposes a hierarchical constraint on the request subject or the request resource, if the subject of the policy is not an ancestor of the request subject in the entity hierarchy, or if the resource of the policy is not an ancestor of the request resource in the entity hierarchy, the authorization policy can be removed from the evaluation. Consider Figure 6 the example. It depicts an example authorization policy 602 with an example header 604 and an example condition 606, as well as an example authorization request 608 and an example entity hierarchy 610. If the entity Group::“Jane / Family” is not an ancestor of the entity User::“John” in the entity hierarchy 610, or if the entity Album::“Jane / Art” is not an ancestor of the Photo::“receipt.jpg” in the entity hierarchy 610, the authorization engine does not need to evaluate the policy 602 against the authorization request 608. Recall that the entity store contains an entity ancestor map that can efficiently and in constant time determine whether an entity is an ancestor of another entity in the entity hierarchy. Therefore, the authorization engine can use the header of the policy to effectively determine whether the policy needs to be evaluated against an authorization request.

[0067] The authorization engine

[0068] Figure 7Shows a policy language engine 710 in the context of a provider network 700. The policy language engine 710 includes a deserializer 712, a parser 714, and an authorization engine 722. A provider network application (e.g., application 104) provides entity data 704 to the policy language engine 710. The entity data 704 represents the application data (e.g., application data 110) of the provider network application for which the developer of the provider network application desires an access control policy. The entity data 704 can be provided in a convenient serialized form, such as JSON or a similar format. The deserializer 712 deserializes the entity data 704 and constructs an entity ancestor map and an entity attribute map in the entity store 718 based on the deserialized form of the entity data 704. The constructed entity ancestor map and entity attribute map index the entities and their attributes in the entity data 704 in the entity store 718.

[0069] At runtime of the provider network application, the provider network application sends an authorization request 702 to the policy language engine 710. The authorization request 702 can be received by the policy language engine 710 in a convenient serialized format (e.g., JSON format). The authorization request 702 specifies a subject, an action, a resource, and a request context. The deserializer 712 deserializes the authorization request 702 to convert it into Figure 7 the deserialized form represented as a request object 716.

[0070] The authorization engine 722 evaluates each policy in one or more policy sets 706 for the authorization request and uses the entity store 718. For example, the policy set 706 can be a subset of a larger policy set, and some policies are removed by the authorization engine 722 from the larger set because they are not applicable to the authorization request 702.

[0071] The parser 714 can parse the policy set 706 to convert it into a more efficient evaluation form, such as Figure 7as shown by the set of policy objects 720 therein. The authorization engine 722 has one or more evaluator components (evaluators 724). Multiple evaluators can be used for parallelism in policy evaluation. The authorization engine 722 is responsible for making an allow or deny decision based on the evaluation of the policy set 706 by the evaluators 724. Each policy in the policy set 706 is evaluated by an evaluator. The evaluation of a policy by an evaluator returns true or false. If the policy is satisfied, the evaluator returns true. Otherwise, the evaluator returns false. The authorization engine 722 combines the individual true / false results from the evaluators 724 into an allow or deny decision. By default, and in accordance with the principle of least privilege, the authorization engine 722 denies the authorization request 702. The authorization engine 722 allows the authorization request 702 if and only if at least one permit policy in the policy set 706 evaluates to true and no deny policy in the policy set 706 evaluates to true. Otherwise, the authorization engine 722 returns a denial.

[0072] The policy language engine 710 returns one of two answers to the requesting provider web application as a response to the authorization request 702. The returned answer 726 is the result of evaluating the policy set 706 against the authorization request 702 using the entity hierarchy data in the entity store 718 (e.g., entity ancestor mappings and entity attribute mappings). One possible answer 726 is to allow the authorization request 702. Another possible answer 726 is that the authorization request 702 is denied. The response 726 also includes diagnostic information. The diagnostic information identifies one or more policies in the policy set 706 that caused the answer 726 to be allowed or denied. This diagnostic information can be useful to the provider web application to explain to the end users of the application (e.g., in a graphical user interface) why their application's request failed or was denied, or for other purposes such as debugging.

[0073] If any policy in the policy set 706 evaluated against the authorization request 702 evaluates to false, the authorization engine 722 can deny the authorization request 702. The authorization engine 722 allows the authorization request 702 only if all policies in the policy set 706 evaluated against the authorization request 702 evaluate to true. If any policy encounters an error in its evaluation against the authorization request 702, the authorization engine 722 can also deny the authorization request 702. The result of evaluating the policies in the policy set 706 against the authorization request 702 can be true, false, or an error. Recall from above that if some policies of the provider web application can be removed from the evaluation, they may not be evaluated against the authorization request. The removed policies are not evaluated against the authorization request 702.

[0074] To ensure that the authorization engine 722 can effectively evaluate policies, the authorization engine 722 can be implemented in a secure but high-performance programming language. For example, the authorization engine 722 can be implemented in the RUST programming language or other similar programming languages. RUST is a high-level programming language but has the performance of low-level programming languages such as C or C++. In one implementation, the authorization engine implemented in RUST can evaluate a typical authorization request involving hundreds of policies, thousands of entities, and even more attributes in less than a millisecond.

[0075] Another benefit of implementing the authorization engine 722 in RUST is that its memory management facilities are very efficient. RUST does not use a runtime garbage collector, which consumes limited computing resources for evaluating policies against authorization requests. Nevertheless, RUST provides memory safety in the form of its type system (which is a theorem prover). During compilation, the RUST compiler attempts to prove that the program being compiled (e.g., the RUST programming language instructions of the authorization engine 722) does not contain memory leaks or dangling references. If the theorem cannot be proven, the program will not compile. RUST also provides bindings to other programming languages (such as JAVA) to build extensions or plugins of the authorization engine 722 in different programming languages.

[0076] The authorization engine 722 can evaluate the set of policies 706 at least partially in parallel. To this end, the authorization engine 722 uses a set of evaluators 724. For example, each evaluator in the set of evaluators 724 can be a separate process, thread, etc., which executes at least partially in parallel with one or more other evaluators on a separate CPU core, CPU, or computing device. The set of evaluators 724 can be greater than, equal to, or less than the number of policies in the set of policies 706 to be evaluated. The set of evaluators 724 can be executed as part of a framework (such as a MapReduce framework, etc.) for handling parallelizable problems across a cluster of computing nodes. For example, the set of evaluators 724 can be executed as a set of map operations in a MapReduce framework. The number of evaluators 724 can correspond to the number of available computing nodes in the cluster that can be used to execute the evaluators at least partially in parallel. For example, each computing node can be a separate CPU core, CPU, or computing device.

[0077] Each evaluator in the set of evaluators 724 evaluates one policy in the set of policies 706 at least partially in parallel with the other evaluators, and over time may execute multiple policies in the set of policies 706. Since each policy in the set of policies 706 can be evaluated independently of the other policies, and since the policies are at least partially evaluated in parallel, once any policy in the set of policies 706 evaluates to false or an error, the authorization engine 722 can stop evaluating the set of policies 706 for the authorization request 702. When the authorization engine 722 makes an early stop decision, the response 726 can be immediately returned to the provider web application without evaluating any remaining policies in the set of policies 706 that have not yet been evaluated for the authorization request 702. This early stop of policy evaluation saves the limited computing resources of the authorization engine 722.

[0078] The separation of the header and conditions in a policy helps with early stopping. Specifically, if the header of a deny policy without conditions evaluates to true, the evaluation of the set of policies 706 can be stopped early. If the deny policy also has conditions, those conditions are also evaluated. If both the header and conditions of the deny policy evaluate to true, the evaluation of the set of policies 806 can be stopped early. This early stop saves the limited computing resources of the authorization engine 722. Thus, when the set of evaluators 724 evaluates a deny policy, the header of the deny policy can be evaluated first. If the evaluation of the header of the deny policy is false, none of the conditions of the deny policy need to be evaluated, the policy does not deny the request 702, and the evaluation can continue with any remaining policies in the set 706. Only when the evaluation of the header of the deny policy is true are any conditions of the deny policy evaluated. If the evaluation of the header of the deny policy is true but the evaluation of the deny policy conditions is false, the policy does not deny the request 702 and the evaluation can continue with any remaining policies in the set of policies 706. In cases where the set of policies 706 includes at least one deny policy, the evaluation of the deny policy can be prioritized over the evaluation of the permit policies such that when a deny policy causes the authorization request 702 to be denied, the permit policies are not unnecessarily evaluated.

[0079] Operations on Entities

[0080] An entity is a reference value in the policy language. The policy language supports three operations on entities: equality, reachability, and attribute retrieval. Specifically, if A, B, and C are entity identifiers, equality is expressed as A == B in the policy language, reachability is expressed as A in B or A in [B, C, …] in the policy language, and attribute retrieval is expressed as A.f, where f is an attribute.

[0081] Equality A == B holds if and only if A and B are the same entity identifier. Thus, User::"Alice" == User::"Alice" holds, but User:"John" == User::"Alice" does not hold. It makes no difference whether different entity identifiers happen to point to objects with the same properties; they are still considered unequal. Equality still holds even if the entity identifier does not actually reference an entity object in the entity hierarchy. Thus, User::"Alice" == User::"Alice" holds regardless of whether User::"Alice" is a dangling reference.

[0082] Reachability A in B holds if and only if A is equal to B, or A is a derivation of B in the entity hierarchy. The expression A in [B, C,...] is equivalent to A in B || A in C ||..., but will produce an error if any of the elements in the set are not entity references. If A and / or B do not exist in the entity hierarchy, A in B will return false, except for the special case of A in A, which will return true even if A does not exist.

[0083] Policies can retrieve the value of an entity's property using the dot operator; for example, A.account retrieves the entity value that references the account object belonging to entity A. An error will be thrown if A does not reference an entity in the reference hierarchy, or if the referenced entity does not have an account property. Entity properties can also be accessed using the [] operator, which accepts a string literal representation of the property; thus, A.account is equivalent to A["account"].

[0084] Namespaces

[0085] Entities can be referenced in policies that use namespaces. For example, PhotoApp::Groups::Album::"vacation" is an example entity identifier, where the entity type is PhotoApp::Groups::Album; that is, it is a type Album defined in the namespace PhotoApp::Groups.

[0086] Primitive and aggregate values

[0087] In addition to entities, the policy language data model includes primitive and aggregate values. These values can be stored in the entity properties in the entity store. These values can also be part of the request context information for authorization requests from provider web applications.

[0088] The primitive data types supported by the policy language include the following four data types:

[0089] (1) Boolean values (e.g., true and false),

[0090] (2) Numbers (e.g., 64-bit signed integers).

[0091] (3) Strings, and

[0092] (4) Network addresses and ranges (e.g., IPv4 or IPv6 addresses and ranges).

[0093] The aggregate data types supported by the policy language include the following two data types:

[0094] (1) Sets. A set can contain elements of different dynamic types. Sets can be constructed in the policy using the [] syntax. Some examples of sets include: [2,4,"hello"],[-1],[],{},{3<5,["nested","set"],true}; and

[0095] (2) Anonymous records. Record attributes are valid identifiers or (arbitrary) strings, and the values can be heterogeneous (the same record can contain values of different dynamic types). Records can be constructed using the {} syntax (e.g.: {"key":"value"},{id:"value"},{"key":"value",id:"value"},{},{"foo":2,bar:[3,4,-47],ham:"eggs","hello":true}). Record attribute values can be accessed like entity attributes using the [] index operator and string literals (e.g., record["key"]) or the dot ('.') operator (e.g., record.foo). Nested record access is similar, e.g., context.some.nested.attribute or context["some"].nested["attribute"].

[0096] Policy language values (i.e., entities, primitive values, and aggregate values) are compared for equality in the usual way. Two sets s1 and s2 are equal if they contain exactly the same elements, regardless of order, i.e., ==. Two records are equal if they consist of the same set of key-value pairs. Values of different types are never equal - in particular, an entity is never equal to a record (even if the record happens to contain the same keys / values as the entity's attributes).

[0097] In addition to equality, policy language values can also be used with a small set of operators and functions listed in the table below. These include relational operators, as well as operations on strings, sets, and records. The && and || operators perform short-circuit operations. For example, false &&... will evaluate to false without evaluating..., and similarly true ||... will evaluate to true without evaluating.... This is the case even if... has a type error, e.g., true || "a" < 3 evaluates to true. Depending on the requirements of the existing specific implementation, the policy language may support other operators, such as arithmetic operators.

[0098] Table 1 below lists the built-in operators and functions of the policy language. This table lists the available overloads for each operator. In addition to the operators and functions in the table, the policy language also supports the if-then-else ternary expression, with the syntax: if expr1 then expr2 else expr3. The conditional expr1 must evaluate to a boolean value.

[0099]

[0100]

[0101] Type

[0102] The policy language is dynamically typed, like JAVASCRIPT or PYTHON. As mentioned above, this means that policies can contain expressions like [3, 4, -47] == "hello", and the authorization engine will accept them without returning or throwing an error (here, it evaluates to false). Similarly, like many other dynamically typed languages, the policy language is type-safe, that is, the type of each value is known at runtime, and operators and functions check whether their arguments have the expected type, and violating these expectations will result in a runtime error.

[0103] Policy Syntax

[0104] Policy language policies are written using the grammar in the table below. A policy consists of three elements:

[0105] (1) The effect of the policy on authorization, either permit or deny (the non-terminal Effect in the grammar);

[0106] (2) The policy head, which restricts which subjects, actions, and resources the policy applies to (the non-terminal Head in the grammar);

[0107] (3) The conditional clause, which further refines the circumstances under which the policy applies (the non-terminal Conds in the grammar).

[0108] Roughly speaking, the policy header describes a role-based access control (RBAC)-style policy, while the conditional clause refines it to express an attribute-based access control (ABAC) policy. The effect and policy header are mandatory, but the conditional clause is optional.

[0109] The following syntax specification for the policy language uses | for alternatives, [] for optional productions, () for grouping, and {} for repeating a form zero or more times. Capitalized words represent syntactic productions, and lexical tokens are all uppercase. Tokens are defined using regular expressions, where [] represents a character range; | represents an alternative; *, +, and? represent zero or more, one or more, and zero or one occurrences, respectively. ~ represents complementation; and – represents difference. The syntax ignores whitespace and comments.

[0110]

[0111]

[0112] Inline policy

[0113] The policy language supports at least two types of policies:

[0114] (1) Inline policy; and

[0115] (2) Policy template.

[0116] The following examples focus on inline policies but also apply to policy templates. The distinguishing feature between inline policies and policy templates is the use of the syntactic?principal or?resource as a parameter in the policy header.

[0117] The following example inline policy c1 for a photo-sharing application permits Jane's friends to view or comment on all photos contained in the albums passed in her travel album (i.e., the album or any nested sub-albums):

[0118] 01:permit(principal in Group::"jane_friends",

[0119] 02:action in[Action::"view",Action::"comment"],

[0120] 03:resource in Album::"jane_trips");

[0121] The following example inline policy c2 prohibits any user other than the owner of a photo-sharing application account from performing any action on resources marked as "private":

[0122] 01:forbid(principal, action, resource)

[0123] 02:when { resource.tags.contains("private")}

[0124] 03:unless { resource in principal.account};

[0125] Policies start with either the permit or forbid keyword. A permit policy grants access, while a forbid policy restricts access by overriding permit policies. The above examples are examples of both types of policies.

[0126] Policies contain the keyword variables principal, action, and resource and may include constraints. Depending on the underlying entity hierarchy, the constraints determine which principals, actions, and resources the policy applies to. Hierarchical constraints on principals and resources take one of two forms: var or var('in' | '==') Entity (additional forms of the policy template will be discussed below). Action constraints can take either of these forms or a third form var in [Entity, Entity,...]. These are RBAC-style constraints; policy c1 uses these RBAC-style constraints, while c2 uses ABAC-style constraints (via the when and unless clauses) to represent the constraints on which principals and resources the policy applies to.

[0127] The RBAC-style equality constraint var == Entity means that the policy applies only when var is equal to Entity (which means the policy applies only to a specific entity Entity). The RBAC-style membership constraint var in Entity means that the policy applies only when var is a descendant of Entity in the entity hierarchy. The IN operator is reflexive, so any entity is implicitly a descendant of itself. For example, the constraint resource in Album::"jane_trips" in policy c1 means that the policy applies only to resources transitively contained in Jane's "trips" album, including the album itself. Finally, the RBAC-style set form var in [Entity, Entity,...] (allowed only for actions) means that var is equal to one (or more) of the entities or their descendants specified in the set. If there is only var, there is no constraint. For example, in policy c2, forbid(principal, action, resource) imposes no constraints on the principal, action, or resource, so the policy applies to all principals, actions, and resources in the system and is subject to any when and unless clauses (if any).

[0128] A conditional clause starts with when or unless and is a boolean expression over input variables. This policy only applies when all when clauses evaluate to true and all unless clauses evaluate to false. Conditional clauses are written in the policy language and are defined by the non-terminal Expr in the grammar. The constraints on the subject, action, and resource in the header can be considered expressions as they are also described by the Expr grammar.

[0129] The policy language is a relatively simple language to minimize ambiguity in the grammar. The policy language has several desirable properties: expressions have no side effects; expression (and policy) evaluation is guaranteed to terminate; the worst-case running time for each policy is quadratic in the policy and input size, but is usually linear.

[0130] The policy language supports relational and logical binary operators (e.g., x < 5 and!(x && y)). Expressions can contain conditional clauses, if E1 then E2 else E3 (like E1? E2 : E3 in C). As mentioned before, expressions can also be included in expressions like A in B or A in [B, C,...]. Given a policy in a serialized format (e.g., JSON), the policy language engine parses it to generate an abstract policy tuple, i.e., c = <Effect, Principal, Action, Resource, Conds>. The elements of the policy tuple correspond to the grammar productions.

[0131] The following three functions are defined on the policy tuple c:

[0132] (1) Effect(c): {Allow, Deny};

[0133] (2) Principal(c), Action(c), Resource(c): Expr;

[0134] (3) Conds(c): List <expr>

[0135] The function Effect(c) returns the allowed policy value Allow and the denied policy value Deny. The function Conds(c) returns the list of Expr clauses for c, which may be empty. These clauses come from the when or unless clauses in the policy; the when clause is a single expression, and the unless clause is a negated expression. The Principal(c), Action(c), and Resource(c) functions return the extended constraint expressions for the input variables Principal, Action, and Resource; if there are no constraint expressions, they simply return true.

[0136] For example, the parsing of the above example policy c1 yields:

[0137] (1) Effect(c1) = Allow

[0138] (2) Principal(c1) = principal in Group::"jane_friends"

[0139] (3) Action(c1) = action in [Action::"view", Action::"comment"]

[0140] (4) Resource(c1) = resource in Album::"jane_trips"

[0141] (5) Conds(c1) = []

[0142] As another example, the parsing of the above example policy c2 yields:

[0143] (1) Effect(c2) = Deny

[0144] (2) Principal(c2) = true

[0145] (3) Action(c2) = true

[0146] (4) Resource(c2) = true

[0147] (5) Conds(c2) = [ resource.tags.contains("private"),!(resource in principal.account)]

[0148] Note that Conds(c1) is empty because c1 has no when or unless clauses, but Conds(c2) is a list of two items where c2's when clause remains the same and its unless clause is negated.

[0149] Policy Template

[0150] Policy templates allow policies to be programmatically created in a safe and convenient way. A policy template has one or more slots. Two slots are?principal and?resource. Slots can only appear in the policy head constraints of their variables and only on the right side of the == or in operators.

[0151] The following policies are templates with?principal and?resource slots:

[0152]

[0153] The authorization engine does not directly evaluate policy templates as part of an authorization request. It first instantiates by providing entity identifiers as arguments for the slots. The number of arguments must match the number of slots in the policy template. The policy against which the authorization request is evaluated can be an inline policy or an instantiated policy template.

[0154] For example, instantiating the above policy template with [{"Principal":"User::\"bob\"","Resource":"Photo::\"tri p\""},{"Principal":"User::\"cat\"","Resource":"Doc::\"sales\""}] will produce a policy instance equivalent to the following two inline policies.

[0155] First equivalent inline policy:

[0156]

[0157] Second equivalent inline policy:

[0158]

[0159] Policy Semantics

[0160] Inline policies and policy instances have the same semantics. A policy c can refer to either an inline policy or a policy instance. An authorization request (equivalent to an "authorization query") is defined as a tuple <P, A, R, X>, where P is the principal, A is the action, R is the resource, and X is the request context. P, A, and R are entity identifiers, while X is a record. The authorization engine approves the request if the authorization relation (defined by the application's set of policies) for a given provider web application satisfies the request - that is, it permits the principal P to perform the action A on the resource R in the situation described by the context X. The authorization relation satisfies the request <P, A, R, X> if and only if the authorization relation satisfies at least one permission (grant) policy and no restriction (deny) policies. We define what it means for a request to satisfy a policy as follows.

[0161] A request <P, A, R, X> satisfies a policy c when the evaluation of the request against c yields the value true. More precisely, each policy c denotes a function [[c]] from an entity hierarchy H and queries a boolean value <P, A, R, X>. The request <P, A, R, X> satisfies c with respect to the hierarchy H when (<[[c]](h)P, A, R, X>) is true.

[0162] The function [[c]] is defined by evaluating the policy c with respect to the entity hierarchy H and the request <P, A, R, X>; the variables principal, action, resource, and context that appear in c are respectively bound to the values P, A, R, and X. The result of the evaluation is true if Principal(c), Action(c), and Resource(c) all evaluate to true; whenever the expressions in Conds(c) evaluate to true; and each unless expression in Conds(c) evaluates to false.

[0163] Policies are total functions, which means they return either true or false for every input. In particular, if the evaluation of a policy under the standard expression semantics would result in an error, for example, because the policy attempts to access an attribute that does not exist for a given entity, then false is returned.

[0164] Another way to view the evaluation of a policy c is that from c we can construct a policy language expression e of the form Principal(c) && Action(c) && Resource(c) && {x | x in Conds(c)}. The authorization engine then evaluates the expression e for a particular request <P, A, R, X> and entity hierarchy H, and the result is either true or false.

[0165] For example, the above example policy c1 corresponds to the expression: principal in Group::"jane_friends" && action in [Action::"view", Action::"comment"] && resource in Album::"jane_trips". There is no conditional clause in this policy.

[0166] As another example, the above example policy c2 corresponds to the expression: true && true && true && resource.tags.contains("private") &&!(resource in principal.account). There is no header constraint in this policy, so each constraint is represented by true in the expression form.

[0167] In addition to calculating the authorization decision (allow or deny), the authorization engine also calculates the reasons accompanying that decision. Specifically, the authorization output is a triple, including the decision, a set of reasons, and a set of errors. If the output satisfies Figure 8 the authorization semantic definition 800, then the output is correct. According to definition 800, if dec is Allow, the reasons include all policy IDs that satisfy the permissions. Otherwise, dec must be "Deny", and the reasons include all policy IDs that satisfy the restrictions. The errors include the evaluation error messages. The semantics are deterministic: it is a function of P, A, R, X, the entity hierarchy H, and the application policies.

[0168] For example, consider Figure 9 the example entity hierarchy 900 and the above example policies c1 and c2. If the authorization request is <P = User:”Alice”, A = Action::”view”, R = Photo::"summer”, X = {}>, then policy c1 is satisfied because User::”Alice” is a derivation of Group::”jane_friends” in the entity hierarchy 900, the resource Photo::”summer” is a derivation of Album::”jane_trips” in the entity hierarchy 900, and the action Action::”view” appears in the set [Action::"view”, Action::"comment”]. Policy c2 is not satisfied because the tags property of Photo::"summer” does not contain "private”. Since policy c1 evaluates to true, c2 evaluates to false, and no policy has an error, the decision allows this authorization request.

[0169] If the authorization request is <P = User: "Alice", A = Action:: "view", R = Photo:: "receipt", X = {}>, then for similar reasons policy c1 is satisfied. However, policy c2 is also satisfied because the when condition evaluates to true. This is because the tags attribute of the resource Photo:: "receipt" contains "private", and the unless condition of c2 evaluates to false because the photo is not a member of the User:: "Alice" account. Since the deny policy c2 evaluates to true, this authorization request is denied.

[0170] Policy and entity storage slices

[0171] When the authorization engine receives an authorization request, it must determine what information it needs to obtain to evaluate the authorization request. In this section on policy and entity storage deletion, the following terms are used:

[0172] Authz service. The authorization service is a network service provider that processes and responds to authorization requests. It is distinguished from the management service responsible for creating, reading, updating, and deleting policy data.

[0173] Authz engine:: For the purposes of this section, the authorization engine is responsible for evaluating policies and producing authorization results. It is distinguished from the authorization service, and the authorization engine is just a component of the authorization service. Each instance of the authorization engine is single-threaded and runs on a single machine. For the purposes of this section, any networking, routing, load balancing, or database components are considered part of the authorization service, but not part of the authorization engine.

[0174] Slice:: A slice is a part of the entity data or policy data that the authorization engine needs to evaluate a particular request at hand. Given an authorization request, the authorization service calculates a slice that contains a subset of the data, and then the authorization engine evaluates the request based on that slice. A key property that is supported is that evaluating an authorization request using slice data always gives exactly the same response as evaluating the authorization request using the entire available dataset, including any error messages or other diagnostics in the response.

[0175] Slicing:: Slicing is the process of calculating a slice, or the algorithm for calculating a slice. Slicing is performed by the authorization service for each authorization request, with some parts of the algorithm that may be pre-computed and stored being subject to modulo arithmetic.

[0176] Select / selected. The slicing algorithm selects data, which means that the selected data needs to be included in the slice for the authorization engine to process.

[0177] JIT:: If the data is provided as part of an authorization request, it is JIT ("Just In Time"). This is in stark contrast to managed data (e.g., data known before the request arrives) or data that may be fetched on demand from other external sources.

[0178] Head constraints:: The head constraints of a policy are constraints on the subject, action, and resource in the policy head, and exclude the content of any when or unless clauses of the policy conditions.

[0179] Head principal / head resource:: For any policy, the head principal is the entity identifier explicitly mentioned in the subject head constraint of the policy. For policy permit(principal == User::"alice",...), the head principal is User::"alice". For policy permit(principal in Group::"friends",...), the head principal is Group::"friends". For a policy without a subject head constraint, e.g., permit(principal,...), the head principal is the special value ANY. The head resource is defined similarly using the resource head constraint of the policy.

[0180] Relevant:: If the head constraints of a policy evaluate to true for the request, the policy is relevant to the authorization request. This does not mean that the entire policy is true, only its head constraints.

[0181] One type of slicing is policy slicing. Policy slicing involves choosing which policies need to be evaluated based on a given authorization request. To facilitate policy slicing, a policy index can be maintained. This index maps the head resources of policies to the policies that have those head resources. For example, a given head resource can be mapped to one or more policies that contain the given head resource. This index is referred to in this document as the policy head resource index.

[0182] When a specific authorization request is received, the authorization service can use the entity ancestor mapping to map the resource R specified in the specific authorization request to the set A of all R ancestors in the entity hierarchy. The policy head resource index can then be used to determine the set P of all policies in the index whose head resources are the resource R or any entity in the set A. P can be used as a policy slice.

[0183] The policy slice P can be reduced by evaluating the head constraints of each policy in P and only selecting the relevant policies in P as the final policy slice P'. The policy slice P' may be smaller and more precise than slice P, but at the cost of additional computation during slicing. Compared with slice P, the smaller slice P' can save network utilization.

[0184] The provider network can host / store some entity data. Other entity data can be provided JIT. For example, the provider network can store entity names and parent relationships. Entity property records can be provided JIT.

[0185] The provider network database can maintain a policy index in terms of (head principal, head resource) pairs. This allows for efficient lookup of policies using a given (head principal, head resource) pair. For example, the policy permit(principal,action == Action::"view",resource in Album::"12345")when {...}; is indexed by the pair (ANY, Album::"12345").

[0186] The hosted entity database contains at least entity names and parent relationships, and also maintains a precomputed transitive closure of the parent relationships: each entity contains pointers to each of its ancestors, not just its immediate parent. Special ANY principal and special ANE resource are used for policies where the head principal or head resource is ANY. In the hosted entity database, the ANY principal is an ancestor of all principals, as is the case with all resources.

[0187] When a specific authorization request is received, let the principal identifier of the request be P, and the resource identifier of the request be R. The authorization service will query the policy database using the above index and select all policies where the (head principal, head resource) pair is (P, R). Then, it will iterate over the ancestors of P and the ancestors of R and select all policies where the (total principal, total resource) pair is (P or any ancestor of P, R or any ancestor of R). As mentioned above, leveraging the precomputed ancestor relationships can improve efficiency - compared to the case of policy slicing when entity data is entirely JIT, in policy slicing, the ancestor relationships have to be recomputed for each authorization request.

[0188] As mentioned above, there are at least two different options when collecting this set of policies: stop here and select all policies found in this way through the index; or, store the head constraints of each policy along with the policy and evaluate these head constraints (including operations) before only selecting the relevant policies. However, as mentioned above, the additional work of evaluating the head constraints may mean additional complexity but little or no benefit (or even negative in terms of net gain).

[0189] In the case where there are many small policies in an application and the entity data is entirely JIT, this policy slicing solution will be more effective than policy slicing. For example, if the application creates new template instances for each user in the application, the number of policies can be a multiple of the number of users, and each policy (template instance) is associated with a specific user or resource in its header constraints. The database index described in this section will help avoid looking at all policies in the system that match the authorized request resource.

[0190] If some or all of the entity data is hosted in the provider network and the entity data is not provided JIT, slicing of the hosted entity data can be performed. Slicing of entity data can involve submitting one or more queries to the entity store. The overall algorithm for policy and entity slicing is as follows.

[0191] For a given authorization request, multiple queries to the entity store may be required. The main reason multiple queries may be needed is the case where an attribute value contains an entity reference. For example, if a policy requires principal.manager.level, not only a query for principal is needed, but also an additional query for principal.manager; however, the principal.manager entity may not be known until the data from the first query is obtained. The authorization engine or validator can enforce a limit on the length of these chains in the policy text to limit the number of queries required to evaluate a single authorization request.

[0192] The first step of the algorithm is to perform policy slicing as described above. Second, for each policy in the policy slice, determine the entity data required to evaluate the policy. This determination involves constructing the abstract syntax tree (AST) of the policy and traversing the AST to determine the entity data required by the policy. This determination is made for all policies in the slice before proceeding to query the entity store for the entity data. This way, the number of queries required to obtain all the entity data can be reduced. Next, query the entity store for the required entity data. Ideally, all the required entity data can be obtained in a single query to the entity store. Even in the presence of attribute chains involving entities, the required entity data may be included as a result of the first query due to different parts of the policy or different policies. Returning to the example above, different parts of the policy or different policies may specify that principal.manager is User::"beth". In this case, only one query is needed and no additional query is required to determine principal.manager. However, if entity data is still missing, additional queries can be submitted to the entity store.

[0193] Policy Validation

[0194] The policy language is dynamically typed. This means that the authorization engine will detect errors when evaluating a policy (e.g., when it encounters an expression such as 1 < "hello"). If the evaluation of a policy results in an error, the evaluation result of the policy is false.

[0195] To avoid the possibility of evaluation errors, the policy language system and method provide pattern-based policy validation. In particular, given a pattern that describes the assumed structure of entities and queries, the validator will flag those policies that may go wrong during evaluation. The validator is sound: if the validator does not flag any policy, then no policy will go wrong when evaluating any entity hierarchy and query that conforms to the pattern specification.

[0196] Validation is optional for users. The user can choose not to run the validator to check the policy. For performance improvement, the authorization engine may not run the validator when evaluating a policy. At runtime, the validator assumes that the given pattern contains complete information about every entity and action mentioned in the policies it considers, and fully enumerates the subject and resource entity types available for a particular operation.

[0197] The following is an example of a pattern:

[0198]

[0199] The above example pattern specifies that each entity of type Employee in the entity store has an attribute jobLevel whose value is of the Long data type, and also has an optional attribute numberOfLaptops, which is also of the Long data type. In an authorization request with the action Action:: "remoteAccess," the subject should always be an entity of type Employee.

[0200] Now consider validating the when clause of the following policy:

[0201]

[0202] To evaluate a given authorization request to reach the when clause, the query must satisfy the policy head constraints. Therefore, the action must be Action:: "remoteAccess." Based on the pattern, the validator can assume that the subject is an Employee, so it has the jobLevel attribute. In this way, the validator will report an error or warning in each comparison in the when clause (lines 03 - 05).

[0203] The validator will report a validation error on line 03 because it cannot be guaranteed that the principal has the optional quarantineLevel attribute. Therefore, accessing the attribute may raise a runtime error. Validation errors will also be reported if the policy contains an attribute that does not exist in the schema (e.g., age) or contains a spelling mistake such as principal.jobbLevel.

[0204] The validator will report a validation error on line 04 because the right operand of > is a string, but the > operator only accepts long integers, so the > operator on line 04 will always raise a runtime error when evaluated.

[0205] The validator will report a validation error or warning on line 05. The left operator of == is always a long integer, the right operand is always a string, and the == operator returns false if its operands have different runtime data types. Therefore, this comparison will always return false. Although this does not cause an evaluation-time error, this may not be the intention of the policy author.

[0206] Validation includes a type-checking step as well as other steps. Like most programming languages, the main purpose of type checking is that each policy language operator has requirements for the types of its operands and returns a result of a given type. For example, x>y requires that both x and y have the long integer type, and it returns a boolean value. If the operands do not have the required types, the validator reports an error: either x>y (where the type of y is not long integer) or x.jobLevel (where the type of x does not have an attribute named jobLevel). In the case of equality ==, it may succeed if the two operands have the same type. As shown in line 03 above, an optional attribute access should be preceded by a has check, e.g.:

[0207] 03:principal has quarantineLevel&&principal.quarantineLevel<5&&

[0208] The has expression in the left operand of && is used to determine that accessing the optional isolationLevel attribute will not raise a runtime error. The && expression short-circuits, so when the attribute does not exist, the entire expression evaluates to false without evaluating the right operand. This can equivalently be written with an attribute access in the has and then branches under an if expression condition.

[0209] The validator compares the policy set with the schema to find inconsistencies. From these inconsistencies, the validator will be able to perform the following operations:

[0210] (1) Detect unrecognized entity types, e.g., misspelling "Album" as "Albom".

[0211] (2) Detect unrecognized actions, e.g., misspelling Action::"viewPhoto" as Action::"viewPhoot".

[0212] (3) Detect actions applied to unsupported subjects / resources, e.g., saying a photo can view a user.

[0213] (4) Detect incorrect use of IN or == (provide hints on correct use), e.g., writing a subject in Album::"trip", but the subject cannot be a Photo.

[0214] (5) Detect unrecognized attributes, e.g., principal.jobbLevel (this is a misspelling and should be "jobLevel").

[0215] (6) Detect unsafe access to optional attributes, e.g., principal.numberOfLapt ops, where numberOfLaptops is an optional attribute (declared with "required": false). These should be protected by a has check, e.g., if the subject has a quarantineLevel, then principal.quarantineLevel else 0. Or, the subject has a quarantineLevel && principal.quarantineLevel < 2.

[0216] (7) Detect type mismatches in operators, e.g., principal.jobLevel > "14", which is an illegal comparison between a long integer and a string.

[0217] (8) Detect policies that always evaluate to false and thus are never applied, e.g., the condition of the policy is: when { ["hello"].contains(1)}. This condition always evaluates to false, so the policy is never applicable.

[0218] The actions in the pattern operation section can specify the expected format of the context, so the errors listed above can also be marked in the context references in the policy condition section.

[0219] Other types of validation are possible. For example, a validator can detect unsafe access to optional attributes through a process called event checking. Attributes of an entity can be specified as optional in a schema. However, a policy can be written that accesses an attribute of an entity without first checking whether the entity has that attribute. A validator can detect this type of error by checking whether the has operator is used on an entity before accessing the attribute, e.g., as in the expression principal has someoptionalattribute && principal.someoptional attribute == "someval". In this expression, the principal refers to an entity whose attribute some optionalattribute may not always exist. If the given entity has that attribute, the expression principal has someoptionalattribute will return true. Then, the short-circuit behavior of && continues to safely evaluate the clause principal.someoptionalattribute == "so meval". If principal has some optional attribute returns false, then && will immediately return false and not evaluate the other clause.

[0220] The validator can detect this situation by making its type-checking steps flow-sensitive. Every time an expression of the form someentityhassomeattribute is reached, the validator knows that expressions that must be executed after the has expression can depend on the existence of someattribute. However, expressions that do not necessarily follow the has expression cannot depend on the existing attribute. Information from multiple has expressions can be aggregated in order to validate the following expression: principalhas attributeA && principal has attributeB && principal.attributeA == principal.attributeB.

[0221] Union types can also be used to verify conditions that apply to values of multiple possible types. For example, suppose that in the following conditional expression, both the User type and the Anon type must have anAttribute: (if principal.isPrivate then User::"AlicePrivate" else Anon::"Public").anAttribute. The type of the (if principal.isPrivate then User::"AlicePrivate" else Anon::"Public") part can be the union User | Anon. During type checking, if each type in the union has the attribute, the validator will allow dereferencing the attribute in the union type, as is the case in our example.

[0222] Typing can also be done via cross product. In this paper, policies can be verified for each combination of principal and resource types in the action specifications of the schema. This provides better precision compared to the alternative of verifying a policy once while specifying the principal and resource as a union type of each specified possibility. The benefit of verification via cross product is fewer false positives compared to using union types.

[0223] The validator can also run in permissive mode. In permissive mode, the schema can be partial. In particular, an entity type can be named, but there is no information about its attributes or members of the entity hierarchy. When an expression with such an incomplete entity type is used in an expression, the validator can infer information about the type from the usage and ensure that the usage is always consistent. For example, if the type of the principal is User, but User is not fully specified in the schema, the validator can accept an expression like principal.name == "Alice*" - this expression implies that User has a name attribute that can be used as a string. However, an expression like principal.name == "Alice*" && principal.name > 5 might be flagged as invalid because the User name attribute cannot be used as both a string and a long integer at the same time, and this must be true for this expression to be evaluated without error.

[0224] Verification Schema

[0225] The verification schema is written in something like JSON (e.g., XML, YAML, Protobuf, or other suitable data serialization formats). The schema contains optional namespace declarations and two lists:

[0226] (1) Entity type specifications, and

[0227] (2) Action specifications.

[0228] These are identified in the schema by the keywords "namespace", "entityTypes", and "actions" respectively.

[0229] The namespace declares a global namespace that will apply to all entity types and actions declared in the schema. The entityTypes list describes the type of each entity that may appear in the entity hierarchy, including the attributes of the entity type and the parent / child relationships that an entity of that type may have with other entities in the hierarchy (if any). The actions list contains the entity IDs of the Action entity type, which can be used as actions in authorization requests, as well as assumptions about the body, resource, and context parts of the requests submitted with that action. Since actions are also entities, this part of the schema also lists the hierarchy information.

[0230] Each entry in the entityTypes list is a JSON or JSON-like object with the following properties:

[0231] (1) name: The name of the entity type as a string. This must be an identifier, defined in the policy language grammar as a sequence of alphanumeric characters, omitting any reserved words of the policy language. If the schema declares a namespace, this type name is qualified by that namespace to form a fully qualified entity type, which must be used when referring to this type in the policy.

[0232] (2) memberOf: A list containing strings that are entity types that can be the direct parents of an entity with this entity type. Such entity types must be valid entity type identifiers declared in the schema. If the memberOf list is empty, or the property is undefined, the entity type can have no ancestors in the entity hierarchy.

[0233] (3) shape: A JSON or JSON-like object that follows the JSON or JSON-like schema style format, with custom type property values of the policy language type. The top level of this object must have the property "type": "Record", since validation treats entity attributes as a kind of record in this schema. Entity attributes can be declared as optional using the required properties described below for record types.

[0234] Each entry in the actions list is a JSON or JSON-like object with the following properties:

[0235] (1) name: The action identifier as a string. This is an entity identifier, not an entity type, so it can contain anything valid in a policy language string. When combined with the entity type Action, this forms the complete entity identifier for the action entity. If the schema declares a namespace, the entity type Action is qualified by that namespace.

[0236] (2) memberOf: A list containing strings that are action identifiers and are the direct parents of this action in the action hierarchy. Note that this memberOf property is more precise than the entityTypes memberOf property. This list defines the complete action identifier and directly defines the action's hierarchy, while the entityTypes list only identifies the type-level relationships in the hierarchy. This means that there should be no cycles in the actions memberOf relationship, but cycles can exist in normal entity types. For example, if the action "get" has itself in its memberOf, it is incorrect, but if the entity type Album has itself in its memberOf list, it is okay.

[0237] (3) appliesTo: A JSON or JSON-like object containing two lists, principalTypes and resourceTypes, which contain the principal and resource entity types that can accompany this action in an authorization request. If there is no appliesTo property in the actions element object, it is assumed that the action can appear in authorization requests for any entity type of principal and resource. Both principalTypes and resourceTypes can be empty lists to indicate an action that cannot be used in authorization requests for any entity type. When these lists are empty and the action is included in the memberOf list of some derived actions, the action can be used as an action group in an in condition but cannot be used directly as an action.

[0238] (4) context: A JSON or JSON-like object in the same format as the entity shape attribute, defining the attributes that must exist in the context record in an authorization request issued using this action.

[0239] The schema format uses a JSON-like schema or a similar structure to declare entity attributes and context. Different values of the type attribute are used to support policy language types.

[0240] (1) String, long integer, and boolean types are used to encode basic policy language types.

[0241] (2) The Set encodes a policy language set type. It is used with an attribute element to hold the type of elements in the set.

[0242] (3) The Record encodes a policy language record type. The attributes attribute is a mapping from record attribute names to their types. The type of each attribute is structured using this JSON or JSON-like format, but with additional attributes. The required attribute specifies whether the attribute always exists in the record. The required attribute defaults to true. Setting it to false means the attribute may not be in the record, so a specific check is needed before accessing the attribute safely.

[0243] (4) The Entity encodes a policy language entity reference type. This is used with an attribute name that specifies the type of the referenced entity. The value of the name is also a policy language Name.

[0244] Differential random testing

[0245] Figure 10 A differential random testing method for testing the policy evaluation function of the production authorization engine 1014 is shown. Standard testing methods can attempt to come up with specific test inputs or sets of test inputs, which include authorization requests, entity stores, and policy sets. Standard testing methods may require a large amount of work to generate test inputs that provide near-complete or complete coverage of the programming functionality of the production authorization engine 1014, including various code branches of the programming language code implementing the production authorization engine 1014. Standard testing methods not only require creating test input data but also creating expected output data. In particular, for each test case, the correct expected output needs to be generated, including the correct allow or deny decision and any diagnostic information. Using the standard testing method, the test inputs are fed to the production authorization engine 1014, and the output of the production authorization engine 1014 for this test input is compared with the expected output. A difference between the actual output and the expected output indicates an error in the production authorization engine 1014. Standard testing methods are impractical for fully testing the production authorization engine 1014 because of the difficulty in generating a set of test inputs and a corresponding set of expected outputs to provide sufficient coverage of the programming functionality of the production authorization engine 1014. This difficulty stems from the various possible policies that can be input into the production authorization engine 1014. Generating the expected output is also difficult because it requires a complete and correct understanding of the entire policy language specification.

[0246] In addition to testing the production authorization and engine 1014 using standard testing methods, a differential random testing method is also used to test the production authorization engine 1914. The differential branding testing method uses Figure 10 A reference implementation of the production authorization engine 1014, referred to as the reference authorization engine 1012, is provided. The reference authorization engine 1012 provides the same functionality as the production authorization engine 1014 but with a simpler implementation. For example, the reference authorization engine 1012 can be implemented in a high-level programming language (such as a high-level imperative and functional compilation language). For example, the reference authorization engine 1012 can be implemented in a verification-aware programming language such as the Dafny programming language. Additionally, the implementation of the reference authorization engine 1012 can be simpler relative to the production authorization engine 1014 because the reference authorization engine 1012 does not need to concern itself with scaling or concurrency issues. The reference authorization engine 1012 only needs to be able to evaluate requests, entity stores, and policy sets within a reasonable test time. For example, the reference authorization engine 1012 is not required to be able to evaluate multiple authorization requests simultaneously or in parallel. The result of the simpler implementation of the reference authorization engine 1012 is that it contains fewer lines of code than the production authorization engine 1014 and thus may have fewer bugs. Overall, the reference authorization engine 102 can be programmed in a programming language that is easy to read and the implementation does not need to be optimized for performance. For example, the reference authorization engine 1012 can be programmed in a programming language different from the programming language used to implement the production authorization engine 1014. In other words, the reference authorization engine 1012 simply needs to be an executable specification of the policy language semantics. Therefore, the reference authorization engine 1012 can be implemented using the programming language that most naturally expresses the specification. In one example implementation, the reference authorization engine 1012 is implemented in approximately 500 lines of code, while the production authorization engine 1014 is implemented in approximately 10,000 lines of code.

[0247] Figure 10 A method for differential random testing of the production authorization engine 104 is provided. In step 1002, a coverage-guided random testing method is used to randomly generate or mutate test inputs 1010. Using the coverage-guided random testing method, an initial test input is randomly generated such that, according to the policy language grammar, the initial test input is syntactically correct. When the test input is executed by the production authorization engine 1014, the coverage of the code implementing the production authorization engine 1014 is tracked. If the execution of the test input results in an increase in code coverage, the test input is retained in the set of test inputs that are used to generate future test inputs by modifying these retained test inputs.

[0248] In step 1004, a test input 1010 is input to a reference authorization engine 1012 and a production authorization engine 1014. The test input 1010 includes an authorization request, an entity store, and a policy set. As a result, the reference authorization engine 1012 generates an output 1020 for the test input 1010, and the production authorization engine 1014 generates an output 1022 for the test output 1010. In operation 1024, the output 1020 of the reference authorization engine 1012 is compared with the output 1022 of the production authorization engine 1014 to determine if they are equal. If the outputs 1020 and 1022 are not equal, there is an error. The two outputs are equal if both outputs 1020 and 1022 reflect the same allow or deny or error decision and identify the same policy set in the diagnosis. If the two outputs 1020 and 1022 are not equal, there is an error in either the reference authorization engine 1012 or the production authorization engine 1014. Since the implementation of the reference authorization engine 1012 is not as complex as that of the production authorization engine 1014, the problem is likely to be in the production authorization engine 1014.

[0249] In step 1006, if evaluating the test input 1010 provides greater coverage of the code implementing the production authorization engine 1014, the test input 1010 is retained for future mutation. Steps 1002, 1004, and 1006 are repeated many times with new test inputs each time. For example, these steps can be repeated about one million times. The number of times these steps are repeated can be determined based on the code coverage of the production authorization engine 1014. For example, if the code coverage seems to reach a maximum after running these steps for some time, the test loop can be stopped. It should be noted that some code of the production authorization engine 1014 may not be accessible when evaluating the test input. Therefore, the maximum code coverage may be less than 100%.

[0250] Rigorous Verification for Policy Analysis

[0251] SMT analysis of policy language systems and methods requires that policies pass strict type - checking requirements before symbolic evaluation and encoding into SMT. The validator of the policy language system and method contains a type - checking and conversion process that meets these requirements and allows for policy analysis of more policies than simply implementing strict type - checking rules.

[0252] Policy language policies are polymorphic because a given policy can be applied to multiple combinations of subject, action, resource, and context types. The validator type - checks the policy for each applicable type combination and considers the following three cases:

[0253] (1) The policy is rejected because one of the combinations has an error. Such policies are never translated into SMT.

[0254] (2) The policy is rejected because each combination is typed as false. Such policies are never translated into SMT.

[0255] (3) The policy is accepted because all combinations are error-free and at least one combination is not typed as false. In this case, the policy is analyzed separately for each non-false typed combination, and if the policy satisfies the required property under each combination, the policy as a whole satisfies that property. This reasoning extends to properties such as inclusion or equality that involve more than one policy.

[0256] The validator accepts the policies in case (3) above. However, some of these policies may cause errors in the symbolic evaluator of the policy analysis (described below) because these policies cannot be translated into SMTLib. SMTlib is the standard input language for SMT solvers. For example, principal.rec == resource.rec, where the two fields contain different records but do have a well-defined least upper bound. Such a policy cannot be translated because the symbolic calculator requires the left and right sides of == to have the same type, like the underlying type system of SMTLib terms.

[0257] Therefore, what is needed is the ability to exclude untranslatable policies before symbolic evaluation.

[0258] A possible approach is to modify the validator to include a strict mode: a flag bit indicates to enforce strict type constraints instead of its normal (more lenient) type constraints. However, this approach complicates the validator and causes the overall analysis to reject more policies than necessary. For example, when the principal type does not declare an active property in one of the type combinations, the strict type rule will always reject a policy with the expression principal has active && principal.active. In contrast, the normal validator simply types this expression as false and may accept the entire policy case 3 above depending on the following.

[0259] Therefore, the validator remains as it is, and an additional strict type checking and transformation (STT) process is added for case 3 above. If the policy passes the normal validation and each non-error combination passes the STT phase, then policy analysis can be performed on the results of the STT phase. Otherwise, the STT phase reports an error.

[0260] To implement STT, cooperation from the validator is used. Specifically, the validator outputs the inferred type of each node in the policy AST for each type combination. Then, the STT phase checks and transforms these fully type-annotated ASTs as follows:

[0261] (1.) For each if expression:

[0262] (1.1) If the condition type is true, then recursively process on the then branch and return the strictly typed node of the result.

[0263] (1.2) If the condition type is false, then recursively process on the else branch and return the strictly typed node of the result.

[0264] (1.3) Otherwise, recursively process on both branches. If the resulting nodes do not have the same strict type, an error occurs.

[0265] (2.) For each == comparison:

[0266] (2.1) If the comparison type is true or false, then simply return the text true or false respectively without recursively processing the arguments. The strict type of the result will be boolean.

[0267] (2.2) Otherwise, recursively process on both sides. If the resulting strict types are different, an error occurs.

[0268] (3.) For every other boolean expression, such as has!, ||, &&, etc.:

[0269] (3.1) If it is typed as true or false, then simply return the text true or false respectively without visiting the children of the node. This is the correct transformation because the validator is sound.

[0270] (3.2) Otherwise, recursively transform and check all sub-expressions.

[0271] The strategies accepted by both the validator and the STT phase satisfy the following strict typing requirements. First, note that the validator will perform event checking, so an expression like the problematic example principal hasactive && principal.active will be typed as false when the principal type has no active fields. Next, note that the STT phase will convert all nodes typed as false to the constant false. In the running example, this means that principal has active && principal.active becomes the node false, which easily satisfies the strict type rules and is thus translatable. Finally, note that these conversions are all correct because the validator is sound.

[0272] Simplify the policy language to SMT through pattern-driven symbolic evaluation.

[0273] The policy language system and method cover a policy language symbolic calculator whose function is to simplify policy language expressions to the SMTLib language. The function of the symbolic calculator is to generate an SMT encoding of decidable, sound, and complete policy language expressions.

[0274] Using a reduction engine to answer general questions

[0275] A policy language system and method includes a satisfiability modulo theories (SMT) policy analyzer that functions to answer general questions about policy language policies by reducing them to SMT queries. For example, the SMT policy analyzer can answer the following questions about a policy language:

[0276] Equivalence: Do two policies produce the same authorization decision for every input (subject, action, resource, context, and entity store)? A variant of this question is whether two sets of policies produce the same result for every input. With an answer to this question, there are opportunities for policy optimization, e.g., replacing a complex set of policies with a simplified policy that has the same effect.

[0277] Subsumption: For all inputs for which a permit policy evaluates to true, does a deny policy also evaluate to true? If so, then the permit policy is useless because it does not add any new permissions as it will always be overridden by the deny policy.

[0278] Triviality: For every input, does a given policy evaluate to true or does a given policy evaluate to false? If so, then the policy is equivalent to a boolean constant in terms of its behavior. For example, a trivially true permit policy permits all requests, which is a security concern, and a trivially false deny policy rejects all requests, which is an availability concern.

[0279] Answering the above questions is a non-exhaustive example of what SMT-based analysis can do. More generally, the policy analyzer can answer any first-order question about policy behavior.

[0280] Functionally, an authorization engine takes as input a policy c, an authorization request q, and an entity store s and returns true, false, or an error. The request q specifies the subject, action, resource, and request context. In other words, the authorization engine encompasses a function from policies, requests, and entity stores to the type Option <bool>The eval function. These properties can be expressed as first-order formulas of the authorization engine results. An SMT policy analyzer can be used to determine the validity of these formulas. For example, for the equivalence problem regarding two policies c[1] and c[2], it can be determined as follows:

[0281]

[0282] More generally, assume that f is Option <bool>A first-order n-ary predicate on. In the equivalent example above, f is a biconditional between two equality comparisons. More generally, f can be an Option <bool>Any combination of Boolean operations on it. Given f and a set of n policies c[1], …, c[n], the SMT policy analyzer can check whether the following general statement is always true:

[0283]

[0284] The SMT policy analyzer works by symbolically evaluating the policies c[1],..., c[n] against the symbolic request and the symbolic entity store . The SMT solver is called to check whether the negation of the desired property is unsatisfiable. Refer to Figure 11 . If the SMT solver finds that formula 1100 is unsatisfiable, the property f holds for all possible inputs. Otherwise, the SMT solver has determined a concrete input on which the property f does not hold.

[0285] In formula 1100, the symbolic evaluation function symeval() takes as input the policy c[i], the symbolic request and the symbolic store . The symbolic values represent arbitrary concrete values of a given type.

[0286] Given these inputs, symeval(policy c[i], symbolic request symbolic store ) produces a symbolic value representing the behavior of policy c[i] on an arbitrary concrete input. In other words, the symbolic request and the symbolic store are the variables in the verification formula 1100, and symeval(policy c[i], symbolic request symbolic store ) is an expression in the SMTLib language over these variables representing all possible behaviors of policy c[i]. The SMT solver searches for an assignment of the symbolic variables to concrete values that makes the verification formula 1100 true. Such an assignment is called a "model" of the verification formula 1100.

[0287] Decidability, Soundness, and Completeness

[0288] As described above, symeval(policy c[i], symbolic request symbolic store ) produces a symbolic value. The symbolic value should be decidable, sound, and a complete encoding of the behavior of policy c[i] on an arbitrary concrete input.

[0289] An encoding is decidable if the SMT solver can answer each verification query for that encoding with a satisfiable ("yes") or unsatisfiable ("no") answer. If the encoding is undecidable, the SMT solver may not be able to answer some queries. In practice, undecidability typically manifests as the SMT solver timing out or the SMT solver returning "unknown" instead of satisfiable or unsatisfiable.

[0290] An encoding is sound if an unsatisfiable answer to a verification query for the encoding implies that the property f is guaranteed to hold for all possible concrete inputs for the strategies c[1],..., c[n]. In other words, an unsatisfiable answer for a sound encoding constitutes a proof that the property holds. If the encoding is not sound, an unsatisfiable answer is not a proof, and strategy analysis based on an unsound encoding may miss errors (i.e., violations of property f).

[0291] While necessary, soundness alone is not sufficient to guarantee that SMT analysis yields useful results. This is because soundness only guarantees that unsatisfiable answers are meaningful - it proves that no violations exist. However, if a sound SMT analysis returns a satisfiable result, the only conclusion is that the SMT analysis was unable to find a proof, even though one may exist. Thus, while useless, a simple analysis that always returns satisfiable results is sound. This is why an encoding should be complete in addition to being decidable and sound.

[0292] An encoding is complete if a satisfiable answer to a verification query on the encoding implies that the model of the verification formula 1100 corresponds to concrete inputs (query q and entity store s) for which the strategies c[1],…, c[n] violate the property f. In other words, a satisfiable answer comes with a model that constitutes a witness - the concrete request q and entity store s such that f(eval(policy c[1], request q, entity store s),…, eval(policy c[n],

[0293] request q, entity store s) is false. If the encoding is not complete, a satisfiable model may not be a witness, and SMT strategy analysis based on an incomplete encoding may produce false positives.

[0294] Completeness is the dual of soundness. Completeness only guarantees that satisfiable answers are meaningful - it provides evidence that f is violated. However, if a complete SMT analysis returns an unsatisfiable result, the only conclusion is that the SMT analysis was unable to find a witness, even though one may exist. Thus, while useless, a simple SMT analysis that always returns unsatisfiable is complete.

[0295] A reliable and complete SMT analysis ensures that both unsatisfiable and satisfiable answers are meaningful. An unsatisfiable answer constitutes a proof of correctness due to its reliability, while a satisfiable answer constitutes a concrete proof of incorrectness due to its completeness.

[0296] Pattern-driven symbolic evaluation of policy languages

[0297] Designing a decidable, sound, and complete encoding for rich policy languages is usually impractical. Existing SMT analysis systems for authorization policy languages choose reliability over decidability and completeness, relying on heuristics to minimize the side effects of undecidability (e.g., timeouts in SMT solvers) and incompleteness (e.g., false positives).

[0298] Policy language systems and methods make different trade-offs. Specifically, policy language systems and methods cover a symbolic evaluator that implements a decidable, sound, and complete encoding on a practically important subset of the policy language, rather than sacrificing one or more of these properties to support the full policy language. Specifically, the encoding focuses on strictly typed policies. The symbolic evaluator rejects policies with loose types. For strictly typed policies, the symbolic evaluator produces a decidable, sound, and complete encoding of the behavior of these policies.

[0299] The policy language is dynamically typed. This means that the authorization engine gives meaning to each expression in the language. For example, the expression 1 < "hello” is a syntactically well-formed expression in the policy language. Evaluating this expression results in a runtime error. In other words, eval(1 < "hello”, request q, entity store s) = None. The full dynamic semantics of the policy language is difficult or impractical to encode in SMT because it requires the use of quantified formulas, which are generally undecidable.

[0300] Avoiding the use of quantifiers has two benefits. First, the policy language symbolic evaluator is restricted to strictly typed expressions. By doing so, verification queries on such expressions can be reduced to quantifier-free formulas in a decidable combination of SMT theories. This reduction provides a sound and decidable encoding of strictly typed policy language expressions in SMT. This reduction is pattern-driven because the symbolic evaluator uses policy language patterns to check whether the input is strictly typed and generates a corresponding well-typed SMT encoding as a pattern-based symbolic value representation.

[0301] The only source of incompleteness in the reduction is the well-formedness assumption of the ancestor relationship of policy language entities. This ancestor relationship maps policy language entities to a set of ancestors in the underlying entity hierarchy. The ancestor relationship is modeled by the entity ancestor mapping in the entity store (see Figure 3 )。The hierarchy is assumed to be a directed acyclic graph (DAG), and a well - formed ancestry relationship must represent the transitive closure of the DAG. In general, it is not possible to express the transitive closure of an arbitrary graph in first - order logic. The property of the policy language expression can be utilized to circumvent this problem, that is, it can only refer to a finite number of entities. This observation is used to generate well - formed assumptions that make the simplification complete.

[0302] Strict - type expression

[0303] As described above, the policy language is dynamically typed, which means that the authorization engine will detect type errors at runtime as it evaluates policy expressions. To avoid the possibility of evaluation errors, the policy language provides pattern - based policy validation, which is described in more detail in this article. Given a pattern that describes the assumed structure of the authorization request and entities, the validator rejects policies that are likely to err during evaluation. If the validator accepts a policy, the validated policy will not err when the authorization engine evaluates it against any entity hierarchy and query that conforms to the pattern's specifications.

[0304] A strict - type policy can be simplified to SMT using a policy - language symbol evaluator. The validator can identify non - strict - type policies. If it fails the validator's strict - type checker, the policy can be rewritten. For example, a minimum upper - bound check in a policy can be replaced with an equality check.

[0305] Consider Figure 12 the example pattern. Pattern 1200 specifies the types of the subject, action, resource, and context variables that make up the request, and pattern 1200 specifies the shape of the entity store. The entity pattern specifies the attributes of each entity and its memberOf relationship (if any). The memberOf relationship lists all the allowed ancestor types for instances of a given entity type. For example, an employee may have a team or a department as its ancestor in the entity hierarchy. Similarly, a team or a department may be part of another department. These are the only two hierarchical relationships allowed by pattern 1200. For example, according to pattern 1200, having an expression in a "subject - resource" policy would be a type error because an employee can never be an ancestor of a document in the entity hierarchy.

[0306] Consider the standard validation of the following policy A:

[0307]

[0308] The standard validator will accept this policy. The validator can determine that the type of the then-branch is the entity type Employee and the type of the else-branch is the record type {numberOfLaptops: Long} based on Policy A and pattern 1200. These two types have a least upper bound, which is the record type that guarantees to contain the property numberOfLaptops of the long integer type. Therefore, accessing this property on the if-then-else expression is always safe. Such an access will never result in an evaluation-time error.

[0309] However, Policy A will not pass the strict type check because the strict type rules require the types of the then-branch and the else-branch of the condition to be the same. Therefore, Policy A is not strictly typed and cannot be reduced to SMT. However, Policy A can be rewritten as an equivalent Policy A' so that it passes the strict type check as follows:

[0310]

[0311] Note that it is not always possible to rewrite a verified policy as strictly typed. For example, consider the following Policy B:

[0312]

[0313] Policy B passes the standard verification because:

[0314] (1) The type of the expression principal.addresses is Set <r1>, where R1 is a record type {zip: String, street:? String};

[0315] (2) The types of the parameters included are R2 = {zip: String}; and

[0316] (3) The types R1 and R2 have a least upper bound (in this case, R1).

[0317] The strict type checker will reject Policy B because the strict type checker requires that the types R1 and R2 be the same. Policy B cannot be rewritten and thus cannot pass strict type checking.

[0318] Generally, if a verified policy involves operations on record sets with different underlying record types, it cannot be rewritten to pass strict type checking. In particular, if expressions e1 and e2 have types Set respectively <r1>and Set <r2>, then R1 and R2 must be the same in order to strictly type the operation sets of these expressions (e.g., e1 == e2, e1.containsAll(e2), and e1.containsAny(e2)).

[0319] Pattern-based symbolic value representation

[0320] To simplify the strict typing strategy to SMT, the symbolic evaluator symbolically evaluates the strategy based on the symbolic requests and the symbolic entity store The symbolic requests and the symbolic entity store Both inputs must conform to the patterns used for type-checking the strategy.

[0321] For illustration purposes, Figure 13 an example symbolic request 1300 for the example pattern 1200 is provided. Figure 14 An example symbolic entity store 1400 for the example pattern 1200 is provided. In the example, a name is introduced for the anonymous record type defined in pattern 1200 in the record type 1500 of Figure 15 to make the symbolic representation easier to read.

[0322] The symbolic request 1300 and the symbolic entity store 1400 are represented using sets of symbolic values, and types are assigned to them according to the request pattern and the entity pattern of pattern 1200.

[0323] The symbolic request 1300 covers four symbolic values, one for each requested field. In the example, according to the requirements of the request pattern, the subject, action, and resource fields are assigned to new symbolic variables of type Employee, Action, and Document. A symbolic variable represents any value of a given type, e.g., SymVar("P", Employee) represents any (unknown) value of type Employee. The context field in the example request 1300 is assigned a symbolic empty record literal. This is a symbolic value that represents a specific concrete value - the concrete empty record literal. Each concrete policy language value can be represented as a symbolic literal value, e.g., the concrete entity reference Employee: "Jane" becomes the symbolic literal value SymEntity(Employee, "Jane"). Symbolic [principal]Used to refer to the symbolic value stored in the request body field. In the example, this is SymVar("P", Employee). Note that if the context in example request 1300 has a richer type, such as record {timestamp: Long} instead of the empty record type {}, the context will be a symbolic variable of that richer type (e.g., the record type {timestamp: Long}).

[0324] The symbol store 1400 encompasses a collection of symbol functions that map entities of a given type to their property records and sets of ancestors. Symbolic (uninterpreted) functions represent arbitrary mappings of a given type; for example, SymFun("f0", Employee, R1) represents an arbitrary mapping from Figure 15 values of type Employee of the record type 1500 to values of the record type R1. The symbol functions in the ancestor field together represent the ancestor relationship for a given entity type. For example, the complete ancestor relationship for the Employee type is represented by two symbol functions f1 and f2, which map each employee to their ancestors of type Team and Department respectively (which may be empty sets). The bracket notation is used to refer to stored content; in our example, [Employee][ancestors][Team] refers to the symbol function SymFun("f1", Employee, Set <team>)。

[0325] The symbol variables and functions given in the symbol request 1300 and the symbol store 1400 are the only unknowns in the encoding sent by the symbol calculator to the SMT solver. The SMT solver searches for concrete assignments of these variables and functions that violate the given verification query. For example, consider the triviality analysis to check whether the above strict type policy A' is always true.

[0326] Policy A' is not always true. The SMT solver produces a witness, indicating that policy A' may be false, by finding an assignment of the symbol variables and functions that causes policy A' to evaluate to false. The following is an example of such an assignment, where the values of irrelevant variables and functions are omitted for brevity.

[0327]

[0328] When the subject is Employee::"Alice", the action is Action::"remoteAccess", and the attributes of the subject are f[0](Employee::"Alice") = {jobLevel:4,numberOf Laptops:2}, the evaluation of policy A' is false.

[0329] Any field in the request or store representation can contain symbolic literal values. In our example, only [context] is literal. But it is also possible to define a symbol request or store where other fields are also literal. For example, the main fields of a request for the symbolic literal SymEntity(Employee,"Jane") or [Employee][attributes] can be set to a concrete function definition. If every field in the request and store is a symbolic literal, the result of the symbolic evaluation is also guaranteed to be literal, and the symbolic evaluator behaves exactly the same as the evaluator of the authorization engine.

[0330] Reducing a strict type expression to SMT

[0331] Figure 16 Shows a symbol evaluator 1620 in the provider network 1600 for reducing a strict type expression to SMT. The symbol evaluator 1620 takes as input the strict type expression 1612, the symbol request 1614, and the symbol entity store 1616. The symbol evaluator produces a symbol value 1630 as output. The symbol value 1630 encodes the semantics of the strict type expression 1612 with respect to the symbol request 1614 and the symbol entity store 1616.

[0332] The symbolic value 1630 is expressed in a term language. The term language includes the basic symbolic values under discussion: symbolic variables, functions, and literals. All other terms are inductively created by applying symbolic operators to these basic terms. For example, SymEntity(Action, "remoteAccess")) produces a term that applies the equality operator to the symbolic variable [action] and the literal Action::"remoteAccess".

[0333] The term language has two important properties. The first property is that it can be directly translated into the SMTLib language. Each term produced by the symbolic evaluator 1620 is directly translated into SMTLib. The second property is that the term constructors (e.g., Eq) employ sound rewrite rules to minimize the complexity of the resulting terms. For example, if all the arguments of a constructor are literals, the result is guaranteed to be a literal: Eq(SymInt(1), SymInt(2)) returns SymBool(false), rather than applying the equality operator to the literals 1 and 2, e.g., Term.App2(TermOp2.Eq, SymInt(1), SymInt(2)). These simplifications make the behavior of the symbolic evaluator 1620 similar to that of a concrete evaluator when the symbolic requests 1614 and the symbolic entity store 1616 consist of literals.

[0334] The symbolic evaluator 1620 operates recursively, like the evaluator of the authorization engine. To encode a strictly typed expression 1612 with n subterms, the symbolic evaluator 1620 encodes each subterm separately and then combines the resulting terms into an output term. The type of the output term matches the type of the value that the evaluator of the authorization engine would produce. Specifically, if, according to the strict type checker, the type of the strictly typed expression 1612 is type T, then eval(strictly typed expression e, authorization request q, term T) produces an Option for a concrete authorization request q and a concrete entity store s <t>A specific value of the type, while the symbol evaluator 1620 generates Option <t>Type of item. Option <t>The type takes into account the possibility that the specific calculation of the strict type expression 1612 may go wrong due to errors that cannot be excluded by verification. Therefore, if the evaluation is in error, the result is None, otherwise, for v of type T, the result is Some(v).

[0335] Make well - formed assumptions about the ancestor relationship

[0336] Except for the IN operator on entities used to test hierarchical membership, the symbolic evaluation function is sound and complete for all operators in the policy language. For the IN operator, the encoding is sound but incomplete. To illustrate this, consider the symbolic evaluation of the following expression:

[0337] Department::"A”in Department::"B”&&Department::"B”in Department::"A”.

[0338] The symbolic evaluator encodes this expression as the term And(t[0],t[1]), where:

[0339]

[0340] A = SymEntity(Department,"A”), and

[0341] B = SymEntity(Department,"B”).

[0342] In other words, to check whether B is an ancestor of A in the entity hierarchy, t[0] first obtains the set of all ancestors of A and then checks whether this set contains B. The term t[1] performs the same calculation to check whether A is an ancestor of B.

[0343] If the term And(t[0],t[1]) is converted to SMTLib and the SMT solver is asked whether there is an assignment for which the term is true, the SMT solver will produce a witness. For example, the SMT solver can return the following model:

[0344]

[0345] In the above model, A is mapped to a singleton set containing B, and B is mapped to a singleton set containing A. This model satisfies the term. However, this model does not correspond to a valid entity hierarchy because in a valid entity hierarchy of a directed acyclic graph (DAG), two entities cannot be ancestors of each other. Therefore, a complete encoding of the example expression will produce a term that is false under all possible assignments. In other words, it is unsatisfiable.

[0346] To solve this problem, the encoding is strengthened by assuming that the ancestor relationship is irreflexive, antisymmetric, and transitive. These assumptions arise from observing that a policy language expression can only access a finite set of entities during evaluation. Specifically, there are only two ways for the evaluation of a policy language expression to generate an entity reference: (1) by evaluating an entity literal (e.g., Department::"A"), or (2) by accessing an attribute that stores an entity reference (e.g., principal.manager, where manager is an Employee). Thus, if the set of all (1) entity literals and (2) entity value attribute accesses that occur in the expression is collected, there is a way to refer to every possible entity reference that the expression might generate during evaluation.

[0347] First, this set of sub-expressions, called collect(e), is collected from the policy language expression e. For example, the collect(e) for the above example expression is the set [Department::"A", Department::"B"].

[0348] Next, the set of terms is determined and is called entities(e) hereinafter.

[0349] The assumptions can be generated in two steps:

[0350] (1) In the first step, iterate over all terms t[i] in the set entities(e). If t[i] can have an ancestor of its own type according to the memberOf relationship, emit the term Not(Contains(anc[i], t[i])). Here, anc[i] is the term representing the relevant ancestor of t[i]. This assumption restricts the ancestor relationship to be irreflexive on the term t[i].

[0351] (2) In the second step, iterate over each pair of terms t[i] and t[j] in the set entities(e). If t[j] can be an ancestor of t[i] according to the memberOf relationship, emit a term of the form Implies(Contains(anc[i], t[j]).Subset(anc[j], anc[i])) for each correct combination of the types of the ancestor sets of t[i] and t[j]. This assumption states that if t[j] is an ancestor of t[j], then the ancestors of t[j] must be contained in the ancestor set of t[i].

[0352] The above two assumptions hold for any ancestor relationship that represents the transitive closure of a directed acyclic graph.

[0353] For example, the assumption generator of the symbolic evaluator will emit the following terms for the above example expression:

[0354] (1) Not (Contains (AppFun (f(6), A), A))

[0355] (2) Not (Contains (AppFun (f(6), B), B))

[0356] (3) Implies (Contains (AppFun (f(6), A), B). Subset (AppFun (f(6), B), AppFun (f(6), A)))

[0357] (4) Implies (Contains (APpFun (f(6), b), a). Subset (AppFun (f(6), A), AppFun (f(6), B)))

[0358] After adding these items (1)–(4) to the original encoding of the above item And(t[0], t[1]), the SMT solver can no longer find a model as expected.

[0359] The policy language system and method include a graphical user interface, a command-line interface, or a software development kit tool that enables users to verify and analyze provider network policies written in the policy language. These tools also include a validator (or simply "validator") and a policy analyzer tool (or simply "policy analyzer"). The validator can capture type errors. The policy analyzer is SMT-based and can capture logical errors.

[0360] Policy Language Item Language

[0361] The following is the formal specification of the strongly simply typed item language used by the symbolic evaluator. The symbolic evaluator simplifies policy language expressions to the item language during the symbolic evaluation process. The item language can be directly translated into SMTLib.

[0362]

[0363] Each item has its type, unless the type can be easily obtained from the sub-items. Items can be created using the factory functions defined below.

[0364]

[0365]

[0366] The following are unary uninterpreted functions representing an arbitrary mapping from entities of a given type to records of a given type.

[0367]

[0368] The following are factory functions for creating items:

[0369]

[0370]

[0371]

[0372] Example provider network environment

[0373] Figure 17 An example provider network environment 1700 is shown in which the techniques disclosed herein are implemented. Environment 1700 includes a provider network 1710 and an optional intermediate network 1730 and an optional customer network 1750. Although the intermediate network 1730 and the customer network 1750 are depicted as being external to the provider network 1710, the intermediate network 1730 and the customer network 1750 can also be located within the provider network 1710. The provider network 1710 provides resource virtualization to customers of the provider network 1710 via a virtualization service 1718. The virtualization service 1718 allows customers to purchase, lease, subscribe to, or otherwise obtain the use of one or more resources (e.g., resource 1712). Figure 17 The provider network 1700 includes a policy evaluation service 1742 for evaluating authorization policies according to the techniques disclosed herein, a policy verification service 1744 for verifying policies according to the techniques disclosed herein, and a policy analysis service 1746 for analyzing authorization policies according to the techniques disclosed herein. Services 1742, 1744, or 1746 can be provided to other services (including each other) in the provider network 1710 via an API. Additionally or alternatively, services 1742, 1744, or 1746 can be provided to customer devices (e.g., customer device 1752 in the customer network 1750) or other network entities (e.g., network entity 1720) in the customer network via an API and the intermediate network 1730.

[0374] The provider network 1710 is for providing a computing environment in which the techniques disclosed herein can be implemented. The provider network 1710 is programmed or configured to follow a cloud computing model. The model enables ubiquitous, convenient on-demand network access to a shared pool of configurable resources such as virtual machines, containers, networks, servers, storage, applications, services, or any other configurable resources of the provider network 1710. Resources can be provisioned and released quickly with minimal administrative effort or service provider interaction.

[0375]

[0376] ​Users of the provider network 1710 (sometimes referred to herein as "customers" in the provider network 1710) automatically provision resources within the provider network 1710, such as virtual machines, containers, server time, network storage, or any other resources, with minimal or no human interaction with the service provider. Resources of the provider network 1710 are available via an intermediate network (e.g., the Internet) and are accessed through standard mechanisms that facilitate the use of heterogeneous remote electronic devices, such as thin client platforms or thick client platforms or any other type of computing platform, such as desktop computers, mobile phones, tablet computers, laptop computers, workstation computers, smart appliances, Internet of Things (IoT) devices, or any other type of electronic device.

[0377] Resources such as computing, storage, processing, memory, and network resources in the provider network 1710 are pooled to serve multiple customers using a multi-tenant model, with different physical and virtual resources being dynamically allocated and reallocated according to customer needs. There is a sense of location independence because customers generally have no control over or knowledge of the exact location of the resources provided, but can specify a location at a higher level of abstraction (such as, for example, at the level of a country, state, data center, or any other location granularity). The provider network 1710 automatically controls and optimizes resource usage by leveraging metering capabilities (e.g., based on pay-per-use, usage-based billing, subscription-based, or any other fee basis) at an abstract level appropriate for the type of service (e.g., computing, storage, processing, memory, network bandwidth, active customer accounts, or any other appropriate level of abstraction). Resource usage in the provider network 1710 is monitored, controlled, and reported, providing transparency to both the provider and the customer of the services being utilized.

[0378] The provider network 1710 can offer its capabilities to customers according to a variety of different service models, including software as a service (SaaS), platform as a service (PaaS), infrastructure as a service (IaaS), or any other service model.

[0379] For SaaS, software applications of the provider network 1710 running on the infrastructure of the provider network 1710 are used to provide capabilities to customers. The applications may be accessible from various remote electronic devices through a thin client interface such as a command line interface (CLI), a graphical user interface (GUI) (e.g., via a web browser or a mobile or web application), a software development kit (SDK), or any other interface. The infrastructure of the provider network 1710 includes hardware resources such as servers, storage, and network resources, as well as software deployed on the hardware infrastructure to support the provided services. Generally, in the SaaS model, customers do not manage or control the underlying infrastructure, including the network, servers, operating systems, storage, or individual application capabilities, except for limited customer-specific application configuration settings.

[0380] For PaaS, customers are provided with the ability to deploy applications created or acquired by the customers onto the hardware and software infrastructure of the provider network 1710 using programming languages, libraries, services, and tools supported by the provider network 1710 or other sources. Generally, in the PaaS model, customers do not manage or control the underlying hardware and software infrastructure, including the network, servers, operating systems, or storage, but can control the deployed applications and may control the configuration settings of the application hosting environment.

[0381] For IaaS, customers are provided with the ability to provision processing, storage, network, and other basic computing resources in which the customers can deploy and run any software, which may include operating systems and applications. Customers generally do not manage or control the underlying hardware and software infrastructure, but can control the operating systems, storage, and deployed applications, and may have limited control over the selection of network components (such as, for example, a host firewall).

[0382] The provider network 1710 can provide its capabilities to customers according to various different deployment models, which include as a private cloud, as a community cloud, as a public cloud, as a hybrid cloud, or any other deployment model.

[0383] In a private cloud, the hardware and software infrastructure of the provider network 1710 is provisioned for the exclusive use of a single organization that may include multiple customers. The private cloud is owned, managed, and operated by the organization, a third party, or some combination thereof, and it can exist on-premises or off-premises.

[0384] In a community cloud, the hardware and software infrastructure of the provider network 1710 is provisioned for the exclusive use of a specific community of customers in organizations with common concerns (such as mission security requirements, policies, and compliance considerations). The community cloud is owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination thereof, and it can exist on-premises or off-premises.

[0385] In a public cloud, the infrastructure is provisioned for public use. A public cloud is owned, managed, and operated by a commercial, academic, or government organization, or some combination thereof. A public cloud can exist within the premises of a public cloud provider.

[0386] In a hybrid cloud, the infrastructure is a composition of two or more distinct cloud infrastructures (private, community, public, or any other cloud infrastructure), which remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability, such as, for example, cloud bursting for load balancing between clouds.

[0387] Resource 1712 is a computing, storage, or networking resource. Resource 1712 is implemented by an electronic device in a data center within provider network 1710. A data center is a physical facility or building that houses computing, storage, and networking infrastructure. Provider network 1710 encompasses many resources implemented by a number of electronic devices distributed across a set of data centers located in different geographical regions or locations. An example of an electronic device is device 1800 described below with respect to Figure 18 description of device 1800.

[0388] An example of resource 1712 is a virtual machine (VM). A virtual machine is a computing resource that uses software instead of a physical computer to run programs and deploy applications. A virtual machine (sometimes referred to as a "guest") can run on a single physical machine (sometimes referred to as a "host"). A virtual machine can execute its own operating system (e.g., UNIX, WINDOWS, LINUX, etc.), and can run at least partially separately from other virtual machines, including virtual machines on the same host. A virtual machine can replace a physical machine. The physical resources of the host can be shared among multiple virtual machines, each running a copy of its own operating system. Access to and use of the physical resources of the host (e.g., hardware processors and physical memory resources) by multiple virtual machines can be coordinated by a virtual machine monitor (sometimes referred to as a "hypervisor"). The hypervisor itself can run on the bare hardware of the host, or as a process of an operating system running on the bare hardware.

[0389] Another example of resource 1712 is a container. In terms of running separate applications on a single platform, a container is like a virtual machine. However, a container typically encapsulates a single application or a collection of one or more related applications, along with runtime dependencies and libraries, while a virtual machine virtualizes the hardware to create a "computer". Another difference is that a container system typically provides services of the operating system core running on the bare hardware of the underlying host to containers that share core services as coordinated by the container system. The container system itself can run on the host by virtue of the operating system core and can, to some extent, isolate containers from each other. Although containers can be used independently of virtual machines, containers and virtual machines can also be used together. For example, a container can run on an operating system running on a virtual machine running on a host.

[0390] Although resource 1712 can be a virtual machine or a container, resource 1712 can be any suitable type of computing, data storage, or network resource in provider network 1700.

[0391] Within provider network 1710, a local Internet Protocol (IP) address 1714 is associated with resource 1712. The local IP address 1714 includes an internal or private network address within provider network 1710. The local IP address 1714 can be, for example, an IPv4 or IPv6 address. For example, the local IP address 1714 can be an address reserved by Request for Comments (RFC) 1918 of the Internet Engineering Task Force (IETF), or have an address format specified by IETF RFC 4193, and can be variable within provider network 1710.

[0392] Network traffic originating from network entity 1720 coupled to intermediate network 1730 or from client device 1752 in client network 1750, whose destination is resource 1712 in provider network 1710, typically is not directly routed to local IP address 1714. Instead, the network traffic is addressed to public IP address 1716. The public IP address 1716 can be mapped to the local IP address 1714 within provider network 1710 using network address translation (NAT) or a similar technique.

[0393] Using a customer device 1752 in a customer network 1750, a customer uses, controls, operates, or benefits from virtualization services 1718, resources 1712, a local IP address 1714, and a public IP address 1716 to implement a customer-specific application and provide the application to one or more network entities (e.g., network entity 1720) on an intermediate network 1730. The network entity 1720 can generate network traffic destined for the application by addressing network traffic for the public IP address 1716. The traffic can be routed via the intermediate network 1730 to a data center of a provider network 1710, which houses electronic devices that implement the resources 1712. Within the data center, the traffic can be routed to the local IP address 1714, where the resources 1712 receive and process the traffic. Response network traffic from the resources 1712 can be routed back onto the intermediate network 1730 and routed to the network entity 1720.

[0394] The provider network 1710 can also provide a storage service 1748 to the customer. For example, the storage service 1748 can be used to store authorization data, entity storage, authorization policies, and authorization policy patterns. The storage service 1748 can provide an API to access data from and store data to storage resources of a virtual data storage (e.g., a folder or "bucket", virtual volume, database, etc.) provided by the provider network 1710.

[0395] Example Electronic Device

[0396] Figure 18 An example electronic device 1800 used in an implementation of the techniques disclosed herein is shown. The device 1800 includes a set of one or more processors 1802-1, 1802-2, ……, 1802-N coupled to a system memory 1806 via an input / output (I / O) interface 1804. The device 1800 can also include a network interface 1816 coupled to the I / O interface 1804.

[0397] The device 1800 is a single-processor system that includes one processor or a multi-processor system that includes multiple processors. Each of the processors 1802-1, 1802-2, ……, 1802-N is any suitable processor capable of executing instructions. For example, each of the processors 1802-1, 1802-2, ……, 1802-N can be a general-purpose processor or an embedded processor that implements any one of various instruction set architectures (ISAs) such as X86, ARM, POWERPC, SPARC, or MIPS ISA or any other suitable ISA.

[0398] The system memory 1806 stores instructions and data accessible to the processors 1802-1, 1802-2, ……, 1802-N. The system memory 1806 is implemented using any suitable memory technology, such as random access memory (RAM), static RAM (SRAM), synchronous dynamic RAM (SDRAM), non-volatile or flash-type memory, or any other type of memory. The program instructions 1808 and data 1810 that implement the required functions, such as the methods, procedures, actions, or operations of the techniques disclosed herein, are stored in the system memory 1806 as code 1808 (e.g., executable to implement in whole or in part the methods, processes, actions, or operations performed by an authorization engine, a validator, the STT phase of a validator, or an SMT-based policy analyzer) and data 1810.

[0399] The I / O interface 1804 can be configured to coordinate I / O traffic between the processors 1802-1, 1802-2, ……, 1802-N, the system memory 1806, and any peripheral devices in the apparatus 1800, the peripheral devices including optionally a network interface 1816 or other peripheral interfaces (not shown). The I / O interface 1804 can perform any necessary protocols, timing, or other data transformations to convert data signals from one component (e.g., the system memory 1806) into a format suitable for use by another component (e.g., the processors 1802-1, 1802-2, ……, 1802-N).

[0400] The I / O interface 1804 includes support for devices attached via various types of peripheral buses, such as variants of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard (e.g., a bus implementing a version of the Peripheral Component Interconnect Express (PCI-E) standard, or another interconnect, such as QuickPath Interconnect (QPI) or UltraPath Interconnect (UPI)). For example, the functionality of the I / O interface 1804 can be split into two or more separate components, such as a north bridge and a south bridge. Additionally, some of the functionality of the I / O interface 1804 (such as the interface to the system memory 1806) can be incorporated directly into the processors 1802-1, 1802-2, ……, 1802-N.

[0401] An optional network interface 1816 is configured to allow data to be exchanged between the device 1800 and another electronic device 1820 attached to the device 1800 via a network 1818. The network interface 1816 supports communication via any suitable wired or wireless network (such as, for example, a certain type of wired or wireless Ethernet network). Additionally, the network interface 1816 may support communication via a telecommunications or telephone network (such as an analog voice network or a digital fiber optic communication network), via a storage area network (SAN) (such as a Fibre Channel SAN), or via any other suitable type of network or protocol.

[0402] The device 1800 optionally includes an offload card 1812 that includes a processor 1814 and may include a network interface (not depicted) connected using the I / O interface 1804. For example, the device 1800 may act as a host electronic device that hosts computing resources such as computing instances (e.g., operating as part of a hardware virtualization service), and the offload card 1812 may execute a virtualization manager that can manage the computing instances executed on the host electronic device 1800. As an example, the offload card 1812 may perform computing instance management operations such as pausing or resuming a computing instance, starting or terminating a computing instance, performing memory transfer / copy operations, etc. These management operations may be performed in cooperation by the offload card and a hypervisor (e.g., in accordance with a request from the hypervisor) executed by the processors 1802-1, 1802-2, ……, 1802-N of the device 1800. However, the virtualization manager implemented by the offload card 1812 may accommodate requests from other entities (such as, for example, from the computing instance itself).

[0403] The system memory 1806 may include one or more computer-accessible media configured to store program instructions 1808 and data 1810. However, the program instructions 1808 or data 1810 may be received, sent, or stored on different types of computer-accessible media. Computer-accessible media includes non-transitory computer-accessible media and computer-accessible transmission media. Examples of non-transitory computer-accessible media include volatile or non-volatile computer-accessible media. Volatile computer-accessible media includes, for example, most general-purpose random access memories (RAM), including dynamic RAM (DRAM) and static RAM (SRAM). Non-volatile computer-accessible media includes, for example, semiconductor memory chips capable of storing instructions or data in floating-gate memory cells composed of floating-gate metal oxide semiconductor field effect transistors (MOSFETs), including flash memories such as NAND flash and solid state drives (SSDs). Other examples of non-volatile computer-accessible media include read-only memory (ROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), ferroelectric RAM, and other computer data storage devices (e.g., disk storage, hard disk drives, optical disks, floppy disks, and magnetic tapes).

[0404] The terms

[0405] In the foregoing description and the appended claims, ordinal numbers such as first, second, etc. may be used to describe various elements, features, acts, or operations. Unless the context clearly indicates otherwise, such elements, features, acts, or operations are not limited by these terms. These terms are only used to distinguish one element, feature, act, or operation from another. For example, a first device may be referred to as a second device. The first device and the second device are both devices, but they are not the same device.

[0406] As used in the foregoing description and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an", "the", and "said" are also intended to include the plural forms.

[0407] As used in the foregoing description and the appended claims, unless the context clearly indicates otherwise, the terms "comprising", "including", "having", "based on", "covering", and other similar terms are used in an open-ended manner in the foregoing description and the appended claims and do not exclude additional elements, features, acts, or operations.

[0408] Regarding "based on", this term is used in some cases in the foregoing description and the appended claims to identify a causal relationship between the steps, acts, or operations. Unless the context clearly indicates otherwise, "A based on B" in these cases means that the performance of step, act, or operation B causes the performance of step, act, or operation A. The causal relationship can be direct (without going through intermediate steps, acts, or operations) or indirect (through the performance of one or more intermediate steps, acts, or operations). However, unless the context clearly indicates otherwise, the term "A based on B" is not intended to require that the performance of B is necessary for the performance of A in all cases, and in some cases, the performance of A may not be caused by the performance of B. However, in these cases, A is not based on B, even though in other cases, A is based on B. Additionally, unless the context clearly indicates otherwise, the term "A based on B" is not intended to require that the performance of B itself is sufficient for the performance of A in all cases, and in some cases, one or more other steps, acts, or operations in addition to B may be performed to cause the performance of A. In such a situation, even if multiple steps, acts, or operations including B are performed to cause A, A may still be based on B.

[0409] Unless the context clearly indicates otherwise, the term "or" is used in the foregoing description and the appended claims in its inclusive sense (rather than in its exclusive sense), such that when used, for example, to connect a series of elements, features, acts, or operations, the term "or" means one, some, or all of the elements, features, acts, or operations in the series.

[0410] Unless the context clearly indicates otherwise, conjunctive language such as the phrase "at least one of X, Y, and Z" in the foregoing description and the appended claims should be understood to convey that an article, item, etc. can be X, Y, or Z, or a combination thereof. Thus, such conjunctive language does not require the separate presence of at least one X, at least one Y, and at least one Z.

[0411] At least some embodiments of the disclosed technology can be described in view of the following clauses:

[0412] 1. A method performed by one or more electronic devices in a provider network, the method comprising:

[0413] Obtain an authorization policy pattern;

[0414] Determine whether there is any inconsistency between an authorization policy in an authorization policy language and the authorization policy pattern;

[0415] Wherein the authorization policy includes:

[0416] (a) Effects;

[0417] (b) An authorization policy header that selects one or more subjects, one or more actions, or one or more resources to which the authorization policy applies; and

[0418] (c) One or more optional conditional clauses that further refine the circumstances under which the authorization policy applies;

[0419] Determine that there is no inconsistency between the authorization policy and the authorization policy pattern, such that it is ensured that the authorization policy has no runtime type errors and runtime property access errors for any input that conforms to the authorization policy pattern.

[0420] 2. The method according to clause 1, further comprising:

[0421] Storing a set of entities arranged in an entity hierarchy; and

[0422] Wherein the authorization policy further includes at least one expression regarding one or more entities in the entity hierarchy.

[0423] 3. The method according to clause 1, wherein the authorization policy language is a dynamically typed language.

[0424] 4. A method performed by one or more electronic devices, the method comprising:

[0425] Obtaining an authorization policy pattern;

[0426] Determining whether there is any inconsistency between an authorization policy in an authorization policy language and the authorization policy pattern;

[0427] Wherein the authorization policy includes:

[0428] (a) An effect;

[0429] (b) An authorization policy header that selects one or more subjects, one or more actions, or one or more resources to which the authorization policy applies; and

[0430] (c) One or more optional conditional clauses that further refine the circumstances under which the authorization policy applies;

[0431] If there is one or more determined inconsistencies between the authorization policy and the authorization policy pattern, then cause information indicating that the authorization policy is invalid with respect to the authorization policy pattern to be displayed; and

[0432] Wherein if there is no determined inconsistency between the authorization policy and the authorization policy pattern, then it is ensured that the authorization policy has no runtime type errors and runtime property access errors for any input that conforms to the authorization policy pattern.

[0433] 5. The method as described in clause 4 further includes:

[0434] storing a set of entities arranged in an entity hierarchy; and

[0435] wherein the authorization policy further includes at least one expression regarding one or more entities in the entity hierarchy.

[0436] 6. The method as described in clause 4 further includes:

[0437] detecting a boolean expression in the authorization policy, the boolean expression dereferencing an optional attribute of an entity without checking for the existence of the optional attribute of the entity as a prerequisite; and

[0438] wherein the displayed information indicates that the boolean expression lacks a check for the existence of the optional attribute of the entity as a prerequisite.

[0439] 7. The method as described in clause 4 further includes:

[0440] detecting an entity type in the authorization policy that is not an entity type listed in the entity type specification; and

[0441] wherein the displayed information indicates the entity type in the authorization policy.

[0442] 8. The method as described in clause 4 further includes:

[0443] detecting an action in the authorization policy that is not an action listed in the action specification; and

[0444] wherein the displayed information indicates the action in the authorization policy.

[0445] 9. The method as described in clause 4 further includes:

[0446] detecting an action applied in the authorization policy to an unsupported principal or resource in the authorization policy; and

[0447] wherein the displayed information indicates the action in the authorization policy and indicates the unsupported principal or resource in the authorization policy to which the action is applied.

[0448] 10. The method as described in clause 4 further includes:

[0449] detecting an improper use of a hierarchy containment operator in the authorization policy; and

[0450] wherein the displayed information includes a hint regarding the proper use of the hierarchy containment operator in the authorization policy.

[0451] 11. The method as described in clause 4, further comprising:

[0452] detecting improper use of equality operators in the authorization policy; and

[0453] wherein the displayed information includes a hint regarding proper use of the hierarchical containment operator.

[0454] 12. The method as described in clause 4, further comprising:

[0455] detecting unrecognized attributes of entities in the authorization policy, where the unrecognized attributes are not specified as attributes of the entities in the authorization policy schema; and

[0456] wherein the displayed information indicates the unrecognized attributes.

[0457] 13. The method as described in clause 4, further comprising:

[0458] detecting type mismatches in operator expressions in the authorization policy, where the operator expressions include operators that have valid semantics only for certain data types, and the operator expressions apply the operators to values of data types for which the operators do not have valid semantics; and

[0459] wherein the displayed information indicates the type mismatches.

[0460] 14. The method as described in clause 4, further comprising:

[0461] detecting that the authorization policy always evaluates to false; and

[0462] wherein the displayed information indicates that the authorization policy always evaluates to false.

[0463] 15. The computer-implemented method as described in clause 4, wherein the authorization policy schema and the authorization policy are identified to the policy validator via parameters in a command-line invocation of the policy validator.

[0464] 16. The method as described in clause 4, wherein the authorization policy language is a dynamically typed language.

[0465] 17. A system, comprising:

[0466] a first set of one or more electronic devices for implementing an authorization policy verification service in a provider network, the authorization policy verification service including instructions that, when executed, cause the authorization policy verification service to perform:

[0467] obtaining an authorization policy schema;

[0468] Determine whether there are any inconsistencies between the authorization policy in the authorization policy language and the authorization policy pattern;

[0469] wherein the authorization policy includes:

[0470] (a) Effects;

[0471] (b) An authorization policy header that selects one or more principals, one or more actions, or one or more resources to which the authorization policy applies; and

[0472] (c) One or more optional conditional clauses that further refine the circumstances under which the authorization policy applies;

[0473] If there are one or more identified inconsistencies between the authorization policy and the authorization policy pattern, cause information indicating that the authorization policy is invalid with respect to the authorization policy pattern to be displayed; and

[0474] wherein if there are no identified inconsistencies between the authorization policy and the authorization policy pattern, cause it to be ensured that the authorization policy has no runtime type errors and runtime property access errors for any input that conforms to the authorization policy pattern.

[0475] 18. The system as described in clause 17, wherein the authorization policy verification service further includes instructions that, when executed, cause the authorization policy verification service to further perform the following:

[0476] Store a set of entities arranged in an entity hierarchy; and

[0477] wherein the authorization policy further includes at least one expression regarding one or more entities in the entity hierarchy.

[0478] 19. The system as described in clause 17, wherein the authorization policy verification service further includes instructions that, when executed, cause the authorization policy verification service to further perform the following:

[0479] Detect a boolean expression in the authorization policy that dereferences an optional property of an entity without checking for the existence of the optional property of the entity as a prerequisite; and

[0480] wherein the displayed information indicates that the boolean expression lacks a check for the existence of the optional property of the entity as a prerequisite.

[0481] 20. The system as described in clause 17, wherein the authorization policy verification service further includes instructions that, when executed, cause the authorization policy verification service to further perform the following:

[0482] Detect the entity type in the authorization policy, where the entity type is not an entity type listed in the entity type specification; and

[0483] where the displayed information indicates the entity type in the authorization policy.

[0484] 21. A method performed by one or more electronic devices in a provider network, the method comprising:

[0485] Receiving an authorization request from a provider network application in the provider network;

[0486] Identifying a set of authorization policies, where each authorization policy in the set of authorization policies includes:

[0487] (a) An effect;

[0488] (b) An authorization policy header that selects a principal, action, or resource to which the authorization policy applies; and

[0489] (c) One or more optional conditional clauses that further refine the circumstances under which the authorization policy applies;

[0490] Based on the evaluation of the authorization request against the authorization policy header in the at least one authorization policy, removing at least one authorization policy from the set of authorization policies;

[0491] Evaluating a subset of the set of authorization policies against the authorization request; and

[0492] Allowing or denying the authorization request based on the evaluation of the subset.

[0493] 22. The method of clause 21, further comprising:

[0494] Storing a set of entities arranged in an entity hierarchy; and

[0495] where the authorization policy further includes an expression regarding one or more entities in the entity hierarchy.

[0496] 23. The method of clause 21, where removing the at least another authorization policy from the evaluation of the authorization request based on the authorization policy header of the at least one authorization policy is further based on:

[0497] Determining a resource identifier of a resource from the authorization request;

[0498] Determining a set of entity identifiers of a set of entities in an entity hierarchy, where the entity identifiers are ancestors of the resource in the entity hierarchy; and

[0499] Determine an authorization policy set, where each authorization policy has a header resource that matches an entity identifier in the resource identifier or the set of entity identifiers.

[0500] 24. A method performed by one or more electronic devices, the method comprising:

[0501] Receiving an authorization request;

[0502] Identifying an authorization policy set, where each authorization policy in the authorization policy set includes:

[0503] (a) An effect;

[0504] (b) An authorization policy header that selects a principal, action, or resource to which the authorization policy applies; and

[0505] (c) One or more optional conditional clauses that further refine the circumstances under which the authorization policy applies;

[0506] Based on the evaluation of the authorization request against the authorization policy header in the at least one authorization policy, removing at least one authorization policy from the authorization policy set;

[0507] Evaluating a subset of the authorization policy set for the authorization request; and

[0508] Allowing or denying the authorization request based on the evaluation of the subset of the authorization policies.

[0509] 25. The method according to clause 24, further comprising:

[0510] Storing a set of entities arranged in an entity hierarchy; and

[0511] Wherein one or more authorization policies in the authorization policy set each further include at least one expression of one or more entities in the entity hierarchy.

[0512] 26. The method according to clause 24, wherein removing the at least one authorization policy from the evaluation of the authorization request based on the authorization policy header of the authorization policy is further based on:

[0513] Determining a principal identifier of a principal from the authorization request;

[0514] Determining a set of entity identifiers of a set of entities in an entity hierarchy, where the entity identifiers are ancestors of the principal in the entity hierarchy; and

[0515] Determining a second authorization policy set, where each authorization policy has a header resource that matches an entity identifier in the principal identifier or the set of entity identifiers.

[0516] 27. The method as described in clause 26, further comprising:

[0517] Determining a subset of a second set of authorization policies, wherein for each authorization policy in the subset of the second set, the set of header constraints of the authorization policy evaluates to true for the authorization request.

[0518] 28. The method as described in clause 24, further comprising:

[0519] Determining required entity data from the subset of the set of authorization policies;

[0520] Sending a query to an entity store to obtain a first set of entity data;

[0521] Receiving the first set of entity data from the entity store;

[0522] Wherein the second authorization policy includes a chain of two or more entity references;

[0523] Determining that the first set of entity data includes specific entity data for a specific entity reference in the chain of two or more entity references; and

[0524] Based on determining that the first set of entity data includes the specific entity data, determining that no additional query needs to be sent to the entity store to obtain the specific entity data.

[0525] 29. The method as described in clause 24, wherein:

[0526] The authorization request specifies a first specific subject;

[0527] The header of a specific authorization policy in the subset of the set of authorization policies includes a hierarchical constraint expression regarding a second specific subject; and

[0528] The method further comprises evaluating the header of the second authorization policy based on accessing an entity ancestor map that maps the first specific subject to a set of specific subjects that are ancestors of the first specific subject in an entity hierarchy, and determining that the second specific subject is within the set of specific subjects that are ancestors of the first specific subject in the entity hierarchy.

[0529] 30. The method as described in clause 24, wherein:

[0530] The authorization request specifies a first specific entity;

[0531] The condition of a specific authorization policy in the subset of the set of authorization policies includes an expression for accessing entity attributes; and

[0532] The method further includes evaluating the conditions of the specific policy based on an entity-attribute mapping that maps the first specific entity to an attribute record of the first specific entity, and accessing the attributes of the attribute record.

[0533] 31. The method according to clause 24, further comprising:

[0534] Randomly generate test inputs;

[0535] Run a production policy authorization engine and a reference policy authorization engine on the test inputs, where the reference policy authorization engine is implemented using a theorem-proving programming language;

[0536] Obtain a first output of the production policy authorization engine on the test inputs;

[0537] Obtain a second output of the reference authorization engine on the test inputs; and

[0538] Compare the first output with the second output.

[0539] 32. The method according to clause 24, further comprising:

[0540] Receive the authorization request from a provider network application in the provider network; and

[0541] Return a response to the authorization request to the provider network application, the response indicating that the authorization request is denied.

[0542] 33. The method according to clause 24, wherein the policies in the authorization policy set include one or more sets of role-based access control expressions that are syntactically separate from one or more sets of attribute-based access control expressions of the policy.

[0543] 34. A system, comprising:

[0544] A first set of one or more electronic devices for implementing an authorization policy evaluation service, the authorization policy verification service including instructions that, when executed, cause the authorization policy evaluation service to perform:

[0545] Receive an authorization request;

[0546] Identify an authorization policy set, wherein each authorization policy in the authorization policy set includes:

[0547] (a) An effect;

[0548] (b) An authorization policy header that selects a principal, action, or resource to which the authorization policy applies; and

[0549] (c) One or more optional conditional clauses that further refine the circumstances under which the authorization policy is applied;

[0550] Based on the evaluation of the authorization request against the authorization policy header in the at least one authorization policy, removing at least one authorization policy from the set of authorization policies;

[0551] Evaluating a subset of the set of authorization policies against the authorization request; and

[0552] Allowing or denying the authorization request based on the evaluation of the subset.

[0553] 35. The method as recited in clause 24, wherein the authorization policy evaluation service further includes instructions that, when executed, cause the authorization policy evaluation service to further perform the following:

[0554] Storing a set of entities arranged in an entity hierarchy; and

[0555] wherein one or more of the authorization policies in the set of authorization policies each further include at least one expression of one or more entities in the entity hierarchy.

[0556] 36. The method as recited in clause 24, wherein removing the at least one authorization policy from the evaluation against the authorization request based on the authorization policy header of the authorization policy is further based on:

[0557] Determining a subject identifier of a subject from the authorization request;

[0558] Determining a set of entity identifiers of a set of entities in the entity hierarchy that are ancestors of the subject in the entity hierarchy; and

[0559] Determining a second set of authorization policies, each authorization policy having a header resource that matches an entity identifier in the subject identifier or the set of entity identifiers.

[0560] 37. The method as recited in clause 26, wherein the authorization policy evaluation service further includes instructions that, when executed, cause the authorization policy evaluation service to further perform the following:

[0561] Determining a subset of the second set of authorization policies, wherein for each authorization policy in the subset of the second set, the set of header constraints of the authorization policy evaluates to true against the authorization request.

[0562] 38. The method as recited in clause 24, wherein the authorization policy evaluation service further includes instructions that, when executed, cause the authorization policy evaluation service to further perform the following:

[0563] Determine the required entity data from the subset of the authorization policy set;

[0564] Send a query to the entity store to obtain a first set of entity data;

[0565] Receive the first set of entity data from the entity store;

[0566] Wherein the second authorization policy includes a chain of two or more entity references;

[0567] Determine that the first set of entity data includes specific entity data for a specific entity reference in the chain of two or more entity references; and

[0568] Based on determining that the first set of entity data includes the specific entity data, determine that no additional query needs to be sent to the entity store to obtain the specific entity data.

[0569] 39. The method according to clause 24, wherein:

[0570] The authorization request specifies a first specific subject;

[0571] The header of a specific authorization policy in the subset of the authorization policy set includes a hierarchical constraint expression regarding a second specific subject; and

[0572] The authorization policy evaluation service further includes instructions that, when executed, cause the authorization policy evaluation service to further evaluate the header of the second authorization policy based on an access entity ancestor mapping that maps the first specific subject to a specific set of subjects that are ancestors of the first specific subject in the entity hierarchy, and determine that the second specific subject is located in the specific set of subjects that are ancestors of the first specific subject in the entity hierarchy.

[0573] 40. The method according to clause 24, wherein:

[0574] The authorization request specifies a first specific entity;

[0575] The condition of a specific authorization policy in the subset of the authorization policy set includes an expression for accessing entity attributes; and

[0576] The authorization policy evaluation service further includes instructions that, when executed, cause the authorization policy evaluation service to further evaluate the condition of the specific policy based on an access entity attribute mapping that maps the first specific entity to an attribute record of the first specific entity, and access the attributes of the attribute record.

[0577] 41. A method performed by one or more electronic devices in a provider network, the method comprising:

[0578] Encoding a set of terms from an authorization policy, wherein the authorization policy includes:

[0579] (a) An effect;

[0580] (b) An authorization policy header that selects a principal, action, or resource to which the authorization policy applies;

[0581] (c) One or more optional conditional clauses that further refine the circumstances under which the authorization policy applies; and

[0582] (d) At least one expression of one or more entities in the entity hierarchy;

[0583] Inputting a satisfiability modulo theories (SMT) formula into an SMT solver, the SMT formula being transformed from the encoding of the authorization policy and optional concrete constraints in the form of an entity hierarchy;

[0584] Receiving an output from the SMT solver, the output indicating whether the SMT formula is satisfiable or unsatisfiable;

[0585] Based on the output from the SMT solver, indicating whether the SMT formula is satisfiable or unsatisfiable, determining an answer to a first-order question regarding the behavior of the authorization policy; and

[0586] Causing information indicating the answer to be displayed.

[0587] 42. The method of clause 41, wherein encoding the set of terms from the authorization policy to produce the encoding of the authorization policy is further based on:

[0588] Validating the authorization policy as a strict type based on an authorization policy schema.

[0589] 43. The method of clause 41, wherein the authorization policy manages access to resources of a provider network application implemented using the provider network.

[0590] 44. A method performed by one or more electronic devices, the method comprising:

[0591] Encoding a set of terms from an authorization policy to produce the encoding of the authorization policy, wherein the authorization policy includes:

[0592] (a) An effect;

[0593] (b) An authorization policy header that selects a principal, action, or resource to which the authorization policy applies; and

[0594] (c) One or more optional conditional clauses that further refine the circumstances under which the authorization policy applies;

[0595] Input a satisfiability modulo theories (SMT) formula into an SMT solver, where the SMT formula is transformed from the encoding of the authorization policy;

[0596] Receive an output from the SMT solver, where the output indicates whether the SMT formula is satisfiable or unsatisfiable;

[0597] Based on the output from the SMT solver, indicating whether the SMT formula is satisfiable or unsatisfiable, determine an answer to a first-order question regarding the behavior of the authorization policy; and

[0598] Cause information indicating the answer to be displayed.

[0599] 45. The method according to clause 44, further comprising:

[0600] Generate an SMT formula using optional concrete constraints in the form of an entity hierarchy,

[0601] where the authorization policy further includes at least one expression regarding one or more entities in the entity hierarchy.

[0602] 46. The method according to clause 44, wherein encoding a set of terms from the authorization policy to produce the encoding of the authorization policy is further based on:

[0603] Verify the authorization policy as a strict type based on an authorization policy schema.

[0604] 47. The method according to clause 44, further comprising:

[0605] Generate a symbolic authorization request based on an authorization request schema of the authorization policy pattern;

[0606] Generate a symbolic entity store based on an entity schema of the authorization policy pattern;

[0607] where the authorization request schema specifies the entity types of a corresponding set of variables, the corresponding set of variables including authorization requests that conform to the authorization request schema; and

[0608] where the entity schema specifies a set of nominal entity types, a set of attribute record types in the set of nominal entity types, and a set of allowed ancestor entity types in the set of nominal entity types, the set of allowed ancestor entity types including an entity hierarchy that conforms to the entity schema.

[0609] 48. The method according to clause 47, further comprising:

[0610] Generate a symbolic authorization request based on the authorization request mode and further based on the following: Assign

[0611] (a) the set of entity types in the corresponding variable set that includes authorization requests conforming to the authorization request mode as

[0612] (b) a set of symbolic variables;

[0613] where each symbolic variable in the set of symbolic variables represents an arbitrary value of the correspondingly assigned entity type.

[0614] 49. The method as described in clause 47, further comprising:

[0615] Generate a symbolic entity store based on the entity mode and further generate a set of symbolic functions based on the entity mode;

[0616] where each symbolic function in the set of symbolic functions either:

[0617] (a) maps an arbitrary entity of a corresponding entity type to an arbitrary attribute record of an attribute record type of the corresponding entity type, or

[0618] (b) maps an arbitrary entity of a corresponding entity type to an arbitrary entity of one or more allowed ancestor entity types of the corresponding entity type.

[0619] 50. The method as described in clause 44, wherein encoding the set of terms from the authorization policy to produce the encoded authorization policy is further based on:

[0620] Encoding an initial set of terms in the authorization policy based on an authorization policy schema;

[0621] Collecting one or more sets of sub-expressions of the authorization policy, the one or more sets of sub-expressions including a set of entity literals and entity value attribute accesses;

[0622] Generating one or more sets of hypothesized terms corresponding to one or more terms in the initial set of terms, the one or more sets of hypothesized terms encoding the authorization policy; and

[0623] Combining the initial set of terms with the one or more sets of hypothesized terms in the set of terms encoding the authorization policy.

[0624] 51. The method as described in clause 50, wherein generating the one or more sets of hypothesized terms is based on generating hypothesized terms that constrain the ancestor relationship to be irreflexive for terms.

[0625] 52. The method as described in clause 50, wherein generating the one or more sets of hypothesized terms is based on generating hypothesized terms that require the ancestor relationship to be transitive and anti-symmetric on a pair of terms.

[0626] 53. The method as described in clause 44, further comprising:

[0627] Obtaining an authorization policy schema and the authorization policy via a command line interface, a graphical user interface, or a software development kit.

[0628] 54. The method as described in clause 44, further comprising:

[0629] Receiving an output from the SMT solver indicating that the SMT formula is satisfiable;

[0630] wherein the output of the SMT solver includes a witness; and

[0631] Causing information indicating the witness to be displayed.

[0632] 55. For the method of clause 44, defining an authorization policy schema and the authorization policy for a provider network application implemented using the provider network.

[0633] 56. A system, comprising:

[0634] A first set of one or more electronic devices for implementing an authorization policy analysis service in a provider network, the authorization policy analysis service including instructions that, when executed, cause the authorization policy analysis service to perform:

[0635] Receiving an authorization policy;

[0636] Encoding a set of terms from the authorization policy, wherein the authorization policy includes:

[0637] (a) Effects;

[0638] (b) An authorization policy header that selects a subject, an action, or a resource to which the authorization policy applies; and

[0639] (c) One or more optional conditional clauses that further refine the circumstances under which the authorization policy applies;

[0640] Inputting a satisfiability modulo theory (SMT) formula into an SMT solver, the SMT formula being transformed from the encoding of the authorization policy and optionally specific constraints in the form of a hierarchy of entities operating on the policy and a query context; and

[0641] Receiving an output from the SMT solver, the output indicating whether the SMT formula is satisfiable or unsatisfiable;

[0642] Based on the output from the SMT solver indicating whether the SMT formula is satisfiable or unsatisfiable, determine an answer to a first-order question regarding the authorization policy behavior; and

[0643] Cause information indicating the answer to be displayed;

[0644] A second set of one or more electronic devices for implementing an authorization policy analysis service in a provider network, the authorization policy analysis service including instructions which, when executed, cause the authorization policy analysis service to perform:

[0645] Store the authorization policy; and

[0646] Send the authorization policy to the authorization policy analysis service.

[0647] 57. The system according to clause 56, wherein encoding the set of items from the authorization policy is further based on:

[0648] Verify the authorization policy as a strict type based on an authorization policy schema.

[0649] 58. The system according to clause 56, the authorization policy analysis service further including instructions which, when executed, cause the authorization policy analysis service to perform the following:

[0650] Generate a symbolic authorization request based on an authorization request schema of the authorization policy schema;

[0651] Generate a symbolic entity store based on an entity schema of the authorization policy schema;

[0652] Wherein the authorization request schema specifies an entity type of a corresponding set of variables that constitute an authorization request conforming to the authorization request schema;

[0653] Wherein the entity schema specifies a set of nominal entity types, a set of attribute record types in the set of nominal entity types, and a set of permitted ancestor entity types in the set of nominal entity types, the set of permitted ancestor entity types including an entity hierarchy conforming to the entity schema; and

[0654] Obtain the authorization policy schema and the authorization policy via a command line interface, a graphical user interface, or a software development kit.

[0655] 59. The system according to clause 56, the authorization policy analysis service further including instructions which, when executed, cause the authorization policy analysis service to perform the following:

[0656] Receive an output from the SMT solver indicating that the SMT formula is satisfiable;

[0657] The output of the SMT solver includes a witness; and

[0658] causes information indicating the witness to be displayed.

[0659] 60. The system of clause 56, wherein the authorization policy manages access to resources of a provider network application implemented using the provider network.

[0660] Those skilled in the art will appreciate that the above examples can be varied in many ways without departing from the scope of the invention. Accordingly, the scope of the invention is to be determined by the following claims and their legal equivalents.< / t> < / t> < / t> < / team> < / bool> < / bool> < / bool> < / expr>

Claims

1. A computer-implemented method, comprising: Obtaining an authorization policy pattern; Determining whether there are any inconsistencies between an authorization policy in an authorization policy language and the authorization policy pattern, such that if there are no determined inconsistencies between the authorization policy and the authorization policy pattern, it is ensured that the authorization policy has no runtime type errors and runtime property access errors for any input that conforms to the authorization policy pattern; Determining one or more inconsistencies between the authorization policy and the authorization policy pattern; And Causing information indicating that the authorization policy is invalid relative to the authorization policy pattern to be displayed.

2. The method according to claim 4, further comprising: Storing a set of entities arranged in an entity hierarchy; And Wherein the authorization policy further comprises at least one expression regarding one or more entities in the entity hierarchy.

3. The computer-implemented method according to claim 1, wherein the authorization policy pattern and the authorization policy are identified to the policy validator through parameters in a command-line invocation of the policy validator.

4. The computer-implemented method according to claim 1, wherein the authorization policy language is a dynamically typed language.

5. The computer-implemented method according to claim 1, wherein the authorization policy comprises: (a) An effect; (b) An authorization policy header that selects one or more principals, one or more actions, or one or more resources to which the authorization policy applies; And (c) One or more optional conditional clauses that further refine the circumstances under which the authorization policy applies.

6. The computer-implemented method according to any one of claims 1 to 5, further comprising: Detecting a boolean expression in the authorization policy that dereferences an optional attribute of an entity without checking for the existence of the optional attribute of the entity as a prerequisite; And Wherein the displayed information indicates that the boolean expression lacks a check for the existence of the optional attribute of the entity as a prerequisite.

7. The computer-implemented method according to any one of claims 1 to 5, further comprising: Detecting an entity type in the authorization policy that is not an entity type listed in an entity type specification; And Wherein the displayed information indicates the entity type in the authorization policy.

8. The computer-implemented method according to any one of claims 1 to 5, further comprising: Detecting an action in the authorization policy that is not an action listed in an action specification; And Wherein the displayed information indicates the action in the authorization policy.

9. The computer-implemented method according to any one of claims 1 to 5, further comprising: Detecting an action in the authorization policy that is applied to an unsupported principal or resource in the authorization policy; And Wherein the displayed information indicates the action in the authorization policy and indicates the unsupported principal or resource in the authorization policy to which the action is applied.

10. The computer-implemented method according to any one of claims 1 to 5, further comprising: Detecting an improper use of a hierarchy containment operator in the authorization policy; And The information displayed includes a hint regarding the proper use of the hierarchical containment operator in the authorization policy.

11. The computer-implemented method according to any one of claims 1 to 5, further comprising: detecting improper use of the equality operator in the authorization policy; and wherein the information displayed includes a hint regarding the proper use of the hierarchical containment operator.

12. The computer-implemented method according to any one of claims 1 to 5, further comprising: detecting unrecognized attributes of an entity in the authorization policy, the unrecognized attributes not being specified as attributes of the entity in the authorization policy schema; and wherein the information displayed indicates the unrecognized attributes.

13. The computer-implemented method according to any one of claims 1 to 5, further comprising: detecting a type mismatch in an operator expression in the authorization policy, the operator expression including an operator that has valid semantics only for certain data types, the operator expression applying the operator to a value of a data type for which the operator does not have valid semantics; and wherein the information displayed indicates the type mismatch.

14. The computer-implemented method according to any one of claims 1 to 5, further comprising: detecting that the authorization policy always evaluates to false; and wherein the information displayed indicates that the authorization policy always evaluates to false.

15. A system, comprising: a first set of one or more electronic devices for implementing an authorization policy verification service in a provider network, the authorization policy verification service including instructions which, when executed, cause the authorization policy verification service to perform the method according to any one of claims 1 to 14.

Images