Previous Topic: Single Sign-On Security ZonesNext Topic: Troubleshooting


Configure Security Zones

Two single sign-on parameters have been added to the Web Agent configuration objects in the policy store. These settings may also be used in local configuration files and are added to the sample local configuration files laid down during installation.

Note: All Web Agents configured through the same agent configuration object belong to the same single sign-on zone.

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. This setting helps you associate cookies with their respective cookie domains. When this parameter is not empty, SiteMinder generates cookies using the following convention:

ZonenameCookiename.

Default: Empty (uses SM as a zone name, which gives the following default names to the cookies):

Limits: Single-valued. This parameter supports English‑language characters only.

Example: Setting the value to Z1 creates the following cookies:

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.

Default: Empty (SM or the SSOZoneName if provided)

Limits: Multi-valued

Specify the Single Sign-on Zone for the Agent
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. This setting helps you associate cookies with their respective cookie domains. When this parameter is not empty, SiteMinder generates cookies using the following convention:

ZonenameCookiename.

Default: Empty (uses SM as a zone name, which gives the following default names to the cookies):

Limits: Single-valued. This parameter supports English‑language characters only.

Example: Setting the value to Z1 creates the following cookies:

Use the SSOZoneName parameter to enter the name of the single sign-on zone a Web Agent is to support. This parameter is case sensitive. If not specified, it defaults to SM. If the value of the SSOZoneName parameter is non-empty, the Web Agent generates cookies with the naming convention:

zone_namecookie_name

where zone_name is the parameter value and cookie_name is the general name of the cookie being created.

Cookies affected by this convention include:

If the user is validated in a single sign-on zone in which that user has not yet established a session, the session specification returned by the Policy Server is used to create a new session cookie for that zone.

When a new cookie is created, its zone parameter is set to the zone name, in order to prevent the user from swapping cookies from different zones by simply renaming them. The cookie validation engine verifies if the zone name matches the prefix used in the cookie's name. This applies only to SESSION and IDENTITY cookies.

To specify the name of the single sign on zone you want the Web Agent to support, add the name of the zone to the SSOZoneName parameter.

The Order of Trust and Failover

Use the SSOTrustedZone parameter to specify the single sign-on zone's order of trust. When processing a request, the Web Agent looks for a SESSION or IDENTITY cookie for each zone in the order they appear in the list.

Any cookies found are validated as usual (decrypted, and tested for a valid host name, single sign-on zone name, and timeouts), then stored in an ordered list of trusted sessions if valid. Prior to authentication, the user's active session (and therefore user identity) are considered the first session in the ordered list of valid sessions.

During authentication, the Web Agent will call validate using the first session in the list. If the validation succeeds, the agent moves on and establishes user identity and affirms the active accordingly. If validation fails, the next session is used in a new validation call, and so forth until validation succeeds or the agent runs out of sessions. If no session validates, the agent challenges the user as usual.

Once validated, the agent ignores all other sessions and instead sticks only to the session that validated for the remainder of request processing. This means that should authorization fail, the user is challenged immediately. Any other existing sessions in the request are not used.