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.
-
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" ] } } }'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" }. Thesubfield of the access token corresponds to theHttpRequest.AccessToken.subjectTrust Framework attribute that your policy uses to make its decision. -
As an experiment, edit the access token value in curl to
change the
subvalue 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" ] } } }'The HTTP response status should now be
201 Created.To better understand how policy decisions work, see For further consideration: Decision Visualiser.