Federation Security Services Guide › Federation Security Services Overview › SiteMinder Components for Federation Security Services › Internationalization in Federation Security Services

Internationalization in Federation Security Services

Federation Security Services supports the following features for I18N internationalization:

• Federation Security Services configuration objects, Java and C++ code are encoded in UTF-8 format for the internationalization purposes.
• SiteMinder supports the creation and consumption of default and customized SAML 1.x, SAML 2.0, and WS-Federation assertions with multibyte user ids and attribute values.
• All target and redirect URLs are encoded per HTTP 1.1 RFC 2616 so multibyte path and file names are handled correctly.

If assertions contain multibyte characters, set the LANG setting of your operating system to the following UTF-8 format:

LANG=xx_xx.UTF-8

For example, for Japanese, the entry would be:

LANG=ja_JP.UTF-8

Federated Single Sign-on with Security Zones

A SiteMinder environment can be set up to include a web application environment for web service protection and a federation environment for federated resource protection. This method can make a SiteMinder deployment more efficient.

Certain federation features require a persistent user session, which means that the SAML assertion is stored in the session store of the Policy Server.

These features include:

Artifact Single sign-on

For SAML 1.x and SAML 2.0, the SAML assertion is stored in a persistent session that the relying party retrieves later.

Single Logout

(SAML 2.0 Single Logout and WS-Fed Signout) at producer and consumer sites. Partner data is stored in a persistent user session to facilitate notification of partners during a federated logout.

Use of persistent user sessions slow down performance because of the required calls to the session store to retrieve assertions or handle log-out requests. To limit the performance impact, use security zones.

A security zone is a segment of a single cookie domain. The security zone lets you partition applications to permit different security requirements for resource access. All applications in a single zone permit single sign-on to one another. If an application is in another zone, the trust relationship that you configure determines single sign-on.

For federated applications at the asserting party, implement the following setup:

• Create a dedicated security zone.
• Create a different zone for all non-federated applications.
• Configure the federated zone to trust the non-federated zone.

The use of different zones confines calls to the session server for only federated applications.

Note: In a federated environment, you can only configure Web Agents and SAML Affiliate Agents to use security zones. Secure Proxy Agents and Application Server Agents do not support this feature.

To configure security zones, enter values for the following Web Agent parameters:

SSOZoneName

Identifies a single sign-on security zone. The zone name is added to the cookie domain name to associate the zone with the domain.

Note: This item supports only English-language characters. Characters from other languages are not supported.

SSOTrustedZone

Displays an ordered list of trusted security zones. Defining zones and trusted zone lists determine the cookies that the Web Agent is able to read and write.

These parameters are part of an Agent Configuration Object or a local Agent configuration file.

For more information about security zones, see the Web Agent Configuration Guide.