There is an external Load Balancer (Akamai/BigIP/etc.) and is sending the actual user IP address in the 'X-Forwarded-For' header.
When users login to Multi Factor Authentication (MFA) enabled Application via SiteMinder and VIP Authentication Hub, the SiteMinder side audit log shows the correct user IP address but on the VIP Authentication Hub side the log is empty or wrong.
Following is Elastic Search for [ appName.keyword :"Demo" ]
| Time | txnId | msg | errorMsg | api | clientId | appName | clientIp | userIp |
|----------------------------+-------+---------------------------+----------+-----------------------+----------+---------+---------------+--------|
| Jan 1, 2022 @ 12:34:56.123 | <id> | User with login id | - | /auth/v1/authenticate | <id> | Demo | 192.168.0.100 | - |
| | | '<name>@example.org' | | | | | | |
| | | provisioned into internal | | | | | | |
| | | store successfully with | | | | | | |
| | | internal userid '<id>' | | | | | | |
Note the "ClientIP" is not the UserIP. "UserIP" is empty.
Cause
Prior to VIP Authentication Hub 2022.Oct, the VIP Authentication Hub doesn't pickup custom IP headers such as X-Forwarded-For or True-User-IP.
Prior to VIP Authentication Hub 2022.Oct, the VIP Authentication Hub doesn't pickup custom IP headers such as X-Forwarded-For or True-User-IP.
The header "X-Forwarded-For" at the Akamai/BigIP/etc. LoadBalancer should be configured, to pass on the user IP to the VIP Authentication Hub. It will then capture the User IP.
The VIP Authentication Hub does get IP addresses from proxied X-Forwarded-For provided the header exists.
If the Nginx ingress was configured as per deployment documentation (1), it should already be configured to proxy real IP, provided from the Load Balancer in front of it has the real IP protocol enabled.
The first step is to discover what IP addresses are seen by the VIP Authentication Hub. This is done by executing a public discovery call which returns IP addresses as seen by AH. This highly useful IP checking operation (2):
https://<host>/<tenant>/.well-known/openid-configuration?sspinfo=true
The last lines of the response will show what VIP Authentication Hub thinks the "clientIp" and "userIp" are:
"clientIp": "198.51.100.1",
"userIp": "198.51.100.1"
Knowing the IP's as seen by the VIP Authentication Hub will help to steer the next steps in the right direction.
For VIP Authentication Hub prior 2022.Oct:
The following steps need to be performed when VIP Authentication Hub is lower than 2022. Oct to update the configuration to read the XFF header. Version 2022. Oct and higher have the configuration as per documentation when deploying the Ingress Controller (1).
# kubectl get configmap ingress-nginx-controller -n ingress -o yaml > ingress-nginx-controller.yaml
apiVersion: v1
data:
use-forwarded-headers: “true”
allow-snippet-annotations: “true”
annotation-value-word-blocklist: load_module,lua_package,_by_lua,location,root,proxy_pass,serviceaccount,{,},’,\
kind: ConfigMap
metadata:
name: ingress-nginx-controller
namespace: ingress
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/version: 1.1.1
helm.sh/chart: ingress-nginx-4.0.16
# kubectl apply -f ingress-nginx-controller-update.yaml -n ingress
Following warning message may be displayed but can be ignored.# kubectl apply -f ingress-nginx-controller-update.yaml -n ingress
Warning: resource configmaps/ingress-nginx-controller is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply.
kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply.
The missing annotation will be patched automatically.
configmap/ingress-nginx-controller configured