Table of Contents
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.
Configure Role-to-Resource mapping for each module.
Configure principal-to-role mapping for each application.
There are two ways of deploying an application in JEUS:
Deploy each EJB module (EJB.jar file) and Web module (.war file) independently.
Deploy a J2EE application (.ear) by compressing several EJB, Web, and connector modules (.rar files) into an EAR file.
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:
[Example 3.1] Security Constraints Configured in EJB Module: <<ejb-jar.xml>>
<?xml version="1.0"?> <ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee"> <display-name>product</display-name> <enterprise-beans> <entity> <ejb-name>product</ejb-name> . . . <security-role-ref> <role-name>cust</role-name> <role-link>customer</role-link> </security-role-ref> </entity> </enterprise-beans> <assembly-descriptor> . . . <security-role> <role-name>administrator</role-name> </security-role> <security-role> <role-name>customer</role-name> </security-role> <method-permission> <role-name>administrator</role-name> <method> <ejb-name>product</ejb-name> <method-intf>Remote</method-intf> <method-name>getSecretKey</method-name> <method-params> <method-param>java.lang.Integer</method-param> </method-params> </method> </method-permission> <method-permission> <unchecked/> <method> <ejb-name>product</ejb-name> <method-name>doSomeAdmin</method-name> <method-params> <method-param>java.lang.String</method-param> </method-params> </method> </method-permission> <method-permission> <role-name>customer</role-name> <method> <ejb-name>product</ejb-name> <method-name>test1</method-name> </method> </method-permission> <exclude-list> <method> <ejb-name>product</ejb-name> <method-intf>Remote</method-intf> <method-name>getCustomerProfile</method-name> <method-params></method-params> </method> </exclude-list> </assembly-descriptor> </ejb-jar>
Descriptions of security constraints in the previous DD (deployment descriptor) file are as follows:
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.
[Example 3.2] Principal-to-Role Mapping: <<jeus-ejb-dd.xml>>
<?xml version="1.0"?> <jeus-ejb-dd xmlns=“http://www.tmaxsoft.com/xml/ns/jeus”> <module-info> <role-permission> <principal>user1</principal> <role>administrator</role> <classname>mypackage.MyRolePermission</classname> </role-permission> <role-permission> <principal>user2</principal> <role>customer</role> </role-permission> <role-permission> <role>roleA</role> </excluded> </role-permission> <role-permission> <role>roleB</role> </unchecked> </role-permission> <unspecified-method-permission> <role>administrator</role> </unspecified-method-permission> </module-info> <beanlist> . . . </beanlist> </jeus-ejb-dd>
The previous example contains the following security information.
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. | |
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. | |
The role roleA is excluded from all Principals, which means that no principal can be in roleA. | |
The role roleB is unchecked in the authorization system, which means that all Principals are automatically included in roleB. | |
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. |
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:
Using user configuration method of the domain that is used by applications, configure the JEUS_HOME/domains/<domain name>/config/security/<security domain name>/accounts.xml file. (Refer to "2.5. Configuring the Security System User Information")
Using the user configuration method of EJB modules (EJB .jar file), Web modules (.war file), and J2EE applications (.ear file), configure the accounts.xml file in the WEB-INF (web module) or META-INF ( EJB module and EAR) directory.
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.
[Example 3.3] Security Configurations: <<ejb-jar.xml>>
<?xml version="1.0"?> <ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee"> <display-name>product</display-name> <enterprise-beans> <entity> <ejb-name>product</ejb-name> . . . <security-role-ref> <role-name>cust</role-name> <role-link>customer</role-link> </security-role-ref> <security-identity> <run-as> <role-name>administrator</role-name> </run-as> </security-identity> </entity> </enterprise-beans> <assembly-descriptor> . . . <security-role> <role-name>administrator</role-name> </security-role> <security-role> <role-name>customer</role-name> </security-role> <method-permission> <role-name>administrator</role-name> <method> <ejb-name>product</ejb-name> <method-intf>Remote</method-intf> <method-name>getSecretKey</method-name> <method-params> <method-param>java.lang.Integer</method-param> </method-params> </method> </method-permission> <method-permission> <unchecked/> <method> <ejb-name>product</ejb-name> <method-name>doSomeAdmin</method-name> <method-params> <method-param>java.lang.String</method-param> </method-params> </method> </method-permission> <method-permission> <role-name>customer</role-name> <method> <ejb-name>product</ejb-name> <method-name>test1</method-name> </method> </method-permission> <exclude-list> <method> <ejb-name>product</ejb-name> <method-intf>Remote</method-intf> <method-name>getCustomerProfile</method-name> <method-params></method-params> </method> </exclude-list> </assembly-descriptor> </ejb-jar>
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.
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.
EJB method Permission configuration
The <method-permission> tag, inside the <assembly-descriptor> tag, specifies security constraints for each EJB method. Child tags are as follows.
Specifies the name of a logical role defined in <security-role>. It has access to the methods defined in the following.
An empty tag. If specified, the following methods will be unchecked. Anyone can access these methods, regardless of its Role.
The method to which the <role-name> and <unchecked> tags will be applied. The child tags are as follows.
Defines excluded EJB methods that no one can access. Only one <excluded-list> tag can exist, but can have multiple child <method> tags.
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.
[Example 3.4] Security Configurations: <<jeus-ejb-dd.xml>>
<?xml version="1.0"?> <jeus-ejb-dd xmlns=“http://www.tmaxsoft.com/xml/ns/jeus”> <module-info> <role-permission> <principal>user1</principal> <role>administrator</role> <classname>mypackage.MyRolePermission</classname> </role-permission> <role-permission> <principal>user2</principal> <role>customer</role> </role-permission> <role-permission> <role>roleA</role> </excluded> </role-permission> <role-permission> <role>roleB</role> </unchecked> </role-permission> <unspecified-method-permission> <role>administrator</role> </unspecified-method-permission> </module-info> <beanlist> <jeus-bean> . . . <run-as-identity> <principal-name>user1</principal-name> </run-as-identity> </jeus-bean> . . . </beanlist> </jeus-ejb-dd>
The following security items can be configured in jeus-ejb-dd.xml.
Security-related configurations
Most security-related settings in jeus-ejb-dd.xml are set in the <jeus-ejb-dd> tag just below the parent tag, <module-info>.
Each tag specifies permission for a role (usually a principal-to-role mapping).
Descriptions of each child tag of <role-permission> are as follows.
Configuring EJB methods that are not defined in ejb-jar.xml
There are three ways to handle EJB methods that are not specified in ejb-jar.xml. They are defined in the child tag, <unspecified-method-permission>, inside the <module-info> tag.
The configurable child tags are as follows.
Configuring EJB Principal which uses the run-as identity
The principal needs to be set for an EJB that uses the run-as identity. The principal name specified in the <jeus-bean> <run-as-identity> <principal-name> tag is used. The principal must be in the role that is specified in the <security-identity><run-as><role-name> tag of ejb-jar.xml.
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:
Configuring web.xml: Role-to-Web Resource mapping configurations
Configuring jeus-web-dd.xml: principal-to-role mapping configurations
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.
Role-to-role reference mapping
The role-to-role reference mappings are configured in the <security-role-ref> tag. Its purpose is to map a role reference to a logical Role. The role reference represents the role in the servlet code.
The <security-role-ref> tag is configured inside the <servlet> tag of web.xml and has the following child tags.
Permissions to access servlet URL (Security constraints)
To restrict the access to Servlet URL, the <security-constraint> tag inside the <web-app> tag is used.
<security-constraint> has the following child tags.
<web-resource-collection> (one or more)
Specifies a list of Web resources for which access constrains are set.
Specifies the roles that can access the web resource defined in the <security-constraint> tag. There must be zero or more <role-name> child tag(s), each specifying a logical role name that allows access to the resource.
If no role name is specified and it is empty (<auth-constraint/>), no one can access the web resource (same as excluded Web resources).
If the <auth-constraint> tag is omitted, the web resource will be unchecked so that any one can access it regardless of the role.
<user-data-constraint> (optional)
Sets whether to declare a "transport guarantee" for connections that are made to the web resources.
It has the <transport-guarantee> child tag, which specifies the guarantee level for the Web resource connections.
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> . . . <run-as> <role-name>R1</role-name> </run-as> <security-role-ref> <role-name>adminRef</role-name> <role-link>R1</role-link> </security-role-ref> . . . </servlet> <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> <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> <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:
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.
Refer to the Servlet specifications for more information about the tags in web.xml. Also refer to "JEUS Web Engine Guide" for additional information about deploying Servlets in JEUS.
This section explains how to configure jeus-web-dd.xml, which is the JEUS DD file for web modules.
Defining Principal-to-Role mapping
To define a principal-to-role mapping in jeus-web-dd.xml, use the <jeus-web-dd> <context><role-mapping> tag.
The following are child tags of <role-mapping>.
Specifies permission for a role (usually a principal-to-role mapping).
The following are descriptions for the child tags.
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.
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.
[Example 3.6] Web Module Security Configurations: <<jeus-web-dd.xml>>
<?xml version="1.0"?> <jeus-web-dd xmlns=“http://www.tmaxsoft.com/xml/ns/jeus”> <context> <context-path>/tutorial</context-path> <docbase>Tutorial</docbase> . . . <role-mapping> <role-permission> <principal>user1</principal> <principal>user2</principal> <principal>customerGroup</principal> <role>R1</role> </role-permission> <role-permission> <role>R2</role> </excluded> </role-permission> <role-permission> <role>R3</role> </unchecked> </role-permission> <role-permission> <principal>tellerGroup</principal> <role>R4</role> <actions>09:00-17:00</actions> <classname> jeus.security.resource.TimeConstrainedRolePermission </classname> </role-permission> </role-mapping> <servlet> <servlet-name>HelloWorld</servlet-name> <run-as-identity> <principal-name>user1</principal-name> </run-as-identity> . . . </context> </servlet> . . . </jeus-web-dd>
Explanation of the previous example are as follows.
This section explains how to set security for J2EE applications (EAR file).
The basic procedure is as follows:
Configuring application.xml: Declare logical roles.
Configuring jeus-application-dd.xml: Configure the security domain for deployment and principal-to-role mapping.
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.
[Example 3.7] J2EE Application Security Configuration: <<application.xml>>
<?xml version="1.0" encoding="UTF-8"?> <application version="1.4" . . .> <description>Application description</description> <display-name>myApp</display-name> <module> <web> <web-uri>myWebApp.war</web-uri> <context-root>myWebApp</context-root> </web> </module> <module> <ejb>myEjbApp.jar</ejb> </module> <security-role> <role-name>Administrator</role-name> </security-role> <security-role> <role-name>Customer</role-name> </security-role> </application>
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
For EJB modules: jeus-ejb-dd.xml (for more information about principal-to-role mapping, refer to "3.2.2. Configuring jeus-ejb-dd.xml")
For Web modules: jeus-web-dd.xml (for more information about principal-to-role mapping, refer to "3.3.2. Configuring jeus-web-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.
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.
Each <role-permission> tag defines a principal-to-role mapping and can optionally configure Excluded and Unchecked Roles. This tag works exactly the same that in jeus-web-dd.xml, jeus-ejb-dd.xml, and policies.xml files.
It has the following child tags.
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:
The principal user2 is mapped to the role Administrator, and uses the default RolePermission. | |
Since the role is unchecked, All principals are in the role Customer. |
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.