GateKeeper Guide : Advanced features

Advanced features
This section describes advanced features such as chaining GateKeepers, callbacks, access control, load balancing, fault tolerance and SSL. It also describes the factors that can improve the performance of GateKeeper.
Chaining of GateKeepers
GateKeepers can be chained together to provide paths through the firewalls. There are two types of chaining
Static chaining of GateKeepers
In static chaining, the preceding GateKeeper is configured to forward messages to the next GateKeeper. The communication path is fixed and is therefore static.
Figure 11
In the figure above, two chained GateKeepers are required to communicate across a firewall. The client applet sends messages to GateKeeper1 which will forward the messages across the firewall to GateKeeper2. GateKeeper1 is able to forward the message to GateKeeper2 because it has the Interoperable Object Reference (IOR) of GateKeeper2. The IOR of GateKeeper2 specifies how to send messages from GateKeeper1 to GateKeeper2 and thus crosses the firewall.
Dynamic chaining of GateKeepers
In static chaining, the communication paths are specified in the GateKeeper's IOR. In dynamic chaining, the communication paths are specified in the server's IOR file. The client, if given the server's IOR file, can use the information in the server's IOR to select a path. The client tries the first path and the next if the first path fails, and so forth.
Figure 12
In the figure above, there are two paths from the client to the server. Both paths require chaining of GateKeepers. The two paths are specified in the server's IOR that the client reads, the first path is tried and on failure the second path is tried. The path is chosen dynamically at runtime.
The way to specify the paths to the server is described in “Specifying communication paths to the server”.
Callbacks
In most implementations, requests are initiated by the clients to which the servers reply. There are also implementations where information must arrive at a client that is not in response to a request from the client which can be implemented by creation of callback objects. Callback objects can be implemented in the three methods described below.
Callbacks without GateKeeper
The implementation shown in the following figure is applicable to cases where the client and server can communicate in both directions. In these cases, there are either no intervening firewalls or the intervening firewalls do not hinder the communications between the clients and servers.
Figure 13
In the above example, the client creates an object, starts the listener, generates an IOR and sends a request and IOR to the server. The server calls the client's listeners and creates a callback connection. Subsequently, all messages to the callback objects will be channeled through the callback connection.
Callbacks without GateKeeper using bidirectional GIOP
With bidirectional IIOP, servers use the client-initiated connections to transmit asynchronous information back to the clients. Servers need not initiate any connections to the client.
Figure 14
In the above figure, the client is able to establish a connection directly to the server, but the server is unable to establish a separate callback connection because of an intervening firewall. Therefore, the client and the server negotiate a bidirectional GIOP connection and share the initial connection established by the client for IIOP traffic in both directions.
The CORBA specification also adds a new policy to portably control this feature. For more information about bidirectional communications exclusive of GateKeeper, see the VisiBroker Developer's Guide.
Callback with GateKeeper's bidirectional support
With bidirectional IIOP, servers use the client-initiated connections to transmit asynchronous information back to the clients. Servers need not initiate any connections to the client. The CORBA specification also adds a new policy to portably control this feature. For information about bidirectional communications exclusive of the GateKeeper, see the VisiBroker for Java Developer's Guide or VisiBroker for C++ Developer's Guide for more information.
Figure 15
In the figure above, GateKeeper sits between the client and server and therefore it acts as a server for the client and as a client for the server. The Client/GateKeeper and the GateKeeper/Server communication channels can be set to unidirectional or bidirectional connections.
You can also selectively set the channels to unidirectional or bidirectional. If the client defines vbroker.orb.enableBiDir=client and the server defines vbroker.orb.enableBiDir=server, the following table describes the type of channels for the different values of vbroker.orb.enableBiDir for GateKeeper.
Bidirectional connection example
An example that demonstrates GateKeeper's support for bidirectional connections is located in the examples/vbroker/gatekeeper/bank_bidir subdirectory under the VisiBroker installation.
The Bank BiDir example is similar to the Bank Callback example, except that in the BiDir example, bidirectional connections are established between the client, GateKeeper, and server. In other words, in the bidirectional implementation, the same connection is used for both forward invocations as well as callbacks.
This example demonstrates how to:
The client
In this example, the client Client.java:
1
Creates a callback object on the POA named callback_poa. (This callback object will be invoked by the server through the GateKeeper.)
2
Binds to the AccountManager object.
3
4
Queries the Account object reference obtained for the balance, again passing the callback object (this time it is passed to the balance method).
The server
In the example, the server Server.java:
1
Creates a persistent POA named bank_poa and a transient POA named account_poa with firewall policy value of EXPORT.
2
Creates an instance of the AccountManager servant.
3
4
5
Property file used to configure the bank server. In this example, the server is configured to accept listen points so that the connection between the GateKeeper and the server will be bidirectional. To make the connection unidirectional, either remove the property vbroker.orb.enableBiDir or set the value of this property to none. The other properties in this file are for loading the firewall package and then setting the firewall path so that server-side objects can be bound and called by the client.
Property file used to configure the bank client. In this example, the client is configured to publish its listen points so that the connection between the client and the GateKeeper will be bidirectional. To make the connection unidirectional, either remove the vbroker.orb.enableBiDir property or set its value to none. As with the server, the vbroker.orb.dynamicLibs property is set to load in the necessary firewall library so that the client request can traverse the GateKeepers.
Security considerations
Caution
Use of bidirectional IIOP may raise significant security issues. In the absence of other security mechanisms, a malicious client may claim that its connection is bidirectional for use with any host and port it chooses. In particular, a client may specify the host and port of security-sensitive objects not even resident on its host. In the absence of other security mechanisms, a server that has accepted an incoming connection has no way to discover the identity or verify the integrity of the client that initiated the connection. Further, the server might gain access to other objects accessible through the bidirectional connection. This is why the use of a separate, bidirectional SCM for callback objects is recommended. If there are any doubts as to the integrity of the client, it is recommended that bidirectional IIOP not be used.
For security reasons, a server running VisiBroker for Java will not use bidirectional IIOP unless explicitly configured to do so. The property vbroker.se.<sename>.scm.<scmname>.manager.importBiDir gives you control of bidirectionality on a per-SCM basis. For example, you might choose to enable bidirectional IIOP only on a server engine that uses SSL to authenticate the client, and to not make other, regular IIOP connections available for bidirectional use. (See “Appendix GateKeeper properties” for more information about how to do this.) In addition, on the client-side, you might want to enable bidirectional connections only to those servers that do callbacks outside of the client firewall. To establish a high degree of security between the client and server, you should use SSL with mutual authentication (set vbroker.security.peerAuthenticationMode to REQUIRE_AND_TRUST on both the client and server).
Access control
GateKeeper has a rules-based access controller built into it. This controller can deny or grant accessibility based on:
All rules are evaluated in the order in which you specify them. Action is taken based on the first matched rule. If there is no matched rule, the default action you specify is taken. See , “Appendix GateKeeper properties” for the syntax of the rules.
Custom-designed access control in GateKeeper
GateKeeper lets you plug-in custom designed Access Control mechanisms. The Access Control Manager invokes all Access Controllers specified using GateKeeper properties. The Access Control Manager uses the following interface for implementation of an Access Controller:
package com.inprise.vbroker.gatekeeper.security;
public interface AccessController {
public void init(org.omg.CORBA.ORB orb, String prefix);
}
Access Controllers use the TcpConnectionInfo interface to get more information about the Client:
package com.inprise.vbroker.orb;
public interface TcpConnectionInfo {
public String getLocalHostName();
public int getLocalPortNumber();
public String getHostName();
public int getPortNumber();
public long getTotalBytesRead();
public long getTotalBytesWrote();
public String name();
public java.io.InputStream getInputStream();
public java.io.OutputStream getOutputStream();
}
The Access Control Manager calls the init method to initialize the Access Controller. GateKeeper supports the following types of Access Controller interfaces:
ObjectAccessController: The isObjectAccessible() method is invoked when the client requests GateKeeper to set up a proxy channel (communication path) to the server object. It should return true if the object is accessible:
package com.inprise.vbroker.gatekeeper.security;
import com.inprise.vbroker.orb.TcpConnectionInfo;
import com.inprise.vbroker.IOP.ServiceContext;
public interface ObjectAccessController extends AccessController {
public boolean isObjectAccessible(
TcpConnectionInfo clientInfo,
org.omg.CORBA.Object server,
ServiceContext[] contexts,
byte[] principal);
}
OperationAccessController: The isOperationAccessible() method is invoked when the client sends requests through the GateKeeper. It should return true if a given operation is accessible:
package com.inprise.vbroker.gatekeeper.security;
import com.inprise.vbroker.orb.TcpConnectionInfo;
import com.inprise.vbroker.IOP.ServiceContext;
public interface OperationAccessController extends AccessController{
public boolean isOperationAccessible(
TcpConnectionInfo clientInfo,
TcpConnectionInfo serverInfo,
org.omg.CORBA.Object server,
String operation,
ServiceContext[] services);}
You can program an access controller (for example, myAC) and install it on GateKeeper using following properties:
vbroker.gatekeeper.security.accessControllers=myAC
vbroker.gatekeeper.security.acl.myAC.type=com.inprise.vbroker.gatekeeper.security.myACImpl
vbroker.gatekeeper.security.acl.myAC.rules=
vbroker.gatekeeper.security.acl.myAC.default=grant
An Access Controller can be implemented as follows:
package com.inprise.vbroker.gatekeeper.security;
import java.util.*;
import java.io.*;
import com.inprise.vbroker.orb.TcpConnectionInfo;
import com.inprise.vbroker.orb.ORB;
import com.inprise.vbroker.IOP.ServiceContext;
public class myACImpl implements
ObjectAccessController, OperationAccessController {
public void init(org.omg.CORBA.ORB orb, String prefix) {
}
public boolean isObjectAccessible(
TcpConnectionInfo clt, org.omg.CORBA.Object svr,
ServiceContext[] contexts, byte[] principal) {
return true;
}
public boolean isOperationAccessible(
TcpConnectionInfo clt, TcpConnectionInfo svr,
org.omg.CORBA.Object server, String operation,
ServiceContext[] services) {
return true;
}
}
The access control methods or rules can be defined by the implementation.
Load balancing and fault tolerance
GateKeeper is most often used to provide a single point of access to the internal network, and therefore it can become congested or become the single point of failure. These problems can be resolved by clustering GateKeepers to provide a degree of fault tolerance and scalability.
Load balancing
A master GateKeeper and one or more slave GateKeepers can be clustered together. The master GateKeeper is responsible for balancing the load among the slave GateKeepers. The server should export the master GateKeeper object reference only.
Figure 16
The figure above shows the property setting for GateKeeper1 and the server. The master GateKeeper can balance the load between a slave GateKeepers on a per object level. On the object level, each client will be redirected to one of the slave GateKeepers based on the load balancing policy. In general, this will balance the load more evenly but potentially use more resources and slower.
The default load balance policy is round-robin. This policy, however, can be customized and is available as a standard package. Please contact Micro Focus for more information.
Additionally, GK2 and GK3 can also have their own slave GateKeepers. In this configuration, a hierarchy of master and slaves can be stacked over one another.
Custom-designed load balancing in GateKeeper
The ORB default implementation of load distribution uses the round-robin algorithm in which the client request is shared among a server and GateKeeper in a sequential order. The following code example shows a distributor implementation:
package com.inprise.vbroker.gatekeeper.ext;
import java.util.Enumeration;
import org.omg.Firewall.GIOPProxy;
import com.inprise.vbroker.orb.*;
import com.inprise.vbroker.util.*;

public class MyDistributor implements Distributor {
private Enumeration _enum;
private UnGuardedVector _servers;
public void init(ORB orb, UnGuardedVector v) {
_servers = v;
_enum = servers.elements();
}
public synchronized GIOPProxy next() {
if (!_enum.hasMoreElements()) {
_enum = _servers.elements();
}
return (GIOPProxy)_enum.nextElement();
}
}
The Server Manager can collect current load related information of other GateKeeper instances in a master/slave configuration. Based on the available real-time information from the Server Managers, the master GateKeeper can reallocate client requests to other GateKeepers. In another scenario, a federation of GateKeepers can exchange load-statistics to distribute the load.
Fault tolerance
A master GateKeeper and one or more backup GateKeepers can be clustered together to be viewed as a single GateKeeper by the client. There are two ways to cluster the GateKeepers:
This configuration is accomplished similarly to dynamic chaining of GateKeeper. It requires no changes to the GateKeeper configuration; you only need to configure the server to include all the backup GateKeepers as a firewall path on the server listener. This approach, however, makes the server configuration more complex.
Scalability and performance guidelines
When assessing GateKeeper performance, it is useful to compare a GateKeeper scenario (Client-GateKeeper-Server) to a direct scenario (Client-Server).
Note
Here performance is represented as response time and scalability is represented as throughput.
The GateKeeper scenario requires two connections and thus two invocations. As a result:
Throughput is reduced: It may be reduced by as much as 50 percent when compared to the direct scenario.
Response Time is slowed: Response time will take longer when compared to the direct scenario. In some cases, it may take up to 200 percent longer.
GateKeeper performance tuning
GateKeeper does not introduce any new performance threshold or throughput threshold which means that GateKeeper will have the same performance and throughput profile as the VisiBroker ORB. Because GateKeeper is a CORBA application, it inherits the basic features of the ORB. As such, all ORB specific performance tuning parameters apply to GateKeeper as well. The following areas described below, however, can affect the performance of GateKeeper:
Bidding mechanism
The client-side ORB can be programmed to select specific bids based on the constraints set by the user. The order of selection of bids can be specified to speed up the process of connection establishment:
Constraint on Bid-Portfolio: The following properties are useful for setting exclusive bids in the case of static chaining of GateKeeper:
vbroker.orb.alwaysProxy
vbroker.orb.alwaysTunnel
vbroker.orb.alwaysSecure
For example, the vbroker.orb.alwaysProxy is useful when a specific GateKeeper is statically chained to another GateKeeper. If you are very sure that only HTTP Tunnelling will be used while chaining the GateKeepers, then set vbroker.orb.alwaysTunnel property can be set to avoid unnecessary bids. When the vbroker.orb.alwaysSecure property is set, then the GateKeeper will use secure communication path only while chaining. Please note that these properties are set on the outer GateKeeper.
Order of Bid-Selection: The order of the bid can affect the speed of the selection of a specific bid. For example, if you are certain that most of the connections allowed on a specific GateKeeper will be of a secure type, you can place the SSL as the first entry in the string as follow:
vbroker.orb.bidOrder=inprocess:liop:ssl:iiop:proxy:hiop:locator
Specifying high-precedence Bid: You can set the following property to the highest precedence bid. By default, it is set to inprocess in the ORB:
vbroker.orb.bids.critical=inprocess
Cache management
The following property sets the cache size of GateKeeper:
vbroker.gatekeeper.cache.size=100
Message marshaling
By setting the chunk size of the stream, you can increase the size of messages exchanged between GateKeeper and the client/server application. The chunk size can have significant impact on the performance of the applications, particularly using HTTP Tunnelling:
vbroker.orb.streamChunkSize=4096
You can try using values such as: 4096, 8192, or 16384. The performance of the applications may vary depending on the maximum size of the packets on your network.
Thread management
Depending on the response needs of GateKeeper, different techniques of thread management can be applied, such as thread pooling, thread-per-session, and so forth. By default, the request forwarding IIOP service uses ThreadPool, and the HIOP service uses ThreadSession:
vbroker.se.exterior.scm.ex-iiop.dispatcher.type=ThreadPool
vbroker.se.exterior.scm.ex-iiop.dispatcher.threadMax=100
vbroker.se.exterior.scm.ex-iiop.dispatcher.threadMin=0
vbroker.se.exterior.scm.ex-iiop.dispatcher.threadMaxIdle=300

vbroker.se.interior.scm.in-iiop.dispatcher.type=ThreadPool
vbroker.se.interior.scm.in-iiop.dispatcher.threadMax=100
vbroker.se.interior.scm.in-iiop.dispatcher.threadMin=0
vbroker.se.interior.scm.in-iiop.dispatcher.threadMaxIdle=300

vbroker.se.exterior.scm.ex-hiop.dispatcher.type=ThreadSession
Connection management
The bi-directional GIOP has advantages of using the same communication path for forward and backward communication. Therefore, Micro Focus recommends that you use the vbroker.orb.enableBiDir property setting in callback scenarios. The following properties let you optimize connection resource usage (see “Appendix GateKeeper properties” for more details):
vbroker.se.exterior.scm.ex-iiop.manager.connectionMax
vbroker.se.exterior.scm.ex-iiop.manager.connectionMaxIdle

vbroker.se.interior.scm.in-iiop.manager.connectionMax
vbroker.se.interior.scm.in-iiop.manager.connectionMaxIdle
vbroker.ce.iiop.ccm.connectionMax should not be used in the context of GateKeeper, because GateKeeper should be allowed to connect to as many servers as needed as it is an intermediate service to potentially many clients. GateKeeper must not stop already connected clients from proceeding with connections to servers just because the number of outgoing connections it can open is limited. Instead, GateKeeper can restrict the number of clients it is willing to service using the following property:
vbroker.se.exterior.scm.ex-iiop.manager.connectionMax
vbroker.ce.iiop.ccm.connectionMaxIdle, however, can be used to drop idle connections to servers. This is particularly useful when the number of servers the GateKeeper would potentially connect to is large, the number of connecting clients is small, and the clients mainly target only a few servers.
Impact of asynchronized invocation of GateKeeper
Asynchronized invocation of GateKeeper does not have a very significant impact on performance and scalability.
GateKeeper performance properties
There are many properties that affect GateKeeper's performance. Those properties related to connection, thread type, mode of operation and call type are described here.
For more information, see “Performance and load balancing” for additional properties that can be adjusted for better performance.
Connection settings
Connection related properties of GateKeeper are:
vbroker.se.<xxx>.scm.<yyy>.manager.connectionMax
vbroker.se.<xxx>.scm.<yyy>.manager.connectionMaxIdle
where <xxx> and <yyy> represent “exterior, ex-hiop”, “exterior, ex-iiop”, “exterior, ex-hiops”, “exterior, ex-ssl”, “interior, in-iiop” or “interior, in-ssl”.
The first property specifies the maximum number of active connections allowed. Limiting connections conserves GateKeeper resources, but may decrease client performance. The default is no limit.
The second property specifies how long an inactive connection is idle before it is closed. The default is 0 which means that inactive connections are never closed.
Thread related settings
When the dispatcher type is “ThreadPool”, the following properties of GateKeeper can be modified to fine-tune performance:
vbroker.se.<xxx>.scm.<yyy>.dispatcher.threadMin
vbroker.se.<xxx>.scm.<yyy>.dispatcher.threadMax
vbroker.se.<xxx>.scm.<yyy>.dispatcher.threadMaxIdle
where <xxx> and <yyy> pair is “exterior, ex-iiop”, “exterior, ex-ssl”, “interior, in-iiop” or ”interior, in-ssl”.
The first property ”threadMin” specifies how many threads are pre-created so that requests can be quickly serviced. The default is 0.
The second property ”threadMax” specifies the maximum number of threads that can be created so that the system cannot be overloaded with too many threads. The default is 100. Any request that cannot be serviced because of too few threads will wait for the next available thread.
The third property ”threadMaxIdle” specifies how long (in seconds) a thread is idle before it is destroyed. The default is 300 seconds.
GateKeeper modes
GateKeeper can run in normal and pass-through mode. The pass-through mode has lower performance because the content of the packets is not examined by GateKeeper but still consume GateKeeper's resources. In fact, each pass-through connection needs exclusive ports throughout the life-span of the connections. A client process can request exclusive connection using policies programmatically.
GateKeeper in its normal mode of operation gives the better performance.
The mode is normal unless the pass-through is enabled by setting the property vbroker.gatekeeper.enablePassthru=true.
Call types
There are three types of calls:
Bi-directional callbacks use a single connection for both forward calls and callbacks. It is more efficient than the VisiBroker 3.x style callbacks.
Bi-directional callbacks are as efficient as the normal forward calls.
GateKeeper and SSL
Note
SSL is a separate optional package; therefore for applets and server objects to run in SSL mode, you must have a SSL component included in their ORB runtime.
GateKeeper with SSL provides the following security features:
For more information about SSL, refer to the VisiBroker Security Guide. Additional properties for setting SSL can also be found in “Appendix GateKeeper properties”.
Figure 17
SSL connections to GateKeeper
The server determines if the connection uses SSL or a regular IIOP connection. The client running in SSL mode may request the connection to be SSL. The server running in SSL mode, however, requires the client to connect to it in SSL mode.
If the client sets vbroker.orb.alwaysSecure=true in its property file, it will always connect to the Server or GateKeeper in SSL mode and will not first try other types of connections (which may fail if the Server or GateKeeper does not accept other types of connection). This shortens the time for connections.
Similarly, setting the same property will help GateKeeper when it connects to the Server.
SSL for forward and bidirectional calls
You can set the following GateKeeper properties to enable SSL for calls from the client (applet) to the server object (via the GateKeeper):
vbroker.se.exterior.host = <host address>
vbroker.se.exterior.scms = ex-iiop, ex-hiops, ex-ssl
vbroker.se.exterior.scm.ex-ssl.listener.port = <port address>
The applet client opens an SSL connection to the GateKeeper. The client-GateKeeper communication channel is in SSL mode. However, the mode of the GateKeeper-server communication channel is determined by the server. If the server's scm is set to SSL mode, the GateKeeper-server communication channel will be in SSL mode.
Bidirectional calls use the same forward communication paths. However, there is additional property setting for bidirectional callbacks.
Enabling the Security Service in GateKeeper
While security is turned on by default, this feature applies to the licensing of the Security Service only. There are, however, no license checks to turn on the Security Service.
In VisiBroker the security is turned off by default as specified in the following property:
vbroker.security.disable=true
By setting the following property in VisiBroker, the application will prompt for username and password for authentication:
vbroker.security.login=true
You must create *.config files (examples shown below) to specify the authentication and realm related parameters.
As a generic example of a security enabled GateKeeper, the IIOP, IIOP/SSL, HIOP, and HIOPS listeners have been enabled in the following set of properties:
gatekeeper.config
System
com.borland.security.provider.authn.HostLoginModule required REALM=myrealm PRIMARYIDENTITY=true;

com.borland.security.provider.authn.ClientSideDataCollection required REALM=testrealm;

};
myrealm
com.borland.security.provider.authn.HostLoginModule required;

};

anotherrealm {
com.borland.security.provider.authn.HostLoginModule required;
};
gatekeeper.properties
vbroker.security.disable=false

vbroker.security.peerAuthenticationMode=none

vbroker.security.secureTransport=false

vbroker.security.trustpointsRepository=Directory:./trustpoints

vbroker.gatekeeper.referenceStore=./gkclnt.ior
vbroker.orb.enableBiDir=both

vbroker.orb.dynamicLibs=com.borland.security.hiops.Init

vbroker.se.exterior.scms=ex-iiop,ex-hiop,ex-ssl,ex-hiops
vbroker.se.exterior.host=143.186.142.21
vbroker.se.exterior.scm.ex-iiop.listener.port=25000
vbroker.se.exterior.scm.ex-hiop.listener.port=25001
vbroker.se.iiop_tp.scm.hiop_ts.listener.port=25002
vbroker.se.exterior.scm.ex-ssl.listener.port=25003
vbroker.se.exterior.scm.ex-hiops.listener.port=25004

vbroker.se.interior.scms=in-iiop,in-hiop,in-ssl
vbroker.se.interior.host=143.186.139.226
vbroker.se.interior.scm.in-iiop.listener.port=15001

vbroker.se.interior.scm.in-hiop.listener.port=15002

vbroker.se.interior.scm.in-ssl.listener.port=15003

# Enable callback using this GateKeeper

vbroker.gatekeeper.callbackEnabled=true

# Enable VBJ3.x (old style) callback also
vbroker.gatekeeper.backcompat.callback=true
vbroker.gatekeeper.backcompat.callback.host=143.186.142.21
vbroker.gatekeeper.backcompat.callback.listeners=iiop,ssl
vbroker.gatekeeper.backcompat.callback.listener.iiop.port=16001
vbroker.gatekeeper.backcompat.callback.listener.iiop.type=IIOPCallback
vbroker.gatekeeper.backcompat.callback.listener.ssl.port=16002
vbroker.gatekeeper.backcompat.callback.listener.ssl.proxyPort=0
vbroker.gatekeeper.backcompat.callback.listener.ssl.type=SSLCallback

# Optional: enable GateKeeper specific Access Control properties
vbroker.gatekeeper.security.accessControllers=myAC
vbroker.gatekeeper.security.acl.myAC.default=grant
vbroker.gatekeeper.security.acl.myAC.rules=rule1
vbroker.gatekeeper.security.acl.myAC.rule1=grant [operation=”*”]

# Optional: Identity of GateKeeper

vbroker.security.wallet.identity=<username>
vbroker.security.wallet.password=<password>
vbroker.security.wallet.type=Directory:<path-to-identities>
The property settings in the following example tell the client to specifically request a secure transport using GateKeeper. The client application collects the username and password and sends this conformation to the server via GateKeeper.
client.config
System {
com.borland.security.provider.authn.ClientSideDataCollection required REALM=myrealm;
};

Client {
com.borland.security.provider.authn.ClientSideDataCollection required;
};
client.properties
  vbroker.security.disable=false
vbroker.security.login=true
vbroker.security.authentication.callbackHandler=com.borland.security.provider.authn.HostCallbackHandler
vbroker.security.authentication.config=client.config

vbroker.orb.dynamicLibs=com.inprise.vbroker.firewall.Init
vbroker.se.iiop_tp.scms=iiop_tp,ssl
vbroker.orb.alwaysProxy=true
vbroker.orb.alwaysSecure=true
The property settings in the following example disables the IIOP listener and the server is assumed to be a secure application that uses SSL transport only:
server.config
System {
com.borland.security.provider.authn.HostLoginModule required REALM=myrealm PRIMARYIDEHostITY=true;
com.borland.security.provider.authn.ClientSideDataCollection required REALM=testrealm;
};

myrealm {
com.borland.security.provider.authn.HostLoginModule required;
};

anotherrealm {
com.borland.security.provider.authn.HostLoginModule required;
};
server.properties
vbroker.security.disable=false
vbroker.security.login=true
vbroker.security.authentication.callbackHandler=com.borland.security.provider.authn.HostCallbackHandler
vbroker.security.authentication.config=server.config

vbroker.orb.dynamicLibs=com.inprise.vbroker.firewall.Init
vbroker.orb.exportFirewallPath=true

vbroker.se.iiop_tp.host=143.186.142.21

vbroker.se.iiop_tp.scm.iiop_tp.listener.type=Disabled-IIOP
vbroker.se.iiop_tp.scm.iiop_tp.listener.port=25000
vbroker.se.iiop_tp.scm.ssl.listener.port=25005

vbroker.se.iiop_tp.firewallPaths=intranet
vbroker.firewall-path.intranet=first,second

vbroker.firewall-path.internet=first
vbroker.firewall.first.type=PROXY
vbroker.firewall.first.ior=http://localhost:16085/gatekeeper.ior

vbroker.firewall.second.type=TCP
vbroker.firewall.second.host=192.75.11.14
vbroker.firewall.second.iiop_port=32000
vbroker.firewall.second.hiop_port=32001
vbroker.firewall.second.ssl_port=32005
Enabling access to the Naming Service through GateKeeper
To start the Naming Service on a fixed IP address and port, you must set the following properties. In the following example, the Naming Service is running on the IP host address: 143.186.142.21 and listener port: 32101:
namingservice.properties
vbroker.agent.addr=143.186.142.21
vbroker.agent.port=25873
vbroker.orb.logger.output=ns_debug.log

vbroker.naming.logLevel=7
vbroker.naming.iorFile=ns.ior

vbroker.orb.dynamicLibs=com.inprise.vbroker.firewall.Init
vbroker.se.iiop_tp.host=143.186.142.21
vbroker.se.iiop_tp.scm.iiop_tp.listener.port=32010
gatekeeper.properties
vbroker.agent.addr=143.186.142.21
vbroker.agent.port=25873
vbroker.agent.enableLocator=false

vbroker.orb.initRef=NameService=corbaloc::143.186.142.21:32010/NameService
vbroker.gatekeeper.referenceStore=gkclnt.ior
vbroker.se.exterior.host=143.186.142.21
vbroker.se.interior.host=143.186.139.226
vbroker.se.exterior.scm.ex-iiop.listener.port=25000
vbroker.se.exterior.scm.ex-hiop.listener.port=25001
vbroker.se.iiop_tp.scm.hiop_ts.listener.port=25002