Previous Topic: Configuration OrderNext Topic: Administrative User Interface Management


Implementing Policy-based Security

This section contains the following topics:

Policy-based Security Overview

Strategies for Managing Security and Users

Security Model Implementation

SiteMinder Application Roles

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:

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

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:

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 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:

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

Illustration showing an example of Access control list

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:

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:

The following graphic provides a definition of a 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:

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 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:

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:

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

  1. Organization and resource requirements—set the basic objective of the security model and identify the resources.
  2. Task assessment requirementsidentify users and roles, and link the roles to tasks.
  3. Access control requirementsestablish access requirements for users based on their role requirements.

    Authorization models based only on access control lists (ACLs) end at this point.

  4. Implementation requirementsdefine 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 SiteMinder security policies incorporate both access control and implementation models.

More information:

Organization and Resource Requirement Considerations

Define Task-Assessment Requirements

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 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:

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:

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

  1. Using a table or chart similar to the security model table described earlier in this chapter, list the resources in the Resources column.
  2. 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.
  3. 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

  1. For each role, identify the tasks the role must perform using the resource.
  2. 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:

How this applies to policies:

Access rights are defined in rules.

To define access control requirements

  1. For each task, identify the type of access that is required to perform the associated task.
  2. 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:

How this applies to policies:

Implementation requirements are defined in responses.

To define implementation requirements

  1. For each task, identify how access should be implemented.
  2. 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.

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