This section contains the following topics:
The following terms apply to single sign-on (SSO) security zones:
Identifies a mechanism by which a Web Agent borrows its configuration properties from a Web Agent configuration object defined in the policy store.
Identifies a mechanism by which single sign-on is implemented in Web Agents across multiple domains. One of the domains is designated as the master domain, and the Web Agents from the other domains are re-directed to a Web Agent in the master domain to provide them with the cookies in that domain.
Identifies a mechanism by which a user authenticated once will not be rechallenged for credentials.
Identifies a sub-set of SSO, defined by an arbitrary identifier (zone name) used to segment application SSO within a single cookie domain. All applications in the same SSO zone allow SSO amongst themselves. SSO to and from other SSO zones may or may not be allowed as defined by zone trust relationships.
Identifies a foreign zone trusted by a local zone for SSO.
Users have the ability to define single sign-on security zones within the same cookie domain, representing a single zone, or across multiple cookie domains, representing different zones. As a result, users have single sign-on within the same zone, but may be re-challenged when entering a different zone, depending on the trust relationship defined between the zones. Zones included in a trusted relationship will not re-challenge a user that has a valid session in any zone in the group.
Single sign-on security zones are implemented entirely by SiteMinder Web Agents. Each zone must reside on a separate Web Agent instance. Multiple zones cannot be created on the same Agent instance.
A security zone is identified by cookies generated by the Web Agent. 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 can generate session cookies and identity cookies with unique names so that the zone affiliation is reflected in the cookie names.
The SSO Security Zones feature is intended for use in situations where SiteMinder administrators wish to segment their single sign-on environments within the same cookie domain. For example, consider the CA.COM domain. Under standard SiteMinder SSO functionality, all 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:
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.
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:
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.
Single sign-on security zones do not need to all belong to the same domain. In fact, zones can be spanned over multiple domains. However, Web Agents only search for trusted zone cookies in their local cookie domain. If no suitable cookies are found, Web Agents continue to redirect to cookie providers only for their own zone.
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.
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:
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”.
Web Agents that do not specify a security zone name (such as all pre-SiteMinder 6.x QMR 5 Web Agents) are considered to belong to the default zone. For backwards compatibility, the default zone is implicitly assumed to have a zone name of SM. This allows SiteMinder r12.0 SP3 Web Agents to support SMSESSION and SMIDENTITY by default with no configuration changes.
Web Agents that do not specify a list of trusted zones trust only their own single sign-on zone (either a specified zone name or default zone if no zone name has been specified).
A Web Agent can be configured to trust other zones in addition to the default zone. It can also use a specified zone name and list no other trusted zone. Agents always trust their own zone first, regardless of whether or not additional trusted zones are specified. In order for a Web Agent using a non-default zone to trust the default zone as well, it must list "SM" in its trusted zone list.
Web Agents look up user sessions in the order of trusted zones. If a valid user session is found, the Web Agent uses the session information to process the user request. If no valid session is found, the Web Agent fails over to the next valid user session in the order of trust.
Responses from failed validations are ignored if there is another session to check. Otherwise, they are processed as normal. This means that if the Web Agent finds three trusted sessions to process and the first two fail to validate, only the responses from validating the third and final session are processed.
In the case of a successful validation, the Web Agent stops processing sessions and immediately begins processing the responses from the successful validation. If the agent has three sessions to validate and the first session validates successfully, the remaining two are ignored and the agent moves on to process the responses for the first successful validation.
The trust relationship between single sign-on zones is not fully transitive. If Zone A is trusted by Zone B, and Zone B is trusted by Zone C, Zone A may not necessarily be trusted by Zone C, as illustrated in the following diagram.
SiteMinder uses state cookies to manage the various events surrounding authentication and authorization. All of these cookies by default begin with the default single sign-on security zone prefix SM. If a new single sign-on zone name is specified, then these cookies are also named to reflect the specified non-default zone name. Below is a list of cookies that are affected by defining a new single sign-on zone:
If a zone name of Z1 is specified, for example, the Web Agent begins creating Z1CHALLENGE=YES cookies for Basic authentication. This allows administrators to create islands of SiteMinder application single sign-on in a single cookie domain (for example, ca.com) where agents will not interfere with each other. The single sign-on trusted zone list then allows single sign-on to occur between these isolated single sign-on zones in a predictable fashion.
With single sign-on zones, authorization proceeds normally after a successful authentication without change. Once the validation process identifies a valid session, the session is used for the remainder of request processing and any other sessions identified in the request are ignored. If authorization fails, the user is challenged regardless of whether or not other sessions are available that might authorize successfully.
The first trusted session that passes validation is the session passed to authorization. If this session fails authorization, the user is challenged for credentials.
|
Copyright © 2012 CA.
All rights reserved.
|
|