I'm pretty new to Oracle so bear with me if I'm asking a silly question :-)
I'm using Oracle Database 11g Enterprise Edition (184.108.40.206.0) under RedHat ES Linux 6.3 (x86_64) and I've been asked, for security reasons, to filter access to the dbase based on both username and client IP addresses.
By editing SQLNET.ORA and adding the "TCP.VALIDNODE_CHECKING = YES" along with the TCP.INVITED_NODES one I've been able to restrict access to only the nodes listed in the last parameter but the idea would be to further check the provided DB username and DENY/ALLOW access based on both the username and the client IP address.
I can change neither the client application nor the GRANTs given at the DB level so I was thinking about the LISTENER process.
Assuming it really makes sense to restrict on the combination of both (that generally implies that you have other problems-- users having the passwords to application accounts, for example, that allow them to theoretically log in to the database as a privileged application user from their desktop, for example) the simplest approach would be to create a login trigger that checks both the IP address and the username (and whatever else you'd like) and to throw an error if you get an invalid combination. For most situations, that is "good enough". A login trigger won't really stop a determined attacker who can always do things like IP address spoofing to get around your trigger. But it will generally stop Timmy the Developer from logging in from his desktop "just to make a quick fix" rather than going through proper channels.
If you want to spend some money, you should also be able to implement this sort of policy using Database Vault but that's another product to license and install. If you're trying to lock down privileged user accounts (i.e. DBAs) or your policies get more involved or you need to defend against determined attackers rather than misguided users, it may be worth looking in to.
A login trigger could be a good idea; I'm also thinking about enabling RADIUS authentication on the LISTENER so that, assuming it could send the IP address of the remote client to the RADIUS server, the latter could grant/deny access given the username/IP combo.