1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
// Code generated by smithy-go-codegen DO NOT EDIT.
// Package verifiedpermissions provides the API client, operations, and parameter
// types for Amazon Verified Permissions.
//
// Amazon Verified Permissions is a permissions management service from Amazon Web
// Services. You can use Verified Permissions to manage permissions for your
// application, and authorize user access based on those permissions. Using
// Verified Permissions, application developers can grant access based on
// information about the users, resources, and requested actions. You can also
// evaluate additional information like group membership, attributes of the
// resources, and session context, such as time of request and IP addresses.
// Verified Permissions manages these permissions by letting you create and store
// authorization policies for your applications, such as consumer-facing web sites
// and enterprise business systems. Verified Permissions uses Cedar as the policy
// language to express your permission requirements. Cedar supports both role-based
// access control (RBAC) and attribute-based access control (ABAC) authorization
// models. For more information about configuring, administering, and using Amazon
// Verified Permissions in your applications, see the Amazon Verified Permissions
// User Guide (https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/) .
// For more information about the Cedar policy language, see the Cedar Policy
// Language Guide (https://docs.cedarpolicy.com/) . When you write Cedar policies
// that reference principals, resources and actions, you can define the unique
// identifiers used for each of those elements. We strongly recommend that you
// follow these best practices:
// - Use values like universally unique identifiers (UUIDs) for all principal
// and resource identifiers. For example, if user jane leaves the company, and
// you later let someone else use the name jane , then that new user
// automatically gets access to everything granted by policies that still reference
// User::"jane" . Cedar can’t distinguish between the new user and the old. This
// applies to both principal and resource identifiers. Always use identifiers that
// are guaranteed unique and never reused to ensure that you don’t unintentionally
// grant access because of the presence of an old identifier in a policy. Where you
// use a UUID for an entity, we recommend that you follow it with the // comment
// specifier and the ‘friendly’ name of your entity. This helps to make your
// policies easier to understand. For example: principal ==
// User::"a1b2c3d4-e5f6-a1b2-c3d4-EXAMPLE11111", // alice
// - Do not include personally identifying, confidential, or sensitive
// information as part of the unique identifier for your principals or resources.
// These identifiers are included in log entries shared in CloudTrail trails.
//
// Several operations return structures that appear similar, but have different
// purposes. As new functionality is added to the product, the structure used in a
// parameter of one operation might need to change in a way that wouldn't make
// sense for the same parameter in a different operation. To help you understand
// the purpose of each, the following naming convention is used for the structures:
//
// - Parameter type structures that end in Detail are used in Get operations.
// - Parameter type structures that end in Item are used in List operations.
// - Parameter type structures that use neither suffix are used in the mutating
// (create and update) operations.
package verifiedpermissions
|
