Skip navigation.
Downloads | Product Documentation | Support

Policy Managers Guide

# Modeling Policies

This section covers the following topics:

- Policy Overview
- Security Configuration
- Authentication Policy
- Role Mapping Policy
- Authorization Policy
- Auditing Policy

# Policy Overview

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:

Only employees in the sales team may view sales documents

or

Only employees in the sales team who are regional managers can alter discounts

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:

- Security Configuration—controls what security services are available and configured for each managed environment
- Authentication Policy—controls what authentication services and user stores are used to validate subject identities
- Role Mapping Policy—dynamically determines which users and groups belong to a role, based on certain rules and conditions
- Authorization Policy—dynamically determines resource privileges for one or more roles, (users and groups), based on certain rules and conditions
- Auditing Policy—defines the type of security-related information (authentication or authorization) to capture and store in a designated place

# Security Configuration

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:

- Database Authentication provider to connect to the customer database
- ASI Authorization provider and ASI Role Mapper provider (these two providers always work together and share the same configuration)
- SAML Credential Mapping provider to map users credentials
- Audit provider to audit transactions in this Security Service Module

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.

# Authentication Policy

How do we determine that the user is who they claim to be?

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.

Table 2-1 Methods of Authentication

Method | Description
Username and password | In username and password authentication, the user provides some form of identification and matching password that the provider (LDAP, Windows NT, or database) checks against the configured metadirectory and validates the identity of the user. If the credentials are trustworthy, the user is authenticated and an internal identity is created and signed.
Certificate | A certificate-based authentication schema is typically used when an SSL or HTTPS client requests access and presents its digital certificate to the server. The server then passes the certificate to the X.509 Identity Assertion provider that verifies the digital certificate and creates a local identity. The digital certificate is issued by a trusted certificate authority and is accepted as a form or user authentication.
Single Sign-On | This form of authentication is typical in a setting where the users are using multiple applications, each of which maintains its own security and requires user identity to control access. These may be within an organization, through an employee portal, or externally on a completely different domain. For example, if the user requires access to separate applications, one in New York with a local LDAP and the other in London that uses a proprietary user database, a SAML identity assertion credential may be passed between these environments, and then either consumed by the remote security system directly or converted to a local identity through credential mapping.

Authentication policy is defined by:

- Configuring a metadirectory to contain your subject data (optionally, containing users, groups, and attributes)
- Configuring one or more authentication providers
- If multiple authentication providers are used, defining the order in which each authentication provider executes

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.

## Users and Groups

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:

- `//user/dir/name`
- `//sgrp/dir/name`

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.

Figure 2-1 Users and Groups

## Identity Attributes

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.

# Role Mapping Policy

How are user roles used in policy management?

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

- Defining roles
- Configuring a role mapping provider
- Defining a set of resources
- Defining rules for users and groups.
- Assigning users and groups to roles

# Authorization Policy

How do we control what the user is allowed to do?

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:

- Configuring an authorization provider
- Defining a resource
- Defining privileges and privilege groups
- Assigning privileges to roles
- Defining rules and conditions to apply

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.

### Defining Resources

A resource represents anything to which you can grant, deny or delegate roles or privileges, and any conditions that apply.

What roles can access the resource?

Some typical resources that you might want to secure, include:

- An application, an application window, or a dialog box
- Specific business transactions, such as a money transfer or security trade
- Application controls, such as buttons and menu selections
- Database or directory server structures
- Web pages, servlets, and Enterprise Java Beans (EJB)
- Products or services in a portal

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.

Figure 2-3 Resource Mapping

## Resource Attributes

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

## Privileges

A privilege represents an action or task in your business policy.

What actions can a user take on a resource or what privileges does a user have?

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.

## Conditions

When can the user or group access the resource?

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.

## Delegation

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 TellerAp`p` application from amy to john.

# Auditing Policy

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