authproxy: MDM device identity authenticated HTTP requests #80
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Declarative Device Management has introduced the concept of an "MDM" Authentication style for asset URLs. For example:
https://github.com/apple/device-management/blob/b838baacf2e790db729b6ca3f52724adc8bfb96d/declarative/declarations/assets/credential.acme.yaml#L43-L57
So for content we want to protect this means we need to authenticate the MDM client identity certificate coming into the MDM server. However because file (or other content) serving is out of scope for NanoMDM we implement this as reverse proxy. When you specify the
-authproxy
switch on the command line with a URL (or use the relevant HTTP handlers in code) NanoMDM transparently authenticates the incoming HTTP request using MDM style authentication (in the same way we verifyCheckInURL
andServerURL
connections) then proxy the request to the URL provided in the command line switch.The proxy URL in the default server is at
/authproxy/
. So if you request/authproxy/foo/bar
and you specified-authproxy 'http://[::1]:9008'
the server will append/foo/bar
to the end of the authproxy URL to come up with:http://[::1]:9008/foo/bar
.The pre-proxy verification involves a few checks:
Mdm-Signature
header or the passed-in certificate with-cert-header
)-ca
switch)If these conditions are met we allow the request to reach the reverse proxy and be passed on. We set the
X-Enrollment-Id
header on the outgoing request to let the target HTTP server know what enrollment ID of the device is trying to connect to it.Internally this is implementation as another method on the storage backends to lookup an enrollment ID based on certificate hash, an authenticating middleware HTTP handler, and, of course, the reverse proxy itself.
Still TODO: