Previous Topic: User Sessions Across Security Zones

Next Topic: The Default Single Sign-On Zone and Trusted Zone List

Trusted Zone Order

A single sign-on security zone is defined by a pair of parameters:

The order in which the trusted zones are listed is important. Consider the following example.

trusted zone

In this illustration, Zone C trusts both Zone A and Zone B. Neither Zone A nor Zone B trusts any other zone, but all zones trust themselves.

When a user makes a request in Zone C, the Web Agent looks for a session or identity cookie in the trusted zones, in the order in which the zones are listed. In this example, Zone C has a list of trusted zones that include C, A, and B.

The following is an order of events that might occur:

  1. The Web Agent first checks to see if the user has a session in Zone C.
  2. If no session is found, the Web Agent checks to see if the user has a session in Zone A.
  3. If no session is found, the Web Agent checks to see if the user has a session in Zone B.
  4. The session specification from each cookie that is found is used to process authentication requests until a successful login occurs.
  5. After a successful authentication, the Web Agent proceeds to authorization.
  6. If no cookies are found or no cookies pass authentication, the agent challenges the user for credentials as usual.

Note that the user experience may depend on the order in which the zones are accessed. In this example, if the user accesses Zone B first followed by Zone C, the user's identity in Zone B is also used in Zone C. If the user accesses Zone A first followed by Zone B and Zone C, the user's identity in Zone A is used, despite the fact that the user was re-challenged in Zone B before going to Zone C.

This will also be the case when sessions with different max and idle session timeouts begin to expire. In the current example, a user with valid cookies in Zone A and Zone C will first get access with the Zone C cookie. If the Zone C cookie expires, the Zone A cookie will be used if it has not expired. Therefore, the user's identity could change from a Zone C identity to a Zone A identity without a credential challenge occurring.

Two or more Web Agents may have different lists of trusted zones but still use a common trusted zone name. In this case, the agents implicitly trust each other but will not trust the same foreign zones. This functionality enables applications to be segmented for single sign-on. A Web Agent supports only a single sign-on zone name. All session, identity, and state cookies generated by that agent use the same single sign-on zone name. Therefore, if two applications do not share the same single sign-on trust requirements, they must be hosted on separate web servers each with its own Web Agent and list of trusted zones.

Note: Foreign zones refer to zones other than the one supported by a given Web Agent. For example, if an agent is configured with SSOZoneName="Z1", then any other zone would be foreign to it. This includes the default zone "SM".


Copyright © 2010 CA. All rights reserved. Email CA about this topic