Okta | Use X-Forwarded-For header to forward user's IP address
#2882
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
coldlink
changed the title
X-Forwarded-For header to forward users ip address …X-Forwarded-For header to forward user's IP address
coldlink
force-pushed
the
mm/okta-ip-address
branch
from
5af5f27
to
c58733a
Compare
coldlink
requested review from
guardian-ci
and removed request for
guardian-ci
coldlink
commented
Sep 6, 2024
| export const defaultHeaders = { | ||
| Accept: 'application/json', | ||
| 'Content-Type': 'application/json', | ||
| export const defaultHeaders = (ip?: string) => { |
There was a problem hiding this comment.
This is the main change for the Okta API side, to convert defaultHeaders to a function that takes the ip
coldlink
commented
Sep 6, 2024
Comment on lines
+134
to
+159
| const ProfileOpenIdClient = (ip?: string) => { | ||
| const client = new OIDCIssuer.Client({ | ||
| client_id: okta.clientId, | ||
| client_secret: okta.clientSecret, | ||
| redirect_uris: Object.values(ProfileOpenIdClientRedirectUris), | ||
| }); | ||
|
|
||
| // Make sure we forward the IP address to Okta by adding it to the headers in the library calls | ||
| // https://github.com/panva/node-openid-client/blob/main/docs/README.md#customizing | ||
| // eslint-disable-next-line functional/immutable-data | ||
| client[custom.http_options] = (_, options) => { | ||
| // Add the IP address to the headers | ||
| const headers = options.headers || {}; | ||
| if (ip) { | ||
| // eslint-disable-next-line functional/immutable-data | ||
| headers['X-Forwarded-For'] = ip; | ||
| } | ||
|
|
||
| return { | ||
| ...options, | ||
| headers, | ||
| }; | ||
| }; | ||
|
|
||
| return client as OpenIdClient; | ||
| }; |
There was a problem hiding this comment.
and the stuff in this file too for the openid-client
coldlink
requested review from
guardian-ci
and removed request for
guardian-ci
coldlink
force-pushed
the
mm/okta-ip-address
branch
from
ddc9d5c
to
5e5b2a4
Compare
coldlink
requested review from
guardian-ci
and removed request for
guardian-ci
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What does this change?
Okta support IP address forwarding if we're running Okta behind an reverse proxy, which we are with Fastly.
https://developer.okta.com/docs/reference/core-okta-api/#ip-address
We can use the
X-Forwarded-Forheader to forward the user's IP address to Okta, which should mean that events in the system log, threat detection (based on ip), and rate limiting, should be specific to the user, rather than generic Fastly IP addresses.This PR adds the IP address and forwards to Okta where possible.
We may also need to make Gateway's public IP addresses in the allowlist in the okta's network security settings as a trusted proxy to forward the user's original IP address with the
X-Forwarded-ForHTTP header: https://github.com/guardian/identity-platform/pull/761We've also added the IP address to the routing logs, so we can use this to help debug issues by IP address, and tie the request id to an IP address making debugging easier.
e.g.
{"ip":"::ffff:127.0.0.1","level":"info","message":"GET, /signin","request_id":"283433f8-d6ed-4a5d-9928-a224ba41a75c"}Tested