You have many options in this area.

1.) Use IPSec tunneling from the client to the server - this ensures that all
transmissions from the workstation to the remote server on the web is fully
encrypted.

2) Do not use real user name/passwords. Have a single stored procedure on
the server that can only be run under one login(the only thing that login can
do). That stored procedure grabs the encrypted strings passed to it by the
client, decrypts them using Gregory Deatzs FreeUDFLib MD5 routines(I can give
more details if you are interested) and returns the users real login name and
password (encrypted with the same MD5 routines). That way, the users never
know thier true username or password except for that one application.
Meanwhile you get the full benefit of individual user names.
(this is heavily summarized, I can go into more detail if you wish)

3) Local IB database that your client connects to, so you have full IBO
connectivity, then you use one of the many forms of replication to sync your
local copy with the master copy. (depending on your application, this may be
just what you need)

4) Midware solution, like asta.

5) A combination of the above..........

Given the number of possibilities, you have a little bit of research ahead of
you before you make a final decission as to how you are going to implement it.

best regards

Dalton

On Tuesday 29 May 2001 11:41, you wrote:
> I would like to hear comments on the best way to connet remotely to
> an IB server. I am considering IBO over a direct IP connection: My
> test thus far seem quite good but I have heard good things about
> ASTA, specifically IBO/ASTA on the server and a thin ASTA client. I
> suppose I would lose all the closely integrated gui components that
> IBO has to offer if I did it this way.. Any ideas would be greatly
> appreciated. What I hope to hear, of course, is that a direct IP
> connetion with an IBO client over IP is acceptable as that seems to
> be the most cost efficient solution.
>