IBM Cognos 最佳实践: 基于平面文件向 IBM Cognos 8 验证身份
简介目的IBM Cognos 8 本身并不验证用户的身份，而是依靠 LDAP 或 Microsoft Active Directory 等第三方身份验证源执行身份验证。这意味着 IBM Cognos 8 会把用户输入的或通过单点登录 (SSO) 机制获得的登录数据（本质上是凭证）交给第三方身份验证源。完成身份验证之后，IBM Co...显示全部简介
目的
IBM Cognos 8 本身并不验证用户的身份，而是依靠 LDAP 或 Microsoft Active Directory 等第三方身份验证源执行身份验证。这意味着 IBM Cognos 8 会把用户输入的或通过单点登录 (SSO) 机制获得的登录数据（本质上是凭证）交给第三方身份验证源。完成身份验证之后，IBM Cognos 8 还需要从身份验证源读取用户的组和角色，让授权功能可以使用这些信息。这个任务由身份验证提供者实现。
因此，要想为 IBM Cognos 环境配置任何类型的安全性，就必须配置安全性提供者。尽管 IBM Cognos 8 提供几个重要的提供者，但是根据软件的可用性和个人技能水平不同，配置它们可能有难度。因此，需要一个轻量的 Custom Java Authentication Provider (CJAP)，它应该容易配置和掌握，而且不需要任何其他软件。
本文档的目的是描述一个基于简单文本文件的 Custom Java Authentication Provider。可以使用这个提供者执行简单的测试安装，因为它不需要数据库或外部源等任何其他软件。另外，可以使用它演示用户供应支持，因为可以使用 Tivoli Identity Manager 等其他软件创建并管理包含用户、组和角色的文本文件。
适用性
本文档中描述的技术和行为已经在 IBM Cognos 8.4（包含 Refresh Pack 1）上测试过。这个 CJAP 使用 IBM JRE version 1.5。
这个提供者当前没有实现可信凭证，因此不支持调度。
功能范围
这个定制提供者的功能如下：
独立于平台的轻量的定制提供者，因为它只使用平面文件。在定制的名称空间只由一个组织/组/租用者共享的情况下，用基本的定制安全性提供者实现用户供应和单点登录。（参见在定制的名称空间只由一个组织/组/租用者共享的情况下配置基本的提供者）在定制的名称空间由多个组织/组/租用者共享的情况下，用复杂的定制安全性提供者实现用户供应和单点登录。（参见
在定制的名称空间由多个组织/组/租用者共享的情况下配置复杂的提供者）通过可信单点登录机制集成 IBM Cognos 8 和自己的安全基础设施。（参见
通过配置定制的可信登录提供者在安全基础设施中集成 IBM Cognos 8 组件）可以使用相同的
customprovider.jar
文件配置所有提供者示例。
了解 IBM Cognos 8 安全模型
身份验证请求的处理流程
图 1. IBM Cognos 8 中身份验证请求的处理流程
当用户请求对 IBM Cognos 8 进行需要身份验证的访问时，处理流程如下（见上面的图 1）：
用户单击一个报告或分析以查看它，请求经过 Gateway 和 Dispatcher 发往表示服务。Gateway 接收请求并把它发送给 Dispatcher。Dispatcher 注意到请求中没有 passport 并把请求发送给 Content Manager。Content Manager 把请求发送给 Access Manager。IBM Cognos 8 系统中禁止匿名访问，所以 Access Manager 把请求发送回 Content Manager 并附带一个错误。这个错误包含的信息说明登录需要什么。例如，如果存在多个名称空间，就要求用户选择一个名称空间。如果只有一个名称空间，可能要求用户提供用户 ID 和密码。Content Manager 把请求和附带的错误返回给 Dispatcher。Dispatcher 把请求发送给表示服务。表示服务为用户创建适当的登录页面，并通过 Dispatcher 和 Gateway 把页面返回给用户。用户输入必需的信息，比如用户 ID 和密码。把信息附加到原来的请求中并通过 Gateway 发送给 Dispatcher。Dispatcher 把请求发送给 Content Manager。Content Manager 把请求发送给 Access Manager。Access Manager 通过身份验证服务与身份验证提供者通信以检验提供的凭证。如果所需的所有信息都是正确的，Access Manager 会颁发一个 Passport ID，把它附加到原请求的 HTTP 头中，再把请求发送回 Content Manager。如果所需的信息不正确或不完整，请求处理失败，返回到第 9 步。Content Manager 把请求发送给 Dispatcher。Dispatcher 处理请求并把它发送给表示服务。表示服务通过 Dispatcher 和 Gateway 把欢迎页面发送给用户。授权和 CAMID
当用户通过身份验证时，颁发
passport，这个对象包含
visa。对于每个名称空间，在成功完成身份验证之后，身份验证提供者都会颁发一个 visa。在这种情况下，passport 包含多个 visa。Passport ID 是 passport 对象的引用，由 Content Manager 组件在内存中维护 passport 对象。Passport ID 被放在
cam_passport
cookie 中，使用这个 cookie 检查用户在当前会话中是否已经成功地通过了身份验证。现在，确定用户的身份，确认对 IBM Cognos Portal 内容的访问权。
IBM Cognos 8 通过继承（嵌套的组成员关系）表明用户（直接或间接）所属的组和角色。对于已经为其颁发了 Passport ID 的名称空间中的组和角色，以及 IBM Cognos 名称空间中的组和角色，都采用这种方法。
在 IBM Cognos 8 中，授权基本上应用于组成 IBM Cognos 8 应用程序的所有对象。所有内容（报告、分析、文件夹、包等等）以及许多函数和系统功能都可以有相关联的权限（例如对 Studios 的访问权）。权限指定谁（用户、组或角色）对于某个对象/功能/函数有哪些特权。
IBM Cognos 中的五个特权级别是：
READWRITEEXECUTETRAVERSESET POLICY在内部，这些特权级别并不包含用户、组或角色的名称，而是包含称为 CAMID 的内部 ID。对于从外部身份验证提供者读取的每个对象，由身份验证提供者构造 CAMID。这也适用于内部身份验证提供者，所以 IBM Cognos 名称空间的所有对象都有分配给它们的 CAMID。IBM Cognos 8 使用 CAMID 存储对对象的访问权，当需要授权时使用它们检查访问权。对用户身份中的对象的 CAMID 和分配给对象的权限进行比较，然后相应地授予或拒绝特权。尽管不同的身份验证提供者以不同的方式构造 CAMID，但是它们都使用一致的布局。CAMID 是一个字符串，由两个相连的字段组成：
CAMID:="CAMID(
NamespaceID 是在 IBM Cognos 配置中为名称空间指定的 ID。AuthProviderSpecificID 是身份验证提供者在内部构造的 ID。
下面是两个示例：
示例 1，用户：CAMID("LDAP:u:uid=admin,cn=admin,ou=support")
其中：
– LDAP 是 NamespaceID
–
uid=admin
是用户的 Relative Distinguished Name (RDN)
–
cn=admin, ou=support
是 Distinguished Name (DN)示例 2，组：
CAMID("LDAP:g:cn=admin,ou=support")
其中：
– LDAP 是 NamespaceID
–
cn=admin, ou=support
是 Distinguished Name (DN)
注意：这个 ID 没有正式的文档记载，因为它是内部的，可能改变而无须通知。这里描述的布局是 IBM Cognos 8.4 当前的情况，在以后的版本中可能会改变而无须通知。当前，AuthProviderSpecificID 由一个类型字段（表示条目的类型）和某个 ID 字符串组成。类型包括：u 表示用户，g 表示组，f 表示文件夹。ID 完全取决于提供者。
Custom Java Authentication Provider 的安装
配置 IBM Cognos 环境
把示例 zip 文件（由两个 jar 文件和四个文本文件组成）解压到一个临时目录并执行以下步骤：
把customprovider.jar
复制到
目录中。把所有
.txt
文件复制到
目录中。
现在，执行以下步骤为以下使用场景配置 Custom Java Authentication Provider (CJAP)。
注意：对于 Content Manager (CM) 和应用层位于不同系统上的分布式 IBM Cognos 8，必须在运行 CM 的所有系统上部署 CJAP。
在定制的名称空间只由一个组织/组/租用者共享的情况下配置基本的提供者
配置 IBM Cognos 8
在 Cognos Configuration 中执行以下步骤：
进入 Security -> Authentication 文件夹。使用弹出菜单在 Authentication 文件夹中添加一个新的名称空间资源（图 2）。给名称空间指定名称，比如 “Basic Custom Provider”，在 Type 菜单中选择类型 “Custom Java Provider”，单击 Ok。图 2. 为定制的提供者添加新的名称空间资源
这为单一组织 CJAP 创建新的名称空间，现在必须像下面这样配置它（图 3）。选择这个名称空间。输入 BASIC 作为提供者 ID。输入
com.ibm.cognos.security.text.BasicCustomProvider
作为类名。
图 3. 配置单一组织 CJAP
现在保存配置并关闭 Cognos Configuration。再次启动 Cognos Configuration，使用名称空间上的弹出菜单测试名称空间。如果在前面的复制步骤中正确地复制了 jar 文件，现在会装载提供者并完成安装，可以为提供者配置用户、角色和组了。
保存新配置并重新启动 IBM Cognos 8 服务。现在，可以作为配置的用户之一登录刚配置的名称空间。
配置单一组织数据库
在第 3 节中，把几个文本文件复制到了
目录中。对于单一组织配置，重要的文件是customprovider_db.txt，它是单一组织提供者的数据库文件。
文件的格式很松散。
这个文件基本上分为四个部分 — 用户、组、角色和文件夹。依次解析每个部分，用在前面的部分中创建的 ID 引用所有对象，否则会出现错误。首先装载用户，然后是角色并分配用户角色，然后装载组并分配成员。最后，装载用于 IBM Cognos Admin 显示的文件夹。
示例用户数据库文件
| //Useruser:40:Test:User A:usera@us.ibm.com:usera:userauser:50:Test:User B:userb@us.ibm.com:userb:userb// Rolesrole:100:::Administrator::40role:101:::Author::40,50role:102:::Consumer::40,50role:103:::AdHoc::50// Groupsgroup:200:::Developers::40,50group:201:::Test Users::40group:202:::All Users::40,50// Foldersfolder:300:::Users::40,50folder:301:::Groups::200,201,202folder:302:::Roles::100,101,102,103 |
用户部分
用户部分包含一些格式严谨的行。行的格式如下：
user:
objectid 是文本字符串，在这个文本文件中必须是惟一的。
角色部分
角色部分包含一些格式严谨的行，它们代表这个名称空间中需要的每个角色。行的格式如下：
User:
objectid 是文本字符串，在这个文本文件中必须是惟一的。角色的成员列表应该包含您希望在登录时具有此角色的所有用户。
组部分
组部分包含一些格式严谨的行，它们代表这个名称空间中需要的每个组。行的格式如下：
User:
objectid 是文本字符串，在这个文本文件中必须是惟一的。组的成员列表可以包含用户、角色或在前面行中已经定义的组的
文件夹部分
文件夹部分包含一些格式严谨的行，它们代表这个名称空间中需要的每个文件夹。行的格式如下：
User:
objectid 是文本字符串，在这个文本文件中必须是惟一的。文件夹的成员列表可以包含用户、角色和组或在前面行中已经定义的文件夹的
在使用单一组织提供者的 IBM Cognos 中标识对象
装载提供者之后，就可以在 Cognos Administration 应用程序中使用数据库中的所有对象。
为 Content Store 中每个对象构造的搜索路径采用以下格式：
CAMID(“
2.2 节解释过 CAMID 的作用。
在 4.1 节中用 Cognos Configuration 定义了 BASIC 名称空间，而在这个名称空间中定义的
customprovider_db.txt
用 objectid 40 标识用户 A，所以对于这个用户，提供的示例会生成搜索路径 CAMID(“BASIC:40”)。
然后，可以为配置的用户设置权限。
图 4. 为配置的用户设置权限
在定制的名称空间由多个组织/组/租用者共享的情况下配置复杂的提供者
根据客户应用程序的规模、客户的多样性以及角色/特性的多样性等因素，多个独立的客户可以共享一个 IBM Cognos 8 实例。这里描述的 “多组织” 配置实现一个由多个 “租用者” 共享的系统，租用者不必知道其他租用者，甚至不必知道他们的应用程序是由单一系统驻留的。随着在企业范围部署 IBM Cognos 8，在大系统上驻留多个 “租用者” 的需求越来越常见了。
配置 IBM Cognos 8
在 Cognos Configuration 中执行以下步骤：
进入 Security -> Authentication 文件夹。使用弹出菜单在 Authentication 文件夹中添加一个新的名称空间资源（图 5）。给名称空间指定名称，比如 “Complex Custom Provider”，在 Type 菜单中选择类型 “Custom Java Provider”，单击 Ok。图 5. 配置复杂的 CJAP
这为多组织 CJAP 创建新的名称空间，现在必须像下面这样配置它（图 6）。选择这个名称空间。输入 MULTI 作为提供者 ID。输入
com.ibm.cognos.security.text.ComplexCustomProvider
作为类名。
图 6. 配置复杂 CJAP 的类名
再次使用名称空间上的弹出菜单测试名称空间。如果在前面的复制步骤中正确地复制了 jar 文件，现在会装载提供者并完成安装。
保存新配置并重新启动 IBM Cognos 8 服务。
配置多组织数据库
在第 3 节中，把几个文本文件复制到了
目录中。对于多租用者配置，重要的文件是customprovider_orgs.txt，它是用于多个组织的注册文件，它引用多个单一组织数据库文件。
在启动时，提供者解析这个文件，然后装载引用的每个单一组织数据库文件。
示例组织注册文件如下所示。
示例组织注册文件
这是基于文件的提供者使用的组织数据库。
org:1:IBM:customprovider_db_ibm.txt
org:2:IBM QA:
customprovider_db_ibmqa.txt
组织部分
这个文件中只有组织部分，其中包含一些格式严谨的行，它们代表需要在这个名称空间中添加的每个组织。行的格式如下：
org:
orgid 是 IBM Cognos 8 在为 Content Store 条目构造惟一搜索路径时使用的 id。file name 是 4.2.1 节讨论过的单一组织提供者的用户数据库文件名。
在使用复杂提供者的 IBM Cognos 中标识对象
装载提供者之后，就可以在 Cognos Administration 应用程序中使用数据库中的所有对象。为 Content Store 中每个对象构造的搜索路径采用以下格式：
CAMID(“
在 5.1 节中用 Cognos Configuration 定义了 MULTI 名称空间，在这个名称空间中用
customprovider_orgs.txt
中的 orgid 1 和customprovider_db_ibm.txt
中的 objectid 40 标识用户 A，所以对于这个用户，提供的示例会生成搜索路径 CAMID(“MULTI:1-40”)。
登录 Complex Custom Provider
对于同一名称空间注册多个组织之后，在登录时应该选择 Complex Custom Provider（图 7）。
图 7. 在登录时选择复杂提供者
屏幕现在应该会更新，会增加选择组织的控件（图 8）。显示所有组织不太安全，在真实的提供者中这应该是文本输入框或隐藏的值，但是显示所有组织对于本文档比较方便。
图 8. 选择适当的组织
选择需要的组织并输入相关的凭证。当作为此组织中的用户登录时，如果此用户有权访问 Cognos Administration，那么只会显示相关用户数据库文件中定义的文件夹。
作为管理员登录 Complex Custom Provider
为了增强安全性，需要内部的管理功能。
这由用户名为 “cognos” 的内部管理用户提供。这个账号的密码也是 “cognos”，当前是硬编码的。可以从名为 “Administrators” 的组织访问此用户，这个组织会自动地添加到选择列表的末尾（图 9）。
图 9. 作为管理员登录 Complex Custom Provider
登录之后，管理用户 “cognos” 是 “Cognos Administrators” 组的成员，具有 “Cognos Administrator” 角色。可以从 Cognos Administration 访问这些角色和组。
登录 Cognos Administration 之后，应该能够访问
customprovider_orgs.txt
文件中定义的所有组织以及内置的 Administration 组织（图 10）。选择任何组织，就会显示此组织的用户数据库文件中定义的文件夹结构。
图 10. 管理员登录功能
因此，可以访问所有组织中的角色和组，现在应该按 Security and Administration Guide 中的说明使用它们保护 IBM Cognos 8 系统。
通过配置定制的可信登录提供者在安全基础设施中集成 IBM Cognos 8 组件
前面介绍的两个提供者只支持基于 “TRUSTED_SIGNON_USER” 变量的 SSO。实现 SSO 需要使用可信登录提供者，这种提供者从 cookie 或 URL 参数获取用户名并填充指定的变量。
可信登录的用户应该是有效的用户，能够成功地向 IBM Cognos 8 验证身份，否则在当前实现中会抛出未处理的异常。
下图显示在实现可信登录提供者的情况下 IBM Cognos 8 的安全架构。
图 11. 定制的可信登录提供者架构
配置 IBM Cognos 8 环境
在 Cognos Configuration 中执行以下步骤：
进入 Security -> Authentication 文件夹。使用弹出菜单在 Authentication 文件夹中添加一个新的名称空间资源（图 12）。给名称空间指定名称，比如 “CustomTrustedSignonProvider”，在 Type 菜单中选择类型 “Custom Java Provider”，单击 Ok。图 12. 为定制的可信登录提供者添加新的名称空间资源
这为可信登录 CJAP 创建新的名称空间，现在必须像下面这样配置它（图 13）。选择这个名称空间。输入 TRUSTED 作为提供者 ID。输入
com.ibm.cognos.security.text.CustomTrustedSignon
作为类名。
图 13. 配置定制的可信登录提供者
配置的可信登录提供者在内部调用 Basic Custom Provider（在
com.ibm.cognos.security.text.CustomTrustedSignon
类中配置）执行身份验证，如果愿意，可以隐藏它。把基本提供者的 “Selectable for Authentication” 字段设置为 “false”（图 14）。它会从登录页面上的名称空间下拉列表中消失。
图 14. 对于身份验证隐藏可信登录提供者名称空间
图 15. 登录可信登录提供者名称空间
可以通过设置 cookie 变量或 Cognos URL 在 com.ibm.cognos.security.text.CustomTrustedSignon 类中用可信用户实现 SSO。在上面的类中从变量 “TRUSTED_SIGNON_USER” 获取用户。
如果可信用户是有效的用户，他会自动地登录 Cognos 名称空间 “BASIC”；否则通过 UI 提示用户输入凭证。也可以配置为登录其他名称空间。
注意：根据应用程序开发人员的习惯不同，注入 cookie 的实现可能不一样。
结束语
本文解释了一个容易使用的 Custom Java Authentication Provider (CJAP)，它只使用文本文件驱动用户供应所需的所有配置（比如身份验证和授权），不需要特殊的数据库、其他软件或外部源。
使用平面文件的 CJAP 的优点
很容易用 TIM (Tivoli Identity Manager) 等外部工具填充 CJAP 使用的平面文件，因此有助于集成 POC 或测试环境。它可以作为轻量的目录服务器，而且在所有系统上都使用平面/文本文件，因此不需要任何数据库或特殊技能。用户只需编写/修改文本文件。它不需要任何第三方软件，所以对于离线设置和测试安装非常方便。它可以在离线状态下保护 IBM Cognos，甚至是在非 Windows 环境中。例如，可以使用它简便地对 Linux 用户进行身份验证。这个 CJAP 只需用在登录时指定的用户名和密码通过 telnet 连接 Linux 计算机。如果没有它，就需要按http://www.ibm.com/developerworks/linux/library/l-pam中的说明集成 IBM Cognos 和 PAM (Pluggable Authentication Module)。可以隐藏在 Cognos Configuration 中为名称空间配置的目录服务器信息（IP、端口等）。
常见问题
在 Namespace ID 属性中不要使用冒号 (:)。错误 “Bad Offset at version 6”：这是由于用比较高的 JRE 版本（JRE 1.5.X 之前的版本）编译 Custom Java Provider 名称空间使用的 jar 文件，在 IBM Cognos 环境中造成 JRE 不匹配。尝试使用比较低的 JRE 版本（JRE 1.4.X 之前的版本）。注意：这里的示例代码已经用 IBM JRE version 1.5 编译过。
收起