Ibm mobilefirst Worklight无法登录到受ltpatoken sso保护的应用程序_Ibm Mobilefirst_Worklight Security

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

ibm-mobilefirst

Ibm mobilefirst Worklight无法登录到受ltpatoken sso保护的应用程序,ibm-mobilefirst,worklight-security,Ibm Mobilefirst,Worklight Security,尝试测试worklight LTPA sso配置时，我无法登录到我的应用程序。但是，我可以通过LTPA登录到受保护的worklight控制台（无需提示输入用户名/密码），因此我知道LTPA令牌得到了正确验证当我使用worklight控制台访问受保护的应用程序时，我从common/init和common/login调用中收到500个错误，因为worklight服务器正在向我提出验证问题这在worklight 6.1.0.2上。我已在此处附上worklight服务器响应的wireshark跟踪：

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

当我使用worklight控制台访问受保护的应用程序时，我从common/init和common/login调用中收到500个错误，因为worklight服务器正在向我提出验证问题

这在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>


/控制台*
com.worklight.core.auth.ext.WebSphereFormBasedAuthenticator
com.worklight.core.auth.ext.WebSphereLoginModule

如果需要，下面是发送到Worklight common/init的请求的wireshark（出于安全考虑，删除了我的LTPAToken）

POST/anywhere工作管理器/apps/services/api/WorkExecution/common/init HTTP/1.1
接受：text/javascript、text/html、application/xml、text/xml、*/*
接受语言：en US
连接：关闭
内容长度：65
内容类型：application/x-www-form-urlencoded；字符集=UTF-8
主持人:
推荐人：https:///AnywhereWorkManager/apps/services/preview/WorkExecution/common/0/default/index.html
用户代理：Mozilla/5.0（Windows NT 6.1；WOW64）AppleWebKit/537.36（KHTML，如Gecko）Chrome/43.0.2357.81 Safari/537.36
via:HTTP/1.1
x-wl-app-version:1.0
来源：https://
iv_服务器名称：reverseproxy webseald-
x-wl-平台-版本：6.1.0.01.20140311-2356
x-request-with:XMLHttpRequest
Cookie:LtpaToken2=；JSESSIONID=；testcookie=oreo
皮肤=&skinLoaderChecksum=&isAjaxRequest=true&x=0.8017935899551958

在webseal连接上有一个设置，我必须设置该设置才能使webseal连接忽略401并将其传递给用户。来自此处记录的worklight sso指南

HTTP基本身份验证头：Ignore（-b Ignore）选项是执行以下操作所必需的在设备之间进行附加的设备身份验证握手交换 Worklight客户端和服务器。IBM Security Access Manager处理401错误和将其返回给客户端，这将阻止应用程序中的进一步处理。使用 HTTP基本身份验证头：忽略解决401错误处理

包含会话cookie（-k）选项导致WebSEAL转发用户会话连接到连接服务器的cookie。这允许检索WebSEAL会话cookie 来自可用于向连接系统提供SSO的请求头

在Worklight Adapters中访问。

在webseal连接上有一个设置，我必须设置该设置才能使webseal连接忽略401并将其传递给用户。来自此处记录的worklight sso指南

包含会话cookie（-k）选项导致WebSEAL转发用户会话连接到连接服务器的cookie。这允许检索WebSEAL会话cookie 来自可用于向连接系统提供SSO的请求头

在Worklight Adapters中访问。

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

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