By enabling
Web-server authentication for the Application Broker executable file,
your Web server can pass the user ID of the client to the Application
Broker in the REMOTE_USER environment variable. By exporting this
environment variable, you can pass the remote-user value to SAS as
the macro variable _RMTUSER. Then your application can use the value
of this variable to activate or de-activate various application features.
Note: You cannot trust that the
Application Broker that is connected to your Application Server is
the same Application Broker that is executed on your Web server machine.
It is possible that another Web server, or a user running the Application
Broker from an operating system command prompt, could make a connection
to your Application Server and supply a bogus value for REMOTE_USER.
In other words, there is not a strong coupling between the Application
Broker and the Application Server to ensure the transmission of a
security context.
This is not to say that Web server
authentication and the REMOTE_USER value are worthless. On the contrary,
they are quite valuable as long as their reliability has not been
compromised. One way to repair the security model outlined above is
to create a strong coupling between the Application Broker and Application
Server. If you can ensure that the only Application Broker that can
run programs on your Application Server is the same Application Broker
that you are authenticating on your Web server, then REMOTE_USER is
a trustworthy value.
You can use the
ServiceSet directive in the
Application Broker configuration
file to define a variable name and
a constant value. For example,
SocketService default "Default service"
Server appsrv.yourcomp.com
Port 5001
ServiceSet passkey "some value that is hard to guess"
With each request to the specified service, the Application
Broker passes all the normal application data and the additional variable
defined by using ServiceSet to the Application Server. In this example,
each request would contain the name/value pair
passkey=some
value that is hard to guess
. You can check the value
of this special variable within your Application Server program. If
the value of this variable passed to your program does not match the
value that you assigned in the configuration file, then you can refuse
the request because it violates your security model. Any requests
that perform the required Web server authentication contain the special
variable that has the correct value. After these requests pass your
initial security check, you can trust the value of _RMTUSER.
Because the Application
Broker merges exported environment variables and variables created
by using the Set directives after the Web server receives the request
from the Web browser, there is no fear of the special variable appearing
in the URL or in the Web server log files. In this example, only the
Application Server sees the variable PASSKEY and its value.
There are some important caveats to this technique. Placing this
"secret" value in the
Application Broker configuration
file means that you must protect the
configuration file and ensure that no one can read its contents. The
"secret" variable and its value must be treated like a password. Secondly,
you need to disable the _DEBUG=1 flag by using the DebugMask directive.
This debug flag displays the "secret" variable and its value in the
Web browser of the user along with the reset of the data for the request.
You also have to include the "secret" variable and its value in your
program code. This means that you have to restrict access to your
program code just as you restricted access to the configuration file.
See also Protecting the Application Broker Configuration File.