CA SiteMinder® policy management models let you define access permissions for web resources and their respective user populations. A policy 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.

All CA SiteMinder® 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:

Applications
Policy domains and domain objects

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

A host configuration object
An agent configuration object
An agent object
A user directory object
Note: For more information about these objects, see the Policy Server Configuration Guide.

Policy Management Using Application Objects

Application objects provide an intuitive method of defining a complete security policy for a web application, website, or web service. Applications associate resources with user roles to specify entitlement policies that determine what users can access what resources.

Note: An application object defines policy information that can otherwise be configured in a policy domain and its subobjects. That is, realms, rules, rule groups, responses, and policies. The following table summarizes this relationship.

Application Dialogs and Group Boxes	Equivalent Domain Component
General settings	Policy domain and the root location of the protected resources.
Components	Realm and the location of the resources within the application that share the same security requirements.
Resource	Rule and the required authentication or authorization actions.
Application Roles	User directory lookups.

Note: For more information about policy management using applications, see the Policy Server Configuration Guide.

Policy Management Using Policy Domains and Domain Objects

Before SiteMinder r12.0, policy domains and domain objects (realms, rules, responses, policies, and so on) were the only way to protect resources. For Policy Server administrators already comfortable with them, policy domains and domain objects can still be used to configure security policies for resources.

A CA SiteMinder® policy is comprised of the following individual CA SiteMinder® objects:

A domain
At least one realm in the domain
At least one rule or rule groups in the domain
(Optional) One or more responses or response groups in the domain

A policy object binds these core objects to identify resources, user populations, and the required actions when CA SiteMinder® grants or denies access to the resource. As such, configuring a CA SiteMinder® policy requires an understanding of each object.

Note: For more information about each of these objects and their individual CA SiteMinder® policy roles, see the Policy Server Configuration Guide.

Identify the Applications to Secure

Which applications are you planning to secure? How do they map to the CA SiteMinder® access management models?

Begin thinking about the individual applications in the organization and the individual resources (URLs) within each application that require the same level of protection. We recommend identifying the following:

Logical groupings of resources, often an individual application, that are associated with one or more user populations. These logical groupings map to either a CA SiteMinder® policy domain or the resource filter of an EPM application. A CA SiteMinder® policy domain or the resource filter of an EPM application represent the root location of the application.
Sets of individual resources (URLs) within an application that have the same security (authentication and authorization) requirements. Sets of resources that share the same security requirements map to either a CA SiteMinder® policy realm or an EPM application component.

Grouping resources in this way helps you map applications to the CA SiteMinder® access management models.

When gathering information about each application, use a resource table similar to the following to help organization information:

Resource	Domain/Application Resource Filter	Realm/Component Resource Filter
Example: Corporate Portal	Example: Performance Management application	Example: Manager resources

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

More information:

Capacity Planning Introduced

Ignore Extensions Parameter

Group Resources into Domains or EPM Applications

Defining a CA SiteMinder® policy domain or an EPM application depends on identifying logical groups of resources, often an individual application, that are associated with one or more user populations. Grouping resources at this level helps you to identify the sets of individual resources (URLs) within an application that share the same security requirements.

Note: For more information about a CA SiteMinder® policy domain or an EPM application, see the Policy Server Configuration Guide.

A strategy for determining these requirements is to review a site map of the organization.

For example, a fictitious company, has a corporate intranet that the following site map represents:

Graphic showing resources grouped into Domains or EPM Applications

In this example, the corporate portal is separated into the following logical groups of resources:

Learning
Performance Management
Support
Business Tools
Corporate

The resource table for the corporate intranet looks like the following:

Resource	Domain/EPM Application Filter	Realm/Component Filter
Corporate Intranet	intranet.example.com	N/A
Learning	intranet.example.com/learning	N/A
Performance Management	intranet.example.com/performance	N/A
Support	intranet.example.com/support	N/A
Business Tools	intranet.example.com/tools	N/A
Corporate	intranet.example.com/corporate	N/A

More information:

Domains and Authentication Performance

Group Resources into Realms or EPM Components

Defining a CA SiteMinder® policy realm or an EPM component depends on identifying sets of individual resources (URLs) that share the same security or personalization requirements within a CA SiteMinder® policy domain or EPM application. The contents of a realm or EPM component share the same authentication scheme. As a result, identifying these resources early in the process can help you determine the authentication schemes required to meet individual security requirements.

Note: For more information about CA SiteMinder® policy realms and EPM components, see the Policy Server Configuration Guide.

For example, although the Performance Management and Business Tools applications each let a specific user population access the root of the application, each application contains additional CA SiteMinder® policy realms or EPM components to provide a level of security or personalization appropriate for the resource:

The Performance Management application contains resources that only full–time employees can access and resources that only managers can access.
The Business Tools application contains resources that only Research and Development employees can access and resources that only Marketing employees can access.

Note: Although not illustrated, CA SiteMinder® policy rules and EPM resources are used to control specific Web Agent, authentication, and authorization events. For more information, see the Policy Server Configuration Guide.

Graphic showing resources grouped into realms or EPM components

The resource table for the applications looks like the following:

Resource	Domain/EPM Application Filter	Realm/Component Filter
Corporate Intranet	intranet.example.com	N/A
Learning	intranet.example.com/learning	N/A
Performance Management	intranet.example.com/performance	/employee /manager
		/employee /manager
Support	intranet.example.com/support	N/A
Business Tools	intranet.example.com/tools	/engineering /marketing
		/engineering /marketing
Corporate	intranet.example.com/corporate	N/A

Identify User Stores

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

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

Identifying the stores each application 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 application, use a table similar to the following to organize information:

User Store Name	User Store Type	Authentication?	Authorization?

Identify Authentication Methods

CA SiteMinder® supports multiple authentication methods to meet the varying levels of protection your resources require:

Basic	MIT Kerberos
Forms-based user ID and password	Server-based, such as RADIUS and SafeWord
Hardware and software token-based, such as RSA^® Ace/SecurID^®	X.509 Certificate-based
Integrated Windows Authentication (IWA)	Custom Authentication schemes created using the CA SiteMinder® SDK
Information Card Authentication Schemes (ICAS), such as Microsoft Windows CardSpace

After you identify the applications to secure, in which we recommend identifying sets of resources (URLs) 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.

When gathering information about each resource, we recommend organizing your information by the applications you plan on securing. For example, the following table assumes that an application is grouped into individual domains and realms, as detailed in applications to secure.

Resource	URL	Realm	Authentication Method

Identify Password Management Options

Do any security policies require your organization to manage user passwords? Do you anticipate managing user passwords in the future?

You can use CA SiteMinder® password policies to enforce the password requirements of your enterprise. A password policy can validate the user's password against any of the following types of characteristics before accepting it:

Composition

Verifies the minimum or maximum length, the types of characters allowed, and if or how often any of those characters can be repeated in a password.

Age

Verifies the time limits for how long the same password can be used, how long a password can remain inactive before it must be changed, and how long or how often before an expired password can be reused. You can specify one of the following responses for users with expired passwords:

disable their accounts
force them to change their passwords

Attempts

Records the number of times the user has previously entered an incorrect password, and takes one of the following actions when that number is exceeded:

disables the account.
waits a specified time period before allowing either one login attempt or reenabling the account.

Note: For more information, see the CA SiteMinder® Policy Server Configuration Guide.

Password Policy Considerations

If you plan to implement password policies in your enterprise, consider the following:

CA SiteMinder® requires read/write access to the user directory, including exclusive use of several attributes within that directory to store passwords and password–related information.
Password policies can affect CA SiteMinder® performance because of the additional user directory searches required to validate passwords. Password policies that are configured to search only part of a user directory, instead of the entire directory, can also affect performance.
If your user directory has a native password policy, this policy must be:
- Less–restrictive then the CA SiteMinder® password policy or
- Disabled
Otherwise the native password policy accepts or reject passwords without notifying CA SiteMinder®. Consequently, CA SiteMinder® cannot manage those passwords.
By default, if a user enters incorrect information when changing a password, CA SiteMinder® returns a generic failure message. This message does not specify the failure reason. Create and enable the DisallowForceLogin registry key to change the default behavior and explicitly tell users why the change failed.
If you use password policies on multiple Policy Servers, synchronize the system times of all servers. Synchronizing times helps to avoid the disabling of accounts or forcing password changes prematurely.
Note: For more information, see the CA SiteMinder® Policy Server Configuration Guide.

Identify Who Will Manage Your Web Agents

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

How your applications are deployed throughout your organization can help you determine the most efficient method of storing the configuration parameters for your CA SiteMinder® Web Agents. Consider the following questions:

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

If you answered yes to questions one or two in the previous list, try the following configuration method:

Central Configuration

Manages the parameters for one or more agents from an agent configuration object (ACO) that resides in the Policy Server. With a central agent configuration, you can update the parameter settings of several agents at once. Generally, each distinct web application uses a separate ACO, whose settings are shared among all the agents that protect the web application. For example, if you have five agents protecting one accounting application, you can create one ACO with the settings that you want for the application. All five 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 application with stricter security requirements, create a separate ACO for the human resources application.

When an agent starts, it reads the AllowLocalConfig parameter values of its associated ACO. When the value is set to no, then the agent uses the parameter settings from the ACO (except the agent log and trace file settings). Agent log files and trace files can always be controlled locally, regardless of ACO settings.

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

If you answered yes to questions three or four in the previous list, try the following configuration method:

Local Configuration

Manages each Web Agent individually using a file installed on the web server itself. When a Web 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 Web Agent uses the parameter settings from LocalConfig.conf file on the web server. The parameter settings from the LocalConfig.conf file override any settings stored in an ACO on the Policy Server.

Note: For more information about the location of the LocalConfig.conf file on your respective web server, see the Web Agent Configuration Guide.

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

Will your enterprise deploy some of your Web Agents on reverse proxy servers?
For example, you want to protect your internal resources with a large group of Web Agents, while implementing reverse-proxy servers in a few locations. You can use local configuration to manage the reverse-proxy Web Agents.
Do you want to allow local web server administrators to change some Web Agent configuration settings but not others?
For example, your organization uses CA SiteMinder® to manage and enforce security policies, but allows 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.

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

Central and Local Configurations Together

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. See the following illustration for an example:

Graphic shows that centerally configured agents receive Parameter Settings from a Single Object on the Policy Server while Locally-configured agents receive parameter settings from a local computer file

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:

Data Center Name	Location	Purpose

More information:

Multiple Data Centers

Identify Resources to be Secured with Multiple Cookie Domains

Will the single-sign on environment in your enterprise extend across multiple cookie domains?

CA SiteMinder® implements single sign-on across multiple cookie domains using a CA SiteMinder® Web Agent configured as a cookie provider.

The cookie domain where the cookie provider Web Agent resides is named the cookie provider domain. All the other Web Agents from the other cookie domains within the single sign-on environment, point to one cookie provider.

The following illustration shows an example of an SSO environment using multiple cookie domains:

Graphic showing how users who authenticate to one domain can go to another without being re-challenged for their credentials

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

Load-balancing for SSO between Cookie Provider Domains and Other Cookie Domains

Will the Agents in your single-sign on environment use load-balancing?

All agents in an SSO environment must refer to a single cookie provider domain. Add a load-balancer between the web servers in your cookie provider domain and the other cookie domains in your SSO environment. The following illustration shows an example:

Graphic showing Multiple Domains in an SSO Environment Using a Load Balancer In Front of the Domain Hosting the Cookie Provider

The Web Agent in the example.org cookie domain points and the Web Agent in the example.com cookie domain both point to the same cookie provider domain of example.net. A load-balancer distributes the traffic evenly between all the web servers in the example.net cookie provider domain.

Determine if Partnerships Require CA SiteMinder® Federation

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

CA SiteMinder® Federation lets you extend CA SiteMinder® functionality to partner sites by enabling identity federation. CA SiteMinder® Federation offers two deployment options: legacy federation and partnership federation.

Federated transactions between partner organizations let your enterprise:

Exchange user identity 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 that is received from a partner.
Allow interoperability across heterogeneous environments.

CA SiteMinder® Federation lets your enterprise generate, consume, or generate and consume assertions. CA SiteMinder® Federation supports the following standards and protocols:

SAML 1.0 (legacy federation only)
SAML 1.1 and 2.0
Microsoft ADFS/WS-Federation (legacy federation only)
SAML browser artifact protocol
SAML POST protocol
WS-Federation Passive Requestor Profile protocol (legacy federation only)

Note: CA SiteMinder® Federation is separately licensed from CA SiteMinder®. Contact your CA account representative for more information about licensing. For more information about federation, see the CA SiteMinder® Federation Legacy Federation Guide or the CA SiteMinder® Federation Partnership Federation Guide.

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

Partner	Standard	Protocol

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–migration
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 Web Agents that ship with CA 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 CA 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 12.52 versions of the respective SDKs 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.
- If single sign–on is a requirement, local Policy Server management results in additional CA SiteMinder® configuration. As illustrated, Policy Servers in both business units must share a key store to let all CA 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 CA SiteMinder® core objects, policies, and EPM applications more challenging because CA SiteMinder® administrators are located in disparate business units.

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

Graphic showing 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 CA SiteMinder® core objects, policies, and EPM applications 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.

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

Graphic showing 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.