Chapter 3. Configuring Security for Applications and Modules

Table of Contents

3.1. Overview
3.1.1. Module Deployment and Application Deployment
3.1.2. Role-to-Resource Mapping
3.1.3. Principal-to-Role Mapping
3.1.4. User Configurations
3.2. Configuring EJB Module Security
3.2.1. Configuring ejb-jar.xml
3.2.2. Configuring jeus-ejb-dd.xml
3.3. Configuring Web Module Security
3.3.1. Configuring web.xml
3.3.2. Configuring jeus-web-dd.xml
3.4. Configuring J2EE Application Security
3.4.1. Configuring application.xml
3.4.2. Configuring jeus-application-dd.xml
3.5. Examples

This chapter explains how to configure security in J2EE applications, EJB, and Web modules.

This section explains basic information related to security configuration for J2EE applications and modules.

The basic procedure for configuring security settings of J2EE application, EJB module, and web module is as follows.

  1. Configure Role-to-Resource mapping for each module.

  2. Configure principal-to-role mapping for each application.

Before deploying an EJB or Web module, the assembler must first configure the role-to-resource mapping for the module. The role-to-resource mapping is also called the security constraint, which refers to mapping a resource of a module to a logical Role.

  • In EJB modules, resources refer to EJB methods, and they are configured in META-INF/ejb-jar.xml

  • In web modules, resources refer to the servlet URLs, and they are configured in WEB-INF/web.xml.

The following are the security constraints configured in the META-INF/ejb-jar.xml file for an EJB module:


Descriptions of security constraints in the previous DD (deployment descriptor) file are as follows:

1

There is an EJB entity called product.

2

The role-to-role reference mapping is declared. The actual declared Role, customer, can be referred to by the role reference name, cust, which means that the role named cust in the EJB code corresponds to the customer Role.

3

The logical role administrator is declared.

4

The logical role customer is declared.

5

The role-to-resource mapping is declared. This enables the role administrator to call the getSecreteKey method of the remote EJB interface. According to this mapping, only Principals belonging to the administrator role can call the getSecreteKey method.

6

doSomeAdmin method is declared as unchecked. This means that anyone can call the method regardless of the Role.

7

Any principal in the role customer can call the test1 method of the product EJB.

8

The getCustomerProfile method is included in the Excluded list. This means that no role can call this method.

The configuration for Web modules is similar to that for EJB modules except that the Roles access Servlet URLs instead of EJB methods. Refer to "3.3. Configuring Web Module Security" for more information about security configuration for Web modules.

The two Roles, administrator and customer, are purely logical and do not have any meaning in the target deployment environment. Therefore, these logical Roles must be mapped to the actual users or user groups of the target system. This is referred to as principal-to-role mapping. Refer to "3.1.3. Principal-to-Role Mapping" for more information about the mapping.

It is usually the task of the deployer to map the role defined in J2EE modules or applications to users or user groups in the actual environment. Note that mappings from Principals to logical Roles have application scope.

For example, if two modules M1 and M2 are deployed as parts of the same application A1, the principal-to-role mappings will be shared by the two modules. Furthermore, another application A2 may have a totally different principal-to-role from A1. Even if A1 and A2 each have the a role with the same name, these are recognized as different roles and are not shared.

These concepts are illustrated in the following figure.


As shown in the previous figure, two different applications A1 and A2 have different principal-to-role mappings, and two modules M1 and M2 share the mapping included in the application.

The principal-to-role mapping is defined in the following files in JEUS.

  • jeus-ejb-dd.xml, the JEUS DD file (EJB module)

  • jeus-web-dd.xml (web module)

  • jeus-application-dd.xml (J2EE application)

The following is the example of the configuration of jeus-ejb-dd.xml for ejb-jar.xml.


The previous example contains the following security information.

1

The role permission that grants the principal (user) named user1 to be in the role administrator. This means that user1 is mapped to the role administrator, and consequently, user1 will inherit all the rights of the Role.

As can be seen in the previous example, custom role permission is defined in the <classname> tag. Refer to "Chapter 2. Configuring the Security System" for more information about the custom role permission.

2

The Role-permission that grants the principal (user) named user2 to be in role customer. This means that user2 is mapped to the role customer and consequently, user2 will inherit all the rights of role Customer. Since no <classname> tag is specified, the default role permission will be used.

3

The role roleA is excluded from all Principals, which means that no principal can be in roleA.

4

The role roleB is unchecked in the authorization system, which means that all Principals are automatically included in roleB.

5

The <unspecified-method-permission> tag determines how unspecified EJB methods are to be handled. An unspecified EJB method is an EJB method that is not included in the <method-permission> tag in ejb-jar.xml.

The <unspecified-method-permission> can be handled in the following three ways: be mapped to a role (like in this example where they are mapped to the role administrator), be marked as excluded (accessible to no one) or be marked as unchecked (be accessible to everyone). The last option, unchecked, is the default value.

Note

The configurations for Web modules (jeus-web-dd.xml) is similar to that for EJB modules, except that the <unspecified-method-permission> tag is not used for Web modules.

There are two user configuration methods:

Note

User information has application security domain scope, regardless of the way it is configured. In other words, a user in a security domain is shared by all applications using the same security domain.

This section explains in detail how to configure security for EJB modules. For more information about security configurations that are not covered here, such as CSI, refer to "JEUS EJB Guide".

There are two security configuration methods as follows:

The ejb-jar.xml file is used to configure the following security items.

  • Role-to-Role Reference mapping

  • security identity configuration

  • Logical role declaration

  • EJB method permission configurations

The following example illustrates how to specify the aforementioned security items in ejb-jar.xml.


The following security items can be specified in ejb-jar.xml.

  • Role-to-Role Reference mapping

    The role-to-role reference mapping is specified in the <security-role-ref> tag. Its purpose is to map a role reference to a logical role. In the EJB code, the role reference is used instead of the actual Role.

    The following tags are used inside the <security-role-ref> tag.

    TagDescription
    <role-name>The role reference which is used in EJB code instead of the actual role name.
    <role-link>The name of the actual role declared in the security-role tag. The role reference is mapped to a role indicated by the role-link.
  • security identity configuration

    Every EJB in the module has a security identity, which will be propagated to other EJBs during remote calls. The security identity for an EJB is configured using the tags, <ejb-jar> <enterprise-beans> <type><security-identity>.

    It has the following child tags.

    TagDescription
    <use-caller-identity>If this tag is empty, the caller of the EJB will be used as the security identity.
    <run-as>If this tag is used, the principal of the role specified in <role-name> will be used as the security identity when an EJB is called. If the <run-as-identity> tag exists in jeus-ejb-dd.xml, this setting will be ignored.

Note

Refer to "3.1.2. Role-to-Resource Mapping" for an explanation of the previous example. Refer to the EJB specification for more information about these tags. Also refer to the "JEUS EJB Guide" for information about deploying EJB modules in JEUS.

The following security configuration items can be specified in jeus-ejb-dd.xml.

  • Security-related configurations

  • Configuring EJB methods that are not defined in ejb-jar.xml

  • Configuring EJB principal which uses the run-as identity

While the ejb-jar.xml file takes care of most role-to-method mappings for the EJB, it still needs to determine where to declare the principal-to-role mappings and how to handle EJB methods that were not handled in ejb-jar.xml. These mappings and handling are configured in the jeus-ejb-dd.xml file, which usually resides in the META-INF directory of the deployed EJB .jar archive.

The following example illustrates how to configure the previous security configuration items in jeus-ejb-dd.xml.


The following security items can be configured in jeus-ejb-dd.xml.

Note

1. Refer to "3.1.2. Role-to-Resource Mapping" for an explanation of the example.

2. Refer to "JEUS EJB Guide" for more information about these tags.

This section explains in detail how to configure security for web (Servlet) modules.

The security of web modules is divided into two parts:

web.xml is the main DD file for a Web archive (WAR file). This is a standard J2EE DD file that usually resides in the WEB-INF directory of the WAR file.

The security items that can be configured in web.xml are as follows.

The following is an example of security configurations of web.xml.

[Example 3.5] Web Module Security Configurations: <<web.xml>>

<?xml version="1.0"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee">
    <servlet>
        <servlet-name>HelloWorld</servlet-name>
        . . .

1       <run-as>
            <role-name>R1</role-name>
        </run-as>
2       <security-role-ref>
            <role-name>adminRef</role-name>
            <role-link>R1</role-link>
        </security-role-ref>
        . . .

    </servlet>
3   <security-constraint>
       <web-resource-collection>
            <web-resource-name>A</web-resource-name>
            <url-pattern>/a/*</url-pattern>
            <url-pattern>/b/*</url-pattern>
            <url-pattern>/a</url-pattern>
            <url-pattern>/b</url-pattern>
            <http-method>DELETE</http-method>
            <http-method>PUT</http-method>
        </web-resource-collection>
        <web-resource-collection>
            <web-resource-name>B</web-resource-name>
            <url-pattern>*.asp</url-pattern>
        </web-resource-collection>
        <auth-constraint/>
    </security-constraint>
4   <security-constraint>
        <web-resource-collection>
            <web-resource-name>C</web-resource-name>
            <url-pattern>/a/*</url-pattern>
            <url-pattern>/b/*</url-pattern>
            <http-method>GET</http-method>
        </web-resource-collection>
        <web-resource-collection>
            <web-resource-name>D</web-resource-name>
            <url-pattern>/b/*</url-pattern>
            <http-method>POST</http-method>
        </web-resource-collection>

        <auth-constraint>
            <role-name>R1</role-name>
        </auth-constraint>
        <user-data-constraint>
            <transport-guarantee>
                CONFIDENTIAL
            </transport-guarantee>
        </user-data-constraint>
    </security-constraint>
5   <security-role>
        <role-name>R1</role-name>
    </security-role>
    <security-role>
        <role-name>R2</role-name>
    </security-role>
    <security-role>
        <role-name>R3</role-name>
    </security-role>
</web-app>  


Descriptions of the previous example are as follows:

1

The run-as-identity is set to role R1, meaning that the propagated security identity of the servlet must be a principal that is in R1. The actual principal is specified in the JEUS DD file.

2

In the <security-role-ref> tag, the actual role R1 is mapped to the role reference adminRef. In the actual Servlet source codes, the role reference adminRef is used instead of the Role.

3

The first security constraint specifies that the URLs with patterns, "/a", "/b", "/a/*", "/b/*" and HTTP methods DELETE and PUT, and all URLs that end with "*.asp" must NOT be accessible to anyone.

This is because it is set to <auth-constraint/>.

4

The second security constraint says that the URLs with patterns, "/a/*", "/b/*" and HTTP method GET, and all URLs with the pattern /b/* and HTTP method POST should only be accessible by Principals that are in the role R1 and the connection should be CONFIDENTIAL.

5

Declares three logical roles: R1, R2, and R3.

If a web resource (URL patterns + HTTP methods) is not configured in web.xml, anyone can access the resource regardless of the Role. This is the default rule for Web applications in J2EE.

This section explains how to configure jeus-web-dd.xml, which is the JEUS DD file for web modules.

  • Setting <run-as-principal> in servlet

    To set <run-as-principal> tag in a servlet, define the <servlet> tag and add the <run-as><principal-name> tag to it. The value of the <principal-name> tag must be the principal that belongs to the role defined in <run-as><role-name> tag of web.xml.

Caution

Currently, there are no tags to specify how to handle the Servlet URLs that are not defined in web.xml of jeus-web-dd.xml. In the Servlet specifications, all unspecified Servlet URLs are always regarded as unchecked and accessible by everyone.

The following is an example of security configurations in jeus-web-dd.xml.


Explanation of the previous example are as follows.

1

The Principals user1, user2, and customerGroup are in the role R1.

2

The role R2 is excluded so no one will be in the role.

3

The role R3 is unchecked so any one can be in the role.

4

The principal tellerGroup will be in the role R4 on the condition that the current time is between 9 am and 5 pm. This logic is implemented in the implies() method of the jeus.security.resource.TimeConstrainedRolePermission class.

5

user1 is used as a run-as-principal. When the Servlet calls an EJB, user1 will be passed as the security identity. Note that the deployer must check that user1 is in the role R1, which is defined in web.xml.

This section explains how to set security for J2EE applications (EAR file).

The basic procedure is as follows:

J2EE application is an archive file with the ".ear" extension. The EAR archive consists of EJB, Web, and connector modules, and any other necessary supporting classes. The META-INF directory contains the application.xml configuration file that provides various information about the application.

This section explains the security-related information in application.xml.

There is basically only one type of security information in application.xml: declaration of logical security Roles. The role declaration applies to all EJB and Web modules in the EAR file and has an application scope.


In the previous example, the two Roles, Administrator and Customer, are declared.

These two roles are used in the DD files of EJB and Web modules to define role-to-resource mappings. Securities for EJB and web modules are explained in "3.2. Configuring EJB Module Security" and "3.3. Configuring Web Module Security".

Before deploying applications to the JEUS Server, ensure that logical roles are mapped to the actual Principals. This mapping is configured in the following files.

  • For applications: jeus-application-dd.xml

It is important to understand all the modules in a J2EE application, because Roles and principal-to-role mappings are shared within the limits of the application. If the role Administrator is defined in the application. xml file, and the principal user2 is granted the role Administrator in jeus-application-dd.xml, this role will be applied to all EJBs and Web modules in the application.

In the same way, even though this role and principal-to-role mapping are defined only in jeus-ejb-dd.xml of a particular EJB module, they are accessible to all modules in the EAR file.

Caution

Note that all principal-to-role mappings in J2EE applications have an application scope whether it is configured in jeus-application-dd.xml, or in a certain jeus-ejb-dd.xml or jeus-web-dd.xml file.

The principal-to-role mappings on the application level are set in jeus-application-dd.xml.

To define a principal-to-role mapping, add the following tags under the <application> tag in jeus-application-dd.xml.

The security domain to which the application is deployed must be specified inside the <application> tag. By default, the security domain, SYSTEM_DOMAIN, will be used, but if a particular application requires a specific security service, a new domain that includes the security service must be created and deployed.

The security domain name can be specified using the deploy command of jeusadmin.


In the previous example, the J2EE application security is set as follows:

1

The principal user2 is mapped to the role Administrator, and uses the default RolePermission.

2

Since the role is unchecked, All principals are in the role Customer.

Note

1. For more information about configuring a security domain, refer to "2.2. Configuring the Security System Domain".

2. For more information about how to develop and configure Custom Permissions, refer to "2.6. Configuring Security System Policies".

3. For more information about how to deploy J2EE applications to JEUS, refer to "JEUS Server Guide".

This section briefly introduces the configuration examples from the previous sections.

The following page shows the login page for accessing the main page. The following page can be accessed only when the checked permission has been set for the URL. If the unchecked permission is set, the screen will directly go to the main page. If the excluded permission is set, authorization will fail and an error page will appear.


If authorization fails or an attempt was made to login using an unauthorized account, an error page will appear. If the login is successful, the following page will appear.


The previous main page has three Servlet links, and can call three EJB methods. A successful login is dependent on the login account and the configuration files. Thus, a user can directly check for accessibility using different configurations and login accounts.