Configuring Container-Managed Security

#### Search Results

Search

# Configuring Container-Managed Security

This document covers the following topics:

- About Container-Managed Security

- Name and Location of the Configuration File for Security

- Activating Security

- Defining Security Constraints

- Defining Roles

- Selecting the Authentication Method

- Choosing the Login Module (WildFly)

- Configuring the UserDatabaseRealm (Apache Tomcat only)

## About Container-Managed Security

Natural for Ajax comes as a Java EE-based application. For the ease of installation, the access to this application is by default not secured. You might, however, wish to restrict the access to certain parts of the application to certain users. An important example is the configuration tool, which enables you to modify the Natural session definitions and the logging configuration of Natural for Ajax . Other examples are the Application Designer development workplace contained in Natural for Ajax or the Natural logon page.

This section does not cover the concepts of JAAS-based security in full extent. It provides, however, sufficient information to activate the preconfigured security settings of Natural for Ajax and to adapt them to your requirements. More information on the topics described in this section can be found, for instance, at http://www.wildfly.org/ .

Notes:

1. The recommended security method is application-managed authentication. For further information, see Configuring Application-Managed Authentication .
2. Container-managed security is not supported for IBM WebSphere Application Server. Use application-managed authentication instead.

## Name and Location of the Configuration File for Security

Security is configured in the file web.xml . The path to this file depends on the application server.

- Wildfly Application Server
  <application-server-install-dir> /server/default/deploy/njx <nn> .ear/cisnatural.war/WEB-INF

- Apache Tomcat
  <tomcat-install-dir> /webapps/cisnatural/WEB-INF

## Activating Security

Great care must be taken when editing and changing the configuration file web.xml . After a change, the application server must be restarted.

Edit the file web.xml and look for the section that is commented with "Uncomment the next lines to add security constraints and roles." . Uncomment this section by removing the comment marks shown in boldface below:

    <!-- Uncomment the next lines to add security constraints and roles. -->
    <!--
    <security-constraint>
          <web-resource-collection>
              <web-resource-name>Administration Tools</web-resource-name>
              <url-pattern>/njxruntimetools/*</url-pattern>
          </web-resource-collection>
    ...
    <security-role>
        <description>Administrator</description>
        <role-name>nwoadmin</role-name>
    </security-role>
    -->

## Defining Security Constraints

The security constraints defined by default are just examples. A `<security-constraint>` element contains of a number of `<web-resource-collection>` elements combined with an `<auth-constraint>` element. The `<auth-constraint>` element contains a `<role-name>` . The whole `<security-constraint>` element describes which roles have access to the specified resources.

Example - the following definition specifies that only users in the role "nwoadmin" have access to the configuration tool:

    <security-constraint>
        <web-resource-collection>
              <web-resource-name>Administration Tools</web-resource-name>
              <url-pattern>/njxruntimetools/*</url-pattern>
          </web-resource-collection>
        <auth-constraint>
            <role-name>nwoadmin</role-name>
        </auth-constraint>
    </security-constraint>

In the following section, you will see where and how the roles are defined.

## Defining Roles

A few lines below in the file web.xml , there is a section `<security-role>` . Here, the roles that can be used in `<security-constraint>` elements are defined. You can define additional roles as needed. The assignment of users to roles is done outside this file and will often be done in a user management that is already established at your site.

Example:

    <security-role>
        <description>Administrator</description>
        <role-name>nwoadmin</role-name>
    </security-role>

## Selecting the Authentication Method

In the file web.xml , there is a section `<login-config>` . The only element that should possibly be adapted here is `<auth-method>` . You can choose between the authentication methods "FORM" and "BASIC" . Form-based authentication displays a specific page on which users who try to access a restricted resource can authenticate themselves. Basic authentication advises the web browser to retrieve the user credentials with its own dialog box.

Example:

    <login-config>
        <auth-method>FORM</auth-method>
    ...
    </login-config>

## Choosing the Login Module (WildFly)

On WildFly, Natural for Ajax is installed as a web application (WAR file). See Installing Natural for Ajax on WildFly .

The configuration of WildFly as a so-called standalone server is described here.

All configuration (especially the security configuration) is centralized in the file <application-server-install-dir> /standalone/configuration/standalone.xml .

The following describes how to create a sample JAAS-based security configuration for WildFly 26:

1. Move the following sample configuration files from <application-server-install-dir> /standalone/deployments/cisnatural.war/WEB-INF to their appropriate location as described below:

   njxnwo-roles.properties and njxnwo-users.properties
   Move these two files to <application-server-install-dir> /standalone/configuration .

2. Add the following security domain definition in the file standalone.xml , under `<security-domains>` :

       <security-domains>
         ...
         <security-domain name="NaturalWebIOAndAjaxRealm" default-realm="NaturalWebIOAndAjaxRealm" permission-mapper="default-permission-mapper">
           <realm name="NaturalWebIOAndAjaxRealm"/>
         </security-domain>
         ...
       </security-domains>

       <security-realms>
         ...
         <properties-realm name="NaturalWebIOAndAjaxRealm" groups-attribute="Roles">
           <users-properties path="njxnwo-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="NaturalWebIOAndAjaxRealm" />
           <groups-properties path="njxnwo-roles.properties" relative-to="jboss.server.config.dir"/>
         </properties-realm>
         ...
       </security-realms>

3. Under <http> add the following:

       <http>
         ...
         <http-authentication-factory name="NaturalWebIOAndAjaxRealm-http" http-server-mechanism-factory="global" security-domain="NaturalWebIOAndAjaxRealm">
           <mechanism-configuration>
             <mechanism mechanism-name="FORM"/>
           </mechanism-configuration>
         </http-authentication-factory>
            ...
       </http>

4. Under <subsystem xmlns="urn:jboss:domain:undertow:12.0" ...> , add the following:

       <subsystem xmlns="urn:jboss:domain:undertow:12.0" ...>
         ...
         <application-security-domains>
           ...
           <application-security-domain name="NaturalWebIOAndAjaxRealm" http-authentication-factory="NaturalWebIOAndAjaxRealm-http"/>
           ...
         </application-security-domains>
         ...
       </subsystem>

This sample configuration uses the login module `UsersRoles`. The login module `UsersRoles` expects the role definitions in one file ( njxnwo-roles.properties ) and the user definitions (password and assignment to roles) in another file ( njxnwo-users.properties ). An example user "admin" with the password "adminadmin" and the role "nwoadmin" is defined to begin with.

You can choose and configure a different login module (for example, one that expects the user and role definitions in a database or in an LDAP directory), or you can even write a custom login module.

## Configuring the UserDatabaseRealm (Apache Tomcat only)

In the tomcat-users.xml file (which is located in the conf directory), specify the role "nwoadmin" for any desired user name and password. For example:

    <user username="pepe" password="pepe123" roles="nwoadmin"/>

For detailed information on the necessary realm configuration for Tomcat, see http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#UserDatabaseRealm .

### On this page

- About Container-Managed Security
- Name and Location of the Configuration File for Security
- Activating Security
- Defining Security Constraints
- Defining Roles
- Selecting the Authentication Method
- Choosing the Login Module (WildFly)
- Configuring the UserDatabaseRealm (Apache Tomcat only)