AdmissionWebhooks, send request headers to access client cookies

[fairbairn]

Our application has to do with LLHLS.

We intend to signed URLs through a front-facing CDN, but this is static and set once per the initial playback. These methods are fairly limited to expiration windows, countries, and possibly an IP address.

We want to secure it further with AdmissionWebhooks, but it is still somewhat limited.

Could the AdmissionWebhooks pass over the client cookies used in the request?

We store authentication cookies and would like those available to validate the request by our control server, but the AdmissionWebhooks documentation states that it only passes over a few parameters.

Since we cannot put our data in the CDN side's authentication token, the best approach is to acquire the data from the cookies relating to the user identification and logged in status.

This is the data that passes now.

{
  "client": 
  {
    "address": "211.233.58.86",
    "port": 29291,
    "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36"
  },
  "request":
  {
    "direction": "incoming | outgoing",
    "protocol": "webrtc | rtmp | srt | llhls | thumbnail",
    "status": "opening | closing",
    "url": "scheme://host[:port]/app/stream/file?query=value&query2=value2",
    "new_url": "scheme://host[:port]/app/new_stream/file?query=value&query2=value2",
    "time": ""2021-05-12T13:45:00.000Z"
  }
}

The theory is that the player will make the request using the signed URL that the front-facing CDN will first enforce, but once the request hits the OME Edge server, it will hit our Access Control Server via the AdmissionWebhooks connector.

If the webhook could send over the request headers (which would include the cookies) in the originating request block, we could acquire our encrypted information to validate that the request is from an authorized user on our system.

The suggestion is to add an array of request.headers to the data block above, possibly with an additional configuration rule to include / filter them (as they will make the request size larger).

[getroot]

I'm a bit confused by this.

1. Is it OME Origin -> OME Edge -> CDN configuration? In this configuration, the CDN cannot cache the content. OME Origin -> CDN configuration is the only way to achieve the distributed effect of CDN. If not, why use a CDN?
2. Does the CDN forward cookies to OME? If so, how about that format?

[fairbairn]

We worked around this limitation, by pulling the cookies from code in memory, and adding them as query params on the fly.

You are correct in that it's likely the CDN would not send the cookies (although that's not been verified).

The CDN still works with us adding as query params, because we can customize the VARY parameters and filter it out for cache logic.