|
|
|
|
|
|
Introduction
This Security Guide is designed to help you understand how the WebLogic Portal product suite leverages the security features of the JavaTM 2 Platform Enterprise Edition (J2EE) specification and the J2EE-compliant security features of the WebLogic Server platform. It provides information about additional security measures that may have been established for individual application components within the WebLogic Portal product suite, and describes ways that you can modify security settings.
As an introduction to WebLogic Portal security, this topic includes the following sections:
Determining Your Application Security Needs
Security is a critical component of developing e-commerce applications that no organization can afford to ignore. Malicious individuals who gain access to your computer systems can temporarily interrupt business, but those who gain access to your customers' personal data can cause long-term damage to your reputation. Even if you have not had any security mishaps, customers are often hesitant to provide personal information over the Web, which could affect your ability to tailor products and services to customer preferences. Therefore, your organization must develop e-commerce applications that protect customer data and communicate a sense of privacy and purpose through the interface. At the same time, however, the application must not be difficult to navigate or perform slowly because of technical security requirements.
As the previous paragraph suggests, determining your application security needs can be challenging. You must balance the need for securing data with the need to make your site easy to navigate and perform quickly. You may want to ask yourself the following questions when attempting to define your application security requirements:
There are many resources in the WebLogic Portal suite's applications that can be protected, including Enterprise JavaBeans (EJBs), servlets, and JavaServer Pages (JSPs). Consider the resources you want to protect when deciding the level of security you must provide.
Like many e-commerce Web sites, you may consider browsing product catalog pages an acceptable activity for both anonymous and authenticated customers. Once a customer decides to purchase an item, however, you may need to identify that customer and retrieve some of their personal information. This information must be protected from all other customers of the Web site.
Similarly, the tools included with WebLogic Portal may allow certain administrators to modify the behavior of your e-commerce Web site. Should these administrators be able to access all resources and all data? Or should the most confidential and strategic information be trusted to only a few individuals?
In some cases, a fault in your application security is easily detected and considered nothing more than an inconvenience. In other cases, a fault might cause great damage to companies or individual clients that use the site. Understanding the ramifications associated with unauthorized access to each resource will help you to properly protect it.
As you read the rest of this Security Guide, keep your answers to these questions in mind. By thinking upfront about your security requirements, you will be more likely to design security-aware applications, and may be better prepared to execute deployment activities.
Reliance on J2EE Standards and WebLogic Server Security
WebLogic Portal security implementations are based on the security requirements defined in the Java 2 Enterprise Edition (J2EE) specification, as well as the security measures implemented the BEA WebLogic ServerTM product.
This dependency has two important implications. First, if implemented properly, you can be confident that the applications you build using WebLogic Portal conform to the latest in J2EE security standards. Second, like the WebLogic Portal applications, your applications will also leverage the centralized security mechanisms of the WebLogic Server container, instead of requiring you to embed security code within individual Enterprise JavaBean (EJB) routines or their clients. Reliance on this centralized security model may significantly reduce the amount of effort required to build and maintain secure applications.
For more information about J2EE security requirements, see the "Security" section in the Java 2 Platform Enterprise Edition Specification, v1.3. For more information about how WebLogic Server implements J2EE security, refer to the Programming WebLogic Security documentation.
Declarative Security in WebLogic Portal
Because WebLogic Portal relies upon J2EE security requirements and the WebLogic Server's implementation of these requirements, security in the WebLogic Portal applications is primarily declarative.
As stated in the J2EE specification, declarative security means specifying an application's security structure—including security roles, access control, and authentication requirements—in a form that is external to the application. This external form is called a deployment descriptor, which is a centralized XML document for (among other things) defining protections on application resources. At runtime, the WebLogic Server container uses the deployment descriptor to enforce the specified security restrictions. Access to a protected resource is granted only if a user's security role matches the role declared in the deployment descriptor for that resource. Security Roles and Deployment Descriptors, provides more information about deployment descriptors and security roles.
A declarative approach to security has several advantages. First, declarative security is fine-grained, meaning that access can be restricted down to a specific method on a JavaBean. This gives you the flexibility to restrict only those resources that need protection. Second, an Application Assembler/Deployer can map security roles used within an application to the users and groups that already exist for a particular production environment at deployment time. This eliminates the need for individual developers to concern themselves with the security details of particular environments, and allows them to focus on other, possibly more important aspects of application development. Third, because deployment descriptor information is centralized and external to its associated application, it can be changed without modifying any JavaServer Page (JSP) or Enterprise JavaBean (EJB) source code. This architecture may significantly reduce the time developers spend debugging and maintaining code, as well as the likelihood of security holes due to programming errors.
Note: More information about declarative security can be found in the Enterprise JavaBeans 1.1 Specification.
Programmatic Security in WebLogic Portal
Programmatic security is also supported by the WebLogic Server container, and WebLogic Portal does occasionally use programmatic security in addition to declarative security. For example, some programmatic security is used in the Portal Administration services because an administrator's association with a portal is determined dynamically, after deployment. The static nature of declarative security (and the fact that it is defined at deployment time) would not work in this case. For more information about Portal Administration, see Portal Administration and Security.
Note: For more information about the differences between declarative and programmatic security, see the "Container Based Security" section of the Java 2 Platform Enterprise Edition Specification, v1.3.
Security Behavior in a J2EE Environment
The following points provide a high-level overview of how security typically works in a J2EE environment. This information is included to provide some context for the WebLogic Server's security activities, as well as to provide a basic understanding of how an application's deployment descriptors and security roles fit into a security policy.
A Web client that has not yet been authenticated requests a URL for a protected resource (for example, a JSP). If acting as a Web server, the WebLogic Server detects this and invokes an appropriate authentication mechanism.
The Web server returns a form to the client requesting authentication data (such as a username and password combination). If using basic authentication, the form displayed to the user is part of the browser's default interface. If using form-based authentication, the interface for data collection can be customized by developers in your organization. Once the user enters their authentication information, the client forwards this data back to the Web server, which validates it and sets a credential for the user.
The user's credential (set in the previous step) can now be used in subsequent requests to determine whether that user is authorized to access a particular protected resource. The Web server consults the deployment descriptor associated with the protected resource to determine the security roles that should be granted access. The Web container then tests the user's credential against each security role, looking for user-to-role matches.
If the Web container obtains an "is authorized" outcome, the Web server returns the result of the original URL request to the client.
The JSP (or other resource) to which the client now has access may perform a remote method call to an Enterprise JavaBean (EJB), using the user's credential to establish a secure association between the JSP and the EJB. This association is implemented in both the Web container and EJB container. The EJB container enforces access control on EJB methods by consulting the EJB's deployment descriptor to determine which security roles should be granted access to the method. If the EJB container obtains an "is authorized" outcome, the container permits the call to the particular EJB method. The result of the method's execution is returned via the Web server and JSP to the client.
As you can see by this simplified description, the Web server acts as an authentication proxy by gathering authentication data from a client and using it to establish an authenticated connection to a protected resource.
Note: For more detailed information about this process, see the "Security" section in the Java 2 Platform Enterprise Edition Specification, v1.3. For more information about authentication and authorization, see Introduction to WebLogic Server Security in the Programming WebLogic Security documentation.
About Security Realms
As described in Security Behavior in a J2EE Environment, a Web server authenticates users and determines which resources within the server users can create, access, or modify. To do this, the Web server uses a security realm. When a user attempts to access a particular resource, the server tries to authenticate and authorize that user by checking the access control list (ACL) and permissions that are assigned to the user within the realm. You can set up multiple security realms, but each instance of a Web server can use only one realm. The server uses the same security realm for your Web site developers and for your customers.
Note: More information about security realms, ACLs, and permissions can be found in the Introduction to WebLogic Server Security section of the Programming WebLogic Security documentation.
The default security realm for the WebLogic Portal is the RDBMS realm. That is, by default the server stores user IDs and passwords, group definitions, and ACLs in the RDBMS data repository.
WebLogic Portal also provides the following alternate security realms:
Provides authentication through a Lightweight Directory Access Protocol (LDAP) server which allows you to manage users in one place, the LDAP directory. When the LDAP security realm is used, the LDAP server authenticates users and groups.
Note: The LDAP realm is a read-only realm. Therefore, use of the LDAP realm may require additional intervention using third-party tools, especially when performing user, group, and delegated administration management tasks.
Uses Windows NT account information to authenticate users. Users and groups defined through Windows NT can be used by your Web application. You can use the WebLogic Server Administration Console to view this realm, but you must use the facilities provided by Windows NT to define users and groups.
Executes a native program, wlauth, to authenticate users and groups using UNIX login IDs and passwords. On some UNIX platforms, wlauth uses a Pluggable Authentication Module (PAM) that allows you to configure authentication services in a UNIX platform without altering applications that use those services. On UNIX platforms for which PAM is not available, wlauth uses the standard login mechanism, including shadow passwords when they are supported. You can use the Administration Console to view this realm, but you must use the facilities provided by the UNIX platform to define users and groups.
When you start the server, the File realm creates user, group, and ACL objects from properties defined through the WebLogic Server Administration Console and stores them in the fileRealm.properties file.
Note: The File realm is designed for use with 10,000 or fewer users. If you have more than 10,000 users, use an alternate security realm.
Next Steps
This Security Guide is intended mainly for individuals in your organization who act as Application Assemblers/Deployers and System Administrators, and assumes a certain level of familiarity with standard J2EE security implementations and with the security mechanisms of the BEA WebLogic Server.
Note: See Development Roles in the Strategies for Developing E-Business Web Sites documentation for more information about these and other organizational roles.
If you have no prior or recent experience with J2EE or WebLogic Server, you may want to spend some time learning about these technologies before proceeding. The following documents contain additional information about WebLogic Portal and WebLogic Server product security, or provide supplemental information that may be helpful for understanding the contents of this Security Guide.
If you feel comfortable with J2EE and WebLogic Server security topics, proceed through this guide—either sequentially or nonsequentially—to answer your questions about WebLogic Portal security.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|