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.
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.
You configure SSO security zones using two Agent Configuration Object (ACO) parameters:
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.
Use the SSOZoneName parameter to name the single sign-on security zone.
Value: 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 ForwardInc.com domain. Without security zones, users accessing ForwardInc applications after 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.
To allow single sign-on across zones in the same cookie domain, define trust relationships between zones using the SSOTrustedZone 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:
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.
During the authentication process, the Web Agent uses trusted zones in the following order when choosing which session or identity cookie to validate:
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."
Note: 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:
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.
Note: 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.
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:
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.