A robust gatekeeper implementation requires two areas of customization:

Some applications may be public, read-only services that can safely allow any anonymous client to access them. Other applications may be restricted to privileged clients only, and the application may need to distinguish clients by name.

Client authentication can be handled by the web server, or by the gatekeeper application, or by both, in series.

You can configure the virtual directory through IIS to require client authentication. Basic Authentication requires the client to provide a username and password, which are verified by the web server. If your clients are logged in to the same Windows domain as the web server, you also can use Integrated Windows Authentication, which handles authentication without sending any passwords over the wire.

Client authentication can be handled by your gatekeeper application, based on another username and password pair sent by the client.

When using "http" Routing, the Flags parameter of the RemoteServer Initiate method is used to send usernames and passwords to the web server and gatekeeper. The first username-password pair goes to the web server (and/or proxy server if your organization requires one). The second username-password pair is passed through to the gatekeeper application to be interpreted however necessary.

These four items must be concatenated into a single string for the Flags parameter. To accommodate arbitrary password strings, there is no predetermined delimiter character. The first character of the Flags parameter is taken as the delimiter, which delimits the next four fields.

For example, if you choose the vertical bar (|) as the delimiter, you can pass two pairs of credentials, like this:

If you are not using web server authentication and you need to pass credentials only to the gatekeeper application, you mayleave the first two fields empty:

The gatekeeper application receives the second username-password pair as part of the Initiate HTTP request message. It can then use whatever method it wants to verify those credentials. The example gatekeeper code (see OpenROAD Server .NET Client Gatekeeper Components) shows how you could call an SCP to handle this.

After you decide which clients to allow in, you then must decide which SCPs they should be permitted to call.

The example gatekeeper code shows how you could call an SCP to obtain the list of permitted SCPs for that application. Another alternative (which the demo uses) is to list the permitted SCP names in a special section of the web.config file for that gatekeeper application.