|
|
SAS/IntrNet 9.1: Application Dispatcher |
|
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 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 will contain the special variable that has the correct value.
These requests will pass your initial security check and then 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 make sure 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 will display 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
An Application Broker might be restricted from making requests from an Application Server if the Application Server's request syntax is limited to specific IP addresses.
For example, the Application Broker is started on a machine with IP address 12.34.56.78. The Application Server is started on another machine using the following syntax:
proc appsrv port=5800;
request fromadr=("12.34.56.99");
run;
A request from the Application Broker to this Application Server fails because the Application Broker's IP address does not match the APPSRV FROMADR.
When you start the server, you can optionally specify an administrative password by using the ADMINPW option. For example,
PROC APPSRV PORT=5001 ADMINPW='XXXX' ...
The password must not contain quotation marks. Specifying a password prevents anyone from running administrative programs such as STOP without supplying the password. By using an HTML form that has a password field, as shown in the following example, you can create an administrative interface to the server:
<FORM ACTION= "/cgi-bin/broker" METHOD="POST">
<INPUT TYPE= "hidden" NAME= "_SERVICE" VALUE="default">
<INPUT TYPE="hidden" NAME="_PROGRAM" VALUE="stop">
Password:
<INPUT TYPE="PASSWORD" NAME="_ADMINPW">
<INPUT TYPE="SUBMIT" VALUE="Shut down">
</FORM>
Note: Use METHOD=POST when creating forms that supply passwords to the Application Server. Including the password on a URL by using METHOD=GET or an explicit URL will expose the password in potentially unsecure places such as Web server logs, Application Server logs, history files or bookmark files.
The SAS log exposes programs and input parameters, which could pose a security issue. There are some actions you can take to hide passwords and other sensitive data from the SAS log. Password values are automatically hidden from the Application Server log. You can disable the SAS log with the DebugMask option. You can also use the prefix _NOLOG_ with macro symbols to hide request variable values.
The _NOLOG_ feature enables you to create special macro symbols that can be sent to the Application Server without publishing the macro values in the APPSRV log. The special macro symbols must start with the prefix _NOLOG_. The prefix is case insensitive. For example:
http://yourserver/cgi-bin/broker.exe?_service=default
&_program=test.getEmployeeSalary.sas&_nolog_salary=secretpw
If _NOLOG_SALARY is displayed in the SAS logs, it shows
_NOLOG_SALARY=XXXXXXXX;
Another recommended security measure is to segregate Dispatcher programs from their data. Dispatcher programs should not be placed in libraries along with the data they read and update. If your operating environment allows you to set read and write permissions for specific directories, then specify or assign the Application Server READ access only to all program libraries. Also, it is best to allocate program libraries by using the ACCESS=READONLY option. If any programs need to create or update data sets or files, then READ and WRITE access must be allowed to those data libraries. Though the Dispatcher functions correctly without these security measures, we strongly recommend that you follow these guidelines.
Do not permit unlimited access to existing application libraries. To achieve a high level of security, restrict access to the Dispatcher application libraries only to those developers who should be allowed to modify application code.
The sample programs shipped with SAS/IntrNet are enabled by default. These samples programs include the ability to browse data in any library defined to an Application Server. If you wish to limit access to SAS libraries defined in a server's data libraries, you should disable the sample programs. You can do this by editing the appstart.sas file (or @APSTXn members on z/OS) for the Application Dispatcher service. You must remove or comment out the ALLOCATE LIBRARY statement for the SAMPLIB libref, remove or comment out the ALLOCATE FILE statement for the SAMPLE fileref, and remove SAMPLE and SAMPLIB from the PROGLIBS statement.
To prevent security holes that could be created inadvertently, review any new code or code that has been changed in any way. See the section on Dispatcher Program Security for details about what to look for to find potential problems.
|
|
SAS/IntrNet 9.1: Application Dispatcher |
|