Authorization policy verification

Abstract

A system and method for authorization policy validation. A validator takes as input the authorization policy to be analyzed and a schema that specifies entity types and their attributes, the types of entity parents in the 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, the policy is guaranteed to be free of type errors and attribute access errors for any input that conforms to the schema.

Description

Technical Field

[0001] The present disclosure relates generally 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 intermediary networks. Access to resources within the provider network is secure through user-specified access control policies. Access control policies are expressive specifications for which resources can be accessed, by whom, and under what conditions. Properly configured policies are a critical component of an organization's security posture.

[0003] The scale and diversity of services built on provider networks are growing. For example, provider networks can encompass serverless computing services, streaming analytics services, edge computing services, and potentially many others. Each offering of a new provider network service used by an organization typically requires a different access policy configuration. As a further complication, customers combine provider network services to implement monolithic applications, which increases the complexity of managing access control policies. Consequently, a challenge for customers of provider networks is to reason about static access control policies for their applications built on dynamic provider networks. Customers would appreciate a solution that allows them to examine their policy configuration based on their security requirements. The present disclosure provides a solution to this and other needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Various examples according to the present disclosure will now be described with reference to the accompanying 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 for an authorization policy language are shown.

[0008] Figure 4 An example syntax for the authorization policy language is shown.

[0009] Figure 5 An alternative example syntax for the authorization policy language is shown.

[0010] Figure 6 An example syntax for the authorization policy language is shown.

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

[0012] Figure 8 Authorization semantics definition is presented.

[0013] Figure 9 An example entity hierarchy is shown.

[0014] Figure 10 Systems and methods for differential random testing of an authorization engine are presented.

[0015] Figure 11 Satisfiability Modulo Theory (SMT) formulations are presented.

[0016] Figure 12 An example policy language schema is presented.

[0017] Figure 13 An example symbol authorization request is presented.

[0018] Figure 14 An example symbol entity store is presented.

[0019] Figure 15 An example symbol record type is presented.

[0020] Figure 16 Satisfiability Modulo Theory (SMT) analysis is shown.

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

[0022] Figure 18 An example of an electronic device used in an implementation of the technology disclosed herein is shown.

[0023] It should be understood that for simplicity or clarity of illustration, the elements shown in the drawings are not necessarily drawn to scale. For example, the size of an element may be exaggerated relative to another element for clarity. In addition, where deemed appropriate, reference numerals have been reused in the drawings to indicate corresponding or similar elements. DETAILED DESCRIPTION

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

[0025] Overview

[0026] Disclosed are systems, methods, and non-transitory computer-accessible media (collectively, the "technology") for authorization policy language systems and methods that allow users 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 (allow statements) or deny access (prohibit statements). Conditions in statements can be based on access details such as source address, encryption, and other configuration options.

[0027] In some aspects, the technology disclosed herein includes systems and methods for authorization policy analysis. A policy analyzer answers first-order questions about authorization policies by reducing the policies to Satisfiability Modulo Theory (SMT). The input to the analyzer includes the policy to be analyzed and a pattern for the policy. If the policy passes rigorous verification against the pattern, 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 policies, for example, whether there is any input such that both policies evaluate to true. Reducing to SMT produces quantifier-free formulas in a combination of decidable theories to support large-scale deployments. This simplification is achieved by focusing the analysis on policies that pass rigorous verification rather than attempting to analyze arbitrary policies.

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

[0029] In some aspects, the technology disclosed herein encompasses systems and methods for authorization policy validation. 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, the policy is guaranteed to be free of type errors and attribute access errors for any input that conforms to the schema.

[0030] Policy Language Overview

[0031] This technology covers a domain-specific policy language for authorization. The policy language system and methods provide easy-to-use syntax and semantics, a fast and secure runtime, and powerful static analysis tools. Authorization is crucial to security. Therefore, the policy language system and methods 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 built using a provider network infrastructure (e.g., a "provider network application"). More specifically, authorization determines whether a subject can perform actions on resources. For example, a subject could be a user of a provider network application. In this example, authorization might involve determining whether the user has permission to perform a specific action (e.g., view) on a resource managed by the application (e.g., a digital photo).

[0033] While provider web applications can perform authorization themselves, it's often better to delegate authorization decisions to a dedicated authorization engine. To facilitate this, the authorization engine provides an application programming interface, or API. The API accepts as input a four-tuple representing an authorization request (equivalent to an "authorization request"). The four-tuple specifies the subject, action, resource, and request context. The request context contains contextual information about the authorization request. This context information can include information such as the network address, the current date and 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 authorization requests and returns a binary answer indicating whether the authorization request is allowed or denied. The authorization engine makes the allow or deny decision based on one or more policy sets. Each policy consists of one or more statements in a policy language. These statements specify permitted and prohibited actions based on application data. For example, application data could be the groups a user belongs to or attributes of a resource.

[0035] Now go to Figure 1 , which illustrates authorization using 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 intermediary network 108. Intermediary network 108 is the Internet or another intermediary data communication network. In this example, provider network application 104 is a photo sharing application. The example of a photo sharing application is merely used to illustrate the concept of authorization. The authorization and policy language systems and methods are not limited to any particular provider network application.

[0036] An example photo-sharing application provides features that one would expect from such an application. These features include the ability for users of the application to organize photos into albums. Albums can be arranged in a hierarchy. For example, a "trips" album includes a "conference" album and a "vacation" album as descendant albums. An "art" album does not have any ancestor or descendant albums. In this example, user "Jane" uploads two photos, and the two photos are organized into albums. Each of the photos is labeled with the name of the photo. The "receipt.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 photo sharing application also features the ability for 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 has created three groups: a "team" group, a "family" group, and a "friends" group. Like albums, groups can also be arranged in a hierarchy. For example, the "family" group is configured as a descendant of the "friends" group. The configuration of Jane's 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, the application data 110 will vary from provider network application to provider network application depending on the particular provider network application 104 at hand. Therefore, Figure 1 The application data 110 depicted in FIG. 1 is only one 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 "Friends" group to view any photo in Jane's "Travels" album. The photo sharing application has saved Jane's preference as an example authorization policy 112. The authorization policy 112 includes statements that express Jane's preference in a policy language. In this example, the authorization policy 112 allows all subjects in Jane's "Friends" group (including all subjects in any derived groups (e.g., a "Family" group)) to view any resource in Jane's "Travels" album, including any derived albums (e.g., a "Vacations" album and an "Art" album). In the example authorization policy 112 and other examples herein, a two-digit line number followed by a single colon character (":") is used as a reference in this description. However, the line number designation may not appear in the actual authorization policy data.

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

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

[0041] In response to receiving Alice's request in step "1," provider web application 104 sends authorization request 122 to authorization engine 102 in step "2." Authorization request 122 specifies user "Alice" as the subject, the requested action as "View," and the resource to be processed as the photo "flower.jpg" in Jane's photo album. Authorization request 122 also specifies a request context, which may include contextual information such as the network address of remote electronic device 106 and one or more key-value pairs associated with the authentication session established for Alice. In this example, authorization engine 102 will allow authorization request 122 based on authorization policy 112 and authorization policy 114 because Alice is permitted to view the photo "flower.jpg" according to authorization policy 112, and authorization policy 114 does not prohibit Alice from performing this action on the resource. More specifically, Alice is in Jane's "Friends" group, the action is "View," and the resource being requested is in Jane's "Travels" album. Therefore, authorization policy 112 permits the requested action. The 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 1. In this example, Alice requests to view Jane's "receipt.jpg" photo, but does not request to view Jane's "flower.jpg" photo. In this case, authorization request 222 is denied by authorization engine 102 because it is prohibited by authorization policy 114. Specifically, authorization policy 114 prohibits authorization request 222 because the "receipt.jpg" photo is marked as "private" and the photo is in Jane's account, not Alice's account. Although authorization policy 112 grants authorization request 222, authorization engine 102 still denies authorization request 222 because there is at least one authorization policy (i.e., policy 114) that prohibits authorization request 222. In other words, by default, a policy that prohibits an authorization request overrides any policy that grants an 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 policies they want, while at the same time being restrictive enough to provide good evaluation / runtime performance and analyzability. Analyzability refers to the ability for 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, as 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. However, depending on which aggregate data types the policy language supports and which operators on aggregate data types it supports, providing precise analyzability of the policy language can become impractical. The policy language supports some aggregate data types and some operators on those aggregate data types without sacrificing the precise analyzability of policies written in the policy language.

[0044] Furthermore, the policy language is both fast and safe. Thus, the 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. Furthermore, 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, in order to simultaneously enforce memory safety and prevent concurrent data races, the programming language can use a borrow checker that tracks the object lifetime and variable scope 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 safety 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 who write policies in a policy language can still make mistakes when translating their intent into policy statements. For example, a user might write a policy or policy set that works in most situations but is overly permissive in certain corner cases, creating security issues. As another example, a user might write a policy or policy set that works in most situations but is overly restrictive in certain corner cases, creating usability issues. The technology disclosed herein encompasses a policy analysis tool that can reason about all possible requests for a policy and all possible states of a policy to detect such corner cases.

[0046] Existing policy languages ​​either offer high expressiveness at the expense of low performance and low analyzability, or offer high performance at the expense of low expressiveness. For example, existing policy languages ​​offer high performance, but are not expressive enough for many applications. Such existing languages ​​allow policy specification for groups, but not for resource attributes and subject attributes. In contrast, the policy language of the present disclosure allows policy specification for groups as well as for resource attributes and subject attributes, while still maintaining performance. In other words, the policy language of the present disclosure provides an effective balance between expressiveness, performance, and analyzability that existing policy languages ​​do not provide.

[0047] The policy language helps write policies based on the application data of the provider network application. The application data of the provider network application varies from application to application. Specifically, the policy language helps write permissions based on group membership and attributes of application-specific entities. For example, Figure 1 and Figure 2 The authorization policy 112 and the authorization policy 114 in the example photo sharing application of are about entities specific to the photo sharing application (such as photos, albums, and sharing groups). These entities are specific to photo sharing and are not necessarily relevant to all provider network applications.

[0048] The policy language system and method also supports flexible recording and aggregation of data types in common data exchange formats. Such common data exchange formats include JavaScript Object Notation (JSON), Extensible Markup Language (XML), etc. Returning to the photo sharing application, authorization decisions may need to be made based on JSON formatted metadata of photos uploaded to the application. The metadata may include location metadata indicating where in the world the photo was taken. The policy language system and method allow the photo sharing application to expose location metadata as attributes of uploaded photos so that policies can be written for these attributes and photos. However, different photo capture devices have different capabilities. Therefore, some of the photos uploaded to the photo sharing application may include location metadata, while some may not. For example, photos captured by a device that does not have Global Positioning Satellite (GPS) capabilities may not include location metadata. The policy language system and method allow policies to be authorized for the location attribute of photos, even if some photos do not have a location attribute and other photos do.

[0049] In some cases, end users of a provider web application will not write permission policies in the policy language. Instead, permission policies will be automatically generated by the provider web application or written by the developer of the provider web application. However, in some cases, depending on the provider web application at hand, end users of the provider web application may write permission policies directly in the policy language. For example, in the case of a photo sharing application, functionality in a pro version of the photo sharing application may allow end users (such as professional photographers) to write complex Boolean permissions and conditions to protect their photos in order to allow their own clients to preview and potentially purchase the photos. To support the case where permission policies are exposed to users of the provider web application, the policy language has a simple and intuitive syntax and semantics that allows permission policies to 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 an entity. Entities are grouped into hierarchies and have attributes. An entity can be considered a reference value, in other words, the name of an object. The name can be in a specific format. For example, a name can include an entity type identifier and an identifier for an entity instance. An instance identifier is a globally unique identifier. The examples herein use simple type names and instance identifiers to provide clear examples. However, in actual implementations, entity type names and entity instance identifiers may be more complex. For example, an entity instance identifier may be a GUID, which is a 128-bit text string that provides a unique reference value. Furthermore, entity type names and entity instance identifiers may be confined to their unique namespaces. For example, each provider network application may have its own namespace or set of namespaces. Therefore, there is no requirement that entity type names or entity instance identifiers be probabilistically unique across all time and space.

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

[0053] The policy language system and method represent 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 policy, the policy language provides an IN operator. The IN operator can be used in a policy to test whether a path exists in the hierarchy between two nodes in the DAG. The policy statement A IN B, where A and B are entities in the entity hierarchy, tests whether entity A is a derivative of entity B in the DAG. For example, referring to the example policy statement 304 using 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 derivative 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 no path exists in entity hierarchy 302 from the Photo::"flower.jpg" entity to the Album::"Jane / Conference" entity.

[0054] Determining the reachability of a graph can be an inefficient operation. The authorization engine of the policy language system and method uses an index to facilitate the efficient evaluation of policy statements using the IN operator. This index is referred to herein as an entity store. For each entity in an 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 an entity ancestor map. For example, an entry in an entity ancestor map can map an identifier of an entity to a set of entity identifiers of entities in the hierarchy that are ancestors of the given entity. For example, an entry in the entity ancestor map of 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 map, the authorization engine can evaluate policy statements using the IN operator in constant time. For a policy statement A IN B using the IN operator, the authorization engine can simply retrieve an entry in the entity ancestor map for entity A and test whether B is a member of the ancestor set of that entry. This is a constant time operation for the authorization engine.

[0055] An entity may have attributes. An entity's attribute set is sometimes referred to herein as an attribute record of the entity or an entity's attribute record. An attribute record may be represented as a JSON object or the like. An attribute record is a mapping from a string value to other values. Other values ​​may be basic data types such as Boolean values, numerical values, string values, and entity identifiers. However, other values ​​may also be other records or value sets. Since an attribute record may be represented as JSON or a similar object, a provider network application may conveniently provide the provider network system and method with the attributes of an entity in the form of JSON or a similar object. Since JSON or the like is a common way for provider network applications to represent their application data, this capability of the policy language system and method makes it easier for provider network applications 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 across entities, attribute records, and nested attribute records. For example, the example policy statement 308 references the value of the "aspect" attribute of the Photo::"flower.jpg" entity, which is a nested record, and in turn accesses the value of the "w" attribute of the nested record. Thus, the policy language supports writing policy statements that dereference chains of one or more entities, records, and nested records without having to worry about whether an entity or a record is being 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 error at evaluation time. The result of an error is that the authorization engine will treat the policy as an implicit deny. The policy language provides a "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, policy statement 310 uses the has operator or predicate to test whether the Photo::"flower.jpg" entity has a "color" attribute. Adding evaluation time, the authorization engine will evaluate policy statement 310 as true because the specified entity does have the specified attribute. On the other hand, the authorization engine will evaluate policy statement 312 as false because the Photo::"flower.jpg" entity does not have a "location" attribute.

[0058] To facilitate efficient evaluation of policies written in the policy language by the authorization engine at evaluation time, the entity store can store entity attribute maps in addition to entity ancestor maps. Entity attribute maps map entities to attribute records. For example, an entry in an entity attribute map can map an entity's identifier to a JSON or similar object representing the record. At evaluation time, the authorization engine can use the entity's identifier to retrieve the JSON or similar object representing the entity record from the entity attribute map. The authorization engine can then continue evaluating policies based on the JSON object. Entity attribute maps for entity hierarchies facilitate constant-time lookups of attribute records for a given entity within the entity hierarchy.

[0059] While the policy language supports sets as values ​​in records, it does not support lists. Lists can be viewed as ordered collections of values. The reason for not supporting lists has to do with the analyzability of the policy language. In particular, no solution has been found to encode the containment operator on lists so that it can be analyzed accurately by SMT. Examples of containment operators 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, using sets allows for accurate SMT analysis. Roughly speaking, the reason for using sets instead of lists for accurate 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 conditions 408. The effect of the authorization policy describes what the effect of the policy is (e.g., allow or deny). The header of the authorization policy specifies hierarchical constraints such as equality or IN operators on subjects, actions, or resources. Conditions are optional and are Boolean expressions on subjects, actions, resources, or request context.

[0062] The header of a policy typically corresponds to a role-based access control (RBAC) rule. The conditions of a policy typically correspond to an attribute-based access control (ABAC) rule. The Boolean expressions in the "when" clause of a condition can essentially be a pure functional subset of languages ​​such as Java or JavaScript. For example, a "when" clause can contain any or all of the following expressions: if-then-else expressions, short-circuit Boolean operators, property access (.), property existence (has), equality (==), hierarchy 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 policy header can test for equality (==) or hierarchical containment (in). The policy language restricts the policy header to only these two types of expressions. Figure 4 In addition to the other types of expressions listed in , these two types of expressions are also allowed in policy conditions.

[0064] Because the types of expressions permitted in a policy header are a subset of the types of expressions permitted in policy conditions, policies can combine headers and conditions into a single syntactic structure. Figure 5 Example policy 502 provides an example of a policy 402 that combines a header 406 and a condition 408. However, for readability, the policy language distinguishes between headers and conditions syntactically and semantically. In particular, 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 a role-based access control policy and an attribute-based access control policy. Specifically, a pure role-based access control policy contains only a header and no conditions. A pure attribute-based access control policy contains conditions, but its header has no restrictions on membership. A policy that is a hybrid of a role-based access control policy and an attribute-based access control policy, such as policy 402, contains both a header and a condition that imposes constraints on membership. In contrast, for Figure 5 In the combined policy 502, compared with policy 402, readers cannot quickly distinguish 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 the policy language separates headers from conditions is performance. This separation facilitates slicing. Slicing is the ability for the authorization engine to determine whether to grant or deny an authorization request by evaluating only a subset of the entities, attributes, or policies that apply to the request. The entity store of a provider web application can be large, potentially containing millions or even billions of entities, attributes, and policies. Therefore, the performance of the authorization engine's policy evaluation is crucial. For example, it may not be possible to load all entities, attributes, and policies that apply to an authorization request into memory at the same time.

[0066] The authorization engine may remove policies from evaluation for authorization requests based on the policy's header. In particular, when the policy's header imposes hierarchical constraints on the request subject or the request resource, the authorization policy may be removed from evaluation if the policy's subject is not an ancestor of the request subject in the entity hierarchy, or if the policy's resource is not an ancestor of the request resource in the entity hierarchy. Consider Figure 6 . 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 Photo::"receipt.jpg" in the entity hierarchy 610, then the authorization engine does not need to evaluate policy 602 against the authorization request 608. Recall that the entity store contains an entity ancestor map that enables efficient, constant-time determination of whether an entity is an ancestor of another entity in the entity hierarchy. Therefore, the authorization engine can use the policy's header to efficiently determine whether the policy needs to be evaluated against the authorization request.

[0067] Authorization Engine

[0068] Figure 77. The policy language engine 710 is shown in the context of the 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 of the provider network application (e.g., application data 110) that the developer of the provider network application wishes to access based on its 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] When the provider web application runs, the provider web 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 the subject, action, resource, and request context. The deserializer 712 deserializes the authorization request 702 to convert it into Figure 7 716 is represented as a deserialized form of the request object.

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

[0071] Parser 714 can parse policy set 706 to convert it into a more efficient evaluation form, such as Figure 7As shown in the policy object set 720 in . The authorization engine 722 has one or more evaluator components (evaluator 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 evaluator 724. Each policy in the policy set 706 is evaluated by the evaluator. The evaluator returns true or false for the evaluation of the policy. 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 evaluator 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 allow policy in the policy set 706 evaluates to true and no prohibit policy in the policy set 706 evaluates to true. Otherwise, the authorization engine 722 returns a deny.

[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 (e.g., entity ancestor mapping and entity attribute mapping) in the entity store 718. One possible answer 726 is that the authorization request 702 is allowed. 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 user 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] The authorization engine 722 can deny the authorization request 702 if any policy in the policy set 706 evaluated against the authorization request 702 evaluates to false. 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. The authorization engine 722 can also deny the authorization request 702 if any policy encounters an error in its evaluation against 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 that as mentioned above, if some policies of the provider network application can be removed from the evaluation, they may not be evaluated against the authorization request. The removed policies will not be 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 is capable of evaluating a typical authorization request involving hundreds of policies, thousands of entities, or even more attributes in less than one 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 would consume limited computing resources used to evaluate policies against authorization requests. Despite this, 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 proved, the program will not compile. RUST also provides bindings for other programming languages ​​(such as JAVA) to build extensions or plug-ins to the authorization engine 722 in different programming languages.

[0076] The authorization engine 722 can evaluate the policy set 706 at least partially in parallel. To this end, the authorization engine 722 uses an evaluator set 724. For example, each evaluator in the evaluator set 724 can be a separate process, thread, etc., which is executed at least partially in parallel with one or more other evaluators on a separate CPU core, CPU, or computing device. The evaluator set 724 can be greater than, equal to, or less than the number of policies in the policy set 706 to be evaluated. The evaluator set 724 can be executed as part of a framework (e.g., a MapReduce framework, etc.) for processing parallelizable problems across a cluster of computing nodes. For example, the evaluator set 724 can be executed as a set of mapping 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 policy set 706 at a time, at least partially in parallel with the other evaluators, and multiple policies in the policy set 706 can be executed over time. Because each policy in the policy set 706 can be evaluated independently of the other policies, and because the policies are evaluated at least partially in parallel, the authorization engine 722 can stop evaluating the policy set 706 for the authorization request 702 as soon as any policy in the policy set 706 evaluates to false or an error. When the authorization engine 722 makes an early stopping decision, a response 726 can be immediately returned to the provider network application without evaluating any remaining policies in the policy set 706 that have not yet been evaluated for the authorization request 702. This early stopping of policy evaluation conserves the limited computational resources of the authorization engine 722.

[0078] The separation of headers and conditions in the policy facilitates early stopping. Specifically, if the header of a prohibited policy without a condition evaluates to true, the evaluation of the policy set 706 can be stopped early. If the prohibited policy also has a condition, the condition will also be evaluated. If both the header and the condition of the prohibited policy evaluate to true, the evaluation of the policy set 806 can be stopped early. This early stopping saves the limited computing resources of the authorization engine 722. Therefore, when the evaluator set 724 evaluates the prohibited policy, the header of the prohibited policy can be evaluated first. If the evaluation of the header of the prohibited policy is false, there is no need to evaluate any of the conditions of the prohibited policy, the policy does not reject the request 702, and the evaluation can continue with any remaining policies 706 in the policy set. Only when the header of the prohibited policy is evaluated to true will any of the conditions of the prohibited policy be evaluated. If the header of the prohibited policy is evaluated to true, but the evaluation of the condition of the prohibited policy is false, the policy does not reject the request 702, and the evaluation can continue with any remaining policies 706 in the policy set. Where policy set 706 includes at least one prohibit policy, evaluation of the prohibit policy may take precedence over evaluation of the grant policy so that the grant policy is not unnecessarily evaluated when the prohibit policy results in the authorization request 702 being denied.

[0079] Operations on entities

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

[0081] The 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. It makes no difference whether different entity identifiers happen to refer to objects with the same properties; they are still considered unequal. Equality holds even if the entity identifiers don't actually refer to entity objects 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 descendant of B in the entity hierarchy. The expression A in[B,C,...] is equivalent to A in B||A in C||..., but will result in an error if any element in the collection is not an entity reference. A in B will return false if A and / or B does not exist in the entity hierarchy, except for the special case of A in A, which returns true even if A does not exist.

[0083] Policies can use the dot operator to retrieve the value of an entity property; for example, A.account retrieves the entity value that refers to the account object belonging to entity A. If A does not refer to an entity in the hierarchy, or if the referenced entity does not have an account property, an error is raised. Entity properties can also be accessed using the [] operator, which accepts a string literal representation of the property; therefore, A.account is equivalent to A["account"].

[0084] Namespace

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

[0086] Primitive and aggregate values

[0087] In addition to entities, the policy language data model also includes primitive and aggregate values. These values ​​can be stored as entity attributes 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) Number (e.g., 64-bit signed integer).

[0091] (3) string, and

[0092] (4) Network address and range (e.g., IPv4 or IPv6 address and range).

[0093] The policy language supports the following two aggregate data types:

[0094] (1) Sets. Sets can contain elements of different dynamic types. Sets can be constructed in policies 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 values ​​may 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":tru e}). Record attribute values ​​can be accessed just 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. 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 key / value pairs as the entity's attributes).

[0097] In addition to equality, policy language values ​​can 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-circuiting operations. For example, false&&... will evaluate to false without evaluating ..., and true||... will evaluate to true without evaluating .... This is true even if ... has the wrong type, for example, true||"a"<3 will evaluate to true. The policy language may support additional operators, such as arithmetic operators, as required by the specific implementation in question.

[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 if-then-else ternary expressions, with the syntax: if expr1 then expr2 else expr 3. The condition 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 raising an error (here, evaluating to false). Similarly, like many other dynamically typed languages, the policy language is type-safe, meaning that the type of each value is known at runtime, and operators and functions check that their arguments have the expected types, resulting in runtime errors if these expectations are violated.

[0103] Strategy Syntax

[0104] Policy Language Policies are written using the syntax in the following table. A policy consists of three elements:

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

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

[0107] (3) Conditional clauses, which further specify the circumstances under which the strategy is applied (non-terminal symbol 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 effects and policy headers are mandatory, but the conditional clause is optional.

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

[0110]

[0111]

[0112] Inline strategy

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

[0114] (1) Inline strategy; and

[0115] (2) Policy template.

[0116] The following examples focus on inline policies, but they also apply to policy templates. The distinguishing feature of inline policies from policy templates is the use of the syntax ?principal or ?resource as parameters in the policy header.

[0117] The following example inline policy c1 for a photo-sharing application allows Jane's friends to view or comment on all photos contained in the delivered album of her travels (that is, the album or any nested subalbums):

[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 photo-sharing application account owner from performing any actions 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 begin with the permit or forbid keyword. A permit policy grants access rights, while a deny policy restricts access rights by overriding the permit policy. The examples above are examples of both types of policies.

[0126] Policies contain the keyword variables subject, action, and resource, and may include constraints. Constraints determine to which subjects, actions, and resources the policy applies, based on the underlying entity hierarchy. Hierarchical constraints on subjects and resources take one of two forms: var or var('in'|'==')Entity (additional forms for policy templates are discussed below). Action constraints can take either form, 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 when and unless clauses) to express constraints on which subjects and resources the policy applies.

[0127] The RBAC-style equality constraint var == Entity indicates that the policy applies only when var is equal to Entity (meaning that the policy applies only to one specific entity, Entity). The RBAC-style membership constraint var inEntity indicates that the policy applies only when var is a derivative of Entity in the entity hierarchy. The IN operator is reflexive, so any entity is implicitly a derivative of itself. For example, the constraint resource in Album::"jane_trips" in policy c1 means that the policy applies only to the resources contained in Jane's "trips" album, including the album itself. Finally, the RBAC-style collection form var in[Entity,Entity,...] (allowed only for actions) indicates that var is equal to one (or more) of the entities specified in the collection, or their derivatives. If only var is present, there are no constraints. For example, in policy c2, prohibit(subject,action,resource) does not impose any constraints on subjects, actions, or resources, so the policy applies to all subjects, actions, and resources in the system, subject to any when and unless clauses, if any.

[0128] Conditional clauses begin with "when" or "unless" and are Boolean expressions on the input variables. The policy applies only if all "when" clauses evaluate to true and all "unless" clauses evaluate to false. Conditional clauses are written in the policy language, defined by the non-terminal symbol "Expr" in the grammar. Constraints imposed by the head on subjects, actions, and resources can be treated as expressions, as they are also described by the "Expr" grammar.

[0129] Policy languages ​​are relatively simple languages, designed to minimize ambiguity in their grammar. They have several desirable properties: expressions have no side effects; expression (and policy) evaluation is guaranteed to terminate; and the worst-case running time of each policy is quadratic in both the policy and the input size, but is generally linear.

[0130] The policy language supports relational and logical binary operators (e.g., x<5 and !(x&&y)). Expressions can contain conditionals such as if E1, then E2, else E3 (e.g., E1?E2:E3inC). As mentioned above, expressions can also be contained within expressions such as A in B or Ain[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 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 Effect(c) function returns the value Allow for the allow policy and Deny for the deny policy. The Conds(c) function returns a possibly empty list of Expr clauses for c. 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 expanded constraint expressions for the input variables Principal, Action, and Resource; if there are no constraint expressions, they simply return true.

[0136] For example, parsing 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, parsing the example policy c2 above 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 principal.account)]

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

[0149] Policy Templates

[0150] Policy templates allow for programmatic creation of policies in a safe and convenient manner. A policy template has one or more slots. The two slots are principal and resource. Slots can only appear in policy header constraints for their variables and can only appear on the right side of a == or in operator.

[0151] The following policy is a template with ?principal and ?resource slots:

[0152]

[0153] The authorization engine does not directly evaluate a policy template as part of an authorization request. It is first instantiated by providing the entity identifier as a parameter to a slot. The number of parameters 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 policy instances equivalent to the following two inline policies.

[0155] First equivalent inline strategy:

[0156]

[0157] A second equivalent inline strategy:

[0158]

[0159] Policy semantics

[0160] Inline policies and policy instances have the same semantics. A policy c can refer to 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 subject, A is the action, R is the resource, and X is the request context. P, A, and R are entity identifiers, and X is a record. The authorization engine grants a request if the authorization relationship for a given provider web application (defined by that application's policy set) satisfies the request—that is, the subject P is allowed to perform action A on resource R under the circumstances described by context X. An authorization relationship satisfies a request if and only if the authorization relationship satisfies at least one permission (allow) policy and no restriction (forbid) policies.<P,A,R,X> We define what it means for a request to satisfy a policy as follows.

[0161] When c is evaluated for a request and evaluates to true, the request<P,A,R,X> satisfies policy c. More precisely, each policy c represents a function [[c]] from the entity hierarchy H and queries the Boolean value<P,A,R,X> When (<[[c]](h)P,A,R,X>) is true, for the hierarchy H, the request<P,A,R,X> Satisfy c.

[0162] Function [[c]] is implemented by evaluating the entity hierarchy H and the request<P,A,R,X> The variables principal, action, resource, and context appearing in c are bound to the values ​​P, A, R, and X, respectively. If Principal(c), Action(c), and Resource(c) all evaluate to true; whenever an expression in Conds(c) evaluates to true; and every unless expression in Conds(c) evaluates to false, then the result of the evaluation is true.

[0163] Policies are total functions, meaning they return true or false for every input. In particular, if a policy would fail to evaluate under standard expression semantics, for example because it attempts to access a property that does not exist for a given entity, then false is returned.

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

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

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

[0167] In addition to computing the authorization decision (allow or deny), the authorization engine also computes the reasons that accompany the decision. Specifically, the authorization output is a triple consisting of a decision, a set of reasons, and a set of errors. If the output satisfies Figure 8 If the authorization semantics defined in definition 800 are correct, the output is correct. According to definition 800, if dec is "Allow," the reason includes the IDs of all policies that satisfy the permission. Otherwise, dec must be "Deny," and the reason includes the IDs of all policies that satisfy the restriction. Errors include the evaluation error message. The semantics are deterministic: they are a function of P, A, R, X, the entity hierarchy H, and the application policy.

[0168] For example, consider Figure 9 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={}> , policy c1 is satisfied because User::"Alice" is a descendant of Group::"jane_friends" in entity hierarchy 900, resource Photo::"summer" is a descendant of Album::"jane_trips" in entity hierarchy 900, and action Action::"view" appears in the set [Action::"view", Action::"comment"]. Policy c2 is not satisfied because the tags attribute 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={}> , policy c1 is satisfied for similar reasons. However, policy c2 is also satisfied because the when condition evaluates to true. This is because the tags property of the resource Photo::"receipt" contains "private," and c2's unless condition evaluates to false because Photo is not a member of the User::"Alice" account. Because policy c2 is prohibited from evaluating 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 about policy and entity store deletion, the following terms are used:

[0172] Authz service. The authorization service is a provider network service that processes and responds to authorization requests. It is distinct from the management service, which is 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 distinct from the authorization service, of which the authorization engine is a component. 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 portion of entity or policy data required by the authorization engine to evaluate the specific request at hand. Given an authorization request, the authorization service computes a slice containing some subset of the data, and the authorization engine then evaluates the request based on that slice. A key property of support is that evaluating an authorization request using sliced ​​data always yields the exact same response as evaluating the authorization request using the entire available data set, including any error messages or other diagnostics in the response.

[0175] Slicing::Slicing is the process of computing a slice, or an algorithm for computing a slice. Slicing is performed by the Authorization Service for each authorization request, modulo some portion of the algorithm that may have been pre-computed and stored.

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

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

[0178] Head constraints:: A policy's head constraints are constraints on the subjects, actions, and resources in the policy's header, and exclude the contents of any when or unless clauses of the policy's conditions.

[0179] Head principal / head resource::For any policy, the head principal is the entity identifier explicitly mentioned in the policy's subject header constraint. 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 policies without a subject header constraint, e.g., permit(principal,...), the head principal is the special value ANY. Head resources are defined similarly using the policy's resource header constraint.

[0180] Relevant:: A policy is relevant to an authorization request if the policy's header constraints evaluate to true for that request. This does not mean the entire policy is true, just its header constraints.

[0181] One type of slicing is policy slicing. Policy slicing involves selecting 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 policy header resources to policies that have those header resources. For example, a given header resource can be mapped to one or more policies that contain the given header resource. This index is referred to herein as the policy header resource index.

[0182] When receiving a specific authorization request, 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's ancestors in the entity hierarchy. The policy header resource index can then be used to determine the set P of all policies in the index whose header resource is 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 header constraints of each policy in P and selecting only the relevant policies in P as the final policy slice P'. The policy slice P' can be smaller and more accurate than the slice P, but at the cost of additional computation required during slicing. Compared to the slice P, a smaller slice P' can save network utilization.

[0184] A provider network can host / store some entity data. Other entity data can be JIT-ed. For example, a provider network can store entity names and parent relationships. Entity attribute records can also be JIT-ed.

[0185] The provider network database can maintain a policy index by (header-subject, header-resource) pair. This allows efficient lookup of policies using a given (header-subject, header-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 managed entity database contains at least the entity name and parent relationship. It also maintains a precomputed transitive closure of the parent relationship: each entity contains a pointer to each of its ancestors, not just its immediate parent. A special ANY principal and a special ANE resource are used for policies where the head principal or head resource is ANY. In the managed entity database, the ANY principal is an ancestor of all principals, as are all resources.

[0187] When a specific authorization request is received, let the subject 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 whose (header subject, head resource) pair is (P, R). It will then iterate over P's ancestors and R's ancestors and select all policies whose (total subject, total resource) pair is (P or any ancestor of P, R or any ancestor of R). As mentioned above, leveraging pre-computed ancestry relationships can improve efficiency - compared to the policy slicing case when the entity data is completely JIT, where the ancestry relationship must 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 by index; or, store the head constraints of each policy along with the policy and evaluate these head constraints (including actions) before selecting only the relevant policies. However, as mentioned above, the extra work of evaluating the head constraints may mean additional complexity for little or no benefit (or even a negative net benefit).

[0189] In situations where there are many small policies in an application, this policy slicing solution will be more efficient than policy slicing when the entity data is completely JIT. For example, if the application creates a new template instance 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 related to 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 to match the resource for the authorization request.

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

[0191] For a given authorization request, the entity store may need to be queried multiple times. The main reason multiple queries might be needed is when an attribute value contains an entity reference. For example, if the policy requires principal.manager.level, then not only will a query be made for principal, but an additional query will also be required 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 limits 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 in the algorithm is to perform policy slicing as described above. Next, for each policy in the policy slice, the entity data required to evaluate the policy is determined. This determination involves building an abstract syntax tree (AST) for the policy and traversing the AST to determine the entity data required by the policy. This determination is performed for all policies in the slice before continuing to query the entity store for entity data. This reduces the number of queries required to retrieve all entity data. Next, the required entity data is queried from the entity store. Ideally, all required entity data can be retrieved in a single query of the entity store. Even if there are property 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 required, and no additional queries are 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 can detect errors while evaluating a policy (for example, when it encounters an expression such as 1 < "hello"). If the evaluation of a policy results in an error, the policy evaluates to false.

[0195] To mitigate the possibility of evaluation errors, the policy language system and method provide schema-based policy validation. Specifically, given a schema describing a hypothetical structure of entities and queries, the validator flags policies that are likely to fail during evaluation. The validator is reliable: if the validator does not flag any policy, then no policy will fail when evaluating any entity hierarchy and query that conforms to the schema.

[0196] Validation is optional for users. Users can choose not to run the validator to check the policy. To improve performance, the authorization engine may not run the validator when evaluating the policy. When running, the validator assumes that the given schema contains complete information for every entity and action mentioned in the policy it considers, and fully enumerates the principal and resource entity types that can be used for a specific operation.

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

[0198]

[0199] The example schema above specifies that each entity of type Employee in the entity store has a property called jobLevel whose value is a long integer, and an optional property called numberOfLaptops, also a long integer. In authorization requests with the action Action::"remoteAccess," the subject should always be an entity of type Employee.

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

[0201]

[0202] In order to evaluate a given authorization request to reach the when clause, the query must satisfy the policy header constraints. Therefore, the action must be Action::"remoteAccess". Based on the schema, the validator can assume that the principal is an Employee and therefore has a jobLevel attribute. As a result, the validator will report an error or warning for each comparison in the when clause (lines 03-05).

[0203] The validator will report a validation error on line 03 because the principal is not guaranteed to have the optional quarantineLevel attribute. Therefore, attribute access may cause a runtime error. Validation errors will also be reported if the policy contains attributes that do not exist in the schema (for example, age) or contains a typo 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 in line 04 will always throw a runtime error when evaluated.

[0205] The validator will report a validation error or warning on line 05. The left operand 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. While this does not cause an evaluation-time error, it may not have been the policy author's intention.

[0206] Verification includes a type checking step, among other steps. As in most programming languages, the main purpose of type checking is that each Strategy Language operator has requirements on the types of its operands and returns a result of a given type. For example, x>y requires that both x and y have type long, and it returns a boolean. The validator reports an error if the operands do not have the required types: either x>y (where y is not of type long) or x.jobLevel (where x's type does not have a property named jobLevel). For equality ==, it may succeed if both operands have the same type. As shown in line 03 above, optional property access should be preceded by a has check, for example:

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

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

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

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

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

[0212] (3) Detect actions applied to unsupported subjects / resources, such as saying that photos can be viewed by users.

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

[0214] (5) Detect unrecognized properties, for example, principal.jobbLevel (this is a typo and should be "jobLevel").

[0215] (6) Detect unsafe access to optional properties, such as principal.numberOfLapt ops, where numberOfLaptops is an optional property (declared with "required":false). These should be protected by has checks, for example, if principal has quarantineLevel, then principal.quarantineLevel else 0. Or, principal has quarantineLevel && principal.quarantineLevel < 2.

[0216] (7) Detect type mismatches in operators, for example, 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 therefore never apply, for example, a policy's condition is: when {["hello"].contains(1)}. This condition always evaluates to false, so the policy never applies.

[0218] The actions in the pattern action section can specify the expected format of the context, so the errors listed above can also be flagged in the context reference 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 the schema. However, it is possible to write policies that access attributes 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 the entity before accessing the attribute, for example, as in the expression principal has someoptionalattribute && principal.someoptionalattribute == "someval" . In this expression, principal refers to an entity whose attribute someoptionalattribute may not always be present. If that attribute is present for the given entity, the expression principal has someoptionalattribute will return true. The short-circuiting behavior of && then safely continues to evaluate the clause principal.someoptionalattribute == "someval" . If principal has someoptionalattribute that returns false, && will immediately return false and the remaining clauses will not be evaluated.

[0220] The validator can detect this situation by making its type checking step 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 presence of SomeAttribute. However, expressions that do not necessarily follow the has expression cannot depend on the presence of the attribute. Information from multiple has expressions can be aggregated so that the following expression is validated: PrincipalHasAttributeA&&PincipalHasAttributeB&&Pincipal.attributeA==Principal.attributeB.

[0221] Union types can also be used to validate conditions that apply to values ​​of multiple possible types. For example, consider the following conditional expression, in which 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, the validator will allow dereferencing a property in the union type if each type in the union has the attribute, as is the case in our example.

[0222] Typing via cross products is also possible. In this context, the policy is validated for every combination of principal and resource types in the schema's operation specification. This provides better accuracy than the alternative of validating the policy once while specifying the principal and resource as union types for each specified possibility. Validation via cross products has the benefit of 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 membership 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 usage is always consistent. For example, if the principal is of type User, but User is not fully specified in the schema, the validator can accept a principal.name expression like "Alice*" - this expression implies that User has a name attribute that can be used as a string. However, a principal.name expression like "Alice*" && principal.name > 5 would likely be flagged as invalid because the User name attribute cannot be used as both a string and a long, which must be true for this expression to evaluate without error.

[0224] Verification Mode

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

[0226] (1) entity type specification, and

[0227] (2) Standardized movements.

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

[0229] The namespace declares a global namespace that will be applied 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 properties of the entity type and the parent / child relationships that entities of that type may have with other entities in the hierarchy (if any). The operations list contains entity IDs of the entity type Action that can be used as operations in authorization requests, as well as assumptions about the subject, resource, and context portions of the request submitted with that operation. 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 that must be used when referring to this type in policy.

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

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

[0234] Each entry in the action 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 that is 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 of strings that are action identifiers and are the direct parents of this action in the action hierarchy. Note that this memberOf attribute is more precise than the entityTypes memberOf attribute. This list defines the full action identifier and directly defines the hierarchy of actions, while the entityTypes list only identifies type-level relationships in the hierarchy. This means that there should not be cycles in actions memberOf relationships, but there can be cycles in normal entity types. For example, it is an error for the action "get" to have memberOf include itself, but it is okay for the entity type Album to include itself in its memberOf list.

[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 authorization requests. If there is no appliesTo attribute 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 that the action 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 action, 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 attributes, defining the attributes that must be present in the context record in the authorization request issued using this action.

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

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

[0241] (2) Set encodes the policy language set type. It is used with the attribute element to store the element type in the set.

[0242] (3) Records encode the policy language record type. The attributes property 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 required attributes. The required attribute specifies whether the attribute is always present in the record. The required attribute defaults to true. Setting it to false means that the attribute may not be in the record, so specific checks are required before it can be safely accessed.

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

[0244] Difference Random Test

[0245] Figure 10 A differential random testing approach for testing the policy evaluation functionality of the production authorization engine 1014 is shown. Standard testing approaches attempt to generate specific test inputs or sets of test inputs, including authorization requests, entity stores, and policy sets. Standard testing approaches can require significant effort to generate test inputs that provide near-complete or complete coverage of the programming functionality of the production authorization engine 1014, including the various code branches in the programming language code that implements the production authorization engine 1014. Standard testing approaches require not only the creation of test input data but also the creation of expected output data. In particular, for each test case, the correct expected output must be generated, including the correct allow or deny decision and any diagnostic information. Using the standard testing approach, the production authorization engine 1014 is fed test inputs, and the output of the production authorization engine 1014 for these test inputs is compared to the expected output. Any discrepancy between the actual and expected outputs indicates a bug in the production authorization engine 1014. Standard testing approaches are impractical for fully testing the production authorization engine 1014 due to the difficulty in generating a set of test inputs and a corresponding set of expected outputs that provide sufficient coverage of the programming functionality of the production authorization engine 1014. This difficulty stems from the variety of possible policies that can be input to 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 license and engine 1014 using the standard test method, a differential random test method is also used to test the production license engine 1914. The differential brand test method uses Figure 10 The reference implementation of the production authorization engine 1014, referred to as the reference authorization engine 1012, is a reference implementation of the production authorization engine 1014. The reference authorization engine 1012 provides the same functionality as the production authorization engine 1014, but has 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 or functional compiled language. For example, the reference authorization engine 1012 can be implemented in a validation-aware programming language, such as the DAFNY programming language. Furthermore, the implementation of the reference authorization engine 1012 can be simpler than that of the production authorization engine 1014 because the reference authorization engine 1012 does not need to address 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. As a result of the simpler implementation of the reference authorization engine 1012, it contains fewer lines of code than the production authorization engine 1014 and is therefore likely to be less buggy. Overall, the reference authorization engine 1012 can be programmed in an easy-to-read programming language, and the implementation does not need to be optimized for performance. For example, the reference authorization engine 1012 can be programmed in a different programming language than the programming language used to implement the production authorization engine 1014. In other words, the reference authorization engine 1012 need only 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 performing differential random testing on a production authorization engine 104 is provided. At 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, initial test inputs are randomly generated so that they are syntactically correct according to the policy language grammar. As the test inputs are 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 inputs results in an increase in code coverage, the test inputs are retained in a set of test inputs, which are used to generate future test inputs by modifying the retained test inputs.

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

[0249] At step 1006, if evaluating test input 1010 provides greater coverage of the code implementing production authorization engine 1014, test input 1010 is retained for future mutations. Steps 1002, 1004, and 1006 are repeated multiple times, each time using new test input. For example, these steps may be repeated approximately one million times. The number of times these steps are repeated can be determined based on the code coverage of production authorization engine 1014. For example, if, after running these steps for a period of time, the code coverage appears to have reached a maximum, the test loop can be stopped. It should be noted that while evaluating test inputs, some code of production authorization engine 1014 may not be accessible. Therefore, the maximum code coverage may be less than 100%.

[0250] Rigorous validation for strategic 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 verifier for the policy language system and method contains a type checking and transformation process that satisfies these requirements and allows policy analysis to be performed on a wider range of policies than simply implementing strict type checking rules.

[0252] Policy Language Policies are polymorphic in that a given policy can apply 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 strategy is rejected because one of the combinations is wrong. Such strategies are never converted to SMT.

[0254] (2) The strategy is rejected because every combination is typed as false. Such strategies are never converted to SMT.

[0255] (3) The policy is accepted because all combinations are correct and at least one combination is not typed as false. In this case, the policy is applied individually to the analysis of each non-false type combination, and if the policy satisfies the required property under each combination, then the policy as a whole satisfies the property. This reasoning can be extended to properties such as inclusion or equality involving more than one policy.

[0256] The validator accepts strategies in case (3) above. However, some of these strategies may cause errors in the symbolic evaluator of the strategy analysis (described below) because these strategies 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 minimum upper bound. Such strategies cannot be translated because the symbolic evaluator requires the left and right sides of == to have the same type, as in the underlying type system of SMTLib terms.

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

[0258] A possible approach would be to modify the validator to include a strict mode: flag indicating that it enforces strict type constraints instead of its normal (looser) type constraints. However, this approach would complicate the validator and cause the overall analysis to reject more strategies than necessary. For example, the strict typing rules would always reject a strategy with the expression principal has active && principal.active when the principal type does not declare an active property in one of the type combinations. In contrast, a normal validator would simply type this expression as false and potentially accept the entire strategy based on case 3 above.

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

[0260] To implement STT, we use cooperation from the verifier. Specifically, the verifier outputs the inferred type of each node in the policy AST for each type combination. The STT phase then checks and transforms these fully typed ASTs as follows:

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

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

[0263] (1.2) If the conditional type is false, recurse on the else branch and return the strictly typed node of the result.

[0264] (1.3) Otherwise, recurse on both branches and 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 literal true or false respectively without recursing on the argument. The strict type of the result will be boolean.

[0267] (2.2) Otherwise, recurse on both sides and 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, simply return the text true or false respectively without accessing the node's children. This is the correct conversion because the validator is reliable.

[0270] (3.2) Otherwise, recursively transform and check all subexpressions.

[0271] The strategies accepted by both the validator and the STT phase satisfy the following strict typing requirements. First, note that the validator performs event checking, so expressions like the problematic example, principal has active && principal.active , will be typed as false when the principal type does not have an active field. Next, note that the STT phase converts all nodes of type 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 typing rules and is therefore translatable. Finally, note that these conversions are all correct because the validator is sound.

[0272] The policy language is simplified to SMT through pattern-driven symbolic evaluation.

[0273] The policy language system and method include a policy language symbolic calculator, which is used to simplify policy language expressions into SMTLib language. The symbolic calculator is used to generate a decidable, sound, and complete SMT encoding of the policy language expression.

[0274] Using reduction engines to answer common questions

[0275] The policy language system and method includes a Satisfiability Modulo Theory (SMT) policy analyzer, whose function is 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 policy languages:

[0276] Equivalence: Do the two policies produce the same authorization decision for each input (subject, action, resource, context, and entity store)? A variation of this question is whether the two sets of policies produce the same result for each input. The answer to this question provides an opportunity for policy optimization, such as replacing a complex set of policies with a simplified policy that has the same effect.

[0277] Subsumption: Does the deny policy evaluate to true for all inputs for which the permit policy evaluates to true? If so, the permit policy is useless because it doesn't add any new permissions since it will always be overruled by the deny policy.

[0278] Triviality: For each input, does a given policy evaluate to true or does a given policy evaluate to false? If so, the policy is equivalent to a Boolean constant in terms of its behavior. For example, a constant-true grant policy grants all requests, which is a security issue, and a constant-true deny policy denies all requests, which is a usability issue.

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

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

[0281]

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

[0283]

[0284] The SMT strategy analyzer requests the symbol and symbol entity storage The strategies c[1],...,c[n] are evaluated symbolically to work. The SMT solver is called to check if the negation of the required property is unsatisfiable. Figure 11 If the SMT solver finds that formula 1100 is unsatisfiable, then property f holds for all possible inputs. Otherwise, the SMT solver has determined a specific input for which property f fails to hold.

[0285] In formula 1100, the symbolic evaluation function symeval() converts the policy c[i], the symbolic request and symbol storage As input, a symbolic value represents any concrete value of a given type.

[0286] Given these inputs, symeval(strategy c[i], symbolic request Symbol Storage ) produces a symbolic value that represents the behavior of policy c[i] on any specific input. In other words, the symbolic request and symbol storage is the variable in the verification formula 1100, symeval(strategy c[i], symbol request Symbol Storage ) is an expression in the SMTLib language for these variables, representing all possible behaviors of policy c[i]. The SMT solver searches for a specific value that assigns the symbolic variables to a value that makes verification formula 1100 true. This assignment is called a "model" of verification formula 1100.

[0287] Decidability, reliability, and completeness

[0288] As mentioned above, symeval(strategy c[i], symbol request Symbol Storage ) produces a symbolic value. The symbolic value should be decidable, reliable, and a complete encoding of the behavior of the policy c[i] for any specific input.

[0289] An encoding is decidable if an SMT solver can answer every verification query against that encoding with a satisfiable ("yes") or unsatisfiable ("no") answer. If the encoding is undecidable, then the SMT solver may be unable to answer some queries. In practice, undecidability often manifests as an SMT solver timing out or an 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 property f holds for all possible concrete inputs of the policy c[1],...,c[n]. In other words, an unsatisfiable answer to the encoding constitutes a proof that the property holds. If the encoding is unsound, an unsatisfiable answer is not a proof, and policy analysis based on the unsound encoding may miss errors (i.e., violations of property f).

[0291] While necessary, soundness alone is insufficient to guarantee that an SMT analysis will produce useful results. This is because soundness only guarantees that unsatisfiable answers are meaningful—it proves the absence of violations. However, if a sound SMT analysis returns a satisfiable result, the only conclusion is that the SMT analysis could not find a proof, even if one might exist. Therefore, simple analyses that always return satisfiable results are reasonable, although useless. This is why encodings 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 means that the model of the verification formula 1100 corresponds to the concrete inputs (queries q and entity stores s) for which policies c[1],…,c[n] violate property f. In other words, the satisfiable answer comes with the models that constitute the witnesses—the concrete requests q and entity stores s—such that f(eval(policyc[1],request q,entity store s),…,eval(policyc[n],

[0293] If the encoding is incomplete, the satisfiability model may not be a witness, and SMT policy analysis based on the incomplete encoding may produce false positives.

[0294] Completeness is a double manifestation of soundness. Completeness guarantees that only a satisfiable answer is 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 could not find a witness, even though one might exist. Therefore, a simple SMT analysis that always returns an unsatisfiable result is complete, although it is useless.

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

[0296] Pattern-driven symbolic evaluation of policy languages

[0297] Designing decidable, sound, and complete encodings for rich policy languages ​​is often impractical. Existing SMT analysis systems for authorization policy languages ​​choose soundness 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 tradeoffs. Specifically, they encompass a symbolic evaluator that achieves decidable, reliable, and complete encodings of 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 loosely typed policies. For strictly typed policies, the symbolic evaluator produces decidable, reliable, and complete encodings of the policy's behavior.

[0299] The policy language is dynamically typed. This means that the authorization engine assigns meaning to every 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 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 decidable SMT-theoretic compositions. This simplification provides SMT with a reliable and decidable encoding of strictly typed policy language expressions. This simplification is pattern-driven, as the symbolic evaluator leverages policy language patterns to check whether the input is strictly typed and generates a corresponding well-typed SMT encoding as a pattern-based representation of the symbolic value.

[0301] The only source of incompleteness in the reduction process is the well-formed assumption about the ancestor relationship of the policy language entities. This ancestor relationship maps the policy language entity to the 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 ancestor relationship must represent the transitive closure of the DAG. In general, it is impossible to express the transitive closure of an arbitrary graph using first-order logic. This problem can be circumvented by exploiting the property of policy language expressions that they can only reference a limited number of entities. This observation is used to generate well-formedness assumptions that make the simplification complete.

[0302] Strictly typed expressions

[0303] As mentioned above, the policy language is dynamically typed, meaning the authorization engine will detect type errors at runtime as it evaluates policy expressions. To mitigate the potential for evaluation errors, the policy language provides schema-based policy validation, which is described in more detail in this article. Given a schema describing the assumed structure of authorization requests and entities, the validator rejects policies that would be incorrect during evaluation. If the validator accepts a policy, the validated policy will not fail when evaluated by the authorization engine for any entity hierarchy and query that conforms to the schema.

[0304] Strictly typed policies can be simplified to SMT using a policy language symbolic evaluator. A validator can identify non-strictly typed policies. If a policy 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 Schema 1200 specifies the types of the subject, actions, resources, and context variables that make up a request, and schema 1200 specifies the shape of the entity store. The entity schema specifies the properties of each entity and its memberOf relationships, if any. The MemberOf relationship lists all the allowed ancestor types of a given entity type instance. For example, an employee may have a team or a department as its ancestor in the entity hierarchy. Similarly, a team or department may be part of another department. These are the only two hierarchical relationships allowed by schema 1200. For example, according to schema 1200, it would be a type error to have an expression in a "subject resource" policy because an employee can never be an ancestor of a document in the entity hierarchy.

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

[0307]

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

[0309] However, strategy A will not pass strict type checking because strict typing rules require that the types of the then and else branches of a conditional be the same. Therefore, strategy A is not strictly typed and cannot be reduced to SMT. However, strategy A can be rewritten into the equivalent strategy A' so that it passes strict type checking as follows:

[0310]

[0311] It is important to note that it is not always possible to rewrite a validated strategy to be strictly typed. For example, consider the following strategy B:

[0312]

[0313] Strategy B passes the standard validation because:

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

[0315] (2) The type of the included parameter is R2 = {zip: String}; and

[0316] (3) Types R1 and R2 have a minimum upper bound (R1 in this case).

[0317] A strict type checker will reject strategy B because it requires types R1 and R2 to be identical. Strategy B cannot be overridden and therefore fails strict type checking.

[0318] In general, if a validated policy involves operations on sets of records whose underlying record types are different, it cannot be rewritten to pass strict type checking. In particular, if expressions e1 and e2 are of type Set <r1>and Set <r2>, then R1 and R2 must be identical to allow strict typing of the set of operations on these expressions (for example, e1 == e2, e1.containsAll(e2), and e1.containsAny(e2)).

[0319] Pattern-based symbolic value representation

[0320] To simplify the strict type strategy to SMT, the symbolic evaluator and symbol entity storage Symbolically evaluates the policy. Symbolic request and symbol entity storage The inputs must conform to the pattern used by the type checking strategy.

[0321] To illustrate, Figure 13 An example symbol request 1300 of the example pattern 1200 is provided. Figure 14 An example symbol entity store 1400 of the example schema 1200 is provided. In the example, Figure 15 Record Type 1500 introduces names for the anonymous record types defined in schema 1200 to make the notation easier to read.

[0322] The symbol request 1300 and the symbol entity storage 1400 are represented using a set of symbol values, which are assigned types according to the request mode and entity mode of the mode 1200.

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

[0324] The symbolic store 1400 contains a set of symbolic functions that map entities of a given type to their attribute records and ancestor sets. A symbolic (uninterpreted) function represents an arbitrary mapping of a given type; for example, SymFun("f0",Employee,R1) represents a function that maps from Figure 15 An arbitrary mapping of values ​​of type Employee to values ​​of type R1 for record type 1500. The symbolic functions in the ancestor field collectively represent the ancestor relationship of a given entity type. For example, the complete ancestor relationship of type Employee is represented by two symbolic functions f1 and f2, which map each employee to its ancestors (possibly empty sets) of type Team and Department, respectively. Bracket notation is used to reference stored content; in our example, [Employee][ancestor s][Team] refers to the symbolic function SymFun("f1",Employee,Set <team>).

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

[0326] Strategy A' is not always true. The SMT solver generates witnesses indicating that strategy A' might be false by finding assignments to symbolic variables and functions that cause strategy A' to evaluate to false. Below is an example of such an assignment, omitting the values ​​of irrelevant variables and functions 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, numberOfLaptops:2}, the evaluation of policy A' is false.

[0329] Any field in the request or storage representation can contain a symbolic literal value. In our example, only [context] is a literal. However, you can also define symbolic requests or storage where other fields are also literals. For example, for the symbolic literal SymEntity(Employee,"Jane") or The main fields of the request for [Employee][attributes] can be set to a specific function definition. If every field in the request and the store is a symbol literal, the result of the symbol evaluation is also guaranteed to be a literal, and the symbol evaluator behaves exactly like the authorization engine's evaluator.

[0330] Simplify strictly typed expressions to SMT

[0331] Figure 16 A symbolic evaluator 1620 in a provider network 1600 is shown for reducing a strictly typed expression to an SMT. The symbolic evaluator 1620 takes as input a strictly typed expression 1612, a symbolic request 1614, and a symbolic entity store 1616. The symbolic evaluator produces as output a symbolic value 1630. The symbolic value 1630 encodes the semantics of the strictly typed expression 1612 with respect to the symbolic request 1614 and the symbolic entity store 1616.

[0332] Symbolic values ​​1630 are expressed in a term language. The term language includes the basic symbolic values ​​in question: symbolic variables, functions, and literals. All other terms are created by applying symbolic operators to these basic terms. For example, SymEntity(Action,"remoteAccess")) produces an item that applies the equality operator to a symbolic variable [action] and the text Action::"remoteAccess".

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

[0334] The symbolic evaluator 1620 operates recursively, just like the evaluator of the authorization engine. To encode a strictly typed expression 1612 with n sub-terms, the symbolic evaluator 1620 encodes each sub-term 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 will produce. Specifically, according to the strict type checker, the type of the strictly typed expression 1612 is type T, and then eval(strictly typed expression e, authorization request q, term T) produces Option for the specific authorization request q and the specific entity storage s. <t>The specific value of the type, and the symbol evaluator 1620 generates Option <t>An item of type Option <t>The type takes into account the possibility that the specific evaluation of a strictly typed expression 1612 may fail due to errors that verification cannot exclude. Therefore, if the evaluation fails, the result is None, otherwise, for v of type T, the result is Some(v).

[0335] Generate well-formed hypotheses about ancestry relationships

[0336] The symbolic evaluation function is reliable and complete for all operators in the policy language, except the IN operator on entities used to test hierarchy membership. For the IN operator, the encoding is reliable 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 gets the set of all ancestors of A and then checks whether that set contains B. Item 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 this term is true, the SMT solver will produce a witness. For example, the SMT solver may return the following model:

[0344]

[0345] In the above model, A maps to a singleton set containing B, and B maps 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, fully encoding the example expression will produce a false term under all possible assignments. In other words, it is unsatisfiable.

[0346] To address this issue, the encoding is strengthened by enforcing the assumptions that ancestry relations are irreflexive, antisymmetric, and transitive. These assumptions arise from the observation that policy language expressions can only access a limited set of entities during evaluation. Specifically, there are only two ways in which the evaluation of a policy language expression can generate an entity reference: (1) by evaluating an entity literal (e.g., Department::"A"), or (2) by accessing a property that stores an entity reference (e.g., principal.manager, where manager is Employee). Therefore, if one collects the set of all (1) entity literals and (2) entity-valued property accesses that occur in an expression, then there exists a way to reference every possible entity reference that an expression could generate during evaluation.

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

[0348] Next, determine the item set and is hereinafter referred to as entity (e).

[0349] Assumptions can be generated in two steps:

[0350] (1) In the first step, iterate over all items t[i] in the collection entity (e). If t[i] can have an ancestor of its own type according to the memberOf relationship, then emit the term Not(Cont ains(anc[i], t[i])). Here, anc[i] is the item representing the relevant ancestor of t[i]. This assumption restricts the ancestor relationship on the item t[i] to be immutable.

[0351] (2) In the second step, for each pair of items t[i] and t[j] in the set entity (e), it is iterated. If t[j] can be an ancestor of t[i] according to the memberOf relation, then items of the form Implies(Contains(anc[i],t[j]).Subset(anc[j],anc[i])) are emitted, each of which corresponds to a type-correct combination 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] Both of the above assumptions hold for any ancestry relationship that represents the transitive closure of a directed acyclic graph.

[0353] For example, the symbolic evaluator's hypothesis generator would emit the following for the example expression above:

[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 terms (1)–(4) to the original encoding of the term And(t[0],t[1]) above, the SMT solver can no longer find the model as expected.

[0359] The policy language system and method include graphical user interface, command line interface, or software development kit tools that enable users to validate 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 catch type errors. The policy analyzer is SMT-based and can catch logic errors.

[0360] Policy Language Item Language

[0361] The following is a formal specification of the strongly simply typed term language used by the symbolic evaluator. The symbolic evaluator reduces policy language expressions to the term language during symbolic evaluation. The term language is directly translatable into SMTLib.

[0362]

[0363] Each item has a type, unless the type can be easily obtained from a child item. Items can be created using the factory functions defined below.

[0364]

[0365]

[0366] The following is a unary uninterpreted function that represents an arbitrary mapping from entities of a given type to records of a given type.

[0367]

[0368] Here are the 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. The 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 Figure 17 1710, but intermediary network 1730 and customer network 1750 may also be located within provider network 1710. Provider network 1710 provides resource virtualization to customers of provider network 1710 via virtualization service 1718. Virtualization service 1718 allows customers to purchase, rent, subscribe to, or otherwise obtain use of one or more resources (e.g., resource 1712).

[0374] Provider network 1700 includes a policy evaluation service 1742 for evaluating authorization policies according to the techniques disclosed herein, a policy validation service 1744 for validating 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 provider network 1710 via an API. Additionally or alternatively, services 1742, 1744, or 1746 can be provided to client devices in a client network (e.g., client device 1752 in client network 1750) or other network entities (e.g., network entity 1720) via an API and intermediary network 1730.

[0375] Provider network 1710 is used to provide a computing environment in which the techniques disclosed herein can be implemented. Provider network 1710 is programmed or configured to follow a cloud computing model. This 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 provider network 1710). Resources can be quickly provisioned and released with minimal management effort or service provider interaction.

[0376] Users of the provider network 1710 (sometimes referred to herein as "customers" of 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, as needed, with minimal or no human interaction with the service providers. The resources of the provider network 1710 are available through an intermediary 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 compute, storage, processing, memory, and network resources in the provider network 1710 are pooled to provide services to multiple customers using a multi-tenant model, dynamically allocating and reallocating different physical and virtual resources based on customer demand. There is a sense of location independence because customers generally do not have control or knowledge of the exact location of the provided resources, but can specify the location at a higher level of abstraction (such as, for example, at the level of country, state, data center, or any other location granularity). The provider network 1710 automatically controls and optimizes resource usage by utilizing metering capabilities (e.g., pay-per-use, fee-based, subscription-based, or any other fee basis) at an abstraction level appropriate to the service type (e.g., compute, storage, processing, memory, network bandwidth, active customer accounts, or any other suitable level of abstraction). Resource usage in the provider network 1710 is monitored, controlled, and reported, providing transparency to both the providers and customers of the utilized services.

[0378] Provider network 1710 may 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] With SaaS, capabilities are provided to customers using software applications of the provider network 1710 running on the provider network's 1710 infrastructure. The applications can be accessed 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 mobile or web application), a software development kit (SDK), or any other interface. The provider network's 1710 infrastructure includes hardware resources such as servers, storage, and network resources, as well as software deployed on the hardware infrastructure that supports the services provided. Typically, in the SaaS model, the customer does 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 customer-created or acquired applications 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. Typically, in a PaaS model, customers do not manage or control the underlying hardware and software infrastructure, including networks, servers, operating systems, or storage, but do have control over deployed applications and may have control over configuration settings for the application hosting environment.

[0381] IaaS provides customers with the ability to provision processing, storage, networking, and other basic computing resources, on which they can deploy and run arbitrary software, including operating systems and applications. Customers typically do not manage or control the underlying hardware and software infrastructure, but do have control over the operating system, storage, and deployed applications, and may have limited control over select network components (such as, for example, host firewalls).

[0382] Provider network 1710 can offer its capabilities to customers according to a variety of different deployment models, including 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 configured for exclusive use by a single organization, which may include multiple customers. A private cloud is owned, managed, and operated by the organization, a third party, or some combination thereof, and it can exist on-site or off-site.

[0384] In a community cloud, the hardware and software infrastructure of the provider network 1710 is configured for exclusive use by a specific community of customers in organizations with common concerns, such as mission security requirements, policies, and compliance considerations. A 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-site or off-site.

[0385] In a public cloud, 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 may reside on the premises of a public cloud provider.

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

[0387] Resources 1712 are computing, storage, or network resources. Resources 1712 are implemented by electronic devices in data centers within provider network 1710. A data center is a physical facility or building that houses computing, storage, and network infrastructure. Provider network 1710 encompasses many resources implemented by many electronic devices distributed across a set of data centers located in different geographic regions or locations. Examples of electronic devices are described below with respect to Figure 18 Device 1800 is described.

[0388] An example of resource 1712 is a virtual machine (VM). A virtual machine is a computing resource that uses software rather than a physical computer to run programs and deploy applications. A virtual machine (sometimes called a "guest") can run on a single physical machine (sometimes called 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 its own copy of the 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 called a "hypervisor"). The hypervisor itself can run on the bare hardware of the host, or run as a process of an operating system running on the bare hardware.

[0389] Another example of resource 1712 is a container. A container is like a virtual machine in that it runs separate applications on a single platform. However, a container typically encapsulates a single application or a collection of one or more related applications, along with runtime dependencies and libraries, whereas a virtual machine virtualizes hardware to create a "computer." Another difference is that a container system typically provides services from the operating system kernel running on the bare hardware of the underlying host to containers that share these core services, as coordinated by the container system. The container system itself can run on the host with the help of the operating system kernel and can isolate containers from each other to a certain extent. While 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 the host.

[0390] Although resource 1712 may be a virtual machine or a container, resource 1712 may 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. Local IP address 1714 comprises an internal or private network address within provider network 1710. Local IP address 1714 may be, for example, an IPv4 or IPv6 address. For example, local IP address 1714 may 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 may be variable within provider network 1710.

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

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

[0394] The provider network 1710 may also provide storage services 1748 to customers. For example, the storage services 1748 may be used to store authorization data, entity storage, authorization policies, and authorization policy schemas. The storage services 1748 may provide an API to access data from and store data in storage resources such as virtual data stores (e.g., folders or "buckets," virtual volumes, databases, etc.) provided by the provider network 1710.

[0395] Example electronic device

[0396] Figure 18 An example electronic device 1800 for use in implementations 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 may also include a network interface 1816 coupled to the I / O interface 1804.

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

[0398] System memory 1806 stores instructions and data accessible by processors 1802-1, 1802-2, ..., 1802-N. 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. Program instructions 1808 and data 1810 that implement desired functionality, such as methods, processes, actions, or operations of the techniques disclosed herein, are stored in system memory 1806 as code 1808 (e.g., executable to implement, in whole or in part, methods, processes, actions, or operations performed by an authorization engine, a validator, an STT stage of a validator, or an SMT-based policy analyzer) and data 1810.

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

[0400] The I / O interface 1804 includes support for devices attached through various types of peripheral buses, such as, for example, a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard (e.g., a bus that implements a version of the Peripheral Component Interconnect Express (PCI-E) standard, or another interconnect such as the Quick Path Interconnect (QPI) or the Ultra Path 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. In addition, 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] The 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 the network 1818. The network interface 1816 supports communication via any suitable wired or wireless network, such as, for example, some 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] Device 1800 optionally includes an offload card 1812, which includes a processor 1814 and may include a network interface (not depicted) connected using I / O interface 1804. For example, device 1800 may function as a host electronic device hosting computing resources such as compute instances (e.g., operating as part of a hardware virtualization service), and offload card 1812 may execute a virtualization manager that can manage the compute instances executing on host electronic device 1800. By way of example, offload card 1812 may perform compute instance management operations, such as pausing or unpausing a compute instance, starting or terminating a compute instance, performing memory transfer / copy operations, and the like. These management operations may be performed by the offload card in cooperation with a hypervisor executed by processors 1802-1, 1802-2, ..., 1802-N of device 1800 (e.g., based on a request from the hypervisor). However, the virtualization manager implemented by offload card 1812 may accommodate requests from other entities (e.g., from the compute instances themselves).

[0403] The system memory 1806 may include one or more computer-accessible media configured to store program instructions 1808 and data 1810. However, program instructions 1808 or data 1810 may be received, sent, or stored on different types of computer-accessible media. Computer-accessible media include 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 include, for example, most general-purpose random access memories (RAMs), including dynamic RAM (DRAM) and static RAM (SRAM). Non-volatile computer-accessible media include, 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 memory, such as NAND flash memory 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., magnetic disk storage, hard drives, optical disks, floppy disks, and magnetic tapes).

[0404] the term

[0405] In the foregoing description and the appended claims, ordinal numbers such as first and second may be used to describe various elements, features, actions, or operations. Unless the context clearly indicates otherwise, such elements, features, actions, or operations are not limited by these terms. These terms are only used to distinguish one element, feature, action, 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, the singular forms "a," "an," "said," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

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

[0408] With respect to "based on," the term is used in some instances in the preceding description and the appended claims to identify a causal relationship between the steps, actions, or operations described. Unless the context clearly indicates otherwise, "A based on B" in these instances means that the performance of step, action, or operation B causes the performance of step, action, or operation A. The causal relationship can be direct (without intervening steps, actions, or operations) or indirect (through the performance of one or more intervening steps, actions, 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 to cause 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 if A is based on B in other cases. Furthermore, 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 to cause the performance of A in all cases, and in some cases, one or more other steps, actions, or operations besides B may be performed to cause the performance of A. In such cases, A may still be based on B even if multiple steps, actions, or operations, including B, are performed to cause A.

[0409] Unless the context clearly indicates otherwise, the term "or" is used in the foregoing description and the appended claims in its inclusive sense (and not in its exclusive sense), so 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, linking language in the foregoing description and the appended claims, such as the phrase "at least one of X, Y, and Z," should be understood to convey that an item, item, etc. can be X, Y, or Z, or a combination thereof. Thus, such linking language does not require the presence of at least one X, at least one Y, and at least one Z, respectively.

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

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

[0413] Get the authorization policy mode;

[0414] determining whether there are any inconsistencies between the authorization policy in the authorization policy language and the authorization policy schema;

[0415] 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] It is determined that there is no inconsistency between the authorization policy and the authorization policy pattern, so that the authorization policy is guaranteed to have no runtime type error and runtime attribute access error for any input that conforms to the authorization policy pattern.

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

[0421] Stores a collection of entities arranged in an entity hierarchy; and

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

[0423] 3. The method of 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] Get the authorization policy mode;

[0426] determining whether there are any inconsistencies between the authorization policy in the authorization policy language and the authorization policy schema;

[0427] The authorization policy includes:

[0428] (a) Effects;

[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 are one or more determined inconsistencies between the authorization policy and the authorization policy schema, causing display of information indicating that the authorization policy is invalid with respect to the authorization policy schema; and

[0432] If there is no definite inconsistency between the authorization policy and the authorization policy pattern, it is guaranteed that the authorization policy has no runtime type error and runtime attribute access error for any input that conforms to the authorization policy pattern.

[0433] 5. The method according to clause 4, further comprising:

[0434] Stores a collection of entities arranged in an entity hierarchy; and

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

[0436] 6. The method of clause 4, further comprising:

[0437] detecting a Boolean expression in the authorization policy that dereferences an optional attribute of an entity without checking the presence of the optional attribute of the entity as a precondition; and

[0438] The information displayed therein indicates that the Boolean expression lacks a check for the presence of the optional attribute of the entity as a prerequisite.

[0439] 7. The method of clause 4, further comprising:

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

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

[0442] 8. The method of clause 4, further comprising:

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

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

[0445] 9. The method of clause 4, further comprising:

[0446] detecting an action in the authorization policy that applies to an unsupported subject or resource in the authorization policy; and

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

[0448] 10. The method of clause 4, further comprising:

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

[0450] The displayed information includes tips on appropriate use of the hierarchical containment operator in the authorization policy.

[0451] 11. The method of clause 4, further comprising:

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

[0453] The displayed information includes tips on proper use of the hierarchical containment operator.

[0454] 12. The method of clause 4, further comprising:

[0455] detecting an unrecognized attribute of an entity in the authorization policy, the unrecognized attribute not specified as an attribute of the entity in the authorization policy schema; and

[0456] The displayed information indicates the unidentified attribute.

[0457] 13. The method of clause 4, further comprising:

[0458] 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

[0459] The displayed information indicates that the types do not match.

[0460] 14. The method of clause 4, further comprising:

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

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

[0463] 15. The computer-implemented method of clause 4, wherein the authorization policy mode 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 of 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 comprising instructions that, when executed, cause the authorization policy verification service to:

[0467] Get the authorization policy mode;

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

[0469] The authorization policy includes:

[0470] (a) Effects;

[0471] (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

[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 determined inconsistencies between the authorization policy and the authorization policy schema, causing display of information indicating that the authorization policy is invalid with respect to the authorization policy schema; and

[0474] If there is no definite inconsistency between the authorization policy and the authorization policy pattern, it is ensured that the authorization policy has no runtime type error and runtime attribute access error for any input that complies with the authorization policy pattern.

[0475] 18. The system of clause 17, wherein the authorization policy verification service further comprises instructions that, when executed, cause the authorization policy verification service to further:

[0476] Stores a collection of entities arranged in an entity hierarchy; and

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

[0478] 19. The system of clause 17, wherein the authorization policy verification service further comprises instructions that, when executed, cause the authorization policy verification service to further:

[0479] detecting a Boolean expression in the authorization policy that dereferences an optional attribute of an entity without checking the presence of the optional attribute of the entity as a precondition; and

[0480] The information displayed therein indicates that the Boolean expression lacks a check for the presence of the optional attribute of the entity as a prerequisite.

[0481] 20. The system of clause 17, wherein the authorization policy verification service further comprises instructions that, when executed, cause the authorization policy verification service to further:

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

[0483] 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] Identify an authorization policy set, where each authorization policy in the authorization policy set includes:

[0487] (a) Effects;

[0488] (b) an authorization policy header, which selects the subject, 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] deleting at least one authorization policy in the set of authorization policies based on an evaluation of the authorization request by the authorization policy header in the at least one authorization policy;

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

[0492] The authorization request is allowed or denied based on an evaluation of the subset.

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

[0494] Stores a collection of entities arranged in an entity hierarchy; and

[0495] The authorization policy further includes expressions regarding one or more entities in the entity hierarchy.

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

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

[0498] determining a set of entity identifiers for a set of entities in an entity hierarchy, said entity identifiers being ancestors of said resource of said entity hierarchy; and

[0499] A set of authorization policies is determined, each authorization policy having a header resource that matches the resource identifier or an entity identifier from the set of entity identifiers.

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

[0501] Receive authorization request;

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

[0503] (a) Effects;

[0504] (b) an authorization policy header, which selects the subject, 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] deleting at least one authorization policy in the set of authorization policies based on an evaluation of the authorization request by the authorization policy header in the at least one authorization policy;

[0507] evaluating a subset of the set of authorization policies against the authorization request; and

[0508] The authorization request is allowed or denied based on an evaluation of the subset of the authorization policies.

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

[0510] Stores a collection of entities arranged in an entity hierarchy; and

[0511] The 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 of clause 24, wherein, based on the authorization policy header of the authorization policy, removing the at least one authorization policy from evaluation for the authorization request is further based on:

[0513] determining a subject identifier of a subject from the authorization request;

[0514] determining a set of entity identifiers for a set of entities in an entity hierarchy, said entity identifiers being ancestors of said subject of said entity hierarchy; and

[0515] A second set of authorization policies is determined, each authorization policy having a header resource that matches the subject identifier or an entity identifier from the set of entity identifiers.

[0516] 27. The method of clause 26, further comprising:

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

[0518] 28. The method of clause 24, further comprising:

[0519] determining required entity data from said subset of said set of authorization policies;

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

[0521] receiving a 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 referenced by specific entities in two or more entity reference chains; and

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

[0525] 29. The method of clause 24, wherein:

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

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

[0528] The method also includes evaluating the header of the second authorization policy based on accessing an entity ancestor mapping, wherein the entity ancestor mapping maps the first specific principal to a specific set of principals that are ancestors of the first specific principal in an entity hierarchy, and determining that the second specific principal is within the specific set of principals that are ancestors of the first specific principal in the entity hierarchy.

[0529] 30. The method of clause 24, wherein:

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

[0531] A condition of a particular authorization policy in the subset of the set of authorization policies includes an expression that accesses an entity attribute; and

[0532] The method also includes evaluating a condition of the specific policy based on accessing an entity attribute mapping that maps the first specific entity to an attribute record of the first specific entity, and accessing the attribute of the attribute record.

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

[0534] Randomly generate test inputs;

[0535] Running a generated policy authorization engine and a reference policy authorization engine on the test input, wherein the reference policy authorization engine is implemented using a theorem proving programming language;

[0536] Obtaining a first output of the policy generation authorization engine on the test input;

[0537] Obtaining a second output of the reference authorization engine on the test input; and

[0538] The first output is compared to the second output.

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

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

[0541] A response to the authorization request is returned to the provider web application, the response indicating that the authorization request is denied.

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

[0543] 34. A system comprising:

[0544] A first set of one or more electronic devices configured to implement an authorization policy evaluation service, wherein the authorization policy evaluation service includes instructions that, when executed, cause the authorization policy evaluation service to perform:

[0545] Receive authorization request;

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

[0547] (a) Effects;

[0548] (b) an authorization policy header, which selects the subject, 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 applies;

[0550] deleting at least one authorization policy in the set of authorization policies based on an evaluation of the authorization request by the authorization policy header in the at least one authorization policy;

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

[0552] The authorization request is allowed or denied based on an evaluation of the subset.

[0553] 35. The method of clause 24, wherein the authorization policy evaluation service further comprises instructions that, when executed, cause the authorization policy evaluation service to further:

[0554] Stores a collection of entities arranged in an entity hierarchy; and

[0555] The 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.

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

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

[0558] determining a set of entity identifiers for a set of entities in an entity hierarchy, said entity identifiers being ancestors of said subject of said entity hierarchy; and

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

[0560] 37. The method of clause 26, wherein the authorization policy evaluation service further comprises instructions that, when executed, cause the authorization policy evaluation service to further:

[0561] A subset of a second set of authorization policies is determined, wherein for each authorization policy in the subset of the second set, a set of header constraints of the authorization policy evaluates to true with respect to the authorization request.

[0562] 38. The method of clause 24, wherein the authorization policy evaluation service further comprises instructions that, when executed, cause the authorization policy evaluation service to further:

[0563] determining required entity data from said subset of said set of authorization policies;

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

[0565] receiving a 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] Determining that the first set of entity data includes specific entity data referenced by specific entities in two or more entity reference chains; and

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

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

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

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

[0572] The authorization policy evaluation service also includes instructions, which when executed will further perform the evaluation of the header of the second authorization policy based on accessing the entity ancestor mapping, wherein the entity ancestor mapping maps the first specific subject to a specific set of subjects that are ancestors of the first specific subject in the entity hierarchy, and determines 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 of clause 24, wherein:

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

[0575] A condition of a particular authorization policy in the subset of the set of authorization policies includes an expression that accesses an entity attribute; and

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

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

[0578] Encodes a set of items from an authorization policy, where the authorization policy includes:

[0579] (a) Effects;

[0580] (b) an authorization policy header, which selects the subject, action, or resource to which the authorization policy applies;

[0581] (c) one or more optional conditional clauses to 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 Theory (SMT) formula into an SMT solver, the SMT formula being converted 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] determining an answer to a first-order question about the behavior of the authorization policy based on an output from the SMT solver indicating whether the SMT formula is satisfiable or unsatisfiable; and

[0586] Information indicating the answer is caused to be displayed.

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

[0588] The authorization policy is validated as a strict type based on an authorization policy schema.

[0589] 43. The method of clause 41, wherein the authorization policy governs 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 items from an authorization policy to produce an encoding of the authorization policy, wherein the authorization policy comprises:

[0592] (a) Effects;

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

[0594] (c) one or more optional conditional clauses to further refine the circumstances in which the authorization policy applies;

[0595] Inputting a Satisfiability Modulo Theory (SMT) formula into an SMT solver, wherein the SMT formula is converted from the encoding of the authorization policy;

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

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

[0598] Information indicating the answer is caused to be displayed.

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

[0600] Generate SMT formulas using optional concrete constraints on the form of entity hierarchies,

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

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

[0603] The authorization policy is validated as a strict type based on an authorization policy schema.

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

[0605] Generate a symbolic authorization request based on the authorization request mode of the authorization policy mode;

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

[0607] wherein the authorization request schema specifies an entity type of a corresponding variable set, the corresponding variable set including an authorization request that conforms to the authorization request schema; and

[0608] The entity schema specifies a set of nominal entity types, a set of attribute record types within the set of nominal entity types, and a set of allowed ancestor entity types within the set of nominal entity types, the allowed ancestor entity types comprising an entity hierarchy conforming to the entity schema.

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

[0610] Generate a symbol authorization request based on the authorization request mode and further based on:

[0611] (a) The entity type set in the corresponding variable set including the authorization request that complies with the authorization request pattern is assigned as

[0612] (b) symbolic variable set;

[0613] Each symbolic variable in the set of symbolic variables represents any value of the corresponding assigned entity type.

[0614] 49. The method of clause 47, further comprising:

[0615] generating a symbolic entity store based on the entity pattern, and further generating a symbolic function set based on the entity pattern;

[0616] Each symbolic function in the set of symbolic functions is either:

[0617] (a) map any entity of the corresponding entity type to any attribute record of the attribute record type of the corresponding entity type, or

[0618] (b) Map any entity of the corresponding entity type to any entity of one or more permitted ancestor entity types of the corresponding entity type.

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

[0620] encoding an initial set of items in the authorization policy based on an authorization policy schema;

[0621] Collect one or more sub-expression sets of the authorization policy, wherein the one or more sub-expression sets include entity literal sets and entity value attribute access;

[0622] generating one or more hypothetical item sets corresponding to one or more items in the initial item set, the one or more hypothetical item sets encoding the authorization policy; and

[0623] The initial set of items is combined with the one or more hypothetical sets of items in the set of items encoding the authorization policy.

[0624] 51. The method of clause 50, wherein generating the one or more sets of hypothesis terms is based on generating hypothesis terms that constrain ancestry relationships to be irreflexive on terms.

[0625] 52. The method of clause 50, wherein generating the one or more sets of hypotheses is based on generating hypotheses that require that an ancestry relationship be transitive and antisymmetric on a pair of terms.

[0626] 53. The method of clause 44, further comprising:

[0627] The authorization policy mode and the authorization policy are obtained via a command line interface, a graphical user interface, or a software development kit.

[0628] 54. The method of 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 comprises a witness; and

[0631] Information indicative of the witness is caused to be displayed.

[0632] 55. 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 comprising instructions that, when executed, cause the authorization policy analysis service to:

[0635] Receive authorization policy;

[0636] Encoding a set of items from the authorization policy, wherein the authorization policy comprises:

[0637] (a) Effects;

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

[0639] (c) one or more optional conditional clauses to further refine the circumstances in which the authorization policy applies;

[0640] inputting a Satisfiability Modulo Theory (SMT) formula into an SMT solver, the SMT formula being converted from an encoding of the authorization policy and optionally specific constraints in the form of the entity hierarchy and query context on which the policy operates; and

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

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

[0643] causing display of information indicative of the answer;

[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 comprising instructions that, when executed, cause the authorization policy analysis service to:

[0645] storing the authorization policy; and

[0646] The authorization policy is sent to the authorization policy analysis service.

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

[0648] The authorization policy is validated as a strict type based on an authorization policy schema.

[0649] 58. The system of clause 56, wherein the authorization policy analysis service further comprises instructions that, when executed, cause the authorization policy analysis service to:

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

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

[0652] wherein the authorization request schema specifies the entity type of a corresponding set of variables, which constitute an authorization request that conforms to the authorization request schema;

[0653] wherein the entity schema specifies a set of nominal entity types, a set of attribute record types within the set of nominal entity types, and a set of permitted ancestor entity types within the set of nominal entity types, the set of permitted ancestor entity types comprising an entity hierarchy conforming to the entity schema; and

[0654] The authorization policy mode and the authorization policy are obtained via a command line interface, a graphical user interface, or a software development kit.

[0655] 59. The system of clause 56, wherein the authorization policy analysis service further comprises instructions that, when executed, cause the authorization policy analysis service to:

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

[0657] wherein the output of the SMT solver comprises a witness; and

[0658] Information indicative of the witness is caused to be displayed.

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

[0660] It will be apparent to those skilled in the art that the above examples can be modified in many ways without departing from the scope of the invention. Therefore, the scope of the invention should be determined by the following claims and their legal equivalents.< / t> < / t> < / t> < / team> < / bool> < / bool> < / bool> < / expr>

Claims

1. A method performed by one or more electronic devices in a provider network, the method comprising: receiving a request to validate an authorization policy in an authorization policy language, wherein a policy language engine is operable to manage access to one or more resources of the provider network based at least in part on the authorization policy; Get the associated authorization policy mode; determining whether there are any inconsistencies between the authorization policy and the associated authorization policy schema, The authorization policy includes: (a) Effects; (b) an authorization policy header that selects one or more subjects, one or more actions, or one or more of the resources to which the authorization policy applies; and (c) one or more optional conditional clauses, wherein the one or more optional conditional clauses further refine the circumstances in which the authorization policy applies; determining that there is no inconsistency between the authorization policy and the authorization policy schema; and Indicates that the authorization policy has no runtime type errors and no runtime property access errors for any input that conforms to the authorization policy pattern.

2. The method of claim 1, further comprising: Stores a collection of entities arranged in an entity hierarchy; and The authorization policy further includes at least one expression regarding one or more entities in the entity hierarchy. The method of claim 1 , wherein the authorization policy language is a dynamically typed language.

4. A method performed by one or more electronic devices, the method comprising: receiving a request to validate an authorization policy in an authorization policy language, wherein a policy language engine is operable to manage access to one or more resources of a provider network based at least in part on the authorization policy; Get the associated authorization policy mode; determining whether there are any inconsistencies between the authorization policy and the associated authorization policy schema, The authorization policy includes: (a) Effects; (b) an authorization policy header that selects one or more subjects, one or more actions, or one or more of the resources to which the authorization policy applies; and (c) one or more optional conditional clauses, wherein the one or more optional conditional clauses further refine the circumstances under which the authorization policy applies; If there are one or more determined inconsistencies between the authorization policy and the associated authorization policy schema, causing display of information indicating that the authorization policy is invalid with respect to the authorization policy schema; and If there are no determined inconsistencies between the authorization policy and the authorization policy schema, it is indicated that the authorization policy has no runtime type errors and no runtime property access errors for any input that conforms to the authorization policy schema.

5. The method of claim 4, further comprising: Stores a collection of entities arranged in an entity hierarchy; and The authorization policy further includes at least one expression regarding one or more entities in the entity hierarchy.

6. The method of claim 4, further comprising: detecting a Boolean expression in the authorization policy that dereferences an optional attribute of an entity without checking the presence of the optional attribute of the entity as a precondition; and The information displayed therein indicates that the Boolean expression lacks a check for the presence of the optional attribute of the entity as a prerequisite.

7. The method of claim 4, further comprising: detecting an entity type in the authorization policy that is not an entity type listed in the entity type specification of the associated authorization policy schema, The displayed information indicates the entity type in the authorization policy.

8. The method of claim 4, further comprising: detecting an action in the authorization policy, the action not being an action listed in an action specification of the associated authorization policy pattern; and The displayed information indicates the action in the authorization policy.

9. The method of claim 4, further comprising: detecting an action in the authorization policy that applies to an unsupported subject or resource in the authorization policy; and The displayed information indicates an action in the authorization policy and indicates the unsupported subject or resource in the authorization policy to which the action is applied.

10. The method of claim 4, further comprising: detecting improper use of a hierarchical containment operator in the authorization policy; and The displayed information includes tips on appropriate use of the hierarchical containment operator in the authorization policy.

11. The method of claim 4, further comprising: Detect improper use of equation operators in the authorization policy, The displayed information includes tips on proper use of the equality operators.

12. The method of claim 4, further comprising: detecting an unrecognized attribute of an entity in the authorization policy, the unrecognized attribute not specified as an attribute of the entity in the authorization policy schema; and The displayed information indicates the unidentified attribute.

13. The method of claim 4, 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 The displayed information indicates that the types do not match.

14. The method of claim 4, further comprising: detect that the authorization policy always evaluates to false; and The displayed information indicates that the authorization policy always evaluates to false.

15. The method of claim 4, wherein the authorization policy mode and the authorization policy are identified to the policy validator via parameters in a command line invocation of the policy validator.

16. The method of claim 4, wherein the authorization policy language is a dynamically typed language.

17. 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 comprising instructions that, when executed, cause the authorization policy verification service to: receiving a request to validate an authorization policy in an authorization policy language, wherein a policy language engine is operable to manage access to one or more resources of the provider network based at least in part on the authorization policy; Get the associated authorization policy mode; determining whether there are any inconsistencies between the authorization policy and the associated authorization policy schema, The authorization policy includes: (a) Effects; (b) an authorization policy header that selects one or more subjects, one or more actions, or one or more of the resources to which the authorization policy applies; and (c) one or more optional conditional clauses, wherein the one or more optional conditional clauses further refine the circumstances under which the authorization policy applies; If there are one or more determined inconsistencies between the authorization policy and the associated authorization policy schema, causing display of information indicating that the authorization policy is invalid with respect to the authorization policy schema; and If there are no determined inconsistencies between the authorization policy and the authorization policy schema, it is indicated that the authorization policy has no runtime type errors and no runtime property access errors for any input that conforms to the authorization policy schema.

18. The system of claim 17, wherein the authorization policy verification service further comprises instructions that, when executed, cause the authorization policy verification service to: Stores a collection of entities arranged in an entity hierarchy; and The authorization policy further includes at least one expression regarding one or more entities in the entity hierarchy.

19. The system of claim 17, wherein the authorization policy verification service further comprises instructions that, when executed, cause the authorization policy verification service to: detecting a Boolean expression in the authorization policy that dereferences an optional attribute of an entity without checking the presence of the optional attribute of the entity as a precondition; and The information displayed therein indicates that the Boolean expression lacks a check for the presence of the optional attribute of the entity as a prerequisite.

20. The system of claim 17, wherein the authorization policy verification service further comprises instructions that, when executed, cause the authorization policy verification service to: detecting an entity type in the authorization policy that is not an entity type listed in an entity type specification of the associated authorization policy schema; and The displayed information indicates the entity type in the authorization policy.

Images