To access the default HTTP headers, you can extract their values from the environment and display them using an ASP script.
To use an ASP script to return SiteMinder variables, your script has to include the ALL_HTTP header, which retrieves all the environment variables, and code that parses out the SiteMinder variables. Use the following script as an example.
<HTML>
<HEAD><TITLE> Test Web Agent Headers </TITLE></HEAD>
<BODY BGCOLOR=#ffffff>
<TABLE BORDER=1>
<TR><TD VALIGN=TOP><B>Variable</B></TD><TD VALIGN=TOP><B>Value</B></TD></TR>
<% For Each key in Request.ServerVariables %>
<TR>
<TD><% = key %></TD>
<TD>
<%
if Request.ServerVariables(key) = "" Then
if GetAttribute(key) = "" Then
Response.Write " " ' To force border around table cell
else
Response.Write GetAttribute(key)
end if
else
Response.Write Request.ServerVariables(key)
end if
Response.Write "</TD>"
%>
</TR>
<% Next %>
</TABLE>
<% Function GetAttribute(AttrName)
Dim AllAttrs
Dim RealAttrName
Dim Location
Dim Result
AllAttrs = Request.ServerVariables("ALL_HTTP")
RealAttrName = AttrName
Location = instr(AllAttrs, RealAttrName & ":")
if Location <= 0 then
GetAttribute = ""
Exit Function
end if
Result = mid(AllAttrs, Location + Len(RealAttrName) + 1)
Location = instr(Result, chr(10))
if Location <= 0 then Location = len(Result) + 1
GetAttribute = left(Result, Location - 1)
End Function %>
When a SiteMinder Web Agent receives a request that follows an initial request by that same user, the Agent validates the session cookie sent with the subsequent request by comparing the IP address of the requesting user with the IP address encrypted inside the session cookie. The address inside the cookie is generated by the Agent during the user’s initial request.
Mechanisms used to balance and manage incoming network traffic, such as firewalls, load balancers, cache devices, and proxies can alter the user’s IP address or make it appear as if all incoming requests are coming from a single or small group of IP addresses. As a result, the Web Agent’s IP checking becomes ineffective. The Web Agent can now perform IP checking in these network environments using a custom HTTP header and a configurable list of safe proxy IP addresses.
The following table lists the terminology for new IP checking functionality.
|
Term |
Definition |
|---|---|
|
HTTP Request Header |
A name/value pair that describes a single element of an HTTP request. |
|
Custom IP Header |
A user-defined HTTP request header used by intermediate HTTP network applications or hardware devices to store the requestor’s IP address. |
|
IP Checking |
Feature that enables the Web Agent to check requests for authenticity by comparing the REMOTE_ADDR in the request with the REMOTE_ADDR value stored in the SMSESSION cookie, after an initial request. This feature is also known as IP validation. |
|
REMOTE_ADDR |
web server variable representing the IP address of the HTTP client making a request to the web server. Also known as REMOTE_IP or CLIENT_IP. This differs from the Requestor IP Address when a proxy server, NAT firewall, or other network service or device sits between the requestor and the target web server. |
|
Requestor |
The initiator of an HTTP request, typically a user at a browser. |
|
Requestor IP Address |
The IP address of the user making the original HTTP request. |
|
Single Sign-on |
Feature that requires a user to enter credentials for secure access to a protected Web site only once during a session. |
|
SMSESSION cookie |
HTTP mechanism used by Web Agents to track single sign-on state. |
The Web Agent can now use a custom HTTP header to determine a user’s IP address instead of using the REMOTE_ADDR variable. If a proxy or other device sets a custom client IP header and the Web Agent is configured to look for that header on an incoming request, the Agent uses that header as the source of the client IP information.
In addition to configuring a custom header, you can set up a list of proxy IP addresses. If the REMOTE_ADDR matches an address in the proxy list, the Web Agent retrieves the user’s IP address from the custom header. Otherwise, the user’s IP address is obtained from the REMOTE_ADDR.
After the Web Agent resolves the requestor’s IP address, the address is stored and used for request processing. If an address cannot be resolved, the IP address is set to unknown.
The Web Agent logs where the client IP address was resolved from to facilitate any debugging that may be necessary.
You can implement IP‑address checking using the following parameters:
Specifies an HTTP header for which the agent searches to find the IP address of the requestor. If no value is specified for this parameter, the default is an empty string. No maximum length is enforced and the value can be any string that contains a valid HTTP header value.
Default: No
Example: HTTP_ORIGINAL_IP
Specifies the IP address of a proxy (such as a cache device) that requires the use of a custom HTTP header. This custom header helps the agent resolve the IP addresses of the requester.
Default: No default
Limits: The string must contain an IP address. Do not use server names or fully qualified DNS host names.
Specifies if the agent validates the IP address of the client. When this value is set to yes, the agent validates that the IP address in the browser cookie matches the IP address of the client. If the addresses do not match, a 403 error message appears in the browser of the user. If the cookie does not contain an IP address, then users are prompted for their credentials.
Default: No (client IP addresses not validated).
Note: These settings are independent of the TransientIPCheck and PersistentIPCheck parameters.
In an environment of 6.x QMR 2 or 3 Web Agents and older Agents, single sign-on may be affected if IP checking is configured.
Web Agents prior to v6.x QMR 2 and 5.x QMR 7 will not be able to resolve the requestor IP address and as a result, SMSESSION cookies created by those Web Agents may be discarded by 6.x QMR 2 or 3 Web Agents. This includes custom Agents using the SDK to generate SMSESSION cookies, Application Server Agents, and any other SiteMinder Agents in a single sign-on environment that use SMSESSION cookies.
Conversely, 6.x QMR 2 and 3 Web Agents may resolve a requestor’s IP address, which then differs from the address resolved by an older Agent.
You can configure the Web Agent to save existing HTTP headers instead of replacing them when new headers are created. This feature is useful for applications that generate multiple SiteMinder responses with the same name but with different values, and need to be included in headers. If there are multiple instances of the same HTTP header, the web server handles this by generating a single header with all the relevant header values separated by commas.
By default, the Web Agent does not preserve headers as a precaution against applications using the wrong header values. For Oracle iPlanet, Domino, and Apache Web Agents to preserve HTTP headers, set the PreserveHeaders parameter to yes. The default value is no.
You can control how the Web Agent handles cache-related request headers by setting the following parameter:
Specifies whether the web agent removes the following cache-related HTTP headers from protected-resource requests before passing those requests to the web server:
This setting affects whether a browser uses cached pages. This setting does not affect auto-authorized resources (including values in the IgnoreExt parameter). The settings of the web server and browser determine whether auto-authorized resources are cached.
This parameter uses the following values:
Important! When this parameter is set to yes, pages of personalized applications lacking the appropriate cache control headers could possibly be cached. This situation introduces unexpected behavior and allows a browser to save sensitive data to the disk.
For terminated sessions, the browser does not use cached content. The value of the AllowCacheHeaders parameter is ignored.
The settings of this parameter affect the following parameters:
Default: No
Limits: Yes, No, None
To remove all cache related headers from protected and unprotected resources, set the value of the AllowCacheHeaders parameter to none.
Note: For more information about HTTP 1.1 caching mechanisms, see RFC 2616, Section 13 "Caching in HTTP."
If you have server applications that are case-sensitive, you can specify the case of the Agent’s HTTP headers. The Web Agent defaults to lower case headers.
For example, Oracle iPlanet web servers, by default, provide the HTTP header variables in lower-case, such as http_sm_user.
Note: IIS Web Agents do not benefit from this feature, because IIS forces all headers to an upper case format.
To use lower case headers, set the LowerCaseHTTP parameter to yes. If you require upper-case header variables, set LowerCaseHTTP to no.
|
Copyright © 2012 CA.
All rights reserved.
|
|