API for Amazon Verified Permissions¶

ABAP Package	`/AWS1/API_VPS_IMPL`
ABAP SDK "TLA"	`VPS`
ABAP Interface	`/AWS1/IF_VPS`

The "TLA" is a Three Letter Abbreviation that appears in ABAP class names, data dictionary objects and other ABAP objects throughout the AWS SDK for SAP ABAP. The TLA for Amazon Verified Permissions is VPS. This TLA helps squeeze ABAP objects into the 30-character length limit of the ABAP data dictionary.

Installation¶

To install the AWS SDK for SAP ABAP, import the Core transport, along with the transport for the VerifiedPermissions module and other API modules you are interested in. A few modules are included in the Core transport itself. For more information, see the Developer Guide guide.

About The Service¶

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.

Using the SDK¶

In your code, create a client using the SDK module for Amazon Verified Permissions, which is created with factory method /AWS1/CL_VPS_FACTORY=>create(). In this example we will assume you have configured an SDK profile in transaction /AWS1/IMG called ZFINANCE.

DATA(go_session)   = /aws1/cl_rt_session_aws=>create( 'ZFINANCE' ).
DATA(go_vps)       = /aws1/cl_vps_factory=>create( go_session ).

Your variable go_vps is an instance of /AWS1/IF_VPS, and all of the operations in the Amazon Verified Permissions service are accessed by calling methods in /AWS1/IF_VPS.

API Operations¶

For an overview of ABAP method calls corresponding to API operations in Amazon Verified Permissions, see the Operation List.

Factory Method¶

`/AWS1/CL_VPS_FACTORY=>create( )`¶

Creates an object of type /AWS1/IF_VPS.

IMPORTING¶

Optional arguments:¶

`IV_PROTOCOL` `TYPE /AWS1/RT_PROTOCOL` `/AWS1/RT_PROTOCOL`¶

`IO_SESSION` `TYPE REF TO /AWS1/CL_RT_SESSION_BASE` `/AWS1/CL_RT_SESSION_BASE`¶

`IV_REGION` `TYPE /AWS1/RT_REGION_ID` `/AWS1/RT_REGION_ID`¶

`IV_CUSTOM_ENDPOINT` `TYPE /AWS1/RT_ENDPOINT` `/AWS1/RT_ENDPOINT`¶

RETURNING¶

`OO_CLIENT` `TYPE REF TO /AWS1/IF_VPS` `/AWS1/IF_VPS`¶

/AWS1/IF_VPS represents the ABAP client for the VerifiedPermissions service, representing each operation as a method call. For more information see the API Page page.

Configuring Programmatically¶

DATA(lo_config) = DATA(go_vps)->get_config( ).

lo_config is a variable of type /AWS1/CL_VPS_CONFIG. See the documentation for /AWS1/CL_VPS_CONFIG for details on the settings that can be configured.

Paginators¶

Paginators for Amazon Verified Permissions can be created via get_paginator() which returns a paginator object of type /AWS1/IF_VPS_PAGINATOR. The operation method that is being paginated is called using the paginator object, which accepts any necessary parameters to provide to the underlying API operation. This returns an iterator object which can be used to iterate over paginated results using has_next() and get_next() methods.

Details about the paginator methods available for service Amazon Verified Permissions can be found in interface /AWS1/IF_VPS_PAGINATOR.