Worklight cannot login to application protected behind ltpatoken sso

Question

While trying to test my worklight LTPA sso configuration, I cannot login to my application. I can however login to a protected worklight console through LTPA (without being prompted for a username/password), so I know that the LTPA token is getting validated correctly.

When I use the worklight console to access my protected application, I get 500 errorsfrom the common/init and common/login call because I am being challenged by the worklight server for authentication.

This is on worklight 6.1.0.2. I have attached the a wireshark trace of the worklight server's response here:

Unauthorized
X-Powered-By: Servlet/3.0
P3P: policyref="/w3c/p3p.xml", CP="CAO DSP COR CURa ADMa DEVa OUR IND PHY     ONL UNI COM NAV INT DEM PRE"
WWW-Authenticate: WL-Composite-Challenge
Content-Type: application/json; charset=UTF-8
Cache-Control: no-cache, no-store, must-revalidate
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Content-Length: 96
Content-Language: en-US
Connection: Close
Date: Fri, 05 Jun 2015 21:23:48 GMT

/*-secure-
{"challenges":{"wl_antiXSRFRealm":{"WL-Instance-Id":"kp3k4l8812ubp1d3ir6oeub9t2"}}}*/

Here's my authenticationConfig.xml

<staticResources>
    <resource id="worklightConsole" securityTest="CustomAdapter-securityTest">
        <urlPatterns>/console*</urlPatterns>
    </resource>
</staticResources>

<securityTests>

    <customSecurityTest name="CustomAdapter-securityTest">
        <test isInternalUserID="true" realm="CustomAuthenticationRealm"/>
    </customSecurityTest>


</securityTests>
<realms>
    <realm loginModule="CustomLoginModule" name="CustomAuthenticationRealm">
      <className>com.worklight.core.auth.ext.WebSphereFormBasedAuthenticator</className>
        <parameter name="login-page" value="/login.html"/>
        <parameter name="error-page" value="/loginError.html"/>
        <parameter name="cookie-name" value="LtpaToken2"/>
    </realm>
</realms>

<loginModules>
<loginModule name="CustomLoginModule">
        <className>com.worklight.core.auth.ext.WebSphereLoginModule 
        </className>
        <parameter name="httponly-cookie" value="true" />
        <parameter name="cookie-name" value="LtpaToken2" />
</loginModule>
</loginModules>

In case you want it, here's the wireshark of the request being sent to the Worklight common/init (with my LTPAToken removed for security)

POST /AnywhereWorkManager/apps/services/api/WorkExecution/common/init HTTP/1.1
accept: text/javascript, text/html, application/xml, text/xml, */*
accept-language: en-US
connection: close
content-length: 65
content-type: application/x-www-form-urlencoded; charset=UTF-8
host: <the internal host>
referer: https://<the external host>/AnywhereWorkManager/apps/services/preview/WorkExecution/common/0/default/index.html
user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36
via: HTTP/1.1 <the external host>
x-wl-app-version: 1.0
origin: https://<the external host>
iv_server_name: reverseproxy-webseald-<the external host>
x-wl-platform-version: 6.1.0.01.20140311-2356
x-requested-with: XMLHttpRequest
Cookie: LtpaToken2=<mytoken>; JSESSIONID=<mysessionid>; testcookie=oreo

skin=&skinLoaderChecksum=&isAjaxRequest=true&x=0.8017935899551958

I see something in the worklight documentation about this.. When new session is initiated the very first request to Worklight server will get a HTTP 401 response containing WL-Instance-Id token. Worklight framework will extract this token and use it as a header on all subsequent requests. In case this header is not present in a request to Worklight server, HTTP 401 will be returned and so on. This security mechanism makes sure that all subsequent requests are coming from the same source as an initial one. — scott dickerson

scott dickerson scott dickerson · Accepted Answer · 2015-06-29T21:44:50

There was a setting on the webseal junction that I had to set to get webseal to ignore the 401 and pass it through to the user. From the the worklight sso guide documented here..

http://www-01.ibm.com/support/docview.wss?uid=swg24034222

The HTTP Basic Authentication Header: Ignore (-b ignore) option is necessary to accommodate an additional device authentication handshake exchange between the Worklight client and server. IBM Security Access Manager handles the 401 error and return this to the client, which prevents further processing in the application. The use of HTTP Basic Authentication Header: Ignore resolves the 401 error processing.

The Include session cookie (-k) option causes WebSEAL to forward the user session cookie to the junctioned server. This allows the retrieval of the WebSEAL session cookie from the request headers which can be used to provide SSO to junctioned systems accessed within Worklight Adapters.

Worklight cannot login to application protected behind ltpatoken sso

1 Answers