PingAuthorize

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

  1. 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" }. The sub field of the access token corresponds to the HttpRequest.AccessToken.subject Trust Framework attribute that your policy uses to make its decision.

  2. As an experiment, edit the access token value in curl to change the sub 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.