Tuesday Tip by Vijay Masurkar, Principal Support Engineer, for 11-27-12
A question such as this has often come up: For Each SiteMinder cookie type, please provide information as to when they are used, their content, ways to secure them: SMSESSION, SMIDENTITY, SMDATA, SMTRYNO, SMCHALLENGE, SMONDENIEDREDIR, SMUSRMSG.
SMSESSION: Is set by Web Agent upon authentication. This cookie represents a user’s session and contains:
User’s ID (User name and user DN)
ClientIP address
ID of the directory or database from which the user was authenticated
SMSESSIONSPEC
Unique Session ID (a hash of the GUID of the logged in user)
Creation time
Last Access Time, etc.
SMIDENTITY: When an anonymous user accesses resources (with user tracking enabled), that user is assigned an SMIDENTITY (anonymous) cookie. When the user moves to another domain, the user is challenged, and if logs in successfully, then is assigned an SMSESSION (logged in) cookie. As this user accesses protected and "anonymous" resources (i.e. resources in a realm that do not require a user to present credentials), the user may enter a domain that contains both cookies for a user. For resources protected by Web Agents starting at 5.x QMR 3 , the Web Agent uses the SMSESSION cookie to identify the user, not the SMIDENTITY cookie. If the user goes from a thoroughly upgraded domain to a domain where older Agents use the SMIDENTITY cookie to identify the user, the cookie used depends on the version of the Web Agent handling the request. For affiliates, the SMIDENTITY cookie is used to inform the affiliate who is trying to access the affiliate site.
SMDATA: Is set by Web Agent to store encrypted user information. It is used when a user selects the save credentials option. With this option selected in your login page, you can return to the site after your session has ended and automatically login using the contents of the SMDATA cookie.
SMTRYNO: Contains number of failed login attempts. Note that when using the DynamicRetry pair of .fcc files, you cannot count user login attempts based on the SMTRYNO cookie.
SMCHALLENGE: Is set by Web Agent when using Basic authentication. The value of this cookie is initially set to YES, which causes the user to be prompted for credentials. The Web browser then sends this cookie back with the credentials entered in the authorization header.
SMONDENIEDREDIR: Is set by Web Agent when using Basic authentication with a redirect upon failed authentication. If both authorization header and the SMONDENIEDREDIR cookie exist, SiteMinder issues a 401 error message. This ensures that users are locked out if they click a Back button.
SMUSRMSG: Is supported for the custom authentication scheme only when FCCCompatMode set to yes. Beginning with v5 QMR3, the Web Agent has the ability to convert the text from an SM_AGENTAPI_ATTR_USERMSG response to a SMUSRMSG cookie when performing a forms challenge. To ensure the SMUSRMSG cookie is removed after the challenge is complete, the FCC consumes the cookie (deletes it from the browser) after a successful POST request,
Further, note that these cookie names can change. SSOZoneName ACO parameter specifies the (case-sensitive) name of the single sign-on security zone a Web Agent supports. The value of this parameter is prepended to the name of the cookie a Web Agent creates. This helps you associate cookies with their respective cookie domains. So, when this parameter is not empty, SiteMinder generates cookies using the following convention: <Zonename><Cookiename>
Default: Empty (uses SM as a zone name, which gives the cookies the following default names):
SMSESSION, SMIDENTITY, SMDATA, SMTRYNO, SMCHALLENGE, SMONDENIEDREDIR
Example: Setting the value to Z1 creates the following cookies:
Z1SESSION , Z1IDENTITY, Z1DATA, Z1TRYNO, Z1CHALLENGE, Z1ONDENIEDREDIR
Securing Cookies
To help protect against cross-site scripting attacks, you can make the Web Agent set the HTTP-Only attribute for any cookies it creates using the following ACO parameter (introduced in 6QMR5 HF06 ): UseHTTPOnlyCookies. Also, you can specify that session cookies are only sent between a protected web server and the requesting browser over secure (HTTPS) connections using the following parameter: UseSecureCookies. See further security best practice details for Web Agents and Cookies in the Agent Configuration Guides for the agent versions in your infrastructure.