Security in WebLogic Platform 8.1
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.
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.
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.
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.
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:
For more information about WebLogic Server domains, see Overview of WebLogic Server Domains in Configuring and Managing WebLogic Server.
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:
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:
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.
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
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:
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.
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:
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.
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:
managerrole can access the login portal.
employeerole can access the Employee portal.
managerrole 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.
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.
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:
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.
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:
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
e2ePortalapplication is launched. This application provides protection to its resources by requiring users to log in.
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
johnhas been authenticated, the page flow controller,
Controller.jpf, of the employee portal (found, in Workshop, under the
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.
johnenters an order requisition for a new laptop, an XML form is created and sent to the Order Requisition business process via the
WorkflowInvokerWeb service control. (This control is found, in Workshop, in the
WorkflowInvokerfolder of the
WorkflowInvokercontrol 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).
e2eWorkflowapplication, receives the XML order and processes it via a sequence of steps. Two of these steps are:
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.
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.