Security Zones for Single Sign-on

SSO security zones let you segment single sign-on environments within the same cookie domain so you can modify how single sign-on works. Security zones enable a company with several divisions to separate applications with different security requirements. Each division can use independent SSO zones and can maintain unique session cookies. So, two sessions for a single user can then exist in the same browser session.
For example, App1 is in zone Z1 and App2 is in zone Z2. When a user logs in to App1, the Web Agent creates a Z1SESSION cookie. When a user logs in to App2, the Web Agent creates a Z2SESSION cookie. The cookies have different names so they do not overwrite each other. Single sign-on is divided between the two applications rather than shared across a single domain. A separate login is required for each application, resulting in a separate session for each application.
sso zones overview
sso zones overview
All applications in the same zone allow single sign-on. A user is challenged only when entering a different zone in the domain, unless you configure a trust relationship between the zones. If there is a trust relationship across zones, sessions can be shared. A user with a valid session in one zone can then travel to other zones without being challenged.
Two or more Web Agents can have different trusted zone lists but still have zones in common. The agents trust any zones that they have in common, as long as the zone is also in the respective trusted zone list. For example, if Agent 1 has zones A and B in its list and Agent 2 has zones B and C, then both agents trust Zone B. Any zone not in the list is considered an untrusted foreign zone.
Set up Security Zones
You configure SSO security zones using two Agent Configuration Object (ACO) parameters:
  • SSOZoneName—Identifies an Agent's local zone by assigning it a name. The default name is "SM."
  • SSOTrustedZone—Lists zone names that an agent trusts.
A single Web Agent instance supports only one local SSO zone, which you identify using the SSOZoneName parameter. An Agent implicitly trusts its local zone. Multiple zones cannot be named using the same Agent instance. 
Based on the zone a web agent is configured to use, the agent generates the session and identity cookies with unique names. These names reflect the zone affiliation. For example, for the default zone named "SM", the session cookie is named SMSESSION. However, if an agent is configured to use a zone that is named "MY" instead of "SM" the SMSESSION cookie becomes MYSESSION.
Agents enforce zones by storing the zone name in the session and identity cookies. Users cannot rename the session or identity cookies to change their zone. When the agent validates these cookies, the agent verifies whether the zone name stored in the cookie matches the prefix in the cookie name.
 Web Agents are considered to be in the same SSO zone by sharing the same value for the SSOZoneName parameter.
Name the Security Zone
Use the 
name the single sign-on security zone. 
Specify a string that uses only English-language characters. This parameter is case-sensitive, single-value ACO parameter. SSOZoneName cannot be set to multiple values.
The Web Agent prepends the value of the SSOZoneName parameter to the names of all the session, identity, and state cookies that it generates. These cookies all share the same zone name. Prepending the zone name associates cookies with their respective zones.
The following table shows the naming convention and the cookies that are affected by this convention:
Cookie Name
Cookie Name in the Default Zone
The SSOZoneName parameter can differentiate two single sign-on deployments in the same browser session. For example, ForwardInc uses 
CA Single Sign-On
 to protect corporate applications. ForwardInc acquires a company, named DemoLtd, that also uses 
CA Single Sign-On
 but its applications are now under the domain. Without security zones, users accessing ForwardInc applications 
 logging into the DemoLtd applications lose their DemoLtd sessions because the ForwardInc SMSESSION cookie overwrites the DemoLtd SMSESSION cookie.
Using SSO zones, DemoLtd can change its implementation to use an SSOZoneName of "DL." Now, a user accessing DemoLtd applications gets a DLSESSION cookie. When that same user accesses ForwardInc applications afterward, the user gets an SMSESSION cookie. By establishing trust between the zones, you can establish SSO between the ForwardInc applications that use the default "SM" zone and the DemoLtd applications that use the "DL" zone. Without a trust relationship, single sign-on between these zones is prohibited.
Define Trusted Security Zones
To allow single sign-on across zones in the same cookie domain, define trust relationships between zones using the 
 parameter. The SSOTrustedZone parameter is a multi-valued ACO parameter, and the values are case-sensitive. Use the SSOTrustedZone parameter to define an ordered list of all trusted zones by name. Enter the zone names in the order that the Web Agent must search for session cookies.
SSOTrustedZone=SM, CA, DL
A single Agent instance can trust more than one SSO zone. For example, consider Zone CA and Zone DL:
  • Zone CA has only one trusted zone, itself
  • Zone DL has two trusted zones, itself and Zone CA, in that order
SSO--Zone A and B
SSO--Zone A and B
In the illustration, Zone CA can be an administrator-only zone, while Zone DL can be a common access zone. An administrator who is authenticated in Zone CA gains access to Zone DL without being challenged. However, a user who is authenticated in Zone DL is challenged when trying to access Zone CA. To gain access to Zone CA, the user must enter acceptable administrator credentials, even though those credentials have already been entered to access zone DL. This approach is useful for verifying correct user presence before allowing access to critical resources.
The trust relationship between security zones is not transitive. Explicitly configure zone trust using the SSOTrustedZone parameter. The only implicit trust is between an Agent and its own local zone.
Understand the Trusted Zone Order
During the authentication process, the Web Agent uses trusted zones in the following order when choosing which session or identity cookie to validate:
  • Local zone first.
  • Trusted zone list.
When processing a request, the Web Agent looks for a cookie for each zone in the order the zones appear in the list. If you do not specify a security zone for a Web Agent, it belongs to the default zone named "SM."
: A Web Agent that is not in the default zone trusts the default zone only if you add "SM" to the trusted zone list.
When a user makes a request for an application, the Agent tries to authenticate that user. For each session or identity cookie the Agent finds, it processes an authentication request until a successful login occurs, or until the agent runs out of existing sessions for the configured trusted zones. If the Agent does not find a valid session, the agent challenges the user for credentials. After a successful authentication, the agent proceeds to authorization. The agent uses the first session that it validates for the remainder of the request processing. If authorization fails, the user is challenged immediately, even though some available sessions are not validated. The Agent does not try other remaining sessions for authorization.
In the following graphic, all three zones are in the same cookie domain:
trusted zones
trusted zones
  • Zone A only trust itself.
  • Zone B trusts Zone A and itself.
  • Zone C trusts itself, Zone A and Zone B.
The order of the trusted zone list is important. The user accesses Zone A and Zone B, acquiring unique session cookies for each zone before accessing an application in Zone C. The Agent uses the session for Zone A in Zone C because A is listed before B in the zone order. Although there is a user session for Zone B, the Zone A session takes precedence. If you want the Zone B session to take precedence, reorder the zone list.
 Each available session in a request can have different user identities; therefore, the application sees different identities depending on the session that the Agent chooses.
Impact of Trusted SSO Zones on the User Experience
When accessing 
CA Single Sign-On
 protected applications, the user experience can vary depending on the order of trusted zones and the order in which the user travels back and forth between applications in different zones.
Consider the impact of trusted zones on the following situations, using the previous illustration as a reference:
  • Impact of Trusted Zone Order on User Identity
    Trusted zones are independent. When a user visits each zone, the Agent creates a unique session cookie. For example, Admin1 authenticates in Zone A first and receives a session cookie. User1 then visits Zone B and a new cookie is created, using a copy of the cookie from Zone A because Zone B trusts Zone A. The Zone B session is based on the session information from Zone A, but the cookies are unique. If the user accesses an application in Zone C, the Agent uses the session cookie from Zone A based on the order of trust. The Agent can use the Zone A session cookie because the session cookies for Zone A and Zone B are copies and contain the same identity.
    Alternatively, if the user visits Zone B first and enters credentials for User1 before visiting Zone A, the result is different. When attempting to access an application in Zone A, the user is challenged because applications in Zone A are not configured to trust sessions from Zone B.  The user enters valid credentials for an administrator account “Admin1” and receives a session cookie for Zone A. The user now has two session cookies, one for User1 in Zone B and one for Admin1 in Zone A. If the user visits Zone C, the Agent uses the session cookie for “Admin1” even though the user visited Zone B first. Although this is expected behavior that is based on the trusted zone order, the experience for the user can be unexpected.
  • Impact of Session Timeouts on Authentication Challenges
    Sessions with different max and idle session timeouts impact when a user is challenged. A user with valid cookies for Zone A and Zone C first gets access with the Zone C cookie because Zone C is first in the list. If the Zone C cookie expires, the Zone A cookie is used, as long as it is not expired. Assuming that the two session cookies do not contain the same user identity, the user identity changes from a Zone C identity to a Zone A identity without a credential challenge. If both session cookies expire, the Agent challenges the user for credentials
  • Impact of Trusted Zones on Authorization Requests
    Authorization proceeds after a successful authentication. The Web Agent completes authentication once the first available session cookie is found to be valid. Any remaining session cookies in the request are ignored. If authorization fails, the user is challenged for credentials regardless of whether other available session cookies let the user authenticate successfully.
Override Local Cookie with Trusted Zone Cookie
When a local cookie is present, Agent does not honor trusted zone cookie. However, some scenarios require Agent to honor a trusted zone cookie instead of a local cookie. For example, the following scenarios describe when a trusted zone cookie must take precedence over a local cookie:
  • Consider that Zone A has two resources, A1 with an authentication level of 5 and A2 with an authentication level of 10, and Zone B has two resources, B1 with an authentication level of 5 and B2 with an authentication level of 10. Zone B trusts Zone A. When a user is authenticated by A1, a cookie ASESSION is created after authentication. When the user accesses B1, a new cookie BSESSION is created using the attributes of ASESSION. When the user access A2, user is re-challenged as A2 has a higher authentication level. A new cookie is created with new authentication level, and it replaces the existing ASESSION cookie as the new ASESSION cookie in the web browser. When the user accesses B2, the request fails as Agent uses BSESSION instead of the latest ASESSION cookie for validation. 
  • Consider that a federation partnership exists in Zone A and Agent exists in Zone B. Zone B trusts Zone A. When a user is authenticated as part of the federation flow, Persistent Attributes of the assertion can be used as headers using session variables in the responses. The assertion is saved in the session store and a cookie ASESSION is created. When a user accesses a trusted zone resource in Zone B within the same web browser, a cookie BSESSION is created using the attributes of ASESSION. User can use the assertion attributes as headers. When the user is re-authenticated by the federation flow, the assertion is updated with new attributes and a new cookie is created. This new cookie replaces the existing ASESSION in the web browser. When the user tries to access a trusted zone resource in Zone B, the headers of the existing BSESSION cookie are displayed instead of the latest headers in ASESSION.  
In such scenarios where a trusted zone cookie must override a local cookie, you can set the 
 ACO parameter to 
 to ensure seamless access to resources. This ACO parameter determines the cookie that must be honored by Agent.  
Security Zones for Multidomain Single Sign-on
Security zones do not have to belong to a single cookie domain; they can span multiple domains. The Web Agent receives cookies for all zones in a single domain by default. In a multidomain deployment, the web agent can request cookies for its own SSO zone from a configured cookie provider but not for trusted zones. So, while trust can exist within each separate cookie domain, it does not extend across cookie domains using a cookie provider.
To establish single sign-on across multiple cookie domains, you configure a Web Agent in one domain as a cookie provider. That Web Agent’s cookie domain becomes the master cookie domain. A cookie provider is able to pass cookies from its own master domain to agents in other cookie domains.  A cookie provider can also take cookies from other web agents to be set in its master domain. Learn more about multidomain SSO.