Administration Guide › Configuring CA SiteMinder® SPS › Configure Security Zones on CA SiteMinder® SPS

Configure Security Zones on CA SiteMinder® SPS

SSO security zones provide configurable trust relationships between groups of applications within the same cookie domain. Users have single sign-on within the same zone, but can be challenged when entering a different zone, depending on the trust relationship defined between the zones. Zones included in a trusted relationship do not challenge a user that has a valid session in any zone in the group.

CA SiteMinder® Web Agents implement single sign-on security zones. Each zone must reside on a separate Web Agent instance. All Web Agents configured through the same agent configuration object belong to the same single sign-on zone.

Cookies generated by the Web Agent identity security zones. By default, the Web Agent generates two cookies: a session cookie named SMSESSION, and an identity cookie named SMIDENTITY. When you configure security zones, the Web Agent generates session cookies and identity cookies with unique names so that the zone affiliation is reflected in the cookie names.

Note: For detailed information about SSO security zones, see the CA SiteMinder Web Agent Guide.

Security Zones Benefits

The SSO Security Zones feature is intended for use in situations where CA SiteMinder® administrators wish to segment their single sign-on environments within the same cookie domain. For example, consider the CA.COM domain. Under standard CA SiteMinder® SSO functionality, all CA SiteMinder® protected applications in CA.COM would use the cookie SMSESSION to manage single sign-on. Consider the following scenario in which SSO Security Zones do not exist:

1. A user accesses an application (APP1). The user is challenged by CA SiteMinder®, logs in to CA SiteMinder®, and creates an SMSESSION cookie.
2. The user accesses a second application (APP2) and is once again challenged by CA SiteMinder®. (Rules prevent SSO from occurring because the user does not have access to APP2 using the APP1 user credentials.) The user logs in and creates a new SMSESSION cookie overwriting the old one with the new logged in session for APP2.
3. The user now returns to APP1 and is challenged yet again, since the user lost the original APP1 session and the APP2 session might not be accepted for APP1. Therefore, SSO does not occur between APP1 and APP2, causing a very frustrating situation.

With SSO Security Zones, APP1 can be placed in zone Z1 and APP2 can be placed in zone Z2. Now logging into APP1 creates a Z1SESSION cookie and access to APP2 results in a Z2SESSION cookie. With different names, the cookies no longer overwrite each other so there is only one login per application now, not one for each time the user moves between the applications as in the example above.

Prior to the SSO Security Zones feature, the only way to perform the same grouping of SSO for applications was to create different network domains and therefore different cookie domains (CA1.COM, CA2.COM, and so on), and use various multi-cookie domain configurations with cookie providers. This is not desirable in most enterprises, since using multiple network domains has certain IT maintenance and support consequences.

Security Zone Basic Use Case

Single sign-on can, on a controlled basis, be broken into several security zones that have configurable trust relationships. For example, consider Zone A and Zone B:

• Zone A has only one trusted zone, its own Zone A.
• Zone B has two trusted zones, its own Zone B as well as Zone A.

The trust relationship in the above illustration is indicated by the arrow, meaning that the user sessions established in Zone A can be used for single sign-on in Zone B.

In this example, Zone A might be an administrator-only zone, while Zone B might be a common access zone. An administrator authenticated in Zone A gains access to Zone B without being rechallenged. However, a user authenticated in Zone B is re-challenged when trying to access Zone A.

User sessions in different zones are independent of each other. Suppose a user authenticates in Zone B first, and then authenticates again in Zone B. Two different sessions are created. In fact, the user may have different identities in both sessions. When the user returns to Zone A, the session established in that zone is used.

Consider what would happen if a user is validated using single sign-on in a zone where that user does not yet have a session. If the user authenticates in Zone A and then visits Zone B for the first time, then a user session is created in Zone B, based on the session information in Zone A, possibly updated by the Policy Server. Note that the user session in Zone A is not updated until the user returns to Zone A.

Parameters for Security Zones

The two single sign-on parameters listed following are manually added to the Web Agent configuration objects in the policy store. These settings can also be used in local configuration files and are added to the sample local configuration files laid down during installation.

SSOZoneName

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. When this parameter is not empty, CA SiteMinder® generates cookies using the following convention: ZonenameCookiename. The default is empty and 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

SSOTrustedZone

Defines an ordered (case-sensitive) list of trusted SSOZoneNames of trust for a single sign-on security zone. Use SM to add the default zone if necessary. Agents always trust their own SSOZoneName above all other trusted single sign-on zones. The default is empty, or can be SM or the SSOZoneName if provided.

Configure CA SiteMinder® SPS Security Zones

You can configure security zones on CA SiteMinder® SPS in one of the following methods:

• Configure security zones on multiple CA SiteMinder® SPS servers that are configured to a Policy Server based on their ACO objects.
• Configure security zones on multiple web servers that are deployed behind an CA SiteMinder® SPS server.

To configure security zones on multiple CA SiteMinder® SPS servers, perform the following steps:

1. Configure the SSOZoneName parameter on the first CA SiteMinder® SPS server.
2. Configure the SSOZoneName and SSOTrustedZone parameters on the CA SiteMinder® SPS servers you want to group as one security zone or different security zones.

To configure security zones on multiple Web servers of an CA SiteMinder® SPS server, perform the following steps:

1. Create an ACO for each Web server that must belong to a security zone.
2. Create a virtual host for a single or group of Web servers that must belong to a security zone.
3. Verify that a unique ACO points to a virtual host so that each virtual host belongs to a different security zone.
4. Configure the SSOZoneName parameter on the ACO of the first Web server.
5. Configure the SSOZoneName and SSOTrustedZone parameters on the ACOs of the virtual hosts you want to group as one security zone or different security zones.