ibm tivoli_Tivoli Access Manager信任关联拦截器（TAI ++）

最新推荐文章于 2020-06-28 05:02:22 发布

cuyi7076

最新推荐文章于 2020-06-28 05:02:22 发布

阅读量532

点赞数

原文链接：https://www.ibm.com/developerworks/tivoli/library/t-tamtai/index.html

版权

ibm tivoli

WebSphere Application Server（WAS）支持带有外围身份验证服务的单点登录（SSO），例如通过“信任关联”的反向代理。启用信任关联后，如果请求通过已执行身份验证的受信任源到达，则不需要WAS对用户进行身份验证。

外围身份验证服务有望：

与WAS建立“信任”
执行用户身份验证
将用户凭证信息插入HTTP请求

WAS中处理信任关联的模块是信任关联拦截器（TAI）。它是一个“可插拔”模块，其职责是：

使用外围身份验证服务验证信任
从请求中提取凭证信息

从WAS 3.5开始，就已经支持信任关联，但是只能将用户ID提供给WAS运行时。调用TAI后，需要进行进一步的用户注册表搜索以创建授权所需的各种凭据（即使此信息已包含在请求中）。 TAI接口已在WAS 5.1.1和WAS 6.0中进行了扩展，以支持返回完整的凭证信息。这意味着在TAI调用之后，不需要其他用户注册表搜索。请注意，如果WAS服务器加入集群或进行下游EJB调用，则必须在WAS中启用凭据传播。

WAS 5.1.1和WAS 6.0都随附了新TAI接口的Tivoli Access Manager（TAM）实现。配置步骤已更改，将在本文后面详细介绍。

使用场景

图1说明了使用新的Tivoli Access Manager信任关联拦截器时涉及的各种组件。为了简化图片，省略了WAS Web服务器“插件”。 TAM WebSEAL服务器可以替换为TAM Web插件安装。

图1. TAM信任关联流程

流程可以描述如下：

用户点击WebSEAL（可能通过其他代理）并被提示进行认证。
WebSEAL对用户进行认证，从用户注册表中获取用户的凭证，并可能授权该请求。
WebSEAL使用包含用户凭证的附加HTTP标头（iv-cred）来扩充请求。更改了基本身份验证标头中包含的密码，使其与配置的SSO用户匹配。该请求被发送到WAS。
WAS接收该请求，并调用TAI方法以确定该请求是否来自已对用户进行身份验证的外围身份验证服务。
WAS调用TAI方法与外围身份验证服务器建立信任关系并检索凭据。此方法通过检查BA标头包含已配置的SSO用户的正确密码来建立与WebSEAL的信任。与TAM授权服务器联系以做出此决定。 TAI与传输无关，并且以相同的方式处理HTTP和HTTPS请求。无法使用相互认证的SSL会话来建立WebSEAL和WAS之间的信任，而只能通过验证SSO密码来建立。 TAI不执行证书检查。然后，从请求中提取iv-creds标头，并将其用于构造PDPrincipal对象。包含用户和组信息的凭据对象是根据PDPrincipal中包含的信息构造的。将Principal和Credential对象插入到从调用返回的JAAS主题中。此时，WAS具有有效的凭证，可用于以通常的J2EE方式做出授权决策。此外，主题现在包含PDPrincipal对象，如果需要，应用程序代码可以访问该PDPrincipal对象。
如果对下游服务器上的EJB进行远程调用。凭据信息（最初是在TAI中提取的）被序列化并发送到下游服务器。另外，如果存在集群，则还可以使用WAS传播框架水平复制序列化的Subject。有关详细信息，请参阅信息中心。

这里要注意的重要点是：

WebSEAL需要将iv-creds标头插入请求中，而不是iv-user标头中
与以前的TAI不同，新的TAI不会直接与LDAP联系。相反，它与TAM授权服务器联系，该服务器验证SSO密码以建立与WebSEAL的信任。这意味着在WAS端需要进行其他配置，以确保TAI可以到达TAM授权服务器。
通过TAI插入到主题中的凭据对象意味着WAS不必在身份验证过程中执行任何其他用户注册表搜索。
如果在WAS 6.0中配置了TAM JACC提供程序，则可以使用TAI插入到Subject中的Principal对象进行授权决策。否则，本机WAS授权仍将起作用。

组态

配置新的TAM TAI（在WAS中名为com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus），包括TAM WebSEAL / Web插件和WAS的配置步骤。在WAS版本之间，TAM TAI属性略有不同。

TAM配置

需要在TAM中创建一个用户，该用户将成为TSE用作信任建立的一部分的WebSEAL可信用户或单一登录用户。

在TAM 5.1中使用pdadmin创建用户的示例是：

用户创建sso cn = sso，o = ibm，c = au sso sso ssopwd
用户修改ssouser帐户-有效是

WebSEAL配置

需要在WebSEAL实例和WebSphere Application Server之间创建一个联结，以确保在请求中传递iv-cred和HTTP Basic Authentication标头。基本认证标头应包含WebSEAL受信任用户（即，单点登录用户）的密码。基本身份验证标头中的用户名是偶然的，该值无关紧要。 TAI将使用WAS中配置的登录ID属性值作为用户，以使用基本身份验证标头中的密码进行身份验证。

在WebSEAL 5.1中创建联结的示例是：

服务器任务“ webseal_instance_name”创建-b供应-c iv-creds -t tcp -h“ websphere_hostname” -p“ websphere_app_port_number”“ junction_name”

-b供应选项确保WebSEAL服务器在请求中传递HTTP基本认证标头
-c iv-creds选项确保WebSEAL服务器在请求中传递iv-creds标头

TAM Web插件配置

配置用于Web服务器的插件时，请确保在请求中传递iv-creds和“基本身份验证”标头。此外，请确保基本身份验证标头包含单点登录用户的密码。

为Web服务器5.1配置TAM插件的示例是：

[通用模块]
认证= BA
会话=会话cookie
授权后= BA
验证后= iv标头

[iv标题]
接受=全部
产生= iv-creds

[BA]
strip-hdr =始终
add-hdr =供应
供应密码=“ sso_user_password”

WAS配置

TAI必须使用TAM验证在iv-creds标头中传递的凭证信息。因此，必须确保已经配置了Tivoli Access Manager Java运行时环境，并且已经执行了服务器SSL配置。如果要在ND中的多个WAS服务器之间进行配置，则需要在服务器SSL配置期间生成的属性文件在所有服务器上的同一位置。如果使用$ {WAS_INSTALL_ROOT}变量，则该位置仅需要相对于WebSphere安装目录相同。

如果尚未配置用于WAS 5.11的AMWAS或用于WAS 6.0的AM JACC提供程序。
1. 配置AMJrte。
  
  配置AMJrte 5.1的示例是：
  
  java -Djava.ext.dirs -Dpd.home =“％WAS_HOME％\ java \ jre \ PolicyDirector” com.tivoli.pd.jcfg.PDJrteCfg -action config -was -host“ policy_server_host”
2. 运行服务器SSL配置
  
  使用AMJrte 5.1运行服务器SSL配置的示例是：
  
  java com.tivoli.pd.jcfg.SvrSslCfg -action config -admin_id“ TAM_admin_user” -admin_id_pwd“ TAM_admin_user_password” -appsvr_id“ app_server_name”-端口“ app_server_port” -mode remote -policysvr“ host：port：rank” port：rank“ -cfg_file” cfg_prop_file_to_create“ -key_file” cert_and_key_file_to_create“

需要使用WebSphere Application Server管理控制台来完成以下步骤。请注意，屏幕截图仅表示WAS 6.0。

确保LTPA是主动身份验证机制。
1. 打开安全标签
2. 选择“全局安全性”链接
3. 确保将主动身份验证机制设置为轻量级第三方身份验证（LTPA）
  1. 如果不是LTPA
    1. 在下拉框中选择LTPA
    2. 点击申请
    3. 保存更改
启用信任关联
1. 打开安全标签
2. 打开身份验证机制选项卡
3. 选择LTPA链接
4. 在LTPA配置中，选择“信任关联”链接
  
  图2.选择信任关联
5. 设置启用信任关联中的复选框
  1. 点击申请
  2. 保存更改

创建WebSEAL信任关联拦截器属性
1. 打开安全标签
2. 打开身份验证机制选项卡
3. 选择LTPA链接
4. 在LTPA配置中，选择“信任关联”链接
5. 选择拦截器链接
6. 选择com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus链接。请注意，新的TAI和旧的TAI com.ibm.ws.security.web.WebSealTrustAssociationInterceptor均可用于配置。有关旧TAI的信息，请参阅信息中心。
  
  图3.选择拦截器链接
7. 选择自定义属性链接
8. 单击新按钮以创建新的自定义属性
9. 创建配置属性，确保在属性之间按下Apply
10. 保存更改
11. 停止并重新启动WebSphere以激活更改

WAS 5.1.1仅属性

com.ibm.websphere.security.webseal.mutualSSL（是/否）
可以配置TAI，以便已经使用相互认证的SSL连接来验证对反向代理的信任。如果将相互SSL属性设置为true，那么将不对Single Sign-on用户执行来自WebSEAL的入站请求验证。因此，如果双向SSL为true，则登录ID属性和“单点登录密码到期”属性不起作用。相互SSL属性的默认值为false。 WAS 6.0不支持此属性，因为许多客户误以为TAI正在对WebSEAL提交的证书进行验证。尽管在传输级别确保通信的安全仍然很重要，但仅此一点不应构成WebSEAL与TAI之间信任的基础。

WAS 6.0 Only属性

com.ibm.websphere.security.webseal.checkViaHeader（是/否）
可以配置TAI，以便在验证请求的信任时可以忽略via头。如果将检查通过标头属性设置为false，则不需要信任通过标头中的所有主机。这也意味着不需要在WebSphere中设置受信任的主机名和主机端口属性。因此，当通过标头检查为false时，唯一的强制性属性是
- com.ibm.websphere.security.webseal.loginId
Check via标头属性的默认值为false。

通用配置属性

com.ibm.websphere.security.webseal.loginId（字符串）
需要使用WebSEAL受信任用户的用户名配置TAI。这是单点登录用户，将使用WebSEAL在请求中插入的基本身份验证标头中的密码进行身份验证。用户名的格式是简称。
这是强制性属性。如果未在WAS中设置，则TAI初始化将失败。
com.ibm.websphere.security.webseal.id（用逗号分隔的字符串列表）
可以配置TAI以确保请求中存在指定的标头。如果请求中并非所有已配置的标头都存在，则无法建立信任。

是5.11
这是WAS 511中的必需属性，没有默认值。如果未设置此属性，则TAI初始化将失败。

WAS 6.0
id属性的默认值为iv-creds。 WebSphere中设置的任何其他值都与iv-creds一起添加到列表中。
com.ibm.websphere.security.webseal.hostnames（以逗号分隔的字符串列表）
需要在此属性中列出所有受信任的主机。如果此属性中未列出主机，则可能不信任通过该主机到达的请求。这取决于通Kong深度的值和忽略代理属性。

原为5.1.1
如果未在WAS中设置hostnames属性，则假定所有请求均来自受信任的主机。

WAS 6.0
如果未设置checkViaHeader属性或将其设置为false，则可信主机名属性将不起作用。
如果将checkViaHeader属性设置为true，并且未在WAS中设置受信任的主机名属性，则TAI初始化将失败。
com.ibm.websphere.security.webseal.ports（用逗号分隔的整数列表）
任何受信任的主机都需要在此属性中列出其端口。如果此属性中未列出端口，则来自该端口的请求可能不会被信任。这取决于通Kong深度的值和忽略代理属性。

WAS 6.0
如果未设置checkViaHeader属性或将其设置为false，则受信任的主机端口属性将不起作用。
如果将checkViaHeader属性设置为true，并且未在WebSphere中设置受信任的主机端口属性，则TAI初始化将失败。
com.ibm.websphere.security.webseal.viaDepth（正整数）
可以将TAI配置为仅检查via头中指定数量的源主机，以确保这些主机是受信任的源。默认情况下，将检查via头中的每个主机是否信任，如果不信任任何主机，则无法建立信任。如果不是所有要求通过标头的主机都必须信任，那么可以设置“通过深度”属性来指示需要信任的主机数。

例

通过：HTTP / 1.1 webseal1：7002，1.1 webseal2：7001

如果未设置过Kong深度属性，将其设置为2或设置为0，并且接收到具有上述过Kong标头的请求，则必须同时信任webseal1：7002和webseal2：7001。
- com.ibm.websphere.security.webseal.hostnames = webseal1，webseal2
- com.ibm.websphere.security.webseal.ports = 7002,7001
如果过Kong深度属性设置为1并且收到了上述请求，则仅需要信任过Kong头中的最后一个主机。
- com.ibm.websphere.security.webseal.hostnames = webseal2
- com.ibm.websphere.security.webseal.ports = 7001
如果过Kong深度属性设置为0，则将检查过Kong标头中的所有主机是否信任。
如果过Kong深度属性设置为负值，而检查过Kong标头属性设置为true，则TAI初始化将失败。
过Kong深度属性的默认值为0。
com.ibm.websphere.security.webseal.ssoPwdExpiry（正整数）
一旦建立了对请求的信任，就将缓存单点登录用户的密码，以供随后的请求信任验证。这样可以节省TAI，而不必为每个请求都使用Tivoli Access Manager重新认证单点登录用户，从而提高了性能。可以通过将“单点登录密码到期”属性设置为所需的时间（以秒为单位）来修改缓存超时时间。如果密码到期属性设置为0，则缓存的密码将永不过期。
如果密码到期设置为负值，则TAI初始化将失败。
密码到期属性的默认值为600。
com.ibm.websphere.security.webseal.ignoreProxy（是/否）
可以对TAI进行配置，以使Via头中作为代理的任何主机都不必成为受信任的主机。通过检查via标题中主机条目的注释字段来查看该主机是否是代理，它可以工作。这不是一种故障安全方法，因为并非所有代理都在via头中插入注释以指示它们是代理。
忽略代理属性的默认值为false。

WAS 6.0
如果将检查通过标头属性设置为false，则忽略代理属性对建立信任没有影响。
com.ibm.websphere.security.webseal.configURL（URL）
为了使TAI能够建立对请求的信任，它需要为WebSphere Java虚拟机运行SvrSslCfg，从而创建属性文件。 TAI使用此属性文件来创建上下文，以便TAM可以验证SSO密码。
如果要在ND中的多个WAS服务器之间进行配置，则需要在服务器SSL配置期间生成的属性文件在所有服务器上的同一位置。如果使用$ {WAS_INSTALL_ROOT}变量，则该位置仅需要相对于WebSphere安装目录相同。

例

com.ibm.websphere.security.webseal.configURL = $ {WAS_INSTALL_ROOT} /java/jre/PdPerm.properties

在ND环境中使用上述属性，服务器SSL配置期间生成的属性文件必须位于所有服务器上相对于WebSphere安装目录的java \ jre位置。

原为5.1.1
这是WAS 5.1.1中的必填属性，没有默认值。如果未设置此属性，则TAI初始化将失败。

WAS 6.0
如果此属性文件不在默认URL 文件中，则为：//：//java.home/PdPerm.properties
- 其中java.home是WebSphere Java虚拟机的完全限定位置
那么必须在config URL属性中设置属性文件的正确url。如果未设置此属性，并且SvrSslCfg生成的属性文件不在默认位置，则TAI初始化将失败。
配置URL属性的默认值为file：//java.home/PdPerm.properties

故障排除

开启跟踪

通过查看WAS生成的跟踪，可以诊断出TAI的大多数问题。要打开TAI跟踪，请确保在WebSphere诊断跟踪服务中设置了以下内容

com.ibm.ws.security。* = all =已启用

故障排除检查

如果对有效用户的身份验证失败，则：

确保TAI初始化成功。通过检查TAMTrustAssociationInterceptorPlus初始化是否没有错误并将其添加到拦截器列表中，可以在跟踪中对此进行验证。如果初始化失败，则检查所有必需属性是否存在。特别要确保SvrSslCfg生成的属性文件存在并且config URL属性具有正确的值。
确保已安装和配置Tivoli Access Manager Java运行时环境（AMJrte），并且已执行SvrSslCfg配置操作。
请求源是否涉及Web服务器插件。确保未设置WebSphere的check via标头属性或将其设置为false，或者未为WebSphere 5.1.1设置可信的主机名和端口属性。无法保证Web服务器插件将哪些主机信息（如果有）放入VIA头中，因此应忽略via头。
如果请求源中仅包含WebSEAL主机。确保在各自的属性中正确设置了所有受信任的WebSEAL主机名和端口。
确保受信任的主机名格式正确。可能需要标准主机名，而不是简称。可以通过在跟踪中查看Http标头名称和VIA标头的值来进行检查。如果不确定，则可以将标准主机名和短主机名都添加到受信任主机名属性。
确保有关WebSEAL实例的相关webseald.conf文件中的虚拟密码或在“ Web服务器插件”中配置的供应密码是登录ID属性中指定的用户的正确密码。
确保在登录ID属性中指定的用户具有有效的帐户。
确保提供了正确的标题。 WebSphere应该获得iv-creds和Basic Authentication标头。可以通过查看跟踪中的Http标头名称和值来进行检查。
如果对配置进行了任何更改，请确保WebSphere已重新启动。
确保未将单点登录用户的缓存密码设置为永不过期，并且单点登录用户密码已更改。 WebSphere可能需要重新启动。

性能问题

缓存单点登录用户密码是影响性能的唯一可用方法。确保将缓存超时属性设置为一个值，该值将减少TAI执行的用户注册表身份验证的数量。默认的缓存超时为600秒。

安全问题

TAM信任关联拦截器是一种非常强大的SSO机制，因此必须小心确保每个安装的安全性。
如果攻击者发现了SSO密码，则可以模拟任何用户。为了防止发现此密码，应采取以下预防措施：

确保WebSEAL，IHS和WAS之间的所有流量都通过SSL。这将有助于确保没有人窃听请求。
使用某种形式的传输级别过滤，以便拒绝来自非WebSEAL主机的HTTP / S连接。如果发现密码，这将有助于防止对WebSEAL SSO请求的欺骗。

还值得注意的是，虽然TAI可以验证请求中的标头，但是请理解，如果您不控制对Web服务器和WAS的访问，则标头很容易被攻击者伪造。 TAI安全性的关键是SSO密码的验证。因此，应用程序应仅检查PDPrincipal对象（可以信任），并且应避免直接访问WebSEAL提供的HTTP标头，如果攻击者能够绕过WebSEAL并直接连接到WAS，则这些HTTP标头可能是伪造的。

WebSEAL和WAS认证会话（不同于HTTP会话）不同步。如果启用LTPA SSO，这可能会成为问题。在这种情况下，LTPA cookie将用于在初始TAI调用之后确定用户的会话信息。这意味着可能出现以下情况：

用户A登录到WebSEAL，TAI将其登录到WAS
WAS向浏览器返回LTPA cookie
用户A注销WebSEAL
用户B登录到WebSEAL，并且LTPA cookie错误地将它们作为用户A登录到WAS

可以通过关闭LTPA SSO或将一些Javascript嵌入到清空和过期所有后端认证cookie的WebSEAL注销页面和登录页面中来防止此情况。关闭LTPA SSO的不利之处在于，将为可能对性能产生负面影响的每个请求调用TAI。

翻译自: https://www.ibm.com/developerworks/tivoli/library/t-tamtai/index.html