Web Agent Guides › Web Agent Configuration Guide › Single Sign-On (SSO) › How to Configure Single Sign-On › Set a Time-out for Saved Credentials

Set a Time-out for Saved Credentials

When a user chooses to have credentials saved, the Policy Server instructs the Web Agent to create a persistent cookie containing the user’s credentials. The cookie allows Web Agents to authenticate a user based on the credentials saved in the cookie, instead of challenging the user to authenticate. You can control how long the persistent cookie remains with the following parameter:

SaveCredsTimeout

Specifies the number of hours that a persistent cookie containing the user credentials will be saved. During this time interval, the Web Agent authenticates the user with the data stored in the cookie. After this time interval expires, the cookie is removed and the Web Agent challenges the user again.

Default: 720 (30 days)

To set a timeout for saved credentials, enter the number of hours you want in the SaveCredsTimeout parameter.

Note: For more information, see the Policy Server documentation.

How to Enforce Timeouts across Multiple Realms

User session timeouts are governed by the realm that the user first logs into. If a user enters a new realm through single sign-on, the time-out values for the new realm are still governed by the session that was established by the initial login at the first realm. If you have different time-out values for different realms, and you want to have each realm use its own time-out values, you can override the time-outs of the original realm.

A user who has already timed out cannot log in to another realm without being rechallenged. For example, if the Idle Timeout in Realm1 is 15 minutes and the Idle Timeout in Realm2 is 30 minutes, a user who accumulates 20 idle minutes in Realm1 will be challenged upon logging in to Realm2.

To override the time-outs of the original realm, configure your Web Agent and realms as described in the following process:

1. Set the value of the EnforceRealmTimeouts parameter to yes.
2. Use the Administrative UI to do the following tasks:
   1. For each realm where you want to supersede the original time-outs (any realm that SSO functionality allows the user to access), do the following:
      • To override the Maximum Timeout value, create a response using the WebAgent-OnAuthAccept-Session-Max-Timeout response attribute.
      • To override the Idle Timeout value, create a response using the WebAgent-OnAuthAccept-Session-Idle-Timeout response attribute.
   2. Bind each of the previous responses to an OnAuthAccept rule.

   Note: For information about creating responses, see the Policy Server Configuration Guide.

Redirect a User after a Session Time-out

Session time-outs are set when you configure a realm with the Administrative UI. When a user’s SiteMinder session times out, the Web Agent does one of the following actions:

• Rechallenges the user for credentials
• Redirects the user to another URL

If a redirect URL is specified, the user is sent to that destination page. If the page is unprotected, the user is granted direct access to that page. If the page is protected, the user is challenged for credentials before being granted access to the page. If no redirection URL has been specified, the Web Agent rechallenges the user for credentials after a session time-out.

You can redirect users whose sessions time out to a URL with a customized web page, which explains why their session has been terminated and how they can reestablish it. For example, you can create a custom web page that displays a message such as, "You have been logged out automatically as a security precaution. Please login again to continue."

If the user is not redirected to another page after a session times out, SiteMinder challenges the user again. This may confuse users because they may not understand why they are being asked to reauthenticate.

To redirect users to different URLs after session time-outs

1. Add the following parameters to your Agent Configuration Object or your local configuration file:

   IdleTimeoutURL

   Specifies the URL where the Web Agent should redirect the user when the idle time-out for the session occurs.

   Example: http://example.mycompany.com/sessionidletimeoutpage.html

   Note: IdleTimeoutURL should only be used for non-persistent sessions; it has no effect if configured for persistent sessions.

   MaxTimeoutURL

   Specifies the URL where the Web Agent should redirect the user when the maximum time-out for the session occurs.

   Example: http://example.mycompany.com/maxtimeoutpage.html

   Default: No default

2. Enter one URL for each of the previous parameters. You can use the same URL for all of the parameters, or you may use different URLs for each.

   If the idle timeout and maximum timeout values for a session (set in the Policy Server) occur at the same time and the IdleTimeoutURL and MaxTimeoutURL parameters are set, the user is redirected to the URL specified in the MaxTimeoutURL parameter when a time-out occurs.

Protect Session Cookies from Misuse with Validation Periods and Expired Cookie URLs

SiteMinder uses time-based session cookie parameters that can substantially reduce the possibility of a SiteMinder session cookie being compromised by administrators or other users who have access to the following items:

• Web server logs
• SiteMinder Web Agent logs
• Potentially compromised proxy servers sitting between domains in the case of cross-domain single sign-on

These time-based session cookie parameters add the concept of "born dates" to session cookies. Agents receiving a session cookie as a result of a redirect (URL session cookie) will look for the cookie born date name/value pair and compare this value with the value set for the CookieValidationPeriod configuration parameter. If the value of the born date and the CookieValidationPeriod parameter value exceed the current time, the cookie is rejected.

To protect session cookies from misuse, set the following parameters:

CookieValidationPeriod

Specifies the time period (in seconds) in which the receiving agent will accept the session cookie. After this time passes, the session cookie will not be accepted. If this field is not used or is set to zero, the session cookie expires when the Idle Timeout and Max Session Timeout values are met.

Default: Empty.

ExpiredCookieURL

(Optional) Specifies a URL that the agent redirects the user to after any session cookie has expired. If neither the born date nor the CookieValidationPeriod are configured, the agent ignores the settings and processes the cookie as usual (backwards compatibility).

Configure Support for SDK Third-Party Cookies

If you use non-SiteMinder Web Agents in your organization, you can configure them to support single sign-on with the following parameter:

AcceptTPCookie

Allows the Web Agent to accept session (SMSESSION) cookies created by third-party (non-SiteMinder) Web Agents. Third-party agents generate and read SMSESSION cookies using the SiteMinder SDK.

Default: No default

Note: For more information, see the SiteMinder Developer's documentation.

To allow the Web Agent to accept session cookies created by non-SiteMinder Web Agents, set the AcceptTPCookie parameter to yes.

Ignore the Cookie Provider for Unprotected Resources

Agents forward all requests to the cookie provider by default. If you have unprotected resources, you can reduce network traffic with the following parameter:

IgnoreCPForNotprotected

Prevents the cookie provider from being queried for unprotected resource requests. When this parameter is set to no, all requests are directed to the cookie provider by the Web Agent. For traditional (nonframework) Agents, configure a cookie provider so that value of this parameter appears in the Web Agent log file.

Default: No

To prevent an agent from contacting the cookie provider when unprotected resources are requested, set the value of the IgnoreCPForNotprotected parameter to yes.

Ignore the Cookie Provider for POST Requests

The following parameter enables these behaviors:

• This setting allows traditional agents to act as cookie providers.
• This setting prevents POST requests from being sent to cookie providers (in all environments).

  LegacyCookieProvider

  Controls whether an agent sends a POST request to a cookie provider. When the agents send POST requests to a traditional agent (operating as a cookie provider), the redirected request becomes a GET. This conversion causes errors. When set to no, the agent sends the POST request to the cookie provider. When set to yes, the agent does not send the POST request to the cookie provider.

  If you are using central agent configuration, add this parameter to your agent configuration object. This parameter exists in local configuration files.

  Default: No (POST requests sent)

Set the value of the LegacyCookieProvider parameter to yes to enable the following behaviors:

• Use traditional agents as cookie providers.
• Prevent any POST requests from being sent to cookie providers.

Force the Cookie Domain

Using fully qualified domain names helps ensure that cookies work properly. You can force the agent to append its cookie domain to the host name in a URL request that meets either of the following conditions:

• The request does not specify a domain.
• The request contains only an IP address.
• Agents can be forced to use a cookie domain by setting the following parameters:

  ForceCookieDomain

  Forces the Web Agent to append its cookie domain to the host name in a URL request that does not specify a domain or contains only an IP address. This parameter works together with the ForceFQHost parameter for added functionality.

  Default: No

  ForceFQHost

  Forces an agent to use a fully qualified domain name. This parameter uses configured Domain Name System (DNS) services to append the cookie domain to the host name in a URL request through DNS services and not an Agent. If the Web Agent receives a request containing a partial URL, then the agent redirects the request back to the same destination resource specified in the original URI. The redirect request uses the fully qualified host name, which the agent determines using the configured DNS services. Use this parameter with the ForceCookieDomain parameter for added functionality.

  Default: No

  Example: When the agent receives a request from http://host1/page.html, it responds with http://host1.myorg.com/page.html. If the agent receives a request such as http://123.113.12.1/page.html, it responds with http://host1.myorg.com/page.html.

  Note: These examples only work with proper DNS lookup tables. Request containing partial domain names that DNS cannot resolve could possibly generate errors.

Follow these steps:

1. Set the value of the ForceCookieDomain parameter to yes.
2. Set the value of the ForceFQHost parameter to yes.

   The agent appends its cookie domain to the host name when necessary.

Implement Cookie Domain Resolution

To implement automatic domain resolution, comment out the CookieDomain parameter or set it to none to cause the Web Agent to create cookies that are good only for the server from which they were issued.

You can further define the cookie domain by adding a value to the CookieDomainScope parameter. The scope determines the number of sections, separated by periods, that make up the domain name. (A domain always begins with a ".")

A CookieDomainScope value of 0 instructs the agent to use the most specific scope for a given host. A value of 1 (resulting, for example, in a cookie domain of .com) is not allowed by the HTTP specification. The value 2 instructs the agent to use the most general scope.

The following table shows some domain names and CookieDomainScope values.

For example, the domain division.myorg.com has a scope of 3. By default, the Web Agent assumes a scope of 2; cookie domains cannot have a scope of 1.

Configure SecureUrls with Single Sign-on

If your single sign-on network has a Web Agent that supports SecureUrls functionality and another Agent that does not, this could result in internal server error messages when a user requests a protected single sign-on resource.

The log for the Web Agent with SecureUrls support shows the reason for the server error, such as the following:

Error. Unable to process request, SecureUrls is disabled.

Note: All Web Agents in a single sign-on environment must have the SecureUrls parameter set to the same value. SiteMinder does not support interoperability between Web Agents with the SecureUrls parameter set to different values.

Prevent Cookie Provider Replay Attacks

You can prevent the cookie provider from being vulnerable to replay attacks with the following parameter:

TrackCPSessionDomain

Validates that the cookie domain of the session cookie matches the cookie domain of the cookie provider. Different cookie domains could indicate a possible replay attack.

Default: No (The domain of cookie provider is not validated).

To prevent cookie provider replay attacks, set the value of the TrackCPSessionDomain parameter to yes.

The agent compares cookie domains and rejects requests when the domains do not match.

How Full Logoff Works

Full logoff support enables a Web developer to make sure that a user is completely logged off from a user session. This protects resources because it gives users a way to end a session without exiting the Web browser and prevents an unauthorized person from assuming control of an open session.

A full logoff uses the following process:

1. A user clicks a button to log off.
2. The Web Agent redirects the user to a customized logoff page that you created.
3. The Web Agent removes the session and authentication cookies from a user’s browser.
4. The Web Agent also removes the session cookie from the local cookie domain and the cookie provider domain, which you specify for single sign-on environments.
5. The Web Agent calls the Policy Server and instructs the Policy Server to remove any session information.

   The user is completely logged off.

More information:

Configure Full Logoff Support for Domino Agents

Configure Full Logoff

The full log-out feature uses a custom log-out page that you create with the following parameter:

LogOffUri

Enables the full log-out function by specifying the URI of a custom web page. This custom web page appears to users after they are successfully logged off. Configure this page so that it cannot be stored in a browser cache. Otherwise, a browser could possibly display a log-out page from its cache without logging the user off. If this situation happens, unauthorized users could possibly have an opportunity to assume control of a session.

Note: When the CookiePath parameter is set, the value of the LogOffUri parameter must point to the same cookie path. For example, if the value of your CookiePath parameter is set to example.com, then your LogOffUri must point to example.com/logoff.html

Default: (all agents except the CA SiteMinder Agent for SharePoint r12.0.3.0) No default

Limits: Multiple URI values permitted. Do not use a fully qualified URL.Use a relative URI.

Example:(all agents except the CA SiteMinder Agent for SharePoint r12.0.3.0) /Web pages/logoff.html

Follow these steps:

1. Create a custom HTTP application that logs the user off. For example, add an Exit or Sign Off button that redirects the user to a URL you specify.
2. Set up the log-out page so it cannot be cached in web browsers. This setting increases security because the page is always served from the web server, and not the cache of the browser. For example, for HTML pages, you can add the following meta tags to the page:

   <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
   

   <META HTTP-EQUIV="Expires" CONTENT="-1">
   

   Important! Some web browsers do not support meta tags. Use a cache-control HTTP header instead.

3. Configure the LogOffUri parameter with the following steps:
   1. Delete the pound sign (#), if necessary.
   2. Enter the URI of the custom HTTP file that will log the user off. Do not use a fully qualified URL.

      The full log-out feature is configured.

More information:

Specify the Cookie Path for Agent Cookies

How to Configure Full Logoff for Single Sign-on

In a single sign-on environment, the session cookies are removed only from the local cookie domain and the cookie provider domain associated with the Web Agent. For single sign-on across multiple cookie domains, the full log-off feature of SiteMinder does not automatically log a user off across all the cookie domains that the user has visited.

To configure log-offs across multiple cookie domains, use the following process:

1. Create one centralized log-off page that contains separate frames (or iframes) for the other cookie domains in your SSO environment. These frames can be a small size, such as 1x1 pixels.
2. For each frame of the centralized log-off page in Step one, add a hyperlink to the Logoff Uri of the associated cookie domain. For example, if you have two other cookie domains, example.org and example.net, you would do the following steps:
   • Add a hyperlink to the Logoff Uri of example.org to one frame.
   • Add a hyperlink to the Logoff Uri of example.net to the other frame.
3. Configure the LogoffUri of the cookie provider domain to point to the centralized log-off page. When the web server loads this log off page, the frames in the centralized log-off page call the logoff pages from the other cookie domains. The user is logged off from all the cookie domains at once.

The following illustration shows an example of using a centralized log-off page:

Note: You can also place the hyperlinks inside <iframe> tags instead of <frame> tags.

Configure Comprehensive Log Out using FCC Forms

If you use FCC forms to authenticate your users, you can configure a comprehensive log out with your FCC form. This method provides an alternative to the LogoffUri parameter.

Follow these steps:

1. Open the .fcc file that you are using to authenticate your users with a text editor. FCC files are located in the following directory:

   web_agent_home/samples/forms
   

   web_agent_home

   Indicates the directory where the SiteMinder Agent is installed.

   Default (Windows 32-bit installations of SiteMinder Web Agents only): C:\Program Files\CA\webagent

   Default (Windows 64-bit installations [SiteMinder Web Agents for IIS only]): C:\Program Files\CA\webagent\win64

   Default (Windows 32-bit applications operating on 64-bit systems [Wow64 with SiteMinder Web Agents for IIS only]): C:\Program Files (x86)\webagent\win32

   Default (UNIX/Linux installations): /opt/ca/webagent

2. Add the following text to the top of your FCC page (before the <_html> tag):

   @smlogout=true
   @target=http://server_name.example.com/directory/your_logout_page.html
   

   Note: your_logout_page indicates a custom html page you create to inform users that they have logged out.

   Comprehensive logout using FCC forms is configured.