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.
The following sections provide a high-level overview of WebLogic Platform 8.1 security:
You can use the WebLogic Platform security model to:
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.
This section introduces the following basic concepts related to securing a Platform-based application:
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.
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:
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:
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:
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:
Note: User portaladmin belongs to the Administrators and PortalSystemAdministrators groups, which are preconfigured for all WebLogic Platform domains.
WebLogic Platform offers a choice of several methods for adding, modifying, or deleting user information:
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.
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
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.
For example, the portal application of the Tour, e2ePortal, is configured with the following roles:
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:
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:
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:
employee or manager role can access the login portal.employee role can access the Employee portal.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:
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:
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:
Programming Web services security in WebLogic Workshop primarily involves writing code that does the following:
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.
WebLogic Platform provides multiple technologies to allow you to define end-to-end security for your applications. These technologies involve:
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:
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:
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.
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.
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. 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). e2eWorkflow application, 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.
|
|
|