ibm tivoli_在没有用户注册表的情况下使用Tivoli Access Manager for eBusiness WebSEAL

于 2020-06-25 02:02:22 发布
阅读量698 收藏
点赞数
文章标签： linux java 数据库 大数据 python
原文链接：https://www.ibm.com/developerworks/tivoli/library/t-tamwebsealur/index.html
版权

ibm tivoli

必备知识

本文假定您基本熟悉：

  • Tivoli Access Manager for eBusiness WebSEAL
  • WebSEAL外部认证接口（EAI）
  • Tivoli Federated Identity Manager运行时，包括安全性令牌服务
  • Servlet的J2EE和Java™编程

要实现和部署本文中描述的方案，您需要配置的TAMeB WebSEAL服务器和配置的Tivoli Federated Identity Manager运行时。

通过可预测的智能安全性来领先于内部威胁

通过可预测的智能安全性来领先于内部威胁

在本文中，我们讨论了通过可靠的基础控制，智能报告和管理工具的组合来识别和防御内部威胁的方法。 阅读白皮书以了解以下内容：

  • 内部威胁的演变
  • 应对内部威胁的智能安全系统。
  • 通过情报和大数据分析增强安全性的方法。

下载“ 通过可预测的智能安全性，领先于内部威胁 。”

解决方案概述

在不使用专用TAMeB用户注册表的情况下使用WebSEAL的解决方案体系结构利用了TAMeB外部认证接口（EAI）的特定功能。 EAI允许外部应用程序（即，在WebSEAL流程外部）执行用户认证（例如，通过将提供的用户名和密码与数据库进行比较），然后通过一组认证将已认证的用户和属性数据返回给WebSEAL。响应HTTP标头以实现登录。 然后，WebSEAL为用户构建和管理Web HTTP会话。 EAI应用程序可以使用两种不同的格式来返回经过身份验证的用户和属性数据：

  • 简单，单独的文本标题传达用户的简短TAMeB用户名和其他扩展属性。 在这种情况下，WebSEAL对具有给定用户名的用户记录执行用户注册表查找，然后从该用户名构建凭证（即扩展特权属性证书（EPAC）），并将其他扩展属性插入该凭证中。 使用此方法，用户必须是TAMeB用户注册表的一部分。
  • 编码的扩展特权属性证书（EPAC）。 在这种情况下，已编码的EPAC（TAMeB用户凭证的专有编码格式）将在单个HTTP标头中返回到WebSEAL。 当WebSEAL在EAI标头中接收到完全编码的EPAC时，它不咨询用户注册表-而是创建一个用户会话，并直接使用EAI提供的EPAC进行填充。 这是适用于本文主题的WebSEAL认证技术，因为它不需要用户进入目录。
用于凭证的TAMeB授权API

这实际上是WebSEAL从基于文本的用户名和属性EAI标头构建EPAC时使用的一组SAME API。 在我们的方案中，这些API没有帮助，因为它们仍要求用户存在于TAMeB用户注册表中。

接下来的问题是-如何建立一个EPAC？ TAMeB提供了一组公共API（Java和C），以允许客户构建和修改EPAC，但是这些API也需要咨询TAMeB配置的用户注册表。

幸运的是，还有另一种方法可以构建TAMeB EPAC， 而无需咨询TAMeB用户注册表。 此替代解决方案利用了Tivoli Federated Identity Manager（TFIM）安全令牌服务（STS）。

TFIM STS是一个Web服务，它支持WS-Trust 1.2和1.3规范，用于验证和交换安全性令牌。 本地而言，TFIM无需咨询TAMeB用户注册表即可构建TAMeB EPAC。 以下各节详细概述了如何开发解决方案，以使用TFIM的本机功能将用户认证为WebSEAL，而无需使用户进入TAMeB注册表。

该解决方案的总体架构如图1所示：

图1.解决方案架构
解决方案架构

工作流程如下：

  1. 最初未经认证的用户尝试访问受保护的资源，并被发送到WebSEAL登录页面。 登录页面将数据发布到EAI应用程序。
  2. EAI应用程序接收身份验证数据（可以只是用户名和密码），并根据现有的用户注册表对其进行验证。 此步骤的最终结果是EAI应用程序现在知道用户是谁，以及应用程序（甚至是WebSEAL）可能需要的任何其他属性数据（例如，组成员身份，个人属性）。
  3. EAI应用程序现在使用TFIM提供的API构造一个简单的用户令牌，称为STSUniversalUser。 可以通过编程方式将必需属性添加到此令牌。
  4. TFIM附带了一个STS客户端API（最初来自Higgins开源身份标识框架 ）来调用TFIM STS。 TFIM STS使用为此目的配置的信任链将STSUniversalUser交换为TAMeB凭据。
  5. EAI应用程序从TFIM STS接收IV-Cred令牌（EPAC），并将其转换为HTTP响应标头。
  6. WebSEAL基于EPAC创建用户会话，并将（现在已认证的）用户重定向到其所需的受保护资源（如步骤1所示）。
  7. WebSEAL识别用户已认证，执行必要的授权检查并授予对资源的访问权限。

联结应用程序的WebSEAL单一登录功能（使用基本身份验证，iv用户标题，基于表单的SSO等）的工作方式与将所有用户存储在TAMeB用户注册表中的方式相同。 但是，需要特别考虑WebSEAL授权，因为这种构建凭证的方法不会在使用访问控制列表（ACL）进行传统授权检查的凭证中提供信息。 两种主要方法都是可行的，并在本文后面进行讨论- 使用授权规则和使用实际的TAMeB组 。

本文的其余部分描述了实现和测试解决方案所必需的开发和配置。 开发和部署解决方案的起点是Tivoli Access Manager for eBusiness WebSEAL的配置安装以及Tivoli Federated Identity Manager运行时。 WebSphere®服务器应可用于运行EAI应用程序。 这可以与用于TFIM运行时的WebSphere服务器相同。

开发EAI应用程序

“可下载资源”部分包含一个示例EAI应用程序，您可以将其用作开发EAI的起点。 首先将EAR文件导入到Eclipse开发环境中，然后打开servlet类com.ibm.demo.EAIServlet。

清单1显示了此类的源代码：

清单1. EAIServlet 
package com.ibm.demo;

import java.io.IOException;
import java.net.URI;
import java.net.URISyntaxException;
import java.util.HashMap;
import java.util.Map;
import java.util.logging.Logger;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.ibm.tivoli.fim.sts.client.IRequestSecurityToken;
import com.ibm.tivoli.fim.sts.client.IRequestSecurityTokenResponse;
import com.ibm.tivoli.fim.sts.client.IStsClient;
import com.ibm.tivoli.fim.sts.client.StsClientFactory;
import com.ibm.tivoli.fim.sts.client.higgins.StsHigginsClientConstants;
import com.tivoli.am.fim.trustserver.sts.STSUniversalUser;
import com.tivoli.am.fim.trustserver.sts.uuser.Attribute;

/**
 * The EAIServlet class is an example template from which you can build your
 * own EAI that uses the TFIM STS to construct TAMeB credentials. It does not
 * perform authenticaiton (just uses a canned username), and its
 * sole purpose is to illustrate how to construct an STSUniversalUser and
 * exchange it at the TFIM STS for a TAMeB credential.
 *
 *
 */
public class EAIServlet extends HttpServlet {

  private static final long serialVersionUID = 1L;

  private static String CLASSNAME = EAIServlet.class.getName();

  private static Logger _log = Logger.getLogger(CLASSNAME);

  Map _stsConfig;

  String _issuer = null;

  String _applies_to = null;

  /**
   * An initialization method. The primary purpose of this method is to
   * establish some init parameters for the STS client. You can choose to do
   * this a completely different way - for example, from ServletConfig parameters.
   */
  public void init() throws ServletException {
    String methodName = "init";
    _log.entering(CLASSNAME, methodName);
    try {
      super.init();
      _stsConfig = new HashMap();

      // initialize from here, or from servlet config, however you like
      _stsConfig.put("sts.endpoint.url",
        "http://localhost:9080/TrustServer/SecurityTokenService");
      _stsConfig.put("enable.must.understand", "false");
      _applies_to = "http://appliesto/ivcred";
      _issuer = "http://issuer/stsuu";
    } finally {
      _log.exiting(CLASSNAME, methodName);
    }
  }

  /**
   * The main entry point into the EAIServlet. This method should read input
   * parameters and perform authentication (the example just uses a canned
   * username and skips authentication), then exchange the determined username
   * and attributes for a TAMeB credential using the TFIM Security Token
   * Service. The resulting TAMeB credential is returned in an EAI header to
   * authenticate to WebSEAL.
   */
  protected void doGet(HttpServletRequest req, HttpServletResponse rsp)
    throws ServletException, IOException {
    String methodName = "doGet";
    _log.entering(CLASSNAME, methodName);
    try {
      // authenticate the user however you want
      String authenticated_user = "shane";

      /*
       * Build an STSUU representing this user (with attributes if you
       * like, as shown)
       */
      STSUniversalUser stsuu = new STSUniversalUser();
      stsuu.setPrincipalName(authenticated_user);
      stsuu.addAttribute(new Attribute("position", null,
        new String[] { "senior software engineer" }));
      stsuu.addAttribute(new Attribute("usergroups", null, new String[] {
        "group1", "group3" }));

      // do a WS-Trust exchange of STSUU for IV-Cred
      String epac = doSTSExchange(stsuu);

      if (epac != null) {
        rsp.setHeader("am-fim-eai-pac", epac);

        // you may set the EAI redirection URL header if you like
        //rsp.setHeader("am-fim-eai-redir-url", "/cgi-bin/epac");
      } else {
        throw new ServletException("Unable to perform STS exchange");
      }
    } finally {
      _log.exiting(CLASSNAME, methodName);
    }
  }

  protected void doPost(HttpServletRequest req, HttpServletResponse rsp)
    throws ServletException, IOException {
    // don't care about request method - do same as "doGet()"
    doGet(req, rsp);
  }

  /**
   * This is the main demonstration function of the EAIServlet - exchanging an
   * STSUniversalUser for a TAMeB credential string, which can be used as an EAI
   * response header.
   */
  String doSTSExchange(STSUniversalUser stsuu) {
    String methodName = "doSTSExchange";
    String result = null;
    _log.entering(CLASSNAME, methodName);
    try {
      /*
       * Initialization - get the STS objects we need to use
       */
      StsHigginsClientConstants constants = new StsHigginsClientConstants();
      IStsClient client = StsClientFactory.getStsClientInstance(_stsConfig);
      IRequestSecurityToken req = StsClientFactory.getRequestSecurityTokenInstance();

      /*
       * Set all the request properties for the RequestSecurityToken
       */
      req.setAppliesToAddress(new URI(_applies_to));
      req.setIssuerAddress(new URI(_issuer));
      req.setRequestType(constants.getValidateRequestType());
      req.setSecurityToken(stsuu.toXML().getDocumentElement());

      /*
       * Send the request, and get a response.
       */
      IRequestSecurityTokenResponse rsp = client.sendRequest(req);

      /*
       * If we got a valid response, extract the TAMeB credential and remove
       * embedded newline characters.
       */
      if (rsp != null) {
        result = stripNewlines(rsp.getRequestedSecurityToken().getTextContent());
      }

    } catch (URISyntaxException ue) {
      // should not happen unless you use invalid applies-to or issuer URI's
      ue.printStackTrace();
      result = null;
    } finally {
      _log.exiting(CLASSNAME, methodName, result);
    }
    return result;
  }

  /**
   * The returned TAMeB credential token contains embedded newline characters -
   * this is used to remove them.
   */
  String stripNewlines(String credToken) {
    String result = credToken.replaceAll("\n", "");
    return result;
  }
}

请注意，在此示例中，不执行对用户数据的身份验证。 而是跳过该步骤，并假定已通过身份验证的用户“ shane ”。

Servlet有两个主要组成部分-初始化常量的init方法和处理请求的doGet方法。

init（）方法

您可能想要更改init方法中的代码，以从ServletConfig参数，配置文件等读取配置，只要配置与TFIM中的STS位置和信任链参数匹配即可。 注意，在本文中，STS终结点URL为http://localhost:9080/TrustServer/SecurityTokenService ，指示该Servlet与TFIM运行时安装在同一WebSphere服务器上。 该URL指向TFIM的WS-Trust 1.2端点。

doGet（）方法

此方法必须向企业用户存储进行身份验证。 在此示例中，假定用户为“ shane”，并且使用TFIM API构建了一个简单的STSUniversalUser令牌。 此STSUniversalUser包含用户名和两个示例扩展属性（ position和usergroups ）。 然后，在TFIM STS上将STSUniversalUser令牌交换为TAMeB凭据令牌。 从TFIM STS返回的TAMeB凭证令牌包含嵌入的换行符，然后在将EPAC转换为单个长字符串之前将其删除。 然后，此值作为EAI响应标头返回，该标头需要匹配标头名称的WebSEAL配置。 本文稍后将显示WebSEAL配置 。

凭证

清单1中的示例代码生成了具有非常简单属性的凭证。 WebSEAL epac演示应用程序可以用来显示凭证的内容，就像本developerWorks教程中的JSP一样 。 图2显示了用清单1中的servlet代码创建的凭证的epac演示应用程序屏幕截图：

图2.用户凭证
用户凭证

注意，在图2中 ， 位置和用户组属性将在本文后面引用。

EAI的TAMeB / WebSEAL配置

TAMeB / WebSEAL环境的配置包括：

  • 用于EAI认证的WebSEAL配置文件的配置
  • 创建与托管EAI应用程序的应用程序服务器的WebSEAL联结
  • 附加允许未经授权访问联结EAI应用程序的TAMeB ACL
  • 将授权约束应用于经过身份验证的用户访问的应用程序

用于EAI认证的WebSEAL配置

WebSEAL管理指南在此处包含有关EAI认证的详细技术信息。 本节总结了启用EAI身份验证的关键步骤。 这些更改包括对webseald-<instance>.conf文件的更新，更改摘要如清单2所示：

清单2.用于EAI认证的WebSEAL配置文件更改 
[eai]
# HTTPS recommended for EAI as sensitive authentication information
# typically posted in forms
eai-auth = https

# Header variables - note that these match those used by default for the TFIM runtime
eai-pac-header = am-fim-eai-pac
eai-pac-svc-header = am-eai-pac-svc
eai-user-id-header = am-fim-eai-user-id
eai-auth-level-header = am-eai-auth-level
eai-xattrs-header = am-eai-xattrs
eai-redir-url-header = am-fim-eai-redir-url

# Indicates that any login with a PAC completely replaces existing login credential
retain-eai-session = no


[eai-trigger-urls]
# The trigger URL for the EAI application. Note that /jct below should be replaced
# with your junction to the application server running the EAIServlet.
trigger = /jct/EAISTS/EAIServlet

[authentication-mechanisms]
# Change according to your particular platform - this example is for Linux.
ext-auth-interface = /opt/pdwebrte/lib/libeaiauthn.so

WebSEAL连接到EAI应用程序服务器

运行EAI servlet的WebSphere服务器的结点可能已经存在（例如，如果有TFIM运行时部署，并且这是您托管EAI servlet的位置），或者您可能需要手动创建它。 如果您需要手动创建它， 清单3使用pdadmin命令行实用程序显示了推荐的命令格式：

清单3. WebSEAL连接 
pdadmin> server task <server_name> create -t tcp -c all -h localhost -p 9080 /jct

EAI的TAMeB访问控制列表

在此示例中，必须授权EAI应用程序由未经身份验证的用户访问。 清单4中所示的访问控制列表（和附件）可以用作设置策略以允许未经身份验证的访问的示例：

清单4.允许未经身份验证的访问EAI应用程序 
pdadmin> acl create unauth
pdadmin> acl modify unauth set group iv-admin TcmdbsvaBRrxl
pdadmin> acl modify unauth set group webseal-servers Tgmdbsrxl
pdadmin> acl modify unauth set user sec_master TcmdbsvaBRrxl
pdadmin> acl modify unauth set any-other Trx
pdadmin> acl modify unauth set unauthenticated Trx

pdadmin> acl attach /WebSEAL/<server_root>/jct/EAISTS/EAIServlet unauth

授权策略模板

使用EAIServlet对用户进行身份验证后，可能需要针对特定​​应用程序强制执行条件授权要求。 在最简单的级别上，所有经过身份验证的人都可以访问所有应用程序，在这种情况下，只需要使用基本的default-webseal ACL即可。 但是，当需要更多选择性授权时，需要执行其他配置。

在具有所有企业用户的TAMeB用户注册表中的传统TAMeB部署中，最常用的授权策略模板形式是TAMeB ACL。 ACL条目依赖于TAMeB注册表中的用户和组 。 这些用户和组具有与之关联的通用唯一标识符（UUID），当从注册表构建凭据时，TAMeB身份验证API会知道这些标识符，而创建ACL时，授权数据库会知道这些标识符。 在运行时进行ACL授权检查时，会将用户凭据的用户和组UUID与ACL数据库中的用户和组进行比较。 在本文中构建的凭据类型中，没有关联的UUID。 因此，TAMeB ACL不是用于细粒度授权的适当形式的授权策略模板。

在这种类型的部署中使用的正确授权策略模板很有可能是TAMeB授权规则，它被编写为可扩展样式表模板（XSLT）。 在TAMeB管理文档中，可以找到有关TAMeB授权规则的更多信息。 清单5中是一个简单的示例规则，该规则将允许具有凭据属性“ position ”，值为“ 高级软件工程师 ”的任何人访问。 请注意，这与添加到清单1的EAIServlet中的示例用户凭证的属性匹配。

清单5.高级软件工程师的授权规则示例 
<xsl:choose>
  <xsl:when test="position = 'senior software engineer'">!TRUE!</xsl:when>
  <xsl:otherwise>!FALSE!</xsl:otherwise>
</xsl:choose>

要创建授权规则，请首先使用上述文本创建一个简单的文本文件（例如/tmp/myrule.txt ），然后使用清单6中所示的pdadmin命令作为指南。 所示命令假定WebSEAL连接到名为/appjct的目标应用程序：

清单6.创建和应用授权规则 
pdadmin> authzrule create myrule -rulefile /tmp/myrule.txt
pdadmin> authzrule attach /WebSEAL/<server_root>/appjct myrule

请注意，属性也可以是多值的，并且授权规则语句可以更复杂。 考虑图2中的凭据中的usergroups属性。 如果您需要允许用户在group1或group2的用户组中，则可以使用清单7中所示的授权规则：

清单7.组1或组2的示例授权规则 
<xsl:choose>
  <xsl:when test="usergroups = 'group1' or usergroups = 'group2'">!TRUE!</xsl:when>
  <xsl:otherwise>!FALSE!</xsl:otherwise>
</xsl:choose>

清单1中的示例代码也将满足此规则，因为用户在其多值列表中具有属性值group1 。 通过根据EAI Servlet的凭证中设置的属性集扩展这些示例，可以开发出任意复杂的授权规则。

IVCred模块和STS链的TFIM配置

此解决方案的TFIM配置包含两个主要组件：

  • 修改IVCred模块实例以构建TAMeB凭据，而无需与TAMeB授权服务器（以及TAMeB用户注册表）进行通信。
  • 创建TFIM STS链以将简单的STSUniversalUser XML令牌转换为TAMeB凭证。

以下小节将详细介绍每个步骤。

修改IVCred令牌模块实例

默认情况下，TFIM中的默认IVCred模块实例通过首先联系TAMeB授权服务器（也称为pdacld）来从用户名构建骨架凭据来颁发TAMeB凭据。 这包括TAMeB用户注册表中定义的该用户的组（及其UUID）。 若要将TFIM配置为不使用TAMeB授权服务器来构建TAMeB凭据，请使用TFIM控制台执行以下步骤：

导航到Tivoli Federated Identity Manger->配置信任服务->模块实例， 如图3所示：

图3. STS模块实例
STS模块实例

选中Default IVCred Token旁边的复选框，然后单击Properties ， 如图4所示：

图4.选择默认IVCred令牌
选择默认的IVCred令牌

取消选中文本Enable Access Manager（IVCred）证书发布（需要配置PDJRTE）旁边的复选框，然后单击OK ， 如图5所示：

图5. IVCred令牌属性
IVCred令牌属性

完成配置更改后，单击“将配置更改加载到TFIM运行时” 。

创建STS链

剩余的TFIM配置要求是创建一个STS链，该链将STSUniversalUser令牌转换为TAMeB凭据令牌。 在这种情况下，不需要身份映射步骤，因为所有必需的参数都是直接从EAIServlet准备的。 TFIM STS用于执行令牌转换。 创建所需的STS链所需的步骤如下：

导航到Tivoli Federated Identity Manger->配置信任服务->信任服务链，然后单击创建 。 信任服务链映射向导将出现， 如图6所示：

图6.信任服务链映射向导-步骤1
信任服务链映射向导-步骤1

选择Next，然后输入Chain Mapping名称和描述， 如图7所示：

图7.信任服务链映射向导-步骤2
信任服务链映射向导-步骤2

选择Next，然后输入Chain Mapping Lookup属性， 如图8所示：

图8.信任服务链映射向导-步骤3
信任服务链映射向导-步骤3

选择Next，然后输入Chain Identification属性， 如图9所示：

图9.信任服务链映射向导-步骤4
信任服务链映射向导-步骤4

选择下一步，然后用链装配面板添加在验证模式令牌默认STSUU，其次是默认IVCred令牌 发行模式下，如图中图10 ：

图10.信任服务链映射向导-步骤5
信任服务链映射向导-步骤5

单击下一步 ，然后单击继续以绕过有关建议的链结构的警告。 下一个面板将是STSUniversalUser令牌模块的配置属性（没有），因此，单击Next转到Access Manager凭据模块的配置属性， 如图11所示：

图11.信任服务链映射向导-步骤6
信任服务链映射向导-步骤6

这些可以保留为默认值，因此单击Next转到Chain Summary面板， 如图12所示：

图12.信任服务链映射向导-步骤7
信任服务链映射向导-步骤7

单击完成以保存链，然后单击将配置更改装入Tivoli Federated Identity Manager运行时 。 这样就完成了STS链的TFIM配置。

测试和调试解决方案

图1中描述的身份验证流程中包含几个组件，包括：

  • 用户/浏览器
  • 联络点（WebSEAL）
  • EAI申请
  • TFIM运行时应用程序

这些组件中的每一个都提供调试和跟踪机会，以确定问题所在。 本节介绍了一些在本文撰写过程中发现最有用的功能。

在浏览器上调试

浏览器本身或命令行浏览器实用程序（如cURL） （在大多数Linux®发行版中广泛使用）用于驱动EAI servlet的最终用户测试，通常是出现问题指示的第一位置。 例如，来自WebSEAL的403 Forbidden消息，指示您不允许未经身份验证的访问EAI servlet（有关配置未经身份验证的允许的ACL的详细信息，请参见清单4 ）。 其他错误也可能出现在源自信任服务器或EAI Servlet的浏览器中。 使用curl命令行浏览器来驱动简单的测试用例，可以检查HTTP响应代码和详细的响应文本，这非常有用。 一个示例调用可能类似于清单8所示：

清单8.使用curl调用EAIServlet 
[root@PestRHAS3 root]# curl -k -v https://10.1.1.111/FIM/EAISTS/EAIServlet
* About to connect() to 10.1.1.111:443
* Connected to test.ibm.com (10.1.1.111) port 443
* SSL connection using AES256-SHA
* Server certificate:
*        subject: /C=AU/CN=test.ibm.com
*        start date: 2007-08-27 02:01:11 GMT
*        expire date: 2013-04-05 02:01:11 GMT
*        common name: test.ibm.com (does not match '10.1.1.111')
*        issuer: /C=AU/CN=test.ibm.com
> GET /FIM/EAISTS/EAIServlet HTTP/1.1
User-Agent: curl/7.10.6 (i386-redhat-linux-gnu) libcurl/7.10.6 OpenSSL/0.9.7a ipv6
    zlib/1.1.4
Host: 10.1.1.111
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

< HTTP/1.1 200 OK
< content-length: 378
< content-type: text/html
< date: Tue, 30 Dec 2008 05:17:11 GMT
< p3p: CP="NON CUR OTPi OUR NOR UNI"
< server: WebSEAL/6.0.0.1 (Build 060314)
< pragma: no-cache
< cache-control: no-cache
< Set-Cookie: PD-S-SESSION-ID=2_ugwTEI+91H-eV+N3GFrYlvkOo1-YIHbc0qi-xe2ACQWD0GxW;
    Path=/; Secure
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<!-- Copyright (C) 2000 Tivoli Systems, Inc. -->
<!-- Copyright (C) 1999 IBM Corporation -->
<!-- Copyright (C) 1998 Dascom, Inc. -->
<!-- All Rights Reserved. -->
<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<TITLE>Success</TITLE>
</HEAD>
<BODY>
<P>Your login was successful.
</BODY>
</HTML>
* Connection #0 left intact
* Closing connection #0

在清单8中给出的特定示例中，请求成功，并且在响应中设置了WebSEAL cookie。 这表明已使用WebSEAL建立了会话（请注意，响应HTTP标头Set-Cookie具有PD-S-SESSION-ID值。

无论如何，很可能您的第一个错误指示将是浏览器中意外输出。 这对于确定问题的根本原因是有价值的信息。

在WebSEAL上进行调试

与WebSEAL相关的几个非常重要的组件对于开发和调试一种解决方案（如本文中介绍的解决方案）必不可少：

  • EPAC CGI应用程序是必不可少的。 成功进行身份验证后，用户可以观察用户凭证的内容，包括所有凭证属性。 除了指示登录成功之外，它对于开发应用程序授权策略的授权规则也很有用。 EPAC CGI应用程序要求在WebSEAL系统上安装PDAuthADK和PDWebADK软件包。 有关其安装和配置的更多详细信息，可以在演示应用程序随附的README中找到，位于<pdwebrte_install_root>/epac_demo/README 。 在等效于EPAC CGI的JSP上，还有一个很好的developerWorks教程。 它也可以用来检查用户的WebSEAL凭证的内容。
  • WebSEAL请求日志（通常位于/var/pdweb/www-default/log/request.log ）是检查浏览器请求是否到达WebSEAL的好资源。 在某些情况下，检查request.log是否有后续请求以检查经过身份验证的用户身份和响应代码可能很有用。 如果EAI servlet应用程序似乎没有接收到请求，则WebSEAL请求日志是一个不错的地方。
  • WebSEAL pdweb.snoop跟踪对于调试WebSEAL和EAI servlet之间的消息非常有用。 这可用于检查EAI Servlet是否将正确的EAI标头返回到WebSEAL。 要启用pdweb.snoop跟踪，请使用清单9所示的pdadmin命令：
    清单9.启用pdweb.snoop跟踪 
    pdadmin> server task <server_name> trace set pdweb.snoop.jct 9
file path=/tmp/pdweb.snoop

    将浏览器对EAI Servlet的请求运行一次后，停止并重新启动WebSEAL-这实际上将禁用跟踪并一次全部清除跟踪日志。 然后可以检查/tmp/pdweb.snoop文件，以检查WebSEAL和EAI Servlet之间的通信。

    如果在这些跟踪中看起来一切正确，请检查EAI的WebSEAL配置并触发URL（常见的错误区域）。

在EAI应用程序和Tivoli Federated Identity Manager运行时进行调试

EAI应用程序和TFIM都在WebSphere软件上运行，因此，可以使用WebSphere跟踪确定调试信息。 清单1显示了演示servlet使用标准的java.util.logging日志记录和跟踪基础结构。 TFIM运行时也使用相同的基础结构。 为了调试对TFIM信任服务器的调用，建议使用清单10中所示的跟踪配置字符串。

清单10. TFIM安全令牌服务的跟踪配置字符串 
*=info: com.tivoli.am.fim.trustserver.sts.modules.*=all

有关TFIM可维护性的更多信息，请参见TFIM在线文档 。

关于示例代码

可下载资源部分中提供的示例应用程序包含一个现成的EAR文件，它将在与TFIM 6.2运行时兼容的WebSphere服务器版本上运行。 该文件中嵌入了许多应用程序JAR和Java源文件。 Java源文件是示例代码-无需担保即可分发，可以自由使用，复制或修改。 嵌入式JAR可能已过时，需要更换，并且来自以下位置。

这组jar文件来自TFIM，并随<fim_install_root>/examples/mapping_extension_functions目录中的TFIM（从TFIM 6.2，修订包1开始） <fim_install_root>/examples/mapping_extension_functions ：

  • com.tivoli.am.fim.common_6.2.0.0.jar
  • com.tivoli.am.fim.sts_6.2.0.0.jar
  • itfim-locale-msgs.jar

这组jar文件是Higgins开源项目（及其依赖项）的一部分，并随TFIM从TFIM 6.2（修订包1）在<fim_install_root>/adks/client/sts目录中一起提供：

  • org.eclipse.higgins.configuration.api.jar
  • org.eclipse.higgins.sts.api.jar
  • org.eclipse.higgins.sts.binding.axis1x.client.jar
  • org.eclipse.higgins.sts.binding.axis1x.common.jar
  • org.eclipse.higgins.sts.binding.common.jar
  • org.eclipse.higgins.sts.client.jar
  • org.eclipse.higgins.sts.common.jar
  • axiom-api-1.2.2.jar
  • 公理-dom-1.2.2.jar
  • axiom-impl-1.2.2.jar
  • axis.jar
  • stax-api-1.0.1.jar
  • wstx-asl-3.0.0.jar

示例EAIServlet代码利用Higgins STS客户端联系TFIM安全令牌服务。 有关Higgins项目的更多信息，请参见此处 。

解决方案的变体

本文中描述的模型可以进行修改以适合各种情况。 本节介绍了已考虑的一些方案。

利用WebSphere安全性进行身份验证

作为一个示例，考虑一个现有的WebSphere注册表配置，该配置针对与Tivoli Access Manager for eBusiness不兼容的外部注册表对用户名和密码进行身份验证。 目标是为此用户建立一个WebSEAL会话。 如果TFIM运行时安装在此WebSphere服务器上，则可以修改信任链以使链中的第一个模块直接针对WebSphere注册表执行UsernameToken验证 （而不是上述的STSUU验证）。 EAI应用程序将提供的UsernameToken和用户名和密码（而不是STSUU令牌）发送给TFIM STS。 在这种情况下，身份验证也将由TFIM（实际上是WebSphere）间接执行。

编写用于身份验证的自定义STS模块

进一步采取这一步骤-如果使用的是自定义身份验证方法，并且您有多个需要对用户进行身份验证的联系点（例如，Web服务以及基于浏览器的访问权限），那么编写您自己的STS模块来验证TFIM STS中的身份验证数据，而不是将该功能编码到EAI应用程序中。 然后，多个身份验证点可以利用同一个SOA服务（TFIM STS）来验证该身份验证数据，而与访问通道无关。 提供了详细的STS模块开发教程 ，该教程描述了如何为TFIM编写和部署自己的STS模块。

使用TAMeB Web插件代替WebSEAL

要考虑的另一个变体是是否要使用TAMeB Web插件而不是WebSEAL。 此TAMeB组件还支持EAI认证，该解决方案应与WebSEAL一样适用。

使用TAMeB组和ACL进行授权

也可以使用混合目录解决方案，其中采用了TAMeB组，但并非所有用户都位于TAMeB目录中。 这允许使用（运行时快得多）TAMeB ACL策略模型而不是TAMeB授权规则来定义授权策略。 在非常高性能的环境中，这是可取的，但要以额外的目录同步和管理为代价。 基本前提是，将基于组条目创建TAMeB ACL并将其应用于受WebSEAL保护的对象。 TFIM运行时在EAI身份验证期间创建的TAMeB凭据必须包含相应的TAMeB组条目，以便ACL授权检查按其应有的成功或失败。 本节的其余部分演示如何使用EAIServlet应用程序和TFIM STS将TAMeB组添加到凭证中。

例如，假设您在外部目录中有多个组，这些组具有实际用户的成员身份。 您可以使用标准的TAMeB管理工具在TAMeB目录中创建相应的组（与组名称匹配），并具有使该组组与您的外部目录保持同步的过程。 请注意，这不是组成员身份，而只是组名称集。 每个TAMeB组都有其短名称（与真实目录中的名称匹配），以及一个关联的通用唯一标识符（UUID）和注册表可分辨名称（DN）。 创建组时设置的DN，但TAMeB透明地为您创建UUID。 首先，您需要知道您的组的UUID和DN。 清单11中的示例演示了如何确定该信息。 该示例显示了两种不同的LDAP搜索-第一种是针对TAMeB使用“最小” LDAP模式，第二种是针对TAMeB使用传统的传统LDAP模式，其中TAMeB组信息包含在以下内容中：实际组条目：

清单11.确定一个TAMeB组UUID 
#### EXAMPLE OF DETERMINING TAMeB GROUP UUID IF USING MINIMAL TAMeB LDAP SCHEMA #####

pdadmin sec_master> group show testgroup
Group ID: testgroup
LDAP DN: cn=testgroup,c=us
Description:
LDAP CN: test
Is SecGroup: Yes
pdadmin sec_master> quit

# ldapsearch -h localhost -p 389 -D cn=root -w passw0rd -b "secauthority=default" -s sub \
    "(&(objectclass=*)(secDN=cn=testgroup,c=us))"  secUUID
cn=testgroup,cn=Groups,secAuthority=Default
secuuid=35e2c214-d863-11dd-aeb2-000d6049840e




#### EXAMPLE OF DETERMINING TAMeB GROUP UUID IF USING LEGACY TAMeB LDAP SCHEMA ####

pdadmin sec_master> group show testgroup
Group ID: testgroup
LDAP DN: cn=testgroup,c=us
Description:
LDAP CN: test
Is SecGroup: Yes
pdadmin sec_master> quit

# ldapsearch -h localhost -p 389 -D cn=root -w passw0rd -b cn=testgroup,c=us -s one \
    "(objectclass=*)" secUUID
secAuthority=Default,cn=testgroup,c=us
secUUID=35e2c214-d863-11dd-aeb2-000d6049840e

现在，对于每个TAMeB组，您都有：

  • 组短名称（与您的外部目录中的组名称匹配）-例如， testgroup
  • 组DN-例如， cn = testgroup，c = us
  • 组UUID-例如35e2c214-d863-11dd-aeb2-000d6049840e

在身份验证期间，您可以从外部目录确定用户所属的组。 然后，您可以使用类似于清单12所示的代码来更新STSUniversalUser以包含该组信息：

清单12.将TAMeB组添加到STSUniversalUser 
...
import com.tivoli.am.fim.trustserver.sts.STSUniversalUser;
import com.tivoli.am.fim.trustserver.sts.uuser.Attribute;
import com.tivoli.am.fim.trustserver.sts.uuser.Group;
...

  /**
   * Adding a TAMeB group to the STSUniversalUser based on the short name, DN, and UUID
   */
  void addTAMGroup(STSUniversalUser stsuu, String groupShortName,
    String groupDN, String groupUUID) {
    final String TAM_TYPE = "urn:ibm:names:ITFIM:5.1:accessmanager";

    Attribute[] attrs = new Attribute[] {
     new Attribute("uuid", TAM_TYPE, new String[] { groupUUID }),
     new Attribute("registryid", TAM_TYPE, new String[] { groupDN }) };

    Group g = new Group(groupShortName, TAM_TYPE, attrs);

    stsuu.addGroup(g);
}

在我们的例子，加入testgroup在EAIServlet建设STSUU时完成，如图清单13：

清单13.将测试组添加到STSUniversalUser 
addTAMGroup(
        stsuu,
        "testgroup",
        "cn=testgroup,c=us",
        "35e2c214-d863-11dd-aeb2-000d6049840e");

最后，还有一个更重要的更新需要对TFIM运行时进行。 默认情况下，TAMeB凭证STS模块不允许动态添加组。 这是TAMeB凭据模块的历史属性，但可以通过配置进行更改。 要允许TAMeB凭据STS模块将组添加到该凭据，请使用TFIM控制台并导航到Domain Management-> Runtime Node Management，然后单击Runtime Custom Properties ， 如图13所示：

图13.设置运行时定制属性
设置运行时自定义属性

单击Create创建一个新属性，然后将新属性的名称更改为： ivcred.allow.groupUpdate ，其值为true ， 如图14所示（不要担心图中显示的其他属性的列表是否确实如此）。与您的配置不匹配）：

图14.设置ivcred.allow.groupUpdate
设置ivcred.allow.groupUpdate

现在，您可以使用servlet创建一个包含TAMeB组的TAMeB凭证， 如图15所示：

图15.具有动态添加组的TAMeB凭证
具有动态添加组的TAMeB凭据

一个TAMeB ACL现在可以用testgroup进入使用，并且该用户将被允许访问。 请注意，TAMeB授权运行时与UUID匹配以执行其实际的授权检查，因此UUID是从TFIM正确构建TAMeB组的关键要素。

其他重要考虑因素

每当您将EAI认证解决方案与WebSEAL结合使用时，而不是对本机TAMeB用户注册表的支持，都必须在EAI应用程序中为您自己手动设置各种功能。 如果身份验证方法实际上是用户名和密码，并且包括以下内容，则这些注意事项将很重要：

  • 密码更改和恢复
  • 密码策略，包括最小和最大长度，重用，强度和有效期
  • 用户帐户生命周期管理，包括供应，启用，禁用和删除用户帐户

任何利用EAI的解决方案（包括这样的解决方案，其中的用户实际上并不驻留在TAMeB用户注册表中）都必须考虑并实施辅助帐户和身份验证支持功能，例如此处所述。

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

ibm tivoli

cuyi7076
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值