Policy Server Guides › Policy Server Configuration Guide › Implementing Policy-based Security

Implementing Policy-based Security

This section contains the following topics:

Strategies for Managing Security and Users

CA IdentityMinder Roles and Access Control

Policy-based Security Overview

Managing users and securing resources successfully are critical aspects of administering an application, a Web site, or a portal. To manage users and secure resources effectively, you must:

Provide users with easy and fast access to appropriate information.
Provide security users can trust.
Protect resources from users who are not allowed access.

Failing to manage users and secure resources effectively can have negative effects on you and your clients, such as:

Jeopardizing resources if security is inadequate.
Losing sales if potential customers lack confidence in the security of your site and avoid the site.
Frustrating customers if the process of accessing resources is cumbersome.
Losing consumer data if you do not track users adequately.

Developing and implementing a strategy that secures your resources and also manages your user base is critical when you build a Web site or Web application.

Strategies for Managing Security and Users

A complete security solution should answer the following questions:

Where is security needed and how much security is needed?
What kind of tasks will be performed? Security-related tasks?
What resources need to be protected and what level of protection is required?
Who has access to the resource and what are they authorized to do?
How is control over user access to protected resources enforced?

Two of the most common methods for managing users and securing resources are access control lists (ACLs) and security policies.

Security policies provide the most complete security solution by defining not only the type of access a user or user group has to a resource but also what happens when a user or user group accesses the resource. Security policies go beyond the capabilities of ACLs by enabling you to manage the user experience. The CA SiteMinder® authorization model is based on security policies.

Access Control Lists

An access control list is an object associated with a resource that defines access privileges for individual users or groups of users. ACLs are associated with resources to establish:

Who can access a resource
What type of access the user has

ACLs provide a straightforward way of granting or denying a specified user or groups of users access to a resource. For example:

The access control list above assigns users in the manager group complete access, users in the clerk group read-only access, and users in all other groups no access to the resource.

Several drawbacks are associated with ACLs:

Controlling a user’s interaction with a resource once the user is authorized and authenticated is difficult. For example, you cannot use ACLs to define session timeouts.
Managing ACLs for large numbers of resources can be prohibitively time consuming and costly. ACLs create a significant administrative burden.
Profiling user information is difficult. Users are added to ACLs, which are then associated with resources, making it difficult to determine all of the resources a user has access to at any given moment.
Qualifying access rights is difficult. It’s virtually impossible to restrict access based on a time or a location.
Personalizing content and defining responses is difficult. If a user has access to a resource, it’s difficult to personalize the content or define what happens when the user is allowed or denied access. For instance, you can’t use an ACL to display or hide a set of buttons when the user accesses the resource.

ACLs are an effective way to protect a resource but an ineffective way to manage the user experience.

SiteMinder Security Policies

Unlike ACLs, policies serve a dual purpose: policies provide security and manage the user experience. Policies are user-centric: policies are constructed around the user group rather than the resource.

Policies define access permissions using rules, responses, and time/location constraints. Policies are then associated with users or user groups to establish:

Where the resource is located
Who can access a resource
What type of access the user has
When they can access a resource
What happens when they access the resource
What happens if they can’t access the resource

The following graphic provides a definition of a CA SiteMinder® security policy.

Illustration showing how a SiteMinder security policy is defined

Policies provide an effective means of managing users and securing resources for the following reasons:

Policies provide more granularity and the ability to personalize content. Responses enable you to define what happens when a user is allowed or denied access, such as which graphics are shown if a user is allowed access or where to redirect the user if the user is denied access.
Policies are easy to maintain. When a user is modified, added to the group, or deleted from a group, all policy definitions that include the user are automatically updated.
Policies provide fine-grained security. Policy definitions can include time restrictions and location (I.P.) restrictions.

Because of the power and flexibility of policies, authorization models based on security policies are more efficient and effective than models based on ACLs.

Manage the End-user Experience

In addition to securing resources, policies in CA SiteMinder® can be used to manage the end-user experience by:

How Privileges Are Established

In a policy, the privilege to access a resource is established by adding a rule to a policy. Rules identify specific resources and either allow or deny the user access to the resources. A single policy can establish privileges for many users: policies can be associated with an individual user, a user group, or the members of an entire user directory.

For example, in the following graphic:

Group 1 has been assigned Rule A and can access resources 1 & 2,
Group 2 has been assigned Rule B and can access resources 3 & 4, and
Group 3 has been assigned both rules and can access all resources.

How Content Is Personalized

Once a user has been granted access to a resource, the policy can then personalize the user’s view of the resource. Policies can customize the view of a resource through the use of responses. Responses are paired with rules and are triggered when a rule fires.

For example, in the following graphic, both Group 1 and Group 2 can access the Resource dialog. However, the view each group has of the dialog differs. The policy for Group 1 uses Response A, which does not provide two buttons (Open Account and Modify Account) or the Platinum tab that Response B makes available.

Graphic showing how the content is personalized using responses for two different groups

How Sessions Are Managed

By managing sessions, you control how long an authenticated and authorized user can access the resource. You can control sessions by:

Specifying the amount of time a user can remain idle, without interacting with the resource.
Idle timeouts protect against unauthorized use of the resource by limiting the amount of time the session remains active if it is not being used. The idle timeout is particularly useful in cases where users leave their computer without logging out of their session. When the idle timeout limit is reached, the session automatically ends.
Specifying the maximum amount of time a user can access a resource before they must re-authenticate.
Maximum timeouts protect against unauthorized use of a resource by forcing an authenticated user to re-authenticate after a specified time. This safeguard ensures that if an authenticated user leaves the computer without logging out and someone else uses the open session, the session will end after a specified amount of time, and the user must re-authenticate to continue using the resource.
Revoking a user’s access to a resource at any time.
In addition to managing how long a session can remain active, you can also end a session immediately if you suspect the integrity of a resource has been compromised. Once a user session has been revoked, the user is disabled in the user directory until you have re-enabled the user using the Administrative UI.

Note: More information about managing sessions exists in the Administration Guide.
Enabling persistent sessions.
You can also implement persistent sessions to provide Windows security context functionality and support for Federated Web Services.

More information:

How Privileges Are Established

How Content Is Personalized

How Persistent Sessions for User Security Contexts Are Maintained

Security Model Implementation

To implement a security model that best meets the needs of your organization, you may create security policies using information gathered in the design phases shown and described below.

Graphic showing the design phase of a security model

Organization and resource requirements—set the basic objective of the security model and identify the resources.
Task assessment requirements—identify users and roles, and link the roles to tasks.
Access control requirements—establish access requirements for users based on their role requirements.
Authorization models based only on access control lists (ACLs) end at this point.
Implementation requirements—define how the access is implemented (in terms of how users are tracked and how content is personalized for users) and how user sessions are managed.
Authorization models based on CA SiteMinder® security policies incorporate both access control and implementation models.

More information:

Define Task-Assessment Requirements

Organization and Resource Requirement Considerations

Organize Security Model Requirements

When completing each phase of the security model design methodology, use a table similar to the one shown below to organize your information. Once you have completed the columns in this table, you can use the information to build CA SiteMinder® security policies.

Resource	Role	Task	Access	Implementation

Organization and Resource Requirement Considerations

Before you can setup a security model, you must establish the organization and resource needs of your organization. Some general issues to consider include:

Are there security guidelines, regulations, or laws your organization is required to meet?
If security needs conflict with business requirements, which requirements take precedence?
Has a lack of security affected the reputation of your organization?
Have security incidents in the past caused financial loss or taken down the site?
Once you have established the overall security requirements and concerns, you are ready to define the more specific security requirements outlined below.

How Organization Security Requirements Are Defined

To determine the more specific security needs, consider the following issues:

These organization requirements:	Affect these tasks:
Who requires access to the resources? How much access do they require? Can you categorize users with similar access requirements into groups?	Configuring user directory connections
Which resources require protection? Do different resources require different levels of protection?	Creating policy domains and realms
How sensitive and valuable is the information? How much do you trust your users? Are your users local or remote? What type of security do your users expect? Will you lose customers if security does not match their expectations?	Creating authentication schemes using authentication templates
Are there security guidelines, regulations, or laws your organization is required to meet? Do different objects require fine-grained protection or personalization? What type of actions do you want to control?	Defining rules
What type of security and controls do your users and customers expect? Do different groups of users require different views of the resource? What events should take place when a user is authenticated or authorized?	Defining responses
How will you implement your requirements?	Defining policies

Identify Resources and Roles

The second part of establishing organization requirements is to identify resources and map resources to roles.

The purpose of this step is to link resources with roles. By linking these two components, you will have a better understanding of what needs protection and what type of protection is required.

When identifying resources:

Identify all known resources, including resources that are planned but do not yet exist. Planning security for all known resources at once, whether they currently exist or not, will save you time.
Create a site map for Web sites to better understand the structure of the resources.

How this applies to policies:

Resources are defined in realms and rules. Roles of users are implied based on the user group to which they belong or based on their user attributes. In an airline application, for example, a user belonging to the Pilot user group would perform tasks associated with the Pilot role.

To identify resources and roles

Using a table or chart similar to the security model table described earlier in this chapter, list the resources in the Resources column.
Identify all subdivisions of a single resource. For example, if a directory called /bidding had two subdirectories below, such as /bidding/flights and /bidding/standby, both subdirectories would be listed as resources. By treating each subdirectory as a separate resource, it will be easier to determine if each resource requires separate security.
Next to each resource, list the roles that will need access to the resource.

Define Task-Assessment Requirements

Task assessment requirements bridge the gap between roles and access-control requirements. When you identify task-assessment requirements, you define the tasks each role performs using the resource.

How this applies to policies:

Although tasks are not specifically defined in policies, you will use this information when assessing access rights for each resource-role pairing in the next section.

To define task-assessment requirements

For each role, identify the tasks the role must perform using the resource.
Enter the task in the Task column, next to the associated resource and role.

More information:

Define Access Control Requirements

Organize Security Model Requirements

Organization and Resource Requirement Considerations

Define Implementation Requirements

Define Access Control Requirements

Access control requirements establish whether or not a role requires access to a resource, and if so, the type of access they require. Two roles that access the same resource may not require the same access to the resource.

For example, two groups of users might perform tasks in the same directory. Group A might use this resource to view and modify the resource, while Group B members would view the resource. Because each user group uses the resource in a different way, access rights would differ:

Group A: Get, Post
Group B: Get

How this applies to policies:

Access rights are defined in rules.

To define access control requirements

For each task, identify the type of access that is required to perform the associated task.
Enter the access requirement in the Access column.

Define Implementation Requirements

Implementation requirements define how the resource is used. How a resource is used can be configured by many variables, including:

Personalization
Time limitations for using the resource
Redirections

How this applies to policies:

Implementation requirements are defined in responses.

To define implementation requirements

For each task, identify how access should be implemented.
Enter the implementation requirement in the Implementation column.

With the security model information complete, you can begin constructing policies that are appropriate for your site.

More information:

Organize Security Model Requirements

Organization and Resource Requirement Considerations

Define Task-Assessment Requirements

SiteMinder Application Roles

Application roles let you specify a group of users for access control based on your organization's business requirements.

CA SiteMinder® Administrators create and assign roles that determine access to a protected application. For example, a business rule may require that only employees with the title "accountant" use a financial application. A CA SiteMinder® Administrator creates a role whose membership is to include employees with the "accountant" title. The administrator then creates an application security policy to protect the application, associating the role with the policy. The policy protects the financial application and only authorizes users with the "accountant" title.

Unlike adding users and user groups to a policy, the scope of roles is not limited to a single directory nor is it limited to a specific directory type. A CA SiteMinder® administrator expresses business requirements in the Administrative UI by creating membership expressions. Membership expressions map to specific LDAP and ODBC user directory attributes. The CA SiteMinder® administrator then defines the role using the membership expressions. As a result, roles are not dependent on user directory-specific attributes and can span across multiple user directories.

Note: More information on application roles exists in Enterprise Policy Management.

CA IdentityMinder Roles and Access Control

If you have integrated CA IdentityMinder and CA SiteMinder®, you can implement policy–based access control using CA IdentityMinder roles. CA IdentityMinder roles enable centralized management of user privileges in external applications.

Note: Fore more information about configuring the integration, see the CA Identity Manager documentation.

The integration requires that:

The Policy Server installation includes the required data definitions for the CA Identity Manager integration at the following location.
```
siteminder_home\xps\dd
```
siteminder_home

Specifies the Policy Server installation path.
The name of the file is:
```
IdmSmObjects.xdd
```
Important! Do not import this file in to the policy store until you have completed the CA IdentityMinder integration. If you import the data definitions before completing the integration, the Policy Server can reach an indeterminate state. Coordinate the integration with your CA IdentityMinder administrator.
CA IdentityMinder administrators manage environments and roles in CA IdentityMinder to determine user access to the applications that CA SiteMinder® secures. The CA SiteMinder® Administrative UI refers to these environments as an IDM environment.
Note: For more information about environments and roles, see the CA IdentityMinder documentation.
CA SiteMinder® administrators use the Administrative UI to associate one or more IDM environments to a policy domain and user directory. A CA SiteMinder® administrator cannot create or manage an IDM environment.
CA SiteMinder® administrators use the Administrative UI to create a policy and associate one or more roles that are available to the IDM environments. A CA SiteMinder® administrator cannot create or manage a CA Identity Manager role.
Note: You cannot apply a CA IdentityMinder role to an enterprise management application.

CA SiteMinder® can also provide details about entitlements that a CA IdentityMinder user has in protected applications. As the following figure illustrates, a CA SiteMinder® administrator associates a response with an access rule in the policy. The response contains a response attribute that specifies a CA SiteMinder®–generated user attribute.

The CA SiteMinder®–generated user attribute retrieves task information from CA IdentityMinder. The Policy Server passes this information to the web agent as an HTTP header variable or a cookie. The web agent makes the header variable or cookie available to the protected application for fine–grained access control.

Graphic showing a CA Identity Manager Environment implementing fine-grained access control