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.

Sign up for GitHub

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

Jump to bottom

fix the toc for securing webhooks #2759

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix the toc for securing webhooks #2759

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions astro/src/content/docs/_shared/_securing_http_requests.mdx
View file
Open in desktop
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be awesome to correct this name to _securing-http-requests.mdx to conform to our standards.

Original file line number Diff line number Diff line change
@@ -1,11 +1,11 @@
---
---
### TLS v1.2
## TLS v1.2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This breaks the outline of the two other places this is used

grep -Rl _securing_http_requests
./extend/events-and-webhooks/securing.mdx
./lifecycle/migrate-users/connectors/generic-connector.mdx
./customize/email-and-messages/generic-messenger.mdx

Suggest we keep it at an h3 and add another header in there. I can take a swing at this if you'd like. (We need to add in the webhook signing section anyway.)

The first step in securing your {props.request_entity}s is to ensure that they are using TLS v1.2 or higher. You should be using a web server that is configured with a certificate from a valid certificate authority and to only receive traffic from a secure connection. We also recommend that you disable all older secure protocols including SSL, TLS 1.0 and TLS 1.1.

If you need a certificate, most cloud providers offer them or you can use LetsEncrypt to generate a certificate and ensure it is always up-to-date.

### Headers
## Headers
When you configure your {props.request_entity} with FusionAuth, you should include a security header of some kind. There are two ways to define a security header:
* Add a Basic Authentication username and password under the **Security**
* Define an HTTP header under the **Headers** tab
Expand All @@ -32,17 +32,17 @@ router.route('/fusionauth-${props.request_entity_lc}').post((req, res) => {
</code>
</pre>

### Certificates
## Certificates
You may provide an X.509 certificate to use with your {props.request_entity}. {props.ssl_certificate_sentence}. It is used to establish a TLS connection to the {props.request_entity} endpoint. Use this option if FusionAuth cannot connect to your {props.request_entity} without the certificate.

Providing this certificate will build a custom SSL context for requests made for the {props.request_entity}. Therefore, any other JDK keystores and certificate authority chains will be bypassed for this request.

### Firewalls
## Firewalls
In addition to using TLS and a security header, you might also want to put a firewall in front of your {props.request_entity}. In most cases, this firewall will only allow traffic to your {props.request_entity} that originated from your FusionAuth instance. Depending on how you are hosting your {props.request_entity}, you might be able to lock down the URL for your {props.request_entity} specifically. You might also leverage an API gateway or a proxy to ensure that only traffic coming from FusionAuth is routed to your {props.request_entity}. The exact specifics of deploying and configuring a Firewall are outside the scope of this document, but you can consult the documentation for your proxy, API Gateway or hosting provider to determine how to manage it.

As an example, you can configure an AWS Application Load Balancer so that traffic coming from the IP address of your FusionAuth servers with a URL of <code>{`https://apis.mycompany.com/fusionauth-${props.request_entity_lc}`}</code> is routed through. You can then configure the Application Load Balancer so that all other traffic to that URL is rejected.

### Controlling Traffic with a Proxy
## Controlling Traffic with a Proxy

Since version `1.31.0`, FusionAuth can be configured to send all outbound HTTP traffic, including that from a {props.request_entity}, through a proxy. This allows you examine any messages sent from FusionAuth. You can audit them, only allow connections to certain hosts, or otherwise modify them.

Expand Down
4 changes: 3 additions & 1 deletion astro/src/content/docs/extend/events-and-webhooks/securing.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,10 +4,12 @@ description: Learn how to secure your Webhooks so that events coming from Fusion
navcategory: developer
section: extend
subcategory: events and webhooks
nestedHeadings: true
---
import SecuringHttpRequests from 'src/content/docs/_shared/_securing_http_requests.mdx';
import * as securing from 'src/content/docs/_shared/_securing_http_requests.mdx';

## Securing Webhooks
export const headings = securing.getHeadings();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to do this for the other two places we include this file?


FusionAuth sends JSON events to your configured Webhooks that might include user information or other sensitive data. Therefore, it is important to ensure that your Webhooks are secured properly to prevent data from being leaked or stolen.

Expand Down
Loading