BEA Logo BEA WLCS Release 3.5

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

 

   WLCS Doc Home   |   Security Guide   |   Previous Topic   |   Next Topic   |   Contents   |   Index

Deployment Descriptors and Security Roles

 

Security for the BEA Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server products is considered declarative because resource protections are centrally defined in configuration files called deployment descriptors, instead of within individual application components. This topic provides you with some general information about deployment descriptors, explains the syntax for the security-related elements you will find within the deployment descriptor files, and describes the deployment descriptor settings for the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server product applications. Because an understanding of security roles is required to understand deployment descriptors, this topic will also be addressed.

This topic includes the following sections:

 


What Is a Deployment Descriptor?

A deployment descriptor is a configuration file with a predefined format that all J2EE compliant Web applications and Enterprise JavaBeans (EJBs) must use, and that all J2EE compliant servers (such as the BEA WebLogic Server) must know how to read. This format is specified in an XML Document Type Definition, or DTD, and thus has a .xml extension. As its name implies, the deployment descriptor describes various deployment settings, including the type of JavaBean (session or entity) and the classes used for the remote, home, and bean class. It also specifies the transactional attributes of every method in the JavaBean, which security roles can access each method, and whether persistence in the entity beans is handled automatically or is preformed by the bean itself. For more detailed information about deployment descriptors, see the Java 2 Platform Enterprise Edition Specification, v1.3.

Note: For the purposes of this Security Guide, only the security-related aspects of a deployment descriptor will be discussed. For in-depth information about other elements in the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server deployment descriptors or for general information about deploying applications, see the Deployment Guide.

What Is a Security Role?

Because much of this document focuses on the deployment descriptor elements that define which security roles can access specific methods, you should know something about security roles. However, before you can understand security roles, you should know something about how the J2EE specification defines users and groups.

J2EE Users and Groups

A J2EE user is similar to an operating system user in that it represents a person. A group is a category of users, classified by common traits such as job title or customer profile. Categorizing users into groups makes it easier to control the access of large numbers of users. A J2EE group is scoped to the entire WebLogic Server.

Note: The Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server use the following WebLogic Server groups, which you can configure using the User Management Administration Tool:

Roles and Principals

A security role is a named grouping of information resource access permissions, defined for an application. Although groups and roles both represent categories of users, a J2EE security role has a different scope that a group. Specifically, a security role is scoped only to a specific application in the WebLogic Server.

Note: For more infomation about assigning security roles in WebLogic Web applications, see "Deploying and Configuring Web Applications."

The J2EE security roles defined for the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server applications are:

Mapping a principal to a role confers the defined access permissions to that prinicpal as long as the principal is "in" the role. For example, an application may define a security role called guest, which provides read-only access to a small subset of all of the application's resources. Any principal in the guest role would then have read-only access to only those few resources.

The J2EE security roles defined for the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server applications map to the following WebLogic Server groups (principals), which may be defined in an application's weblogic.xml file:

With this mapping, the AdministrativeRole always includes the admin group. Therefore, although you cannot modify access control lists (ACLs) at run time, you can provide specific users with access at run time simply by adding them to the appropriate group. For example, if you want to give user JohnDoe access to the JSP Administration Tools (which require administrative privileges), simply add JohnDoe to the admin group.

Notes: For more information about role to principal mapping in the weblogic.xml file, see The weblogic.xml Deployment Descriptors.

For more information about access control lists (ACLs), see "ACLs and Permissions" in the Security Fundamentals chapter of the Programming WebLogic Security documentation.

Deployment Descriptor Files in Enterprise Applications

A J2EE application, which may or may not be saved as a compressed Enterprise ARchive (EAR) file, generally consists of:

Thus, although the deployment descriptor provides a central location for security-related deployment information, it is likely that an enterprise application will require more than one deployment descriptor file to communicate its security requirements to the server. In fact, for each individual Web application that comprises the enterprise application, there are two deployment descriptors: web.xml and weblogic.xml. For each EJB JAR that comprises the enterprise application, there are also two deployment descriptors: ejb-jar.xml and weblogic-ejb-jar.xml. Each of these deployment descriptor files are discussed in later sections of this chapter.

Location of Deployment Descriptor Files in the Product Directory Structure

The Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server product is essentially a collection of several prewritten Web applications and Enterprise JavaBeans (EJBs), organized into a single enterprise application. This enterprise application is called wlcsApp, and is located in the $WL_COMMERCE_HOME/WebLogicCommerce3.5/config/wlcsDomain/
applications
directory, where $WL_COMMERCE_HOME is the directory where you installed the product. The individual applications that comprise wlcsApp include exampleportal, tools, and wlcs, which are located in their own subdirectories under the wlcsApp directory. This directory structure, along with some additional subdirectories and files, is shown in
Figure 2-1.

Figure 2-1 Location of Web Application Deployment Descriptors in the WebLogicCommerce3.5 Directory Structure


 

As Figure 2-1 also shows, in each application subdirectory (such as $WL_COMMERCE_HOME/WebLogicCommerce3.5/config/wlcsDomain/
applications/wlcsApp/wlcs
) there is a WEB-INF subdirectory. The WEB-INF directory contains the two deployment descriptors for the Web application: web.xml and weblogic.xml. The contents of the web.xml and weblogic.xml files for each of the prewritten applications are described later sections of this chapter.

As Figure 2-2 shows, the wlcsApp directory contains JAR files for all the Enterprise JavaBeans (EJBs) that make up the enterprise application. It is within each JAR file that the deployment descriptors ejb-jar.xml and weblogic-ejb-jar.xml can be found. The contents of the ejb-jar.xml and weblogic-ejb-jar.xml files for each of the prewritten EJBs are described in Application Services and Security.

Figure 2-2 Location of EJB Deployment Descriptors in the WebLogicCommerce3.5 Directory Structure


 
 
 

 


About the web.xml and weblogic.xml Application Deployment Descriptors

As previously described, each Web application has two deployment descriptors: web.xml and weblogic.xml. This section provides a general description of these files, then lists the contents of these files (that are relevant to security) for the wlcs, exampleportal, and tools applications.

The web.xml Deployment Descriptors

Along with other information, the web.xml application deployment descriptor contains several sets of elements for implementing the J2EE declarative security model. These deployment descriptors are located in each application's WEB-INF directory. Each web.xml deployment descriptor may contain elements for each of the following security-related topics:

These topics are described in detail in the following sections.

Note: For more information about the XML elements this section describes, refer to "web.xml Deployment Descriptor Elements" in the Developing WebLogic Server Applications documentation.

Port Numbers and Security Constraints for Generated URLs

This section describes the elements in the web.xml deployment descriptor that configure the createWebflowURL() method to do the following:

Note: For more information about the createWebflowURL() method, see "Using Webflow in Your Web Pages," which is located in the "Customizing Webflow and Pipelines" chapter of the Guide to Managing Presentation and Business Logic: Using Webflow and Pipeline documentation.

Generate Port Numbers for

HTTP and HTTPS

The <context-param> element syntax shown in Listing 2-1 determine which port numbers the createWebflowURL() method encodes in the URLs that it generates.

Listing 2-1 Elements That Generate Port Numbers

<context-param>
<param-name>HTTP_PORT</param-name>
<param-value>port-number</param-value>
</context-param>
<context-param>
<param-name>HTTPS_PORT</param-name>
<param-value>port-number</param-value>
</context-param>

Determine Which Links Use HTTPS

The <context-param> element syntax shown in Listing 2-2 declares a set of files, pipelines, and input processors that need to be accessed via HTTPS.

Listing 2-2 Elements That Determine Which Links Use HTTPS

<context-param>
<param-name>HTTPS_URL_PATTERNS</param-name>
   <param-value>
URLs-and-URL patterns
</param-value>
</context-param>

When the createWebflowURL() method encounters one of the resources you declare in the <param-value> subelement, it generates a URL that uses the HTTPS protocol.

Session Timeout

The <session-config> element syntax shown in Listing 2-3 specifies how many minutes of inactivity the server will tolerate before ending the session.

Listing 2-3 Element That Specifies Session Timeout

<session-config>
   <session-timeout>number of minutes until 
timeout
</session-timeout>
</session-config>

Declarations of Secure JSPs

The <security-constraint> element syntax shown in Listing 2-4 declares a collection of resources (JSPs) that only specific security roles can access.

Listing 2-4 Elements That Declare Secure JSPs

<security-constraint>
   <web-resource-collection>
	<web-resource-name>name of the resource collection
</web-resource-name>
      	<description>documentation of the collection's scope and
purpose
</description>
	<url-pattern>single URL pattern: use as many url-pattern
elements as you need. One pattern/filename per element.
</url-pattern>
	<http-method>GET</http-method>
<http-method>POST</http-method>
   </web-resource-collection>

<auth-constraint>
	<description>documentation of the authorization
constraint
</description>
      	<role-name>name of declared security role: use as many
role-name elements as you need. One role per element.
</role-name>
   </auth-constraint>

<user-data-constraint>
	<transport-guarantee>INTEGRAL or CONFIDENTIAL; 
see below for details</transport-guarantee>
   </user-data-constraint>
</security-constraint>

Use one of the following values in the <transport-guarantee> element:

Additionally, any roles used within the <auth-contraint> portion of the element must also be declared within the web.xml deployment descriptor, using the following syntax shown in Listing 2-5.

Listing 2-5 Elements That Declare Security Roles

<security-role>
   <description>declaration documentation for the security roles
used in the <auth-contraint> element
</description>
   <role-name>name of security role</role-name>
</security-role>

To give another role access to the resource collection, add <role-name> elements to the <auth-constraint> element, and add the role to the <security-role> declaration.

You can also add <url-pattern> elements to specify new directories or to specify specific files. Note that a pattern or filename must start with a / (forward slash) character. For more information on specifying URL patterns, refer to the Java Servlet Specification v2.2.

Note: If you add or modify any <url-pattern> elements, and if the transport-guarantee is set to INTEGRAL/CONFIDENTIAL, be sure to update those patterns in the <context-param> element for SSL.

The weblogic.xml Deployment Descriptors

Along with the web.xml deployment descriptor, each J2EE component application also requires a weblogic.xml deployment descriptor, which declares deployment properties specific to the WebLogic Server. The weblogic.xml deployment descriptor is located in the same directory as web.xml (that is, in the application's WEB-INF subdirectory).

Among other elements, the weblogic.xml file contains the element syntax shown in Listing 2-6, which maps a J2EE security role to a user or group (principal) that a security realm uses to define access control lists (ACLs).

Listing 2-6 Elements That Map Roles to Principals

<security-role-assignment>
   <role-name>J2EE role</role-name>
<principal-name>security-realm user or group</principal-name>
</security-role-assignment>

Notes: For more information about security realms and ACLs in the WebLogic Server, see "Security Fundamentals" in the Programming WebLogic Security documentation.

For more information about the non-security related elements in weblogic.xml, see "The weblogic.xml File," located in "The Reference Domain" chapter of the Deployment Guide.

The wlcs Application's Deployment Descriptors

As described in The web.xml Deployment Descriptors, the e-commerce (wlcs) application's web.xml deployment descriptor specifies the following security-related information:

As described in The weblogic.xml Deployment Descriptors, the wlcs application's weblogic.xml deployment descriptor specifies the following:

Port Numbers for HTTP and HTTPS

The default port numbers for HTTP and HTTPS defined in the wlcs Web application's web.xml deployment descriptor are 7501 and 7502, respectively.

If you want the wlcs Web application to use the same port numbers as the WebLogic Server instance (for example, if you are using WebLogic Server as your HTTP server), either deactivate these elements by surrounding them in comment tags
(<!-- -->), or change the values to match the listen port properties for the server. If you want the wlcs Web application to use different port numbers (for example, if you want to use the port numbers of a proxy server), change the values shown in the appropriate element. For more information, refer to
"Changing the Listen Ports" in the Deployment Guide.

Links Using HTTPS

The links in the wlcs Web application that are defined in the web.xml deployment descriptor to use HTTPS are shown in Listing 2-7.

Listing 2-7 wlcs Application Links That Use HTTPS

<context-param>
<param-name>HTTPS_URL_PATTERNS</param-name>
   <param-value>
/commerce/user/*,/commerce/order/*,/commerce/register/*,
newuser_*,profilenewcc_*,paymentnewcc_*,profileeditcc_*,
paymenteditcc_*,viewprofile_*,editprofile_*,
editdemographics_*,profilenewaddress_*,profileeditaddress_*,
changepassword_*,EnterShippingInfo_*,SelectShippingAddress_*,
AddNewShippingAddress_*,orderhistory_*,RefreshOrderHistory_*,
AuthorizePayment,CommitOrder,RefreshPaymentHistory,
DeleteCreditCard,TaxVerifyShippingAddress_*,
shoppingcart_InitShippingMethodList
</param_value>
</context-param>

If desired, you can add specific resource names or name patterns to the <param-value> element. Specify patterns for Pipelines and input processors in the form of pattern_*. For example, to enable SSL for all requests to input processors whose names start with profileeditcc_, use the pattern profileeditcc_*.

Notes: When naming specific Pipelines and input processors, do not use the .inputprocessor or .pipeline extension

If you add any target names or patterns to the <param-value> element, you must also add them to the <security-constraint> element, which is described in Declarations of Secure JSPs.

Session Timeout

By default, the $WL_COMMERCE_HOME/server/webapps/wlcs/WEB-INF/web.xml deployment descriptor sets the parameter to 15 minutes. You can modify this setting depending on your security needs.

Secure JavaServer Pages (JSPs)

As shown in Listing 2-8, the wlcs web.xml deployment descriptor declares a single role, CustomerRole, in the <role-name> element, and several <url-pattern> elements.

Listing 2-8 Secure JSPs for the wlcs Application

<!-- Configuration for customer self administration pages 
Configuration for role: Customer Role -->
<security-constraint>
   <web-resource-collection>
	<!-- Define a resource collection -->
	<web-resource-name>Customer Profile - Self Administration
Pages
</web-resource-name>
<description>Customer Profile - Self Administration Pages
</description>
	<!-- URL pattern for the resource collection -->
	<url-pattern>/commerce/user/*</url-pattern>
<url-pattern>/commerce/order/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
   </web-resource-collection>

<!-- This contraint applies to users with role "CustomerRole" -->
   <auth-constraint>
<description>Users with role "CustomerRole"</description>
<role-name>CustomerRole</role-name>
<auth-contraint>

<!-- For enabling SSL, specify CONFIDENTIAL or INTEGRAL -->
   <user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<!-- Configuration for customer self registration pages -->
<security-constraint>
   <web-resource-collection>
	<!-- Define a resource collection -->
	<web-resource-name>Customer Self Registration
</web-resource-name>
<description>Customer Self Registration Pages
</description>
	<!-- URL pattern for the resource collection -->
	<url-pattern>/commerce/register/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
   </web-resource-collection>

<!-- For enabling SSL, specify CONFIDENTIAL or INTEGRAL -->
   <user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
.
.
.

<!-- Declare all the roles used in the <auth-constraint> element above -->
<security-role>
<description>Registered customers with role CustomerRole
</description>
<role-name>CustomerRole</role-name>
</security-role>

Role to Principal Mapping

The e-commerce (wlcs) application's weblogic.xml deployment descriptor specifies the security-related information shown in Listing 2-9.

Listing 2-9 wlcs Security Role to Principal Mapping

<!-- Role mapping to the realm groups: The following elements  
declare mappings between J2EE roles and WLCS groups -->
<!-- J2EE role CustomerRole maps to WLCS group "wlcs_customer" -->
<security-role-assignment>
<role-name>CustomerRole</role-name>
<principal-name>wlcs_customer</principal-name>
</security-role-assignment>

The exampleportal Application's Deployment Descriptors

As described in The web.xml Deployment Descriptors, the exampleportal (ACME) application's web.xml deployment descriptor specifies the following security-related information:

As described in The weblogic.xml Deployment Descriptors, the exampleportal application's weblogic.xml deployment descriptor specifies the following:

Secure JavaServer Pages (JSPs)

As shown in Listing 2-10, the exampleportal web.xml deployment descriptor declares a single role, PortalUserRole, in the <role-name> element, and one <url-pattern> element.

Listing 2-10 Secure JSPs for the exampleportal Application

<security-constraint>
   <web-resource-collection>
      <web-resource-name>Portal Resources</web-resource-name>
        <description>The Portal user logged-in Pages. Note that since 
all portal pages (both in a logged-in state and a
non-logged-in state) are accessed via the same URL
(portal.jsp), you cannot uniquely trigger authorization on
that URL. Instead,the _userlogin.jsp resource is used.
</description>
      <url-pattern>/portals/repository/_userlogin.jsp
</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
   </web-resource-collection>
   <auth-constraint>
<description>Portal Users</description>
<role-name>PortalUserRole</role-name>
</auth-constraint>
   <user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
.
.
.
<security-role>
<description>Portal Users</description>
<role-name>PortalUserRole</role-name>
</security-role>

Role to Principal Mapping

The exampleportal (Acme) application's weblogic.xml deployment descriptor specifies the security-related information shown in Listing 2-11.

Listing 2-11 exampleportal Security Role to Principal Mapping

<!-- The Portal User Role mapping to the Security Realm -->
<security-role-assignment>
<role-name>PortalUserRole</role-name>
<principal-name>AcmeUsers</principal-name>
<principal-name>wlcs_customer</principal-name>
</security-role-assignment>

The tools Application's Deployment Descriptors

As described in The web.xml Deployment Descriptors, the tools application's web.xml deployment descriptor specifies the following security-related information:

As described in The weblogic.xml Deployment Descriptors, the tools application's weblogic.xml deployment descriptor specifies the following:

Secure JavaServer Pages (JSPs)

As shown in Listing 2-12, the tools web.xml deployment descriptor declares a single role, AdminRole, in the <role-name> element, and three <url-pattern> elements.

Listing 2-12 Secure JSPs for the tools Application

<security-constraint>
   <web-resource-collection>
      <web-resource-name>Administration Tool Pages
</web-resource-name>
      <description>The Administration Tool Pages</description>
      <url-pattern>/tools/*</url-pattern>
<url-pattern>/repository/*</url-pattern>
<url-pattern>/security/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
   </web-resource-collection>
   <auth-constraint>
<description>Administrators</description>
<role-name>AdminRole</role-name>
</auth-constraint>
   <user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
.
.
.
<security-role>
<description>Administrators</description>
<role-name>AdminRole</role-name>
</security-role>

Role to Principal Mapping

The tools application's weblogic.xml deployment descriptor specifies the security-related information shown in Listing 2-13.

Listing 2-13 tools Security Role to Principal Mapping

<!-- The Admin Role mapping to the WebLogic Realm -->
<security-role-assignment>
<role-name>AdminRole</role-name>
<principal-name>admin</principal-name>
</security-role-assignment>

 


About EJB Deployment Descriptors

Each JAR scoped to an enterprise application contains two associated XML deployment descriptors: ejb-jar.xml and weblogic-ejb-jar.xml. It is in these XML files that an application's individual JavaBeans are registered with appropriate security constraints.

Note: Because the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server enterprise application consists of many EJB JAR files, the detailed contents of the EJB deployment descriptors can be found in Application Services and Security.

The ejb-jar.xml Deployment Descriptors

An ejb-jar.xml file is the primary deployment descriptor for an Enterprise JavaBean (EJB). As such, the root element of this deployment descriptor element is <ejb-jar>. The <ejb-jar> element contains mandatory structural information about all included enterprise beans (defined in the <enterprise-beans> subelement), and may include an application-assembly descriptor. If present, the assembly descriptor contains the enterprise bean's security configuration information (in the <assembly-descriptor> subelement). This element structure is shown in Listing 2-14.

Listing 2-14 ejb-jar.xml Element Structure

<ejb-jar>
   <enterprise-beans>
	<entity>Declares an entity bean
<security-role-ref>Declares the security role for the
entity bean
</security-role-ref>
</entity>
	<session>Declares a session bean
<session-type>Stateful or Stateless</session-type>
<security-role-ref>Declares the security role for the
session bean
</security-role-ref>
</session>
   </enterprise-beans>
   <assembly-descriptor>
	<security-role>
<description>Documentation of the security
role
</description>
<role-name>Name of the security role</role-name>
</security-role>
	<method-permissions>
	   <role-name>Name of the security role</role-name>
  	   <method>
<ejb-name>Name of the bean</ejb-name>
<method-name>Name of the bean's method</method-name>
</method>
	</method-permissions>
   </assembly-descriptor>
</ejb-jar>

As Listing 2-14 also shows, the <enterprise-beans> element contains <entity> subelements when declaring entity beans, and/or <session> subelements when declaring session beans. The <entity> and <session> elements may further contain <security-role-ref> subelements, which enable the EJB to do programmatic security checking, if such behavior is desired. Also within the <session> element is a <session-type> subelement that describes whether the session bean is stateful or stateless.

If included, the <assembly-descriptor> element includes security roles and the individual method permissions associated with these security roles. The <security-role> subelements declare all the roles by which bean method calls will be authorized. Each security role requires a mapping to an actual group name in the corrresponding weblogic-ejb-jar.xml file. (The weblogic-ejb-jar.xml file is described in the following section.)

The assembly descriptor's <method-permission> subelement declares authorizations for each method in a bean. However, these entries are typically listed by security role (<role-name>), then by bean (<ejb-name>) and then by method (<method-name>). Therefore, there is usually one <method-permission> entry for each security role defined in the previously described <security-role> element.

The weblogic-ejb-jar.xml Deployment Descriptors

One purpose of the weblogic-ejb-jar.xml deployment descriptor is to associate the security role names that may be needed for a particular service (as defined in the corresponding ejb-jar.xml file) to principal names. Listing 2-15 shows the syntax of the security-role assignment element.

Listing 2-15 Syntax of the Security-Role Assignment Element

<security-role-assignment>
   <role-name>Name of security role</role-name>
<principal-name>Corresponding principal name</principal-name>
</security-role-assignment>

Notes: The role to principal mappings used in the web.xml deployment descriptor may also be used in weblogic-ejb-jar.xml. For more information about the web.xml application deployment descriptor, see About the web.xml and weblogic.xml Application Deployment Descriptors.

For more information about security roles and principals, see Roles and Principals.

 

back to top previous page next page