Implementation Guide › Plan a CA SiteMinder® Web Services Security Implementation

Plan a CA SiteMinder® Web Services Security Implementation

This section contains the following topics:

Policy Management Models

Identify the Web Services to Secure

Identify User Stores

Identify Authentication Methods

Identify Who Will Manage Your SiteMinder WSS Agents

Identify Data Centers

Determine if Advanced Encryption Standards are Required

Determine if Virtualization is to be Used

Determine how to Manage Policy Servers

Determine how to Manage SiteMinder WSS Agents

Policy Management Models

CA SiteMinder® Web Services Security access management models let you define access permissions for applications and their respective user populations. An access management model establishes the following:

• What resource is protected.
• Who can access the resource.
• What type of access user populations have.
• What happens when CA SiteMinder® grants access to the resource.
• What happens when CA SiteMinder® denies access to a resource.

Almost all CA SiteMinder® Web Services Security functionality is available, regardless of which model you use. The primary difference between the models is the level of CA SiteMinder® knowledge required to configure each. The following Administrative UI objects represent the policy management models:

• Application objects
• Policy domains and policy objects

Note: The following CA SiteMinder® core objects are required to configure an application object or CA SiteMinder® domain policy:

• A host configuration object
• An agent configuration object
• An agent object
• A user directory object

  For more information about these objects, see the Policy Server Configuration Guide.

Policy Management Using Application Objects

The recommended method for creating and managing new security policies for your CA SiteMinder® Web Services Security environment is to define application objects that represent one or more related web services and then generate the component and resource settings that define what to protect from associated WSDL files.

Note: Application objects do not support policy expressions using variable objects. Content-based authorization using variables must be implemented using policy domains and policies.

Policy Management Using Policy Domains and Policies

For Policy Server administrators already comfortable with CA SOA Security Manager or CA SiteMinder®, policy management using policy domains and domain objects (realms, rules, responses, policies, and so on) — can still be used to perform manual configuration of security policies for web service resources.

Domains and domain objects must also be used in the following situations:

• To modify policies created traditionally and migrated from a previous CA SOA Security Manager deployment.
• To implement content-based authorization using variables.

Identify the Web Services to Secure

Which web services are you planning to secure? How do they map to the CA SiteMinder® Web Services Security policy management methods?

Begin thinking about the individual web services in your organization and the sets of operations within each web service that require the same level of protection. We recommend identifying the following:

• Logical groupings of resources, often offered by individual web services, that are associated with one or more user populations.
• Sets of individual operations within a web service that have the same security (authentication and authorization) requirements.

Note: Identifying the web services that require protection also aids in capacity planning.

More information:

Capacity Planning Introduced

Identify User Stores

CA SiteMinder® Web Services Security can authenticate and authorize users through one or more connections to existing user stores in your enterprise network. After you identify the web services to secure, consider the following questions:

• Do the web services use a centralized user store or use separate user stores for authentication?
• If the web services use separate stores, does this project include a task to centralize the user identities into a single store?
• Do the web services use the same store to authenticate and authorize users? Or is a separate store or stores used for authorization?

Identifying the stores each web service uses helps you to:

• Identify the user store connections a CA SiteMinder® Administrator must configure in a CA SiteMinder® policy domain to protect the resource.

  Note: For more information about configuring user store connections within a domain, see the Policy Server Configuration Guide.

• Determine if your environment requires the CA SiteMinder® directory mapping feature. By default, CA SiteMinder® assumes that users are authenticated and authorized against the same user store or stores. However, you can configure a CA SiteMinder® policy domain to authenticate against one or more stores and authorize against others.

  Note: For more information about directory mapping, see the Policy Server Configuration Guide.

When gathering information about each web service, use a table similar to the following to organize information:

More information:

Identify the Web Services to Secure

Identify Authentication Methods

CA SiteMinder® Web Services Security supports four authentication methods to meet the varying levels and types of protection your resources require:

XML Document Credential Collector

Validates XML messages using credentials gathered from the message itself by mapping fields within the document to fields within a user directory.

XML Digital Signature

Validates XML documents digitally signed with valid X.509 certificates.

WS‑Security

Validates XML messages using credentials gathered from WS‑Security headers in the SOAP envelope of an incoming message.

CA SiteMinder® Web Services Security can produce and consume WS‑Security tokens, enabling you to use the WS‑Security authentication scheme to deploy a multiple-web service implementation across federated sites.

SAML Session Ticket

Validates XML messages using credentials obtained from CA SiteMinder® Web Services Security synchronized-sessioning SAML assertions (which contain an encrypted combination of a CA SiteMinder session ticket and a CA SiteMinder user public key) placed in the message HTTP header, SOAP envelope, or cookie.

CA SiteMinder® Web Services Security can generate and consume SAML Session Ticket assertions. This enables you to use the SAML Session Ticket authentication scheme to deploy a multiple-web service implementation within a single Policy Server domain.

After you identify the web services to secure, in which we recommend identifying web service operations that share the same security requirements, consider the following questions:

• Are their authentication guidelines, regulations, or laws your organization is required to meet for specific types of resources?
• How sensitive and valuable is the information?
• What types of users are accessing this information?
• What type of security do these users expect?

Answering these types of questions helps you to

• Identify the authentication methods your environment requires
• Identify the authentication schemes a CA SiteMinder® Administrator must configure to protect a specific resource.

  Note: For more information about configuring authentication schemes, see the Policy Server Configuration Guide.

More information:

Identify the Web Services to Secure

Identify Who Will Manage Your SiteMinder WSS Agents

SiteMinder WSS Agents connect to a Policy Server upon startup. The Policy Server contains an Agent Configuration Object (ACO), which directs the associated SiteMinder WSS Agent to the location of its configuration parameters.

How your web services are deployed throughout your organization can help you determine the most efficient method of storing the configuration parameters for your SiteMinder WSS Agents. Consider the following questions:

1. Are most of your web services deployed on a large server farm with the same security requirements?
2. Are most of your web services managed by a centralized person or group?
3. Are most of your web services deployed on separate servers with different security requirements?
4. Are most of your web services managed by different personnel in different departments or physical locations?

CA SiteMinder® Web Services Security offers the following configuration methods:

Central Configuration

If you answered yes to questions one or two in the previous list, try central configuration in which one or more SiteMinder WSS Agents are managed from an Agent Configuration Object (ACO) that resides in the Policy Server. With central configuration, you can update the parameter settings of several SiteMinder WSS Agents at once. Generally, each distinct web service uses a separate ACO, whose settings are shared among all the SiteMinder WSS Agents that protect the web service. For example, if you have five SiteMinder WSS Agents protecting one accounting web service, you can create one ACO with the settings for the web service. All five SiteMinder WSS Agents would use the parameter settings from the same ACO.

For different applications, we recommend using separate Agent Configuration Objects. For example, if you want to protect a human resources web service with stricter security requirements, create a separate ACO for the human resources web service.

When a SiteMinder WSS Agent starts, it reads the value of the AllowLocalConfig parameter of its associated ACO. If the value is set to no, then the SiteMinder WSS Agent uses the parameter settings from the ACO.

Note: We recommend using central agent configuration (wherever possible) because it simplifies agent configuration and maintenance.

Local Configuration

If you answered yes to questions three or four in the previous list, try local configuration in which each SiteMinder WSS Agent is managed individually using a file installed on the server itself. When a SiteMinder WSS Agent starts, it reads the value of the AllowLocalConfig parameter of its associated Agent Configuration Object (ACO). If the value is set to yes, then the SiteMinder WSS Agent uses the parameter settings from LocalConfig.conf file on the application or web server. The parameter settings from the LocalConfig.conf file override any settings stored in an ACO on the Policy Server.If you answered yes to questions three or four in the previous list, try the following configuration method:

Note: For more information about the location of the LocalConfig.conf file on your application or web server, see the corresponding SiteMinder WSS Agent Guide.

You can also use a combination of central and local configuration to meet your needs. For example, you can manage three similar web servers with central configuration, while managing the other two servers with local configuration.

The following questions can help you identify other situations where local agent configuration better serves the needs of your enterprise:

• Will your enterprise deploy custom SiteMinder WSS Agents on XML gateways?

  For example, you want to protect your internal resources with a large group of SiteMinder WSS Agents, while implementing XML gateways in a few locations. You can use local configuration to manage the custom SiteMinder WSS Agents on XML gateways.

• Do you want to allow local server administrators to change some SiteMinder WSS Agent configuration settings but not others?

  For example, your organization uses CA SiteMinder® to manage and enforce security policies, but allows application and web server administrators in remote offices to customize their log on and log off pages. You can add individual parameters to the value of the AllowLocalConfig parameter of the ACO to allow the administrators to change only those settings for the customized pages but no others.

Identify Data Centers

Multiple factors, which are discussed later, can influence how you decide to implement CA SiteMinder® components across multiple data centers. Identifying the data centers and the purpose each is to serve in your CA SiteMinder® environment prepares you to make informed decisions when determining how to implement CA SiteMinder® components. Consider the following questions:

• How many data centers does your deployment include and where is each center located?
• If you have multiple data centers:
  • Will they all be active or are some only intended for disaster recover or backup?
  • Will each protected application reside in a single data center or across multiple centers?
  • Will you configure failover on the data center-level or across data centers?
  • What is the bandwidth and throughput between the data centers?

When gathering information about each data center, use a resource table similar to the following to organize your results:

More information:

Multiple Data Centers

Determine if Advanced Encryption Standards are Required

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

The CA 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 CA SiteMinder® environment only uses AES–compliant algorithms to encrypt sensitive data. A CA SiteMinder® environment can operate in one of the following FIPS modes of operation.

• FIPS–compatibility
• FIPS–only

Note: For more information about the cryptographic libraries CA 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 SiteMinder WSS Agents that ship with CA SiteMinder® 12.52 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 CA SiteMinder®. This requirement includes all agents, custom software using older versions of the CA SiteMinder® Web Services Security SDK. Re–link all such software with the 12.52 versions of the SDK to achieve the required support for FIPS–only mode.

Determine if Virtualization is to be Used

Will CA SiteMinder® be implemented to a virtual environment?

Consider the following before implementing CA 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 CA 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 CA 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 CA 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 CA 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 CA SiteMinder® infrastructure; local Policy Server management can result in more Policy Server and policy stores to manage and upgrade.
• Can make a consistent implementation and management of CA SiteMinder® core objects, policies, and application objects more challenging because CA SiteMinder® administrators are located in disparate business units.

Centralized 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 CA SiteMinder® core objects, policies, and application objects because all CA SiteMinder® administrators are located in the same business unit.
• Can make the management of these objects easier because all CA SiteMinder® administrators are located in the same business unit.

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

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

Determine how to Manage SiteMinder WSS Agents

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

Note: For more detailed information about how to configure Agent-related objects, see the CA SiteMinder® Web Services Security Policy Configuration Guide and the SiteMinder WSS Agent Guide for your SiteMinder WSS Agent type.