Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

authproxy: MDM device identity authenticated HTTP requests #80

Merged
merged 13 commits into from
Aug 28, 2023

Conversation

jessepeterson
Copy link
Member

@jessepeterson jessepeterson commented Jul 14, 2023

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 verify CheckInURL and ServerURL 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:

  • The request has a certificate (either the Mdm-Signature header or the passed-in certificate with -cert-header)
  • The request's certificate was issued from a CA that NanoMDM trusts (-ca switch)
  • The request's certificate matches any previously enrolled MDM device enrollment (by the cert's SHA-256 hash).

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:

  • Docs (Operations Guide)
  • Test(s)

http/authproxy/authproxy.go Outdated Show resolved Hide resolved
http/authproxy/authproxy.go Outdated Show resolved Hide resolved
storage/storage.go Outdated Show resolved Hide resolved
http/mdm/mdm_cert.go Show resolved Hide resolved
@jessepeterson jessepeterson merged commit 62a372a into micromdm:main Aug 28, 2023
4 checks passed
@jessepeterson jessepeterson deleted the authproxy branch August 29, 2023 18:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant