MobileFirst 6.3 adapter IGNORE_COOKIES policy still sends cookies

We are using custom device provisioning to authenticate devices to our WebSphere Portal back-end.

We have our adapter set to connect as endUser, and the cookies policy to IGNORE_COOKIES.

But for some reason, the adapter still uses a shared Ltpa token to connect to the backend for all devices.

In this state, the user is NOT authenticated in the Worklight Server yet, so I am not sure whether the connect as endUser option will work as intended. But IGNORE_COOKIES should?

var input = {
    method : 'get',
    returnedContentType : 'json',
    path : 'DeviceService/DeviceInfo/' + deviceId,
    headers : {"Authorization": "Basic " + auth},
    parameters : {
        token: token
    }
};

try {
    var result = WL.Server.invokeHttp(input);
    return result;
} catch (e) {
    WL.Logger.error("ERROR: " + e);
    return null;
}

Our authenticationConfig.xml is as follows:

<?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">
    <!-- Licensed Materials - Property of IBM
             5725-I43 (C) Copyright IBM Corp. 2006, 2013. All Rights Reserved.
             US Government Users Restricted Rights - Use, duplication or
             disclosure restricted by GSA ADP Schedule Contract with IBM Corp. -->
    <securityTests>
        <mobileSecurityTest name="MAPCertLogin">
            <testDeviceId provisioningType="custom" realm="MAPLoginRealm"/>
            <testAppAuthenticity/>
        </mobileSecurityTest>
    </securityTests>
    <realms>
        <realm loginModule="StrongDummy" name="SampleAppRealm">
            <className>com.worklight.core.auth.ext.FormBasedAuthenticator</className>
        </realm>
        <realm loginModule="MAPLoginModule" name="MAPLoginRealm">
            <className>com.worklight.core.auth.ext.DeviceAutoProvisioningAuthenticator</className>
            <parameter name="validate-csr-function" value="Authenticator.validateCSR"/>
        </realm>
    </realms>
    <loginModules>
        <loginModule name="StrongDummy">
            <className>com.worklight.core.auth.ext.NonValidatingLoginModule</className>
        </loginModule>
        <loginModule name="requireLogin">
            <className>com.worklight.core.auth.ext.SingleIdentityLoginModule</className>
        </loginModule>
        <loginModule name="MAPLoginModule">
            <className>com.worklight.core.auth.ext.DeviceAutoProvisioningLoginModule</className>
            <parameter name="validate-certificate-function" value="Authenticator.validateCertificate"/>
        </loginModule>
    </loginModules>
</tns:loginConfiguration>

I can't confirm it anymore, but I am pretty sure this worked in our Worklight 6.2 environment.

What could be the reason for the ltpa token still being send?

A defect was found for this problem and a fix is available for IBM customers. Contact IBM Support for more details.

ibm.com/support