Supported configurations for LTPA

IBM MobileFirst Platform Foundation supports different configuration options to take advantage of LTPA, based on the server configuration and administrative requirements.

Protective application server (Option 1)

This configuration is formally known as Option 1 in tutorial WebSphere LTPA-based authentication, which we can find on the Get Started page. The application server is configured to protect all resources in the MobileFirst Server application, which is given specified roles. The application server sends the login page if the user does not send a valid LTPA token with the request. After the user sends valid credentials, the original request is sent to the MobileFirst Server application with an LTPA token. The LTPA realm consumes the LTPA token and automatically logs in the user.

The following image shows a protective application server flow:

This option is not preferred for new configurations. The application server such as the WAS Liberty (Liberty) protects all resources and forces users to log in before any other authentication mechanism. The behavior occurs regardless of the expected authentication order for a security test.

To use this option with Liberty, edit the web.xml from the MobileFirst Server WAR file and Liberty's server.xml file. The following example shows the required modifications to the web.xml file:

<!-- Existing web.xml configuration here -->
<security-constraint id="worklightSecurityConstraint">
  <web-resource-collection id="worklightWebResourceCollection">
    <web-resource-name>Worklight Server</web-resource-name>
    <description>Protection area for Worklight Server.</description>
    <url-pattern>/*</url-pattern>
    <http-method>GET</http-method>
    <http-method>POST</http-method>
  </web-resource-collection>
  <auth-constraint id="worklightAuthConstraint">
    <description></description>
    <role-name>allAuthenticationUsers</role-name>
  </auth-constraint>
  <user-data-constraint id="worklightUserDataConstraint">
    <transport-guarantee>NONE</transport-guarantee>
  </user-data-constraint>
</security-constraint>
<security-role id="securityRoleAllAuthenticatedUsers">
  <description>All Authenticated Users Role.</description>
  <role-name>allAuthenticationUsers</role-name>
</security-role>
<login-config>
  <auth-method>FORM</auth-method>
  <form-login-config>
    <form-login-page>/login.html</form-login-page>
    <form-error-page>/loginError.html</form-error-page>
  </form-login-config>
</login-config>

The following example shows the required modifications to the server.xml file:

<featureManager>
  <feature>appSecurity-1.0</feature>
  <!-- Any additional features we need go here -->
</featureManager>
<!-- Use an existing user registry instead if we have one.
     This registry is just an example. -->
<basicRegistry>
  <user name="sampleuser" password="demo" />
</basicRegistry>
<!-- Any additional settings go here -->
<application context-root="/worklight"
             location="worklight.war"
             name="worklight"
             type="war">
  <classloader commonLibraryRef="worklight-6.1.0,apps-common" />
    <!-- This is our addition: application-bnd.
         The security-role defines who is authorized into a role from web.xml -->
    <application-bnd>
      <security-role name="allAuthenticationUsers">
        <special-subject type="ALL_AUTHENTICATED_USERS" />
      </security-role>
    </application-bnd>
  </classloader>
</application>

Remember to add the login.html and loginError.html files to the root directory in the MobileFirst Server WAR file to provide a way for the user to log in. See step 4 of Configure the MobileFirst LTPA realm.

Protective MobileFirst security test (Option 2)

An alternative configuration allows the server to use all of the MobileFirst security test configuration features. This option is preferred for new configurations. For example, Option 1 always asks the user to log in on the first request. Option 2 asks for the user to authenticate only when the MobileFirst Server deems that it is necessary.

The following image shows a protective security test flow:

You need to modify only Liberty's server.xml file to configure this option. The WASLTPARealm handles the actual authentication against the user registry defined in the server.xml file. The example configuration allows the user with the user name sample user and the password demo to authorize correctly.

The following example shows the required modifications to the server.xml file:

<featureManager>
  <feature>appSecurity-1.0</feature>
  <!-- Any additional features we need go here -->
</featureManager>
<!-- Use an existing user registry instead if we have one.
     This registry is just an example. -->
<basicRegistry>
  <user name="sampleuser" password="demo"/>
</basicRegistry>
<!-- Any additional settings go here -->
<application context-root="/worklight"
             location="worklight.war"
             name="worklight"
             type="war">
  <classloader commonLibraryRef="worklight-6.1.0,apps-common"/>
    <!-- This is our addition: application-bnd.
         The security-role defines who is authorized into a role from web.xml -->
    <application-bnd>
      <security-role name="allAuthenticationUsers">
        <special-subject type="ALL_AUTHENTICATED_USERS" />
      </security-role>
    </application-bnd>
  </classloader>
</application>

Remember to add the login.html and loginError.html files to the root directory in the MobileFirst Server WAR file to provide a way for the user to log in. See step 4 of Configure the MobileFirst LTPA realm.

Parent topic: MobileFirst security overview