Testing your authorization model
To understand the effect of Amazon Verified Permissions authorization decision when you deploy your
application, you can evaluate your policies as you develop them with the Using the Amazon Verified Permissions test bench and with HTTPS REST API requests
to Verified Permissions. The test bench is a tool in the AWS Management Console to evaluate authorization requests
and responses in your policy store.
The Verified Permissions REST API is the next step in your development as you move from a conceptual
understanding to application design. The Verified Permissions API accepts authorization requests with
IsAuthorized, IsAuthorizedWithToken, and BatchIsAuthorized as signed AWS API
requests to Regional service endpoints. To test
your authorization model, you can generate requests with any API client and verify that
your policies are returning authorization decisions as expected.
For example, you can test IsAuthorized
in a sample policy store with the
following procedure.
- Test bench
-
-
Open the Verified Permissions console at Verified Permissions console. Create a policy
store from the Sample policy store with the
name DigitalPetStore.
-
Select Test bench in your new policy store.
-
Populate your test bench request from IsAuthorized in the Verified Permissions API reference. The following
details replicate the conditions in Example 4
that references the DigitalPetStore
sample.
-
Set Alice as the principal. For Principal taking
action, choose
DigitalPetStore::User
and enter
Alice
.
-
Set Alice's role as customer. Choose Add a
parent, choose
DigitalPetStore::Role
, and enter
Customer.
-
Set the resource as order "1234." For Resource
that the principal is acting on, choose
DigitalPetStore::Order
and enter
1234
.
-
The DigitalPetStore::Order
resource requires
an owner
attribute. Set Alice as the owner of
the order. Choose DigitalPetStore::User
and
enter Alice
-
Alice requested to view the order. For Action
that principal is taking, choose
DigitalPetStore::Action::"GetOrder"
.
-
Choose Run authorization request. In an
unmodified policy store, this request results in an ALLOW
decision. Note the Satisfied policy that
returned the decision.
-
Choose Policies from the left navigation bar.
Review the static policy with the description Customer Role - Get
Order.
-
Observe that Verified Permissions allowed the request because the principal was
in a customer role and was the owner of the resource.
- REST API
-
-
Open the Verified Permissions console at Verified Permissions console. Create a policy
store from the Sample policy store with the
name DigitalPetStore.
-
Note the Policy store ID of your new
policy store.
-
From IsAuthorized in the Verified Permissions API reference, copy the
request body of Example 4 that references the
DigitalPetStore sample.
-
Open your API client and create a request to the Regional service
endpoint for your policy store. Populate the headers as shown in the
example.
-
Paste in the sample request body and change the value of
policyStoreId
to the policy store ID you noted
earlier.
-
Submit the request and review the results. In a default
DigitalPetStore policy store, this request returns
an ALLOW
decision.
You can make changes to policies, schema, and requests in your test environment to
change the outcomes and produce more complex decisions.
-
Change the request in a way that changes the decision from Verified Permissions. For example,
change Alice's role to Employee
or change the owner
attribute of order 1234 to Bob
.
-
Change policies in ways that affect authorization decisions. For example,
modify the policy with the description Customer Role - Get
Order to remove the condition that the User
must be
the owner of the Resource
and modify the request so that
Bob
wants to view the order.
-
Change the schema to allow policies to make a more complex decision. Update
the request entities so that Alice can satisfy the new requirements. For
example, edit the schema to allow User
to be a member of
ActiveUsers
or InactiveUsers
. Update the policy so
that only active users can view their own orders. Update the request entities so
that Alice is an active or inactive user.