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
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
// 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].
//
// For more information about the Cedar policy language, see the [Cedar Policy Language Guide].
//
// 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.
//
// [Cedar Policy Language Guide]: https://docs.cedarpolicy.com/
// [Amazon Verified Permissions User Guide]: https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/
package verifiedpermissions
|
