Working Around SiteMinder 500 Errors for Unauthorized Federation Service Provider Access

Overview: SiteMinder provides federation capabilities for SAML (and other protocols). SiteMinder's federation capabilities are accessed through a set of web services installed with the Web Agent Option Pack. The federation web service throws a 500 error instead of automatically redirecting the user for re-authentication like a standard SiteMinder Web Agent when the user has a valid SiteMinder session, but is not authorized to access the configured SAML Service Provider. This can be worked around in a couple of ways, but one way to handle this is to leverage the federation 500 error redirect to automatically redirect the user to a page which logs the user out and then redirects back to the federation URL.

The following is required for this configuration:

  1. Custom redirect page that takes the federation POST variables and redirects the user back to the sent SPID. This page should be placed on a web server with an installed SiteMinder Web Agent.
  2. Configure the redirect page as the logoff URI within the agent’s configuration object (ACO).
  3. Set the custom error page as the Server Error URL in the Additional URL Configuration section on the Advanced tab of the SAML service provider configuration dialog.

Custom Redirect Page: The custom redirect page can be an ASP, ASP.NET, JSP or any other dynamic page that can take POST parameters, parse them and redirect the user back to a URL. The following ASP code is an example of a page that takes the information from SiteMinder and redirects the user back to the federation URL:

Dim relaystate, spid, fedurl, redirecturl

if relaystate = "" Then
End If

<title>Redirect Page</title>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<% Response.Redirect(redirecturl) %>

To use this code, set the fedurl variable to the base federation URL for the environment. The page should then be dropped on a server with a SiteMinder Web Agent in an unprotected folder. For example in a folder like:

<WWW root>redirectlogoffredirect.asp  (is the file was an ASP named logoffredirect.asp)

where <WWW root> is the base document folder for the web server site.

Configure the Page as the LogoffUri Agent Parameter: Setting the custom redirect page as the logoffUri for SiteMinder ensures that the SiteMinder session is ended so that when the user is redirected page to the federation URL they will then be prompted to log in again. In the example above, the URI for the page is /redirect/logoffredirect.asp. To add this:

  1. Open the Agent Config Oject (ACO) for the Web Agent  installed on the server with the custom redirect page.
  2. Uncomment the LogoffUri parameter and add the URI (not URL) for the custom redirect page.
  3. Save the ACO.

The configuration change will be automatically picked up be the agent. In this example, the ACO looks like the following image:

Set the Server Error URL: Once the custom error page is deployed and configured as the LogoffUri, the next steps is to tell SiteMinder to redirect to this page when the user would normally receive a 500 error from the federation web service. While we are using to redirect the 500 error thrown when a user is not authorized, this has the side effect of sending all 500 errors to the redirect page. This may or may not be an issue in your environment. To configure the Server Error URL:

  1. Open the SiteMinder FSS Administrative UI.
  2. Click on the Domains tab.
  3. Open the federation domain.
  4. Click on the SAML Service Providers left-nav item.
  5. Open the Service Provider configuration.
  6. Click on the Advanced tab.
  7. Click the [Custom Error URL Config] button.
  8. Check the Enable Server Error URL checkbox.
  9. Enter the URL for the custom redirect page (e.g.
  10. Change the drop-down to Http Post.
  11. Save the configuration.

Setting the drop-down to Http Post is required so that the necessary information is sent to the redirect page. This allows the redirect page to redirect the user back to the correct Service Provider configuration. Making the redirect page dynamic ensures that a common redirect page can be used for multiple Service Provider configurations.