Re: Intercepting SQL*NET
Date: 13 Dec 1994 19:41:10 GMT
Message-ID: <3cktcm$jm_at_taquito.abq.bdm.com>
jwheat (jwheat_at_bftzha8) wrote:
: The question is: Is it possible/pratical to intercept SQL*NET (ORASRV) at
: or prior to connect time and issue a system call? We need to make an API
: call to the Secuity Dynamics software to validate the card number and
: PIN. If the user fails the authentication, we need to be able to stop the
: database connection. ORASRV seems to bypass the INETD Deamon - Can anyone
: confirm or deny this?
: We have implemented a similar solution for DAL/INFORMIX by intercepting
: the INETD and passing the information to REXEC and then make the API call
: to the Secuity Dynamics software.
: Oracle marketing has indicated that they are prepared to implement such a
: feature in a future version of SQL*NET, but we have an immediate need.
: Please post your replies to this group.
: Thanks, in advance
: Jon Wheat
Yes, it is possible to intercept SQL*NET at or prior to connect time to issue a system (or other) call. We were trying to address a similar problem with SQL*Net for TCP/IP where we wanted to force operating-system level authentication before the client successfully established a connection with the Oracle server process. In this case, Oracle was running on a VAX 8820 running VMS with TGV's TCP/IP protocol stack. We wrote a custom listener process for incoming connections on a port other than port 1525 (the port that is commonly used with SQL*Net version 1). We modified the the client TCP/IP services file to call that port also for SQL*Net connections.
The code parsed the incoming packets, got the user id from the SQL*Net connect string, and forced OS-level authentication at that point. If the user was successfully authenticated, the listener process passed the packets back and forth between Oracle's listener process on port 1525 and the client. The disadvantage of this approach is that it introduced additional overhead which resulted in a noticeable performance degradation. We eventually rejected this approach because we were not willing to take the performance hit and we did not want to code the custom listener process at a lower level to see if we could improve performance (we were using TGV's socket library). Received on Tue Dec 13 1994 - 20:41:10 CET