This section contains the following topics:
Policy-based Security Overview
Strategies for Managing Security and Users
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.
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.
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:
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.
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.
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.
In addition to securing resources, policies in SiteMinder can be used to manage the end-user experience by:
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:
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.
By managing sessions, you control how long an authenticated and authorized user can access the resource. You can control sessions by:
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.
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.
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.
You can also implement persistent sessions to provide Windows security context functionality and support for Federated Web Services.
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.
Authorization models based only on access control lists (ACLs) end at this point.
Authorization models based on SiteMinder security policies incorporate both access control and implementation models.
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 |
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Before you can setup a security model, you must establish the organization and resource needs of your organization. Some general issues to consider include:
To determine the more specific security needs, consider the following issues:
|
These organization requirements: |
Affect these tasks: |
|---|---|
|
Configuring user directory connections |
|
Creating policy domains and realms |
|
Creating authentication schemes using authentication templates |
|
Defining rules |
|
Defining responses |
|
Defining policies |
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
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
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
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
With the security model information complete, you can begin constructing policies that are appropriate for your site.
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.
|
Copyright © 2012 CA.
All rights reserved.
|
|