Skip navigation.
Downloads | Product Documentation | Support

Security in WebLogic Platform 8.1

# Introducing WebLogic Platform 8.1 Security

WebLogic Platform 8.1 provides a single, unified security framework for all deployments, including portal applications, integration applications, and J2EE applications running on WebLogic Server. All WebLogic Platform components use the WebLogic Server LDAP-based security model introduced in 7.0, and do not require Compatibility Security. In addition, third-party security providers that you may add apply, uniformly, to all components of the WebLogic Platform product.

The following sections provide a high-level overview of WebLogic Platform 8.1 security:

- Overview of WebLogic Platform Security
- Securing a Platform-Based Application

# Overview of WebLogic Platform Security

You can use the WebLogic Platform security model to:

- Program your applications with end-to-end security
- Add custom security extensions to provide tighter security policies
- Protect specific resources within your WebLogic Platform-based applications, such as WebLogic Portal and WebLogic Integration resources, by specifying security policies for those resources
- Map company business rules to security policies in distributed deployments, providing easy customization of application security to business requirements
- Easily update security policies, with no downtime
- Run more than one security provider at a time, as part of a transition scheme or migration path
- Use standard J2EE security technologies and the Java Authentication and Authorization Service (JAAS)

Security for all components of the WebLogic Platform product are based on the WebLogic Security Service. For a complete overview of this service, see Introduction to WebLogic Security. We recommend that you read that document in addition to the sections that follow.

# Securing a Platform-Based Application

This section introduces the following basic concepts related to securing a Platform-based application:

- The WebLogic Platform Domain
- Protecting Resources in a Platform-Based Application
- Using Web Service Security (WS-Security)
- Obtaining End-to-End Security

Wherever it is applicable, these sections show examples from the End-to-End WebLogic Platform Tour, to which we refer, in this document, simply as the Tour. The Tour includes basic security settings that demonstrate how resources in a Platform-based application can be protected. The sections that follow take a closer look at those security settings, showing how WebLogic Platform security works in such an application. These sections also explain how security settings can be extended—for example, in a production environment—to take advantage of additional features of WebLogic Platform security, resulting in a comprehensively secure platform application environment.

For complete details about the Tour, see the WebLogic Platform Tour Guide.

## The WebLogic Platform Domain

When you perform a complete installation of WebLogic Platform, all WebLogic Platform components and sample application files are installed on your system in a set of WebLogic Server domains. A domain is the basic unit of administration for WebLogic Server: it consists of one or more WebLogic Server instances and logically related resources and services that are managed, collectively, as one unit.

After installation, you typically create a new domain using the Configuration Wizard. Administrators can define security settings that apply either domain-wide, or to a particular Platform component. In general, domain-wide security resources are shared by the applications running within a domain.

An example of the platform domain is the Tour domain, called `end2end`. You can locate the files for this domain in the following directory:

>     BEAHOME/weblogic81/samples/domains/end2end

(The Tour application itself is in the `BEAHOME``/weblogic81/samples/platform/end2end` directory.)

The Tour domain requires that the WebLogic Server, WebLogic Portal, WebLogic Integration, and WebLogic Workshop components be configured in that domain to run the Tour. You can refer to the Tour domain for examples of the following:

- Applying security to application resources
- Defining user information
- Creating security roles
- Using default security providers

For more information about WebLogic Server domains, see Overview of WebLogic Server Domains in Configuring and Managing WebLogic Server.

## Protecting Resources in a Platform-Based Application

The goal of configuring security for a Platform-based application is to protect the application's resources. For example, the Tour includes two portals that require protection: the employee portal and the manager portal. To keep these resources secure, an administrator must ensure that:

- Only authorized employees have access to the portals.
- Only managers have access to the managers portal.

When only managers have access to the managers portal, back-end resources that are accessible only through that portal are protected by default.

The following sections discuss how these resources are protected:

- Configuring Users and Groups in a Platform-Based Application
- Configuring Security Roles
- Configuring Security Policies
- Using Declarative Security

### Configuring Users and Groups in a Platform-Based Application

Users and groups are classifications designed to control access to application resources. A user is an entity that can be authenticated. It may be a person or a software entity, such as a Java client. Each user is given a unique identity within a security realm. For more efficient security management, BEA recommends further classifying users in groups. A group is a collection of users who usually have something in common, such as the department of the company in which they work.

BEA recommends the use of groups for the sake of efficiency: when users are assigned to groups, you can manage a larger number of users at any given time. For example, the Tour is preconfigured with the following users and groups:

- Four users: `john`, `scott`, `rachel`, and `portaladmin`
- Two groups:

- `employee` group, consisting of `john` and `scott`
- `manager` group, consisting of `rachel`

Note: User `portaladmin` belongs to the `Administrators` and `PortalSystemAdministrators` groups, which are preconfigured for all WebLogic Platform domains.

#### How to Add, Modify, or Delete User Information

WebLogic Platform offers a choice of several methods for adding, modifying, or deleting user information:

- When you create a domain for your application using the Configuration Wizard, the Configuration Wizard prompts you for the username and password of the administrator who can start the server. For more information, see "Configuring an Administrative Username and Password" in Configuring Security in Creating WebLogic Configurations Using the Configuration Wizard.

When you add users and groups at the time you create the application domain, you have the opportunity to establish an initial set of users before the application is started. This capability can be very useful when propagating an existing application and user information to new domains. For more information, see "Configuring Users and Groups" in Configuring Security in Creating WebLogic Configurations Using the Configuration Wizard.

- When your application is running, you can use the administration consoles to add, change, or delete user information.

You configure users and groups, roles, or policies—and modify or delete that information—anytime the application is running.

Use the WebLogic Server Administration Console for adding basic user information and configuring security for WebLogic Server resources. But if you want to configure security for resources specific to WebLogic Portal or WebLogic Integration—for example, by adding trading partners or specifying access to portal resources—you should use the administration consoles for those components, as appropriate. The security information you provide using these consoles is maintained in the default WebLogic Server security store.

Whenever you add a user through any of the consoles, that user becomes visible in all of the other consoles. Likewise, when you remove a user from any of the administration consoles in WebLogic Platform, that user is no longer visible from any other console.

The exception to this cross-component access to user information involves user profiles, which provide additional data for certain types of users. User profiles are used with WebLogic Integration and WebLogic Portal. For more information, see Managing User Profile Information.

All user and group information is maintained in the default security store, an LDAP security directory. For a description of this store, see Where User Information Is Stored.

For more information, see Users and Groups in Securing WebLogic Resources, which explains how to provide security for resources and to create, add, modify, and delete users and groups

### Configuring Security Roles

A security role is a privilege granted to users or groups based on specific conditions. For example, an administrator may define a security role called `AppAdmin`, which affords access to a particular servlet. Any user or group granted the `AppAdmin` security role has access to that servlet. Multiple users or groups can be granted a single security role. Like groups, security roles allow you to restrict access to WebLogic Platform resources for several users at once. However, unlike groups, security roles:

- Are computed and granted to users or groups dynamically, based on conditions such as user name, group membership, or the time of day.
- Can be scoped to specific WebLogic resources within a single application in a WebLogic Server domain (unlike groups, which are always scoped to an entire WebLogic Server domain).

Granting a security role to a user or a group confers the defined access privileges to that user or group, as long as the user or group is in the security role. Multiple users or groups can be granted a single security role. A given role can be used to protect access to zero or more resources.

For example, the portal application of the Tour, `e2ePortal`, is configured with the following roles:

- `employee`
- `manager`

In the Tour, these roles are used to protect portal access so that only employees can access the Employee portal, and only managers can access the Manager portal. For more information about how this is done in the Tour, do the following:

1. Start WebLogic Workshop.
2. Open the file `e2ePortal.work` in the following directory:

>     BEAHOME/weblogic81/samples/platform/end2end/e2ePortal

3. Display the `Controller.jpf` file in the `e2ePortalProject` folder.

The `Controller.jpf` file defines the page flow for the various JSPs in the Portal application. For more information about this Portal application, see "Reviewing the Avitek Intranet Portal" in Logging In to the Avitek Corporate Intranet in WebLogic Platform Tour Guide.

For more information about how to configure security roles, see the following:

- Security Roles in Securing WebLogic Resources
- Delegated Administration Overview in the WebLogic Administration Portal Online Help
- User Management in Managing WebLogic Integration Solutions

### Configuring Security Policies

Access to a resource is always performed based on a security policy. A security policy is created when you define an association between a WebLogic resource and one or more users, groups, or security roles.

The WebLogic Platform Tour is configured with security policies that determine who has access to the employee and manager portals in the `e2ePortal` Web application. These security policies, specified declaratively in the `web.xml` deployment descriptor file, ensure that the `e2ePortal` resources are protected as follows:

- Only users in the `employee` or `manager` role can access the login portal.
- Only users in the `employee` role can access the Employee portal.
- Only users in the `manager` role can access the Manager portal.

In the Tour, the `web.xml` file is located on the `WEB-INF` folder of the `e2ePortalProject` folder. You can also find more information about the Tour's `web.xml` file in "Configuring Security in Web Applications" in Logging In to the Avitek Corporate Intranet in the WebLogic Platform Tour Guide.

You can define security policies to protect access to particular application resources. These security policies are called scoped security policies. By default, resources are preconfigured with a security policy that grants access to everyone. You define scoped security policies via the administration consoles provided with WebLogic Platform. For example, to restrict access to a particular portlet, use the WebLogic Administration Portal.

For information about how to configure security policies, see the following topics:

- For information about configuring security policies on WebLogic Server resources, see Security Policies in Securing WebLogic Resources.
- For information about configuring security policies on portal resources, see Delegated Administration Overview and Overview of Visitor Entitlements in the WebLogic Administration Portal Online Help.
- For information about configuring security policies on WebLogic Integration resources, including business processes, see the following topics in Managing WebLogic Integration Solutions:

- User Management for information about defining new users, groups, and roles
- "Process Security Policies" in Process Configuration for information about restricting access to the different resources of a WebLogic Integration process
- "Setting Channel Security Policies" in Message Broker for information about restricting access to resources used by the Message Broker

### Using Declarative Security

The J2EE specification defines standard, portable deployment descriptors for J2EE application components, such as Web applications, EJBs, and Web services. You can define security information declaratively in the deployment descriptors for those entities. The deployment descriptors map the application's logical security requirements to its run-time definitions. At run time, the application container uses the security definitions to enforce the requirements. An example of this declarative security is provided in the `web.xml` file of the `e2ePortal` application in the Tour (for more information, see "Configuring Security in Web Applications" in Logging In to the Avitek Corporate Intranet in the WebLogic Platform Tour Guide).

If you use WebLogic Workshop, you can also declaratively specify security constraints via annotations for Web applications, Web services, controls, business process, and EJBs. When WebLogic Workshop builds the application, it automatically generates the security information required in the corresponding J2EE security descriptors for that application.

For complete details about specifying security in deployment descriptors, see the following:

- For Web application security, see "Developing Secure Web Applications" in Securing Web Applications in Programming WebLogic Security.
- For EJB security, see "Using Declarative Security with EJBs" in Securing Enterprise JavaBeans (EJBs) in Programming WebLogic Security.
- For security of Web services created in WebLogic Workshop, see Web Service Security (WS-Security) in the WebLogic Workshop Help.
- For security of Web services created in the WebLogic Server J2EE programming environment, see Configuring Security in Programming WebLogic Web Services.
- For security of business processes created in WebLogic Workshop, see the @common:security Annotation in the WebLogic Workshop Help.

## Using Web Service Security (WS-Security)

WebLogic Workshop provides message-level security for Web services through an implementation of the WS-Security OASIS Web service security standard. The WebLogic Workshop implementation of WS-Security lets you secure the Simple Object Access Protocol (SOAP) messages passed between Web services using:

- Security tokens
- Digital signatures
- Encryption

Programming Web services security in WebLogic Workshop primarily involves writing code that does the following:

- Authorizes clients
- Sends credentials with outgoing messages
- Associates WS-Security policies to Web services and Web services controls

The declarative security that you program in WebLogic Workshop uses the same authentication and authorization mechanisms provided for all of WebLogic Platform. The security programming mechanisms available in Workshop merely provide a way to specify policies in deployment descriptors for the run-time code that is generated by the Workshop framework.

For information about and examples of using WS-Security when implementing Web services in the Workshop IDE, see Web Services Security (WS-Security) in the WebLogic Workshop Help.

You can also implement WS-Security in Web services that you create in the WebLogic Server programming environment. For more information, see "Overview of Web Services Security" in Configuring Security in Programming WebLogic Web Services.

Note: BEA's current implementation of the Web Services Security Core Specification is based on Working Draft Version 1.0, dated April 5, 2002. Because this specification is not yet an OASIS Standard, BEA's implementation is subject to change in future versions of WebLogic Server. Customers using the message-level security features described in "Overview of Web Services Security" in Configuring Security in Programming WebLogic Web Services should do so with the understanding that this implementation may not be compatible with Web Services Security implementations based on other versions of the Core Specification.

## Obtaining End-to-End Security

WebLogic Platform provides multiple technologies to allow you to define end-to-end security for your applications. These technologies involve:

- Authentication of users or participants in the application
- Authorization to protected resources
- Control over the definition of confidential communication.

The Tour shows an example of how the WebLogic Security Service works to provide end-to-end security for an application that spans multiple components of WebLogic Platform. Consider the scenario in which an employee, `john`, logs in to the Avitek Employee portal to do the following:

1. Verify that the Human Resources department has correctly entered his personal data
2. Submit a requisition order for a new laptop.

The following steps enable you to take a closer look at how the WebLogic Security Service protects all the application resources involved in servicing the two requests issued by `john`:

1. First, before any employees log in to the Avitek Employee portal, the portal application itself needs to be started. WebLogic Server always authenticates who can start a server. You can control who can start the server on which you deploy your applications by requiring that the server prompt for a username and password.

You can also preconfigure this authorized user when you create a new domain via the Configuration Wizard. Because the Tour runs in "development mode," the startup scripts are preconfigured to start the server on behalf of the administrator username `weblogic`.

2. After the Tour has been started, the `e2ePortal` application is launched. This application provides protection to its resources by requiring users to log in.

The `e2ePortal` uses FORM authentication, which is a style of authentication provided by the WebLogic Server servlet container to validate the username and password against the data stored in the WebLogic Server Authentication provider (in this case, the LDAP directory that is embedded in WebLogic Server). The definition of the FORM authentication is specified within the `<login-config>` section of the `web.xml` deployment descriptor for the `e2ePortal` application. A valid authentication associates the current thread with the Subject information of the authenticated users, and redirects the control to the `begin` action of the `Controller.jpf` file in the `e2ePortal` page flow. This action extracts the role from the Subject and, depending on this role, redirects the flow to either the `Employee.portal` or to the `Manager.portal` portals.

3. After `john` has been authenticated, the page flow controller, `Controller.jpf`, of the employee portal (found, in Workshop, under the `employee` directory of `e2ePortalProject`) uses the Subject to extract the appropriate username and retrieve information stored in the database via a database control. This information is then displayed in the corresponding portlet.
4. When `john` enters an order requisition for a new laptop, an XML form is created and sent to the Order Requisition business process via the `WorkflowInvoker` Web service control. (This control is found, in Workshop, in the `WorkflowInvoker` folder of the `e2ePortal` directory.) This `WorkflowInvoker` control uses the standard Web service-based invocation mechanism to start the Order Requisition process. Note that because JMS currently does not automatically propagate the credentials of the invoker to the receiver, and because HTTP-based SOAP requests cannot propagate the identity automatically, you should design the appropriate mechanisms to pass these credentials to the receiver, if needed (for example, by adding the credential to the XML message).
5. The Order Requisition process, defined in the `e2eWorkflow` application, receives the XML order and processes it via a sequence of steps. Two of these steps are:

1. Assigning an approval task to `john`'s manager, `rachel`

The task is generated via a task control that is protected so that only members of the `Administrators` group can generate tasks. The Tour uses `run as` to switch the identity (by default, anonymous) of the JMS receiver (the Order Requisition process) to the `installAdministrator` user, who is a member of the `Administrators` group. The task is directed to the user who is authorized to respond to the task: `rachel`. This validation is performed when `rachel` logs in via the Manager portal.

2. Accessing the inventory system to verify that the laptop is in stock

Access to the inventory system is implemented via a WebLogic Integration Application View that uses a J2EE JCA adapter to access a database containing the inventory. The database is accessed on behalf of the user `weblogic`, and the mapping from the `InstallAdministrator` user is automatically done to the user `weblogic` (note that both users are members of the `Administrators` group) by the WebLogic Server J2EE JCA mechanisms.

As you can see, security for your application must be designed and planned from the outset. WebLogic Platform provides multiple tools for configuring security, depending on the components that you want to use. You should become familiarized with these tools before you design the security of your application. For a set of useful links to the more detailed documentation provided by the different WebLogic Platform components, see Where to Find More Information, in this document.