Skip to main content

Public connectivity (customer-managed)

In the public model you publish the integration target on the internet yourself, and wawa connects to it from its regional egress IPs.

You host and secure it

For public integrations, hosting, securing, patching and monitoring the published endpoint is the clinic's responsibility. wawa cannot take responsibility for infrastructure it does not operate. If you would rather keep the target off the internet, use a Site-to-Site VPN.

What we need from you​

For each integration target:

  • A public URL (hostname) that resolves to a public IP you assigned to that target.
  • The protocol and port. We typically prefer HTTPS; if the target speaks another TCP- or UDP-based protocol, we can add support for it.
  • For HTTPS: a certificate from a public CA, or, if it is self-signed or issued by an internal CA, your internal root CA certificate.
  • Credentials for the target, as listed in the integration's guide.
  • Confirmation that inbound access is restricted to wawa's egress IPs for your region.

What we give you​

  • Our regional egress IPs to allowlist. All wawa connections to your target come from these addresses.

Recommendations​

These are good practice for anything exposed to the internet. They are not a substitute for your own security review.

  • Allow only wawa's egress IPs, and only on the ports the integration uses. Everything else stays closed.
  • Expose only what the integration uses. Publish specific paths or services, not whole servers or admin interfaces. Each integration guide lists what wawa calls.
  • Don't challenge machine traffic. Bot protection, CAPTCHAs, login pages or WAF challenges in front of the target break wawa's requests. Exempt wawa's egress IPs from them.
  • Keep it patched and monitored. Apply security updates to the target and anything in front of it, and alert on failed logins and unusual traffic.
  • Tell us the hostname the server answers to, if it is on shared hosting that routes by name (SNI).
  • Use a dedicated service account for wawa, with a long generated password, rotated at least annually.

Example: HTTPS reverse proxy​

Illustrative only. Adapt it to your environment and security policies. This example publishes a DICOMweb server running on the same host, exposing only the paths wawa uses:

server {
  listen 443 ssl;
  server_name dicom.clinic.example;

  ssl_certificate     /etc/ssl/clinic/fullchain.pem;
  ssl_certificate_key /etc/ssl/clinic/privkey.pem;

  # wawa's regional egress IPs only (example: Europe)
  allow 52.19.76.222;
  allow 52.48.12.42;
  allow 99.81.219.122;
  deny  all;

  location /dicom-web/         { proxy_pass http://127.0.0.1:8042; }
  location /worklists          { proxy_pass http://127.0.0.1:8042; }
  location /changes            { proxy_pass http://127.0.0.1:8042; }
  location /tools/bulk-content { proxy_pass http://127.0.0.1:8042; }
}
Last updated on