Tuesday Tip by Vijay Masurkar, Principal Support Engineer, for 10-16-12
The SiteMinder Secure Proxy Server (SPS) is a high-performance proxy gateway that extends the reach of the SiteMinder security architecture by providing a set of deployment options that allow for greater centralization of administration and enable alternative sessioning models. SPS proxy rules control the flow of requests to destination servers. In releases through SPS R12.0 SP3, rules can only be added, deleted or modified by editing proxyrule.xml file.
Forward and Redirect Modes
The SPS proxy rules are dynamic, and when a change is made to the proxyrules.xml it is reflected at the next incoming HTTP request. So, there is no need for a restart of the proxy’s services. The two commonly deployed conditions are URI and HOST. In the example below, the condition (cond) being used is of type URI. The most often used cases are “forward” and “redirect”. In the example below, the condition of URI is used which means the SPS will filter on URI and if there is a match to the case statement for the URI it will execute the forward or redirect below that. So, in the simple example below, /hr will “forward” to hr.company.com and / employee will “redirect” to http://employees.company.com. (More complex rule example will be covered in a later tip.)
<nete:cond type="uri" criteria="beginswith">
<nete:case value="/hr">
<nete:forward>http://hr.company.com$0</nete:forward>
</nete:case>
<nete:case value="/employee">
<nete:redirect> http://employees.company.com$0 </nete:redirect>
</nete:case>
</nete:cond>
Using $1 and $0
The usage of $1 and $0 will depend on the requirements of the backend server the SPS is redirecting to. The purpose of these two parameters is to fill in the URI portion of the request.
Typically for the HOST cond you would want to use $0 , which will concatenate the full URI portion of the incoming request to the backend’s HOST.
www.sps.com/hr will end up looking like www.mybackend.com/hr when $0 is used.
Typically, for the URI ‘cond’ you would want to use $1, which will strip from the URI portion of the incoming request the portion you are matching on; so, leaving the remaining URI for the backend request.
<nete:cond type="uri" criteria="beginswith">
<nete:case value="/foo">
<nete:forward>http://hr.company.com$1</nete:forward>
</nete:case>
www.sps.com/foo/bar will end up looking like www.mybackend.com/bar when $1 is used.
www.sps.com/foo/bar will end up looking like www.mybackend.com/foo/bar when $0 is used.
Enabling Debug
SPS has a debug parameter that can be added to the proxyrules.xml which will log additional information for the FORWARD and REDIRECTS the proxy engine is performing. This can be useful for debugging issues for the proper backend host and uri building to determine that the proper URL’s are being created.
< nete:proxyrules xmlns:nete=http://www.ca.com/ debug=yes >
<nete:forward>http://127.0.0.1:88$0</nete:forward>
</nete:proxyrules>
Other Data Needed for Debug
Depending on the type and complexity of the issue at hand, you will need other data files, logs and traces as well for debugging; such as httpd conf, httpd logs, web server access log, proxy engine conf, proxy engine logs, web agent log and trace log, details of custom filter (if used), truss (system call tracing of process on Unix) of proxy engine, etc.
For functional details, refer to Secure Proxy Server Administration Guide and Release Notes.