IBM Cognos BI 身份验证和单点登录（4）

look_w

持久保存会话中的身份验证信息在处理请求时，身份验证提供程序将使用所提供的登录数据，向附加到它的身份验证来源进行验证。如果验证成功，会话将被视为已经向 IBM Cognos BI        对所提供的用户身份进行验证，提供程序需要持久保存此状态。为此，身份验证提供程序为向其验证会话的命名空间发出一个签证 (visa)。
签证维护用户的安全上下文，也就是登录数据（为执行身份验证而传递给 IBM Cognos BI 的凭据或令牌）和用户的身份（用户所属的组和角色）。签证将用于得出用于其他请求身份验证的        IBM Cognos BI 服务的凭据，或者创建将存储在一个计划表中的受信任凭据。签证还将添加到一个由 CAM 管理的内存型表中，这个表持有所有有效的签证。
因为在一个会话中，用户可向多个命名空间进行验证，所以会话可以有多个签证，每个对应一个命名空间。会话的所有 visa 收集都在一个所谓的护照 (Passport)        中进行管理。在获取会话中的第一个签证后，将会创建此会话的护照，并为其分配一个随机生成的标识符        (PassportID)，该标识符用作护照的主键。只要会话注销或过期，就会立即销毁护照。
签证和护照仅保存在内存中，由 CAM 组件管理，绝不会发送给其他任何服务或组件。对 PassportID 的引用以及其他非敏感会话信息会经过签名和 base64        编码，然后，在一个名为 cam_passport 的 HTTP 会话 cookie 中传递给客户端。
通过使用 cam_passport cookie，会将对所有后续请求的身份验证信息保存在同一个客户端会话中。该 cookie 被发送到 CAM_AsyncAAService，供        DispatcherService 进行确认，如果成功，那么请求将被处理。其他任何结果都将触发重新验证。
通过配置，可以将 cookie 标记为安全，以便仅通过 SSL 加密连接发送它。此外，还可以配置 cookie 域和 cookie        路径。默认情况下，在没有设置显式的域或路径时，只会将 cookie 发给发出服务器和路径。自 IBM Cognos BI version 10.1.1.0 (IBM Cognos 10        Refresh Pack 1) 开始，cam_passport cookie 支持 HTTPOnly 标记，这将阻止它被脚本读取。
前面已经提到过，如果在一个可配置的时间段内没有发生护照确认来重置空闲计时器，那么会话将会超时。默认超时值为 3600 秒（60 分钟），会话过期时，护照将被删除，存储在        cam_passport cookie 中的引用将会失效。
身份验证流程IBM Cognos BI 客户端（比如浏览器）、基于 SDK 的应用程序（比如 BI Modeller）和其他集成了 IBM Cognos BI        安全性的产品，将发送调用特定服务的请求。之前在         节中已经介绍过，这些请求最终将到达一个 IBM Cognos Dispatcher Service。身份验证通常由该 Dispatcher Service        在收到任何请求时隐式触发。当它遇到一个未经验证的 IBM Cognos BI 会话时（由 cam_passport cookie        的缺失可以看出，对一个新会话的首次请求就属于这种情况），将会触发身份验证流程。会话已经过验证（由 cam_passport cookie 的存在可以看出）后，来自 cookie        的护照引用是通过调用身份验证流程来确认的。如果发现会话过期，则会再次触发完整的身份验证。只有与一个会话关联的护照仍然有效时，Dispatcher Service        才会继续处理请求，并最终将它分配给请求的服务的一个实例。
但是，在某些情况下，身份验证功能会由一个 IBM Cognos 服务显式调用。

• 访问配置来向一个外部命名空间（Cognos Namespace          以外的命名空间）执行身份验证的数据来源，或者访问配置为使用单点登录的数据来源，但由于授权或缺乏定义的原因而没有可用的单点登录机制。在这些情况下，身份验证将由执行报告的服务显式调用，但在大多数情况下，用户都不会注意到这一点，除非要求提示用户输入凭据。只要护照中还没有针对外部命名空间的签证，或者以前向外部命名空间的身份验证由          SSO 执行，但该 SSO 可能不需要适合数据库验证的凭据，只需要使用一些 SSO 令牌，就会出现这种情况。
• 通过 Cognos Connection 将计划表保存在一个已由 SSO 执行身份验证的会话中，就会得到一个非凭据的 SSO 令牌。SSO          令牌通常不包含密码，但根据身份验证提供程序，这可能使凭据不能被存储为受信任的凭据。在执行身份验证时，通过 Presentation Service          调用来收集一个凭据（通常为用户名和密码），该凭据通常足以存储为受信任的凭据。
• 用户可以单击 IBM Cognos Connection 中的 Log On 链接来启动对另一个命名空间的身份验证。
• IBM Cognos SDK 客户端或另一个 IBM Cognos BI 服务调用 Logon/LogonAs 方法。例如，计划功能将让一个称为 Monitor Service          的服务触发身份验证来建立一个会话，以便在后台代表特定用户执行某种操作。

无论对请求的验证被隐式调用还是显式调用，Dispatcher Service 实例都会将当前请求的一个副本推入一个堆栈，并在 CAM_AsyncAAService        接管操作时将请求转发给该 CAM 组件。身份验证流程完成后，正常情况下会从堆栈检索原始请求并处理请求。在 CAM 组件收到一个身份验证请求时，它首先会分析 SOAP 请求的          <bus:CAM> 部分中的 <action> 元素所指示的请求操作。此操作可能是          logon、logonAs 或 validate 之一。
validate 操作
与其他两个操作相比，validate 操作是一个轻型操作。简单来讲它就是对由一个给定护照引用所标识的现有护照进行确认。如果引用的护照仍然有效，CAM        将向调用方发出一个正面响应，然后，后者会继续执行处理。如果应用的护照过期或者不存在，则会返回一个负面结果，请求的发送方必须对这个结果进行处理，通常是调用身份验证流程。
logon 操作
此操作将调用整个登录流程，以便首先分析身份验证的一般配置。它是一个一般性操作，不需要满足任何前提条件，调用此操作也不需要任何具体信息。此方法用于支持匿名身份验证。
如果系统被配置为允许匿名访问，那么会话将变为使用预定义的匿名用户执行验证，因为 IBM Cognos BI        中没有真正的匿名会话。可以使用一个内部身份验证提供程序实现此功能，该功能既不可见，又不能配置。使用一些硬编码的虚拟用户凭据意味着不需要使用显式凭据。
匿名身份验证具有优先权，也就是说，即使至少有一个配置了指定身份验证的命名空间，也将针对登录操作对匿名用户进行身份验证。与此同时，如果在会话已被验证为匿名的后调用 logon        操作，身份验证流程将继续进行，就像在禁用了匿名访问时将对 logon 操作的处理一样。
如果禁用了匿名访问，身份验证流程会继续执行 logonAs 操作步骤，就像直接调用该操作一样。
logonAs 操作
一个发送给 CAM 的的将调用 logonAs 操作的请求，并会跳过 logon 操作所提供的前兆信息。这会排除匿名身份验证，而且需要专门对一个有效的命名空间执行身份验证。
CAM 的第一步是确定有多少有效的身份验证提供程序可用，从而确定有多少命名空间可用于身份验证。在 CAM 组件启动时，它会调用每个身份验证提供程序来初始化和创建一个活动实例。从        IBM Cognos 10 开始，这些实例在其自己的称为 CAMLPSrv 的物理进程中运行。对于身份验证提供程序的每个实例，将有一个        CAMLPSrv 进程。例如，在配置了三个命名空间但一个未能初始化的系统中，将有两个有效的身份验证提供程序实例和两个 CAMLPSrv 进程。
如果有多个有效的命名空间，但它们都未指定为用于身份验证，那么 CAM 将会抛出一个 UserRecoverable        异常来启动一次身份验证对话，它会请求客户端对该异常做出反应。预期的响应是重新发送原始响应，添加一个指示器来表明该命名空间用于身份验证。这通过指定要向其执行验证的命名空间的        NamespaceID（从命名空间配置中）来完成，进而隐式地确定要使用的身份验证提供程序。NamespaceID 可以在 SOAP 请求的          <bus:CAM> 结构的一个元素中指定，或者被用作一个名为 CAMNamespace 的 HTML          <form> 参数。对于重新发送的请求，CAM 操作必须切换为 logonAs，因为现在有一个指示器表明要将哪个命名空间用于身份验证。对于        HTML 客户端，比如浏览器，这通过嵌入在 Presentation Service        所生成的提示页面中的脚本代码来完成。对于其他任何类型的客户端，这必须编程方式来处理（通过在下一个请求的 SOAP          标头中设置相应的操作）。执行这一步是为了确保排除匿名身份验证流程。有关如何为不同的客户端处理命名空间选择的详细信息，请参阅场景一节。
如果只有一个可用的命名空间或已通过指定 NamespaceID        来显式选择了一个命名空间，那么请求会被传递到相应的身份验证提供程序。然后，提供程序会根据它的需求来处理身份验证请求。
下面介绍了通用的身份验证流。它适用于 IBM Cognos BI 提供的所有现成的身份验证提供程序（Cognos 提供程序），但 CA        SiteMinder 提供程序和 SharedSecret 提供程序除外，二者都是 TSP。之前在自定义 Java 身份验证提供程序 (CJAP)        一节中已经提到，TSP 不会实现身份验证模式，而是仅代管请求。
身份验证提供程序首先将会检查请求中是否有足够的登录数据来完成身份验证。根据提供程序所支持的登录数据类型，这将包括用于计划的受信任凭据或 SDK        客户端所发送的凭据。哪些类型的登录数据具有优先权取决于提供程序，但所有 Cognos 提供程序都会按以下顺序检查登录数据类型：

• 受信任的凭据
• SDK 凭据
• SSO 令牌
• HTML <form> 变量

在实现一个完整的身份验证提供程序的 CJAP 中，可能不支持某些类型的登录数据。因为 SDK API 不会强制编程人员支持所有类型的登录数据，所以需要与 CJAP        的作者进行核对。
在请求中包含受信任的凭据或 SDK 凭据时，尽管可能已经配置了 SSO，但 Cognos 提供程序可能不会认可 SSO。只有在每种凭据类型都不可用时，Cognos        提供程序才会检查其配置，以便查看是否已启用 SSO。
如果 SSO 已启用，提供程序将会返回一个 SystemRecoverable 异常，用它来启动 “身份验证之舞”，以便获取 SSO        令牌的受信任的值。需要多少次往返通信（SystemRecoverable 响应），才能提供足够的信息来尝试使用 SSO，这完全取决于提供程序。例如，LDAP 提供程序将仅使用一个        SystemRecoverable 异常来检索一个服务器变量，但 Microsoft Active Directory 提供程序将经历多次往返通信来交换 Kerberos        令牌。
在提供程序收到足够的数据后，它会继续尝试 SSO。SSO 的详细信息将在本文后面的单点登录到 IBM Cognos BI 一节中介绍。如果 SSO        成功，身份验证对话将会结束，并在一个响应中向客户端返回 cam_passport cookie 和成功状态。
如果未配置 SSO，Cognos 提供程序将会分析请求中是否存在 HTML <form>        变量，如果存在，则会尝试根据这些变量来执行验证。
如果基于可用登录数据的身份验证成功，那么提供程序将会发出一个签证，并将其传递给 CAM，后者将创建或更新会话的护照。对于 Presentation Service 转发请求的        HTML 客户端，CAM 还将发出或更新 cam_passport cookie。对于其他客户端，会在 SOAP 响应中返回护照引用。
如果没有任何登录数据可用，提供程序将使用一个 UserRecoverable        异常作为响应，表明登录数据缺失或无效。请求的发送方将会负责处理此异常，并被要求在附加了一种支持类型的登录数据后重新发送请求。
其他错误，比如与身份验证来源的连接问题和身份验证来源返回的错误，将在一个 Unrecoverable 异常中报告给请求的发送方。请求的发送方负责处理此异常。