Worklight 无法登录到受 ltpatoken sso 保护的应用程序

Posted 2023-02-25

【中文标题】Worklight 无法登录到受 ltpatoken sso 保护的应用程序

【英文标题】：Worklight cannot login to application protected behind ltpatoken sso

【发布时间】：2015-06-05 21:38:40

【问题描述】：

在尝试测试我的 worklight LTPA sso 配置时，我无法登录到我的应用程序。但是，我可以通过 LTPA 登录到受保护的工作灯控制台（无需提示输入用户名/密码），因此我知道 LTPA 令牌得到了正确验证。

当我使用 Worklight 控制台访问受保护的应用程序时，我从 common/init 和 common/login 调用中收到 500 个错误，因为 Worklight 服务器要求我进行身份验证。

这是在工作灯 6.1.0.2 上。我已在此处附加了 worklight 服务器响应的 wireshark 跟踪：

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"*/

这是我的 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>

如果您需要，这里是发送到 Worklight common/init 的请求的 Wireshark（为安全起见删除了我的 LTPAToken）

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

【问题讨论】：

我在 Worklight 文档中看到了一些关于此的内容。当启动新会话时，对 Worklight 服务器的第一个请求将获得包含 WL-Instance-Id 令牌的 HTTP 401 响应。 Worklight 框架将提取此令牌并将其用作所有后续请求的标头。如果对 Worklight 服务器的请求中不存在此标头，则将返回 HTTP 401，依此类推。这种安全机制确保所有后续请求都来自与初始请求相同的来源。

【参考方案1】：

我必须设置 webseal 联结点上的设置才能让 webseal 访问 忽略 401 并将其传递给用户。来自此处记录的 worklight sso 指南..

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

HTTP Basic Authentication Header: Ignore（-b 忽略）选项是必要的 容纳一个额外的设备认证握手交换之间 Worklight 客户端和服务器。 IBM Security Access Manager 处理 401 错误和 将此返回给客户端，这会阻止应用程序中的进一步处理。指某东西的用途 HTTP Basic Authentication Header：忽略解决401错误处理。

包含会话 cookie (-k) 选项使 WebSEAL 转发用户会话 cookie 到联结的服务器。这允许检索 WebSEAL 会话 cookie 来自可用于向联结系统提供 SSO 的请求标头 在 Worklight 适配器中访问。