Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-1396

Authentication Caching Policy "Allow" returns the first transaction as 403 (Unauthorized) for new keys

    Details

    • Target Release:
    • Steps to Reproduce:
      Hide

      1. In the Admin Portal, configure APIcast for an API as "self-managed" and add a new Caching Policy configured as "Allow".
      2. Launch the APIcast container image (Docker or OpenShift).
      3. Simulate an outage between APIcast and the 3scale Backend after it has started (e.g. block the communication through a firewall rule).
      4. Make a 'curl' call to the APIcast using a key which was not used before the previous step.
      5. After some time, 403 (Unauthorized) will be returned by APIcast.
      6. Make the same 'curl' call again using the same key in the Step 4.
      7. APIcast will return 200 (OK) straight away.

      Repeating the Steps 6. and 7. will provide the same result. Hence, only the first transaction receives 403 (Unauthorized).

      Show
      1. In the Admin Portal, configure APIcast for an API as "self-managed" and add a new Caching Policy configured as "Allow". 2. Launch the APIcast container image (Docker or OpenShift). 3. Simulate an outage between APIcast and the 3scale Backend after it has started (e.g. block the communication through a firewall rule). 4. Make a 'curl' call to the APIcast using a key which was not used before the previous step. 5. After some time, 403 (Unauthorized) will be returned by APIcast. 6. Make the same 'curl' call again using the same key in the Step 4. 7. APIcast will return 200 (OK) straight away. Repeating the Steps 6. and 7. will provide the same result. Hence, only the first transaction receives 403 (Unauthorized).

      Description

      When setting the Authentication Caching Policy to Allow:
      "Allow mode caches both authorized and denied calls. If the policy is running under allow mode, cached calls will continue to be denied or allowed based on cached status. However, any new calls will be cached as authorized."

      Documentation: https://access.redhat.com/documentation/en-us/red_hat_3scale/2-saas/html/deployment_options/apicast_policies#authentication_caching

      And the communication between APIcast and the 3scale Backend suffers an outage, if a new key is used (one which was not used before when the communication was working and hence not cached), the first transaction returns 403 (Unauthorized) and only the following ones returns 200 (OK).

      The expected behavior according to the Documentation would be to receive 200 (OK) starting from the first transaction.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                david_ortiz_l David Ortiz
                Reporter:
                estevao.konecsni Estevao Konecsni
                Tester:
                Jakub Smadis
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: