The authentication configuration file
All types of authentication component are configured in the authentication configuration file.
Authentication components, security tests, realms, login modules, and authenticators are all configured in the authenticationConfig.xml authentication configuration file, which is in the /server/conf directory of your MobileFirst project. A web security test or mobile security test must contain a <testUser> element that specifies the realm name. The definition of a realm includes the class name of an authenticator, and a reference to a login module, and refers to a collection of resource managers that recognizes a common set of user credentials and authorizations. Authenticators are the entities that authenticate clients. Authenticators collect client information, and then use login modules to verify this information.
| Realm reference | Login module reference | Description |
|---|---|---|
| wl_anonymousUserRealm | WeakDummy | This realm is the default user realm. As having
a user identity is mandatory for a user to use IBM MobileFirst™ Platform Foundation properly,
use this realm if you do not require any special identification of
users. This realm gives the user a random unique user ID to be used
for various features in the server, such as reports and audit, identification
of access to back-end systems, and push notification. This realm is
transparent, that is, it does not require any user interaction. The wl_anonymousUserRealm realm is a persistent cookie and is used by MobileFirst Server to differentiate between different application instances. MobileFirst Server looks for a WL_PERSISTENT_COOKIE cookie in each request. In case none is found, it will generate a GUID and send it back to the client in a Set-Cookie header with a one-year expiration date. |
| wl_antiXSRFRealm | WLAntiXSRFLoginModule | This realm is used to avoid cross-site request forgery attacks. When a new session is initiated, the first request to MobileFirst Server gets an HTTP 401 response that contains the WL-Instance-Id token. The MobileFirst framework extracts this token and uses it as a header on all subsequent requests. If this header is not present in these subsequent requests, HTTP 401 is returned again. This security mechanism makes sure that all subsequent requests are coming from the same source as the initial one. |
| wl_authenticityRealm | wl_authenticityLoginModule | This realm is used to verify that application is authentic and it was not modified by a third party. The realm is applicable to Android, iOS, Windows Phone Silverlight 8, and Windows 8 Universal. The basic authenticity check is based on certificates that are used to sign applications. Extended application authenticity is based on the application binary file. This functionality is only available on the IBM-supported editions of IBM MobileFirst Platform Foundation, and is supported by Android, iOS, Windows 8 Universal, and Windows Phone Silverlight 8 only. You cannot enable extended authenticity if you use the internal MobileFirst Development Server that is embedded in MobileFirst Studio. |
| wl_deviceAutoProvisioningRealm | WLDeviceAutoProvisioningLoginModule | The description of this parameter is the same as for wl_deviceNoProvisioningRealm, but the obtained device identity is automatically provisioned by the MobileFirst Server. This realm must be used with wl_authenticityRealm. |
| wl_deviceNoProvisioningRealm | WLDeviceNoProvisioningLoginModule | A default device identity realm. Device identity is similar to user identity, but it is provided by the device itself. Device identity is relevant for hybrid and native smartphone environments only. The device identity is a must for functionality such as push notifications, and reports. This parameter means that the obtained device identity is used as is, without provisioning. |
| wl_directUpdateRealm | WLDirectUpdateNullLoginModule | This realm is used to enable the direct update feature. The direct update feature allows for updating of application web resources (not native code) on client devices without the need for users to explicitly download and install the new version. This realm is useful when a fix or an enhancement is done to the web resources of the application and you do not want to start a full release cycle for it. It can be configured to test for updates once per session, per each request, or disabled. For more information about direct update, see Configuring and customizing direct update. |
| wl_remoteDisableRealm | WLRemoteDisableNullLoginModule | This realm is used to block applications with specific application environments or versions from accessing resources on the server, or to notify clients with some mandatory message that is related to the server. This realm is typically used when a new application version is released and you no longer want the applications with the older versions to connect to the server. In this case, for example, you want to give directions to the clients on how to obtain the new version of the application with a link to its market download page. Another typical use of this realm is when you find a problem with an application security and you want to immediately block access from this application to sensitive data until the problem is fixed. You can configure the contents of the block or notification message and give a link to more information or the new version. For more information about remote disable, see Remotely disabling application connectivity. |
MobileFirst static resources (other than Application Center) such as the MobileFirst Operations Console are also configured in the authentication configuration file, in the <resource> element.
The configuration file has the following structure:
<?xml version="1.0" encoding="UTF-8"?>
<tns:loginConfiguration xmlns:tns="http://www.worklight.com/auth/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<staticResources>
<resource>...</resource>
<resource>...</resource>
</staticResources>
<securityTests>
<customSecurityTest>...</customSecurityTest>
<customSecurityTest>...</customSecurityTest>
</securityTests>
<realms>
<realm>...</realm>
<realm>...</realm>
</realms>
<loginModules>
<loginModule>...</loginModule>
<loginModule>...</loginModule>
</loginModules>
</tns:loginConfiguration>