[Feature Request] Use the URLPattern API instead of Regular Expressions for Subscriptoin Endpoint Whitelisting

[jmrah]

This feature request is in regards to the current FWOA subscription behaviour

Is your feature request related to a problem? Please describe.

Current behaviour: When a FWOA client creates a Subscription, the FWOA system verifies that the callback URL supplied in Subscription request matches a whitelist of URLs. If it does not match any URL on the whitelist, the request is rejected. This URL whitelist is a configurable list of string literals or regular expressions.

Likewise, when the FWOA is about the send a Subscription notification to a webhook callback, it verifies again that the URL that it is sending to is whitelisted, matching the URL against a string literal or regular expression.

"Problem": Using regular expressions for URL checking works, but:

1. Is too flexible. A regex can be anything, even though ideally the pattern should be constrained to the realm or URLs
2. Complicated, and thus prone to error. It is difficult to get correct, especially when providing patterns for URLS, and can be difficult to understand.

Describe the solution you'd like
Instead of using string literals or regular expressions to provide URL validation for subscription URL webhooks, I am proposing that the URLPattern API be used instead. Here are two brief examples of what that syntax looks like:

• Exact URL match: http://foo.bar.com/baz
• Subdomain and path-part alternatives: http://(foo|fooey).bar.com/*/baz

I think the URLPattern API would be an improvement over stirng literals or regular expresisons because:

1. It is a familiar and supported syntax. Most users immediately recognize and can intuit the glob-like syntax, and its syntax is used in popular server side framework like Express.js.
2. It constrains the patterns to be URL-like, instead of regex-anything.
3. It is easier to write and read than regex
4. It has the flexability to break-out into regex patterns if needed

I would propose using the urlpattern-polyfill library use it with Node.

Describe alternatives you've considered
I have considered the path-to-regex NPM library that the URLPattern API is based on, but dismissed it because that library has no support for the origin part of the URL.

Additional context
In a hypothetical future where FWOA tenants can self-serve their whitelisted Subscription callback URLs, having an easy to use, yet flexible syntax for specifying patterns would be helpful. Thus, although this change is of limited utility now, it would be beneficial in the use case described.

Note: I am working on a PR both against the routing and deployment repositories to implement this change at the moment.

[nguyen102]

Thank you for creating this feature request. We've added it to our team's backlog. Stay tuned!

[nisankep]

FHIR Works on AWS has been moved to maintenance mode. While in maintenance, we will not add any new features to this solution. All security issues should be reported directly to AWS Security at [aws-security@amazon.com] (mailto:security@amazon.com). If you are new to this solution, we advise you to explore using [HealthLake] (https://aws.amazon.com/healthlake), which is our managed service for building FHIR based transactional and analytics applications. You can get started by contacting your AWS Account team. If you are an existing customer
of FHIR Works on AWS, and have additional questions or need immediate help, please reach out to fwoa-migration-support@amazon.com or contact your AWS Account team.