首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

IBM Cognos BI 身份验证和单点登录(3)

IBM Cognos BI 身份验证和单点登录(3)

自定义 Java 身份验证提供程序 (Custom Java Authentication Provider,        CJAP)除了开箱即用地提供的身份验证提供程序之外,IBM Cognos BI 还提供了一个软件开发工具包 (SDK) 来使用 Java          编写自定义身份验证提供程序 (CJAP)。CJAP 实现了一个定义明确的 Java        接口,提供了读取和搜索来自身份验证来源的安全对象,基于各种凭据类型执行身份验证,可能还提供 SSO 支持功能。通过使用        SDK,可发挥出附加到几乎任何类型的身份验证来源和支持基于任何给定令牌的 SSO 的巨大潜力。
还有一种称为 Trusted Signon Provider (TSP) 的特殊类型的 CJAP。TSP 在本质上是一个轻型        CJAP,因为它仅实现一个特定的功能部分。TSP 充当着一个完整的身份验证提供程序之前的代理,用作一个受(IBM Cognos        BI)信任的相关方。它不能单独存在,因为它没有附加到任何身份验证来源,不会在运行时在 IBM Cognos Administration 中显示为命名空间。它仅基于 IBM        Cognos Configuration 出于连接目的而指定的配置设置,在内部定义一个命名空间对象。TSP 所做的工作就是使用一个发送到 IBM Cognos BI 的 HTTP        请求中的令牌来执行身份验证,应用必要的操作从该令牌推断用户身份,并在添加了一个可供辅助身份验证提供程序使用的额外令牌之后,将原始请求传递给这个辅助提供程序。它有效地将自定义令牌转换为受配置的服务提供程序支持的令牌。然后,辅助提供程序将处理该令牌,就像该令牌是从一个受信任方传递给它,跳过该提供程序中的初始验证步骤。它将直接前进到对传递的用户身份的确认步骤。
一个 TSP 示例是 IBM Cognos BI 以开箱即用方式提供的 Computer Associates (CA) SiteMinder 身份验证提供程序。SiteMinder        TSP 所做的工作是:使用名为 SMSESSION 的专用加密 SiteMinder cookie,采用 Computer Associates 所提供的 SiteMinder API        来解密该 cookie 的内容,然后从中推断用户身份。此用户身份(从技术上讲是一个字符串)首先放入标准的 HTTP 标头 REMOTE_USER        中,然后将请求传递到辅助身份验证提供程序。当然,这个辅助提供程序必须支持基于 REMOTE_USER HTTP 标头的 SSO。一些通过 IBM Cognos BI        提供开箱即用的验证功能的身份验证提供程序都满足此要求。SiteMinder Namespace 中没有用户,这些用户只能通过为此身份验证配置的辅助身份验证提供程序来进行访问。
身份验证对话尽管很容易想到一个发送用于身份验证的请求包含所有需要的登录数据(要验证的命名空间和该命名空间的有效凭据),但事实上并不是所有使用情形都是这样的。对于身份验证提供程序,发送给它的每个请求都被单独对待,但在某些情形下,身份验证流程不是一个单步操作。相反,身份验证流程可能需要多个步骤,这些步骤构成一次类似于关系数据库事务的逻辑对话。该对话包含在客户端、IBM        Cognos 入口点、CAM_AsyncAAService 和/或处理身份验证提供程序之间交换的多个请求和响应,要么成功,要么失败。
这个对话概念允许向身份验证请求的发送方返回限定的响应。这些响应要么要求提供继续执行身份验证的后续步骤所需的额外信息,要么告知所发生的阻碍身份验证流程继续进行的错误。响应向发送请求的客户端触发的具体操作,将依赖于客户端的类型和响应类型。这些对话概念已在自定义身份验证提供程序开发指南,第          2 章,身份验证请求:流场景 中提及的 3 个场景中介绍。
如果身份验证请求未包含立即完成身份验证所需的足够的登录数据,IBM Cognos BI          身份验证提供程序将使用一种回调机制,使身份验证提供程序能够向用户或系统请求额外的信息。身份验证提供程序返回一个所谓的异常,这类似于 Java        异常,因为调用方(在此情况下是身份验证请求的发送方)负责处理该异常。调用方负责解释异常并做出反应,要么发送另一个包含更多信息,使身份验证流程能继续进行的请求,要么告示用户可能发生的错误。
IBM Cognos BI 身份验证提供程序可返回 3 种类型的异常。这些异常出现在跟踪级日志中,是 Presentation Service 为基于 HTML        的客户端呈现的面向用户的对话框的基础。在以下对异常的描述中,在日志文件中找到的实际标签和错误代码被放在括号中。
  • UserRecoverable 异常 (camAuthUserRecoverable, error -36)
                告知发送方,最终用户/客户端需要提供数据,这些数据应附加到一个新请求中。返回给发送方的异常包含有关请求的数据的具体信息。对于基于 HTML          的客户端,这意味着发送方需要提供一个用户界面,提示用户缺少的信息,要求用户在添加新信息后重新发送请求。一个典型的例子是,采用 Presentation Service          呈现一个提示页面,使用一个 HTML 表单收集所需的数据。同样有效但不太容易看到的一个例子是,一个 Web          服务客户端将解析响应,呈现一个自定义身份验证页面,并在对异常的响应中提供输入的凭据。
  • SystemRecoverable 异常 (camAuthSystemRecoverable, error -37)
    告诉 IBM          Cognos          入口点,需要更多数据,它必须没有来自最终用户/客户端的进一步交互的情况下获取这些数据。这些异常用于实现          SSO。所有有效的 IBM Cognos 入口点组件都会处理这些异常,从本地(在 IBM Cognos          入口点上)环境中读取通用的服务器变量和受保护的标准变量,比如 REMOTE_USER(网关和 Dispatcher)和 USER_PRINCIPAL(仅限          Dispatcher)。附加到以 HTML 格式编码和签名的原始请求的额外数据(形成一个新请求),然后自动代表客户端发送回身份验证提供程序 -          实际的客户端并未参与,所以请求不会出现在任何客户端 HTTP 轨迹中。
  • Unrecoverable 异常 (camAuthUnRecoverable, error -38)
              表示一个无法通过任何进一步操作纠正的错误。实际上,这指示了提供程序的某个内部问题,致使身份验证无法完成,这个问题是:不得针对此身份验证发送更多请求。身份验证无法处理时,发送方将通知最终用户/客户端或记录一个故障。
总体上讲,这个流程表明在身份验证最终成功或失败之前,一次身份验证对话可能需要在身份验证提供程序与 IBM Cognos        入口点、客户端或最终用户之间执行多轮请求和响应。这种来回通信(还涉及到 CAM_AsyncAAService 和 CAM)也被称为身份验证之舞          (authentication dance)
登录数据上一节介绍了通过一个对话来收集足够的登录数据,以处理身份验证请求的概念。本节将介绍 IBM Cognos BI 提供的所有完整的身份验证提供程序接受的登录数据的实际类型。
发送给身份验证提供程序的请求中有 4 种可能的登录数据类型
  • 受信任凭据 (TC)
    这种类型的凭据由 IBM Cognos BI          身份验证提供程序在之前的一次经过验证的会话中为用户创建。在该会话中,用户要么显式要求保存他的凭据供离线使用,要么通过保存一个计划表 (schedule)          来隐式地触发身份验证程序这么做。这时,为了验证这个之前的会话而提供的凭据是加密的,并被作为针对该用户的受信任凭据对象的一部分而存储在内容库 Content Store)          中。每个用户只有一个受信任凭据对象,它可持有来自任何已定义的命名空间和 IBM Cognos BI 系统中的关联身份验证提供程序的 TC。
              例如,一个计划表将存储一个引用,这个引用被称为受信任凭据对象的凭据路径。从技术上讲,这些凭据可能是包含用户名和密码的二进制令牌或字符串。只有凭据路径在请求中传递 - TC          绝不会离开内容库。
    收到一组 TC          后,身份验证提供程序仅调用一个函数来隐式地验证它们的起源或一致性,这个函数封装了从内容库中检索实际凭据值并解密它的功能。为了实际验证这些凭据,提供程序对身份验证来源进行了身份验证。
              TC 可能过期或失效。例如,如果将密码存储在 Content Manager 中后,可能在身份验证来源中进行了更改,那么此时必须更新 TC。TC 的更新可由创建它们的用户在 IBM          Cognos Connection 中显式执行,或者从 IBM Cognos BI version 10.1          开始,它们可自动更新。更新过程将更新针对用户在实际会话中登录的所有命名空间的所有 TC。
  • 凭据
    凭据也被称为 SDK 凭据,由 IBM Cognos SDK 程序在向 IBM Cognos BI          执行身份验证时发送。从技术上讲,它们是字符串,很可能是用户名和可选的密码。凭据将在请求以明文形式传递,除非在 SDK 程序与 IBM Cognos BI Dispatcher          之间使用了安全套接字层 (SSL)。身份验证提供程序将通过尝试向身份验证来源进行验证,针对该来源对这些凭据进行检验。
  • HTML <form> 字段 - 用户名和密码
    如果运行基本身份验证而不是 SSO          或基于凭据的身份验证,那么系统会提示用户输入其用户名和密码。这意味着基本身份验证仅适用于基于交互式 HTML 的客户端。用户提供其凭据后,Presentation Service          生成的 HTML 页面会在两个预定义的 HTML <form> 字段中提供它们。这些凭据可在发送给 IBM Cognos BI          入口点的请求中看到(明文)。如果入口点是一个 IBM Cognos Gateway,那么在将请求传递给 CAM_AsyncAAService          之前,应该对密码参数进行加密。如果入口点是一个 IBM Cognos Dispatcher,则不会提供密码加密功能。在敏感的环境中,推荐对 HTTP 通道使用 SSL          加密,以减轻攻击者从线路上探取密码的风险。
  • SSO 令牌
    身份验证提供程序也可支持 SSO 令牌。这些令牌可能是简单的 HTTP 标头、CGI 环境变量、受保护的服务器变量或 cookie。从理论上讲,甚至          HTML <form> 元素或 HTML 请求的其他任何元素都可能是 SSO 令牌。稍后,我们会在单点登录到 IBM            Cognos BI 一节中介绍这些概念。
返回列表