Policy Managers Guide
|
 |
 |
|
|
 |
 |
This section covers the following topics:
Creating policies to use with BEA WebLogic Enterprise Security is a multi-step process and this section contains an overview of the general steps for managing that process. A well-written policy accurately represents the business and security rules for your enterprise, is easy to manage, and is designed for maximum efficiency. It is important to carefully design your policy with these goals in mind.
A simple administration policy is provided for you as an example. This security policy defines some default security roles and rules that protect the Administration Server and Administration Console resources. For a more detailed overview of what this policy is, see Admin Policy in the BEA WebLogic Enterprise Security Administration Guide.
You manage your policies based on your specific security needs and business processes. Although your security configurations, resources, users and groups, roles, and rules vary, you can use the following conceptual examples to understand the basic building blocks and how they work together. Managing policy starts with understanding how your business rules are associated with your resources, and how your users interact with those resources.
Sometimes business application users informally define the business rules. Sometimes, formalized business rules are created by a business analyst (or others) who has a more complete understanding of the requirements for an application.
Business rules may be recorded in a spreadsheet, table, or other detailed description and may appear as a series of declarative statements, for example:
When you define your business rules or evaluate your security risks, you identify resources that you need to protect, the privileges to allow, and the rules and conditions that apply for each user or group of users.
A resource is simply an object used to represent an underlying application or application component, that can be protected from unauthorized access using roles and policies. The number or resources that require protection is always increasing and forever changing. Resources are hierarchical in nature; thus, when you assign a policy to a resource, all child resources inherit that policy. Policies assigned to child resources or attributes override policies assigned to a parent resource.
Developing a policy typically begins by determining which resources you need to protect. You then create roles and rules to define which privileges apply to each resource, and under what specific conditions. Next, policy rules are created that control which users and groups belong in these roles, and under what conditions. Once these policies are deployed, the Security Service Modules apply these policies to the resources they are managing.
BEA WebLogic Enterprise Security can be used to define and implement the following types of security policies:
Once you determine the environments you want to protect, you configure the security services to be used in that environment. Your configuration policy is managed through the Administration Console and each Security Services Module may have a unique or shared configuration.
The configuration policy includes setting up the desired services for each of the supported service types: authentication, authorization, auditing, role mapping, and credential mapping. Each type of service may have one or more security providers configured, depending on your specific needs. For example, you might install a Security Service Module in a web server and authenticate incoming users against a customer database-controlling which parts of the application user interface the user can access based on their role in the organization-and pass their identity to the application server behind the firewall. In this case, you might configure the following providers:
BEA WebLogic Enterprise Security includes five service types and each one is optional. In addition, you may have multiple authentication providers configured, for example you can authenticate users against either an LDAP or a database. For detailed information on how each service is implemented, see Security Services in the Introduction to BEA WebLogic Enterprise Security.
You can use the providers included with the product or you may use a custom provider developed by a third-party vendor. Custom providers are configured using their own security policy and are generally managed externally, rather than managed through the Administration Console. For detailed information on how to develop a customer provider, see Developing Security Providers for BEA WebLogic Enterprise Security.
An authentication policy determines whether the subject (user or group) is known to a trusted authentication service. The service may use Active Directory, a database, an LDAP directory, or even a legacy application to access user profile information. The method of authentication you select depends on the type of user directory and authentication method desired or on the form of identity you accept from a trusted external source (see Table 2-1). For example, a web application might require a simple username and password schema, whereas a financial application might require some additional form of authentication.
Authentication policy is defined by:
Users, groups and their attributes are typically stored in an external data directory that you access through a metadirectory. For additional information on configuring a metadirectory for use with BEA WebLogic Enterprise Security, see Configuring Directories, as described in Administration Application Installation.
In BEA WebLogic Enterprise Security, the identity is called a subject and refers to the users and groups incorporated into your policies, through roles. User and group data, along with their attributes, are typically stored and managed in external directories and databases, and are gathered into the subject at the time of authentication. The metadirectory in which your users and groups are stored, is referred to simply as a directory from within the Administration Console. You can also create additional directories, users and groups through the Administration Console. A user or group is represented using the directory name, as follows:
where dir represents the name of the directory to which the user (user) or group (sgrp) belongs.
While user data changes less frequently, group membership changes even less frequently. Typically, for ease-of-management, you want to design a policy that applies to a large community, as establishing policies for each and every user can be very time consuming and does not scale well. Organizational structure, in the form of groups, corresponds well to typical business policies and is very useful for determining role membership. Typically, a group hierarchy is based on an organization model of the company, although this is not necessary. For example, the source of your user data might be an employee database, where a user belongs to four groups: the employee group, the Sales department group, the London office group and the star-salesmen group.
Thus, you want to create groups of users (or groups of groups), whose tasks are related and for whom the policy enforcement is the same. In the following example (see Figure 2-1), Tellers are assigned to the Teller Group.
A user or group can contain attributes that further describe their characteristic—who they are and what they can do; these are referred to as identity attributes. You can use these identity attributes to define dynamic conditions for a role to which a user or group belongs. For example, consider that account balance is an attribute of a user. To allow customers with an account balance over $100,000 to access the premier banking features of your application, you could write a role rule that only allowed access to the application if the customer were in a specific role.
Grant(//role/premierbanking,//app/policy/bankapp, //sgrp/bankusers/customers/) if accountbalance > 100000
This role rule allows customers who belong to the premierbanking role, to access the resource called bankapp, if they have an accountbalance of over $100,000. The accountbalance is included for each customer in the bankusers group (sgrp) as an attribute.
User privilege is also based on the roles the user may hold at the time an access request is made. Unlike groups, which are relatively static and persist for the session, roles are highly dynamic and are assigned to users by processing role policies. Role mapping significantly reduces the number of policies required and makes features like delegation easy to manage.
Role policies are combined with authorization requests (this is done automatically for you), or are directly accessed to support uses like application or portal personalization. If you configure the role mapping service, role policies can also use the same conditions that are available for the authorization service.
The basic format of the role rule looks like this:
grant|deny(role, resource, group|user) IF condition
Where grant or deny is the privilege, role defines the role that applies, resource defines the application or application component to protect, group specifies what users and groups belong to the role, and condition applies any constraints to apply to the role rule.
After you determine who the authenticated users are, you delineate their responsibilities by determining what role they play and the groups to which they belong. A role may apply to one or more users and usually refers to some group of related tasks. For example, a group of bank tellers might have access to the same group of applications (resources) to perform specific banking tasks; thus, you might have a role called Teller Role and assign your group of tellers to that role. Figure 2-2 shows a group of tellers who belong to a teller group. The tasks they perform in your organization can then be grouped into roles.
For example, individuals or groups may be assigned the Teller Role, to which anyone who is a member can access specific resources and perform the same specific tasks. You can apply restrictions and conditions to access of the resource by defining the rules that apply to a role. The privileges or actions allowed on that resource are defined by an authorization policy. Now, anyone who does not have a Teller Role does not have access to the TellerApp.
Figure 2-2 Role Mapping Policy
A role mapping policy is designed by:
An authorization service manages the interactions between users and resources, by defining the type of action the user may take. This action is referred to as a privilege. An authorization policy defines the tasks the requesting user can do with the requested resource, optionally based on conditions.
A resource is simply an object used to represent an underlying application or application component (or any resource), that can be protected from unauthorized access using roles and policies. Resources are often hierarchical in nature; thus, when you assign a policy to a resource, all child resources inherit that policy. Policies assigned to child resources override policies assigned to the parent resource. An authorization policy is designed by:
You can assign policies to any of the defined resources, or to attributes or operations of a particular instance of a resource. Authorization policies are specific to the Authorization provider configured.
A resource represents anything to which you can grant, deny or delegate roles or privileges, and any conditions that apply.
Some typical resources that you might want to secure, include:
Note: In development mode, you may use the Resource Discovery tool to help define resources for a particular application. For more information, see Resource Discovery.
In our example (see Figure 2-3), the teller group is granted (or denied) access to the TellerApp resource.
Resources can contain attributes that provide additional data about what that resource is and who may access it. For example, filetype could be a resource attribute that you use to define an html, image, jsp, or pdf file type. Then, you could grant access to all pdf files in a directory by adding the condition: if filetype = pdf.
A privilege represents an action or task in your business policy.
Each rule is structured using the following general syntax:
grant(privilege, resource, subject) IF condition1, and condition2, and condition3;
For example, if you have the policy rule "Only Managers can open an account," "OpenAccount" might be one of your privileges, while Managers represents the role (comprised of users and/or groups of users). Remember, the target of the operation is the resource. Now, to add the privilege for LeadTellers (the role) to open an account (the privilege), the rule might look like this:
grant(//priv/OpenAccount, //app/policy/TellerApp, //role/LeadTellers)
if time24 in [900..1700] AND
dayofweek in [Monday..Friday];
where the account can only be opened (OpenAccount is the privilege), using the TellerApp (TellerApp is the resource), by anyone belonging to the specified role (LeadTellers is the role), between the time of 9:00 AM and 5:00 PM (a time condition), on Monday through Friday (a date condition).
There are many types of conditions included with the ASI Authorization and ASI Role Mapping providers. You can use any of the built-in conditions in your rules. For detailed information on designing rules and using conditions, see Defining Rules.
You typically want to apply conditions to define the time of day or the days of the week when a user or group can access the resource and perform a task. Conditions may contain one or more comparative statements joined using a Boolean operator (for example, AND, OR, or NOT). If the result of the entire expression evaluates to true, then the policy statement is true for the selected privileges, resources, and policy subjects.
Once you determine the conditions for the rule, you can define conditions, such as time, date, etc. For example, the following rule might be generated for our authorization policy:
GRANT(any, //app/policy/TellerApp, //sgrp/directory/tellers/)
if time24 in [900..1700] AND
if dayofweek in [Monday..Friday] ;
This policy rule grants access to all users belonging to the group called tellers to the resource called TellerApp, from 9:00 AM to 5:00 PM, Monday through Friday.
Many types of conditions may exist when a rule is applied. Often, these include conditions based on contextual data available from the application. For example, a transaction amount passed in as a parameter to an EJB method. In some cases, a rule could require dynamic data not available in the application and the provider would need to retrieve it from another source or compute it from another piece of data. This requires more advanced application development, but can be accomplished through the use of ARME Plug-ins. For additional information, see "Provider Extensions" in the Administration Guide.
Policy can also be applied by delegating a role or privilege from one user or group to another user or group. This is called delegation. For example, a manager may delegate the ability to approve expense reports to his assistant manager.
DELEGATE (any, //app/policy/TellerApp, //user/TellerApp/john/, //user/TellerApp/amy/)
delegates privileges related to the TellerApp application from amy to john.
The auditing service makes a vast amount of information available from all the services, but it is the auditing provider that determines what parts of this information are captured, where the information is directed, and the format of the information. An auditing policy defines what types of transactions you record from all the security services.
The log4j Audit Channel provider features allow you to output the results to: an output stream, a Unix Syslog daemon, a Windows NT Event Logger, or any other reporting facility in a variety of formats. It also allows you to select the level of auditing required.
Note: A negative effect on performance occurs whenever auditing features are used. The more information audited, the more significant the effect on performance.
To define auditing policy, you must first determine which events you want to record. The most commonly recorded events might include each successful and unsuccessful event related to various components. For additional information on what type of information can be audited see, Audit Events in the BEA WebLogic Enterprise Security Administration Guide.
The Log4j auditing features support the standard Log4j features provided by the Apache Jakarta Project. For complete information on Log4j and how to configure auditing features, see http://jakarta.apache.org/log4j/docs/.
|
|
|
