Skip to content

Latest commit

 

History

History
145 lines (115 loc) · 8.51 KB

3.7.caching.md

File metadata and controls

145 lines (115 loc) · 8.51 KB
Raw

Caching

Saving the best for last, oh my! So for a whole bunch of reasons, we wound up with our own caching solution instead of the Mixer's. (Lucky us, fun times.) Fingers crossed, our caching should be decent enough for most scenarios but time will tell. If you dig deep into the adapter logs, you should be able to see that it caches calls to DAPS and AuthZ. A DAPS ID token gets cached for the amount of time specified in the JWT exp field whereas there's more to caching of AuthZ decisions than meets the eye:

  • A decision gets cached for t seconds where t is the least of: consumer JWT expiry (computed from exp in DAPS token), user JWT expiry (computed from exp in KeyRock token), and the configured maximum in the adapter's config—i.e. the value of cache_decision_max_seconds.
  • Caching takes into account all call inputs so if you change JWTs or HTTP method/path, etc. even slightly the adapter will ask again his boss AuthZ for permission.

For example, if you look at the logs to see what happened while the adapter serviced the last call we made to Orion, you should be able to spot an entry similar to

AuthZ
Request: &{
  Daps: {
    ConnectorID: 4e16f007-d959-4eb2-b47d-78dd0c4eab0e
    Issuer: https://daps.aisec.fraunhofer.de
    Membership: true
    Scopes: [ ids_connector ids_scope_pseudo_second_element ]
    SecProfile: map[
      audit_logging: 2
      pseudo_second_element: ids_security_profile_pseudo_second_element
      ]
  }
  KeyRock: {
    AppID: 7bc2b735-7fdd-40ea-8cb2-acae9b241ca7
    AppAzfDomain: wCIwcYFkEeqBNVYbm7c9rA
    Roles: [ role1 role3 role4 ]
  }
  FiwareService: service
  RequestPath: /v2/
  RequestVerb: GET
}
Decision: Permit
Caching: decision saved to cache

Ah, AuthZ's decision got cached. Try the same call again now and then you should see a cache hit

AuthZ
  Request: ...
  Decision: Permit (cached)

So far so good, but let's try something trickier. The token below is the same as the KeyRock JWT we used just now except it doesn't have an exp claim—same same but different...

$ export USER_JWT=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJvcmdhbml6YXRpb25zIjpbeyJpZCI6IjA5ZDQzOTVlLTkzMWMtNDc1Yy1hNzIzLWFmMzYyYjU2M2IxMSIsIm5hbWUiOiJPcmcyIiwiZGVzY3JpcHRpb24iOiJPcmcyIiwid2Vic2l0ZSI6bnVsbCwicm9sZXMiOlt7ImlkIjoiYTg1ZTg3ZjgtYjdlOC00NTdlLWFhYjEtZmJjM2E0ZTg4MTg1IiwibmFtZSI6InJvbGUzIn1dfSx7ImlkIjoiM2FlNmEzYTMtNTFmNS00MDI1LTk4YzMtOWNlYWViNTNjMGIyIiwibmFtZSI6Ik9yZzEiLCJkZXNjcmlwdGlvbiI6Ik9yZzEiLCJ3ZWJzaXRlIjpudWxsLCJyb2xlcyI6W3siaWQiOiI5MmMyZDM3Zi01ODBiLTQ3YmEtOTE3OC1kOWNhOGVjMTIzNzgiLCJuYW1lIjoicm9sZTQifSx7ImlkIjoiYTg1ZTg3ZjgtYjdlOC00NTdlLWFhYjEtZmJjM2E0ZTg4MTg1IiwibmFtZSI6InJvbGUzIn1dfV0sImRpc3BsYXlOYW1lIjoiIiwicm9sZXMiOlt7ImlkIjoiOTNjOWU1MDMtMDVlNi00ZmFmLTllNTQtNDUzMWMwOTQ4YzYyIiwibmFtZSI6InJvbGUxIn0seyJpZCI6IjkyYzJkMzdmLTU4MGItNDdiYS05MTc4LWQ5Y2E4ZWMxMjM3OCIsIm5hbWUiOiJyb2xlMyJ9XSwiYXBwX2lkIjoiN2JjMmI3MzUtN2ZkZC00MGVhLThjYjItYWNhZTliMjQxY2E3IiwidHJ1c3RlZF9hcHBzIjpbXSwiaXNHcmF2YXRhckVuYWJsZWQiOmZhbHNlLCJpbWFnZSI6IiIsImVtYWlsIjoiYWxpY2UtdGhlLWFkbWluQHRlc3QuY29tIiwiaWQiOiJhZG1pbiIsImF1dGhvcml6YXRpb25fZGVjaXNpb24iOiIiLCJhcHBfYXpmX2RvbWFpbiI6IndDSXdjWUZrRWVxQk5WWWJtN2M5ckEiLCJlaWRhc19wcm9maWxlIjp7fSwiYXR0cmlidXRlcyI6e30sInVzZXJuYW1lIjoiYWxpY2UiLCJ0eXBlIjoidXNlciIsImlhdCI6MTU4NzIwNjYzNn0.cDwmiYvxVZONMKHSJpE1UAJZdqHSMTzZ-PRchvdv1jE

and if we curl the same request again

$ curl -v "${ORION_BASE_URL}/v2/" \
       -H "header:${HEADER_VALUE}"  \
       -H "X-AUTH-TOKEN:${USER_JWT}" \
       -H "Fiware-Service:service"

this time the log message should read

AuthZ
  Request: ... same as earlier ...
  Decision: Permit
  Caching: decision not saved to cache

Uh, what's that "decision not saved to cache"? Why?! Well without an exp field, you can't expect calls to get cached, can you? Adapter the Constable rightly refuses to make any assumptions about expiry of a token without an exp field. Likewise, if the idea of accidentally caching AuthZ decisions for too long gives you the chills, we've got a piece-of-mind configuration knob you can turn to shorten the amount of time the adapter can reuse a cached decision. Remember the cache mechanics explanation? Well, cache_decision_max_seconds does exactly what it says on the tin and can help put your mind to rest when you have a sneaking suspicion DAPS and KeyRock are having a bit of a cavalier attitude to token expiry, setting exp too far in the future. Here are valid DAPS and KeyRock JWTs expiring in 2052:

$ export DAPS_JWT=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRlZmF1bHQifQ.eyJpZHNfYXR0cmlidXRlcyI6eyJzZWN1cml0eV9wcm9maWxlIjp7ImF1ZGl0X2xvZ2dpbmciOjIsInBzZXVkb19zZWNvbmRfZWxlbWVudCI6Imlkc19zZWN1cml0eV9wcm9maWxlX3BzZXVkb19zZWNvbmRfZWxlbWVudCJ9LCJtZW1iZXJzaGlwIjp0cnVlLCJpZHMtdXJpIjoiaHR0cDovL3NvbWUtdXJpIiwidHJhbnNwb3J0X2NlcnRzX3NoYTI1OCI6ImJhY2I4Nzk1NzU3MzBiYjA4M2YyODNmZDViNjdhOGNiODk2OTQ0ZDFiZTI4YzdiMzIxMTdjZmM3NTdjODFlOTYifSwic2NvcGVzIjpbImlkc19jb25uZWN0b3IiLCJpZHNfc2NvcGVfcHNldWRvX3NlY29uZF9lbGVtZW50Il0sImF1ZCI6IklEU19Db25uZWN0b3IiLCJpc3MiOiJodHRwczovL2RhcHMuYWlzZWMuZnJhdW5ob2Zlci5kZSIsInN1YiI6IkM9REUsTz1GSVdBUkUsT1U9Q1RPSURTQSxDTj00ZTE2ZjAwNy1kOTU5LTRlYjItYjQ3ZC03OGRkMGM0ZWFiMGUiLCJuYmYiOjE1ODgxNjMyODMsImV4cCI6MjU4ODE2Njg4M30.dOnaOtKU6P-UM9xx_xiEaNGQhm6UFdh-AVTmL9Op6_S0LukNOnstkZVLl6yxq077QS-t0lGFjj7ofRL-q6YS2yEfK8JsZ45pynQJz-uIUo85GuHadmtuP-ODHsxFO5-qyzIXcswM8c4aTaJfW6Mi_WZ7hp2yoJPEFhlPPBwHGhExTV_vLmdTEBcGpNdK90j-rcsZSq0K5MOLAVwbQunxoke8b8DZjtIdbOwqm5l7D0banGYfKRUd3r2aFwp2OhcrSb-XeP_kFB9sYZKSimKOJOREJphrTG92XVdFu5Hls3Bwtc7i8QLJwwn-HVHHxWMD2ghzBF0mmGLodvWQNik7ww
$ export HEADER_VALUE=$(sh scripts/idsa-header-value.sh "${DAPS_JWT}")
$ export USER_JWT=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJvcmdhbml6YXRpb25zIjpbeyJpZCI6IjA5ZDQzOTVlLTkzMWMtNDc1Yy1hNzIzLWFmMzYyYjU2M2IxMSIsIm5hbWUiOiJPcmcyIiwiZGVzY3JpcHRpb24iOiJPcmcyIiwid2Vic2l0ZSI6bnVsbCwicm9sZXMiOlt7ImlkIjoiYTg1ZTg3ZjgtYjdlOC00NTdlLWFhYjEtZmJjM2E0ZTg4MTg1IiwibmFtZSI6InJvbGUzIn1dfSx7ImlkIjoiM2FlNmEzYTMtNTFmNS00MDI1LTk4YzMtOWNlYWViNTNjMGIyIiwibmFtZSI6Ik9yZzEiLCJkZXNjcmlwdGlvbiI6Ik9yZzEiLCJ3ZWJzaXRlIjpudWxsLCJyb2xlcyI6W3siaWQiOiI5MmMyZDM3Zi01ODBiLTQ3YmEtOTE3OC1kOWNhOGVjMTIzNzgiLCJuYW1lIjoicm9sZTQifSx7ImlkIjoiYTg1ZTg3ZjgtYjdlOC00NTdlLWFhYjEtZmJjM2E0ZTg4MTg1IiwibmFtZSI6InJvbGUzIn1dfV0sImRpc3BsYXlOYW1lIjoiIiwicm9sZXMiOlt7ImlkIjoiOTNjOWU1MDMtMDVlNi00ZmFmLTllNTQtNDUzMWMwOTQ4YzYyIiwibmFtZSI6InJvbGUxIn0seyJpZCI6IjkyYzJkMzdmLTU4MGItNDdiYS05MTc4LWQ5Y2E4ZWMxMjM3OCIsIm5hbWUiOiJyb2xlMyJ9XSwiYXBwX2lkIjoiN2JjMmI3MzUtN2ZkZC00MGVhLThjYjItYWNhZTliMjQxY2E3IiwidHJ1c3RlZF9hcHBzIjpbXSwiaXNHcmF2YXRhckVuYWJsZWQiOmZhbHNlLCJpbWFnZSI6IiIsImVtYWlsIjoiYWxpY2UtdGhlLWFkbWluQHRlc3QuY29tIiwiaWQiOiJhZG1pbiIsImF1dGhvcml6YXRpb25fZGVjaXNpb24iOiIiLCJhcHBfYXpmX2RvbWFpbiI6IndDSXdjWUZrRWVxQk5WWWJtN2M5ckEiLCJlaWRhc19wcm9maWxlIjp7fSwiYXR0cmlidXRlcyI6e30sInVzZXJuYW1lIjoiYWxpY2UiLCJ0eXBlIjoidXNlciIsImlhdCI6MTU4NzIwNjYzNiwiZXhwIjoyNTg3MjEwMjM2fQ.hbOxwJjmJ6P9654kedT0GqnbjvvtmIKPldONvV1JP9U

Now edit deployment/sample_operator_cfg.yaml to set a 5 second max for AuthZ decision caching

params:
  authz:
    cache_decision_max_seconds: 5

then save and apply the new settings

$ kubectl apply -f deployment/sample_operator_cfg.yaml

Finally ask Orion what are the available API endpoints

$ curl -v "${ORION_BASE_URL}/v2/" \
       -H "header:${HEADER_VALUE}"  \
       -H "X-AUTH-TOKEN:${USER_JWT}" \
       -H "Fiware-Service:service"

wait (exactly!) one second and then make the same call again. The adapter log should report

AuthZ
  Request: ...
  Decision: Permit
  Caching: decision saved to cache

AuthZ
  Request: ...
  Decision: Permit (cached)

The adapter cached the decision for the first call and reused it in the second call since 5 seconds haven't gone by so the cache entry is still valid. But if you wait another 5 seconds and curl the same request once more, this time you should find the adapter made a fresh call to AuthZ since the previously cached decision is now stale

AuthZ
  Request: ...
  Decision: Permit
  Caching: decision saved to cache

How much can you shrink cache_decision_max_seconds? The lowest possible value is 0, in which case, the adapter won't cache AuthZ decisions. Try this: set it to 0, apply the new setting (kubectl apply) and curl the same request again. The log should report a decision of Permit but say it wasn't saved to the cache. So if the same request comes in again, the adapter will have to call AuthZ again.