Symantec Access Management

Hi All,

I am trying to fetch the Client's IP in order to generate SMSession for the User. I tried request.getRemoteAddr(), however it only gives the Proxy/lb IP not the Original IP of the client.

I have also tried to fetch from the Header (X-Forwared-For) & CustomIPHeader, both are coming as null. I tried setting CustomIpHeader in the ACO parameter, still it didn't work.

I am making AgentAPI.login call and need the IP address.

Siteminder Version R12.52

Appreciate your inputs.

Thanks,

Priyotosh

The client IP address parameter to the AgentApi login call is just for logging/informational purposes, so any value will work.

However, if you want the policy server logs to reflect the real user's IP Address, then you should talk to the network administrator about getting the user's device IP Address to be passed through the network's firewalls/proxies/load balancers, etc.

No, the Client IP can also be used to perform Transient/Persistent IP checking. It is not just for loggin/information purpose.

Thanks Ujwol. Looks "X-Forwarded-For" header is set in the LB. But still I am not able to fetch it from request Header.

I will do some more digging and let you all know, how it goes.

Thanks,

Priyotosh

Thanks for bringing up the Transient/Persistent IP checking Ujwol, that certainly applies to web agents. And come to think of it, for web agents the IP can also be used in policies to limit authorization by workstation IP address.

But when writing custom agents, in practice I don't remember ever setting workstation IP. So what I should have said is that the user's IP address MAY only be used for logging purposes, depending upon how the agent is used and how the data the agent provides is used in policies.

In any event, the issue has probably nothing to due with SiteMinder, and can't be fixed by changing any SiteMinder configuration. The problem is most likely a firewall/proxy/load balancer issue and any of those devices that are used must be configured to pass through the user's IP address in a way that can be accessed by standard header variables.

But Priyotosh, before you contact the network administrators, you need to ask yourself how the IP address is going to be used and whether or not you really even need it.

Rick

Thanks Rick for your response. We need the client IP for logging/auditing purpose.

Priyotosh, I second what Richard Siek said above. It's not a programming issue. You need to work with your network administrator to make sure you get what you need in the X-Forwarded-For, the original Requester IP.

With all the settings mentioned in the product documentation for CustomIPHeader, you still won't get the original Requester IP in the X-Forwarded-For because intermediate devices (proxies, etc.) may add their own IP to  X-Forwarded-For (as AB has mentioned), and that's when CA SSO reports it cannot determine.  There's a reason, and it has to do with a well-known vulnerability that CA SSO doesn't want to deal with when there're multiple IP's in the X-Forwarded-For.

When what's in ProxyDefinition matches what's coming out of the REMOTE_ADDR header (i.e. the last Proxy or intermediate device as Ujwol said), it will pick up what's in the X-Forwarded-For; and that's the original Requester IP because all others should be removed (or not added) when the request reaches the CA SSO agent. 

Best Wishes.

- Vijay

Hi Priyotosh,

When smsession cookie is created it first check for sm_client_ip header. If this value in null it takes proxy  IP as that value.

Can you check with other IP Checking parameters TransientIPCheck or PersistentIPCheck  and see once.

Thanks.

Hi Priyotosh,

Did you try fetching like below ?

String remoteAddr = request.getOriginalRequest().getRemoteAddr();

Thanks,

Sharan

Tried that too. But could not get the result.

Thanks

Thanks Krishna, I have tried setting TransientIPCheck, but still could not fetch the header.

I will let you know how it goes.

Thanks

Hi Priyotosh,

To my understating your configuration is as below:

Client (browser) --> Proxy  --> SiteMinder Web Agent

Now, if you try to read the REMOTE_ADDR header on the Web Agent side, it is expected that this will give you proxy IP.

To be able to read the original client IP (browser IP) , you will need to configure your Proxy to pass this as a X-Forwarded-For header (or any other custom header). Only then you will be able to read the same at the web agent side.

For e.g.

• If you are using F5 as LB/Proxy , you will need to enable X-Forwarded-For as per this guide :https://support.f5.com/csp/article/K4816 
• If you are using Apache as reverse proxy, mod_proxy_http by default adds X-Forwarded-For header.

Hope this helps.

Regards,

Ujwol

My experience these days is that IP checking is pretty much useless.  Proxies, load balancers etc. (very few setup x forwarded for correctly) Then when you come from mobile channels the mobile providers have ways to route your requests differently so the user IP address can even change during a session.    

Plus if you are trying to get the IP address of the original device (almost impossible unless you run client code on the device) for the purpose of using IP address checking, the ip address will appear to not be the same as the actual IP address since SSO IP checking looks at the network layer not the device itself.  -- This is why we introduced the Device DNA feature of 12.52 where SSO runs code in the browser to collect a bunch of client side information to create the Device DNA.