Implementation Guide › Architectural Considerations › Implementation Considerations › Determine if Partnerships Require Federation Security Services

Determine if Partnerships Require Federation Security Services

Do existing or planned business-to-business (B2B) partnerships require your organization to share resources securely with partners?

CA SiteMinder Federation Security Services lets you extend SiteMinder functionality to partner sites by enabling identity federation. Federated transactions between partner organizations let your enterprise:

• Exchange user information between partners in a secure fashion
• Establish a link between a user identity at a partner and a user identity in your company
• Enable single sign–on across partner web sites in multiple domains
• Handle different user session models between partner sites, such as single logout across all partner web sites or separate sessions for each partner web site
• Control access to resources based on user information received from a partner
• Allow interoperability across heterogeneous environments

Federation Security Services lets your enterprise generate, consume, or generate and consume assertions. Federation Security Services supports the following communication standards and protocols:

• SAML 1.0, 1.1, and 2.0
• Microsoft ADFS/WS-Federation
• SAML browser artifact protocol
• SAML POST protocol
• WS-Federation Passive Requestor Profile protocol

Note: Federation Security Services is separately licensed from SiteMinder. Contact your CA account representative for more information about licensing. For more information about Federation Security Services, see the Federation Security Services Guide.

If your organization plans on implementing Federation Security Services, use a table similar to the following to identify partners and the possible methods for enabling identity federation.

Determine if Advanced Encryption Standards are Required

Does your organization require the use of Federal Information Processing Standard (FIPS) 140–2 compliant algorithms?

The SiteMinder implementation of the Advanced Encryption Standard (AES) supports the FIPS 140–2 standard. FIPS is a US government computer security standard used to accredit cryptographic modules that meet the AES.

The Policy Server uses certified FIPS 140–2 compliant cryptographic libraries. These cryptographic libraries provide a FIPS mode of operation when a SiteMinder environment only uses AES–compliant algorithms to encrypt sensitive data. A SiteMinder environment can operate in one of the following FIPS modes of operation.

• FIPS–compatibility
• FIPS–migration
• FIPS–only

Note: For more information about the cryptographic libraries SiteMinder uses and the AES algorithms used to encrypt sensitive data in FIPS–only mode, see the Policy Server Administration Guide. For more information about the FIPS modes of operation and which to use when installing the Policy Server, see the Policy Server Installation Guide.

If you are implementing AES encryption through FIPS-only mode, consider the following:

• All third–party components, including directory servers, databases, and drivers must be configured to support FIPS–compliant algorithms.

  Note: For more information about your vendors ability to support the FIPS 140–2 standard, see the vendor-specific documentation.

• If the environment uses X.509 Client Certificate authentication schemes, be sure that the user certificates are generated using only FIPS–compliant algorithms.
• If the Policy Servers are to connect to policy stores or user stores using SSL, be sure that the Policy Servers and directory stores use certificates that are FIPS–compliant.
• All Web Agents that ship with SiteMinder r12.x are FIPS–compliant. To determine if other agents are FIPS–compliant, see the agent–specific documentation.

Important! An environment that is running in FIPS–only mode cannot operate with and is not backward compatible to earlier versions of SiteMinder. This requirement includes all agents, custom software using older versions of the Agent API, and custom software using PM APIs or any other API that the Policy Server exposes. Re–link all such software with the r12.0 SP3 versions of the respective SDKs to achieve the required support for FIPS–only mode.

Determine if Virtualization is to be Used

Will SiteMinder be implemented to a virtual environment?

Consider the following before implementing SiteMinder to a virtual environment:

• Be sure to review the CA policy on virtualization.
• Be sure to:
  • Understand the virtual environment and the performance overhead the host system can impose on applications.
  • Tune the virtual environment to eliminate as much as the performance overhead as possible.

    Note: For more information about performance tuning the virtual environment, see the vendor–specific documentation.

• Be sure to size the CPU, disk space, and memory available to the virtual environment. Use the system requirements detailed in each SiteMinder installation guide to determine how many components to deploy to the entire system.
• Be aware of issues associated with clock synchronization and multiple operating systems. Unsynchronized clocks can result in unexpected SiteMinder behavior.
• When considering where to deploy components:
  • We recommend deploying Policy Servers to the virtual environment. We recommend that Policy Servers have their own Ethernet port. A dedicated port helps to prevent SiteMinder from missing requests because it is competing with other virtual hosts for available bandwidth.
  • We recommend deploying Web Agents to virtualized web servers.
  • We recommend deploying all SiteMinder data stores to physical hardware and operating systems. Directory servers and databases can become very resource dependent. If deployed to the virtualized environment, this dependency can result in performance degradation.

Determine how to Manage Policy Servers

Should individual business units be responsible for managing Policy Servers? Or can a single business unit manage all Policy Servers centrally?

Local Policy Server Management

If individual business units manage Policy Servers and policy stores locally, consider that local Policy Server management:

• Lets each business unit manage their security requirements based on their individual needs.
• Can increase the complexity of the SiteMinder infrastructure:
  • Local Policy Server management can result in more Policy Server and policy stores to manage and upgrade.
  • If single sign–on is a requirement, local Policy Server management results in additional SiteMinder configuration. As illustrated, Policy Servers in both business units must share a key store to let all SiteMinder Agents share the same keys.

    Note: The illustration details a shared key store to depict a single sign–on requirement. A shared key store is not the only way to implement single sign–on and additional requirements exist. For more information about key management scenarios to facilitate single sign–on, see the Policy Server Administration Guide.

• Can make a consistent implementation and management of SiteMinder core objects, policies, and EPM applications more challenging because SiteMinder administrators are located in disparate business units.

The following illustration details two business units managing Policy Servers locally:

Central Policy Server Management

If a single business unit is to manage Policy Servers centrally, consider that central Policy Server management:

• Can facilitate a consistent implementation of SiteMinder core objects, policies, and EPM applications because all SiteMinder administrators are located in the same business unit.
• Can make the management of these objects easier because all SiteMinder administrators are located in the same business unit.

  Note: As illustrated, individual business units can continue to manage the SiteMinder Agents protecting their applications.

• Can simplify the SiteMinder infrastructure. Central management can result in fewer Policy Server and policy stores to manage and upgrade.
• Lets administrators monitor SiteMinder performance centrally.

The following illustration details a single business unit managing all Policy Servers:

Determine how to Manage Web Agents

If you have several Web Agents which will all be configured identically, then using an Agent Configuration object on the Policy Server will make managing your Web Agents easier. A single Agent configuration object can be shared among an unlimited number of Web Agents. Configuration changes made on the Policy Server are automatically applied to any Web Agents which use the configuration object.

Note: For more information, see the Web Agent Configuration Guide.