Testing the policy by making an HTTP request
Having tested the policy from the Policy Editor to prove the policy works as intended, we can confirm that policy enforcement from end-to-end by sending an HTTP request through the PingAuthorize Server reverse proxy.
Steps
-
Send a request using
curl
.curl --insecure --location --request POST 'https://localhost:7443/meme-game/api/v1/games' \ --header 'Authorization: Bearer { "active": true, "sub": "user.99@example.com" }' \ --header 'Content-Type: application/json' \ --data-raw '{ "data": { "type": "game", "attributes": { "invitees": [ "user.99@example.com" ] } } }'
Result:
You should receive an error response with a response status of
403 Forbidden
.The request has an access token value of
{"active": true, "sub": "user.99@example.com"}
. Thesub
field of the access token corresponds to the HttpRequest.AccessToken.subject Trust Framework attribute that your policy uses to make its decision. -
As an experiment, edit the access token value in
curl
to change thesub
value to an email address for a different domain. What should happen with this new request?Send a request using
curl
.curl --insecure --location --request POST 'https://localhost:7443/meme-game/api/v1/games' \ --header 'Authorization: Bearer { "active": true, "sub": "user.99@my-company.com" }' \ --header 'Content-Type: application/json' \ --data-raw '{ "data": { "type": "game", "attributes": { "invitees": [ "user.99@example.com" ] } } }'
Result:
The HTTP response status should now be
201 Created
.To better understand how policy decisions work, see For further consideration: Decision Visualiser.