cognos使用自定义函数_将单点登录添加到您的IBM Cognos 8自定义Java身份验证提供程序

cognos使用自定义函数

目的

作为标准IBM Cognos 8 SDK文档的一部分的《定制Java身份验证提供程序开发人员指南》提供了编写定制Java身份验证提供程序（CJAP）所需的主要概念。它甚至描述了身份验证可以基于什么，以及如何从入口点请求其他信息。但是，该描述过于简短，并且缺少实际利用这些技术向完整的Custom Java Authentication Provider添加对单点登录（SSO）的支持的示例。但是，可能需要向客户提供全面的解决方案。

在本文档中，将提供身份验证过程的背景以及有关如何使用提供的SDK处理SSO的描述性信息。作为示例，SSO支持将添加到作为SDK样本的一部分提供的“ JDBCSample” CJAP中。

适用性

本文档中发布的概念和背景适用于所有版本的IBM Cognos 8。

本文档中的代码示例是使用IBM Cognos 8.4.1开发和测试的。尽管作者无法保证代码示例无需进行调整即可工作，但他不知道任何其他技术先决条件，只是用适当的JRE版本重新编译JDBCSample的（调整后的）源代码以使代码在产品的其他版本中工作。

排除与例外

该文档通常不会涵盖设计和编码自定义Java身份验证提供程序（CJAP）。本文涵盖的唯一方面是向完整的身份验证提供程序添加对单点登录（SSO）的支持。

使用示例代码（JDBCSample）要求已安装IBM Cognos 8 SDK并获得许可。

希望读者熟悉CJAP SDK和Java编程。

IBM Cognos 8中的身份验证

本章将提供对IBM Cognos 8中认证过程所涉及的概念和组件的全面描述。

请求和会话

用户（浏览器）或代码（SDK应用程序）通过与Cognos入口点（EP）建立HTTP会话将请求发送到IBM Cognos 8。有效入口点可以是直接访问的IBM Cognos 8 Dispatcher，也可以遵循最佳实践，是部署到Web服务器的IBM Cognos 8 Gateway。

由于IBM Cognos 8基于面向服务的体系结构（SOA），因此由Cognos系统提供的全部功能是由一组独立的服务实现的，该组独立的服务使用SOAP协议在外部进行相互通信。因此，发送到IBM Cognos 8入口点的每个请求都必须路由到可以处理该请求的某些目标服务。组成IBM Cognos 8的每个服务都处理不同类型的请求，而路由是IBM Cognos 8体系结构的主要概念之一。

路由由IBM Cognos 8 Dispatcher Service处理。无论请求是直接发送到分派器还是通过网关发送（每个网关都会将其请求中继到配置中指示的单个分派器），都将由访问的分派器上的分派器服务实例处理。如果这是该HTTP会话中收到的第一个请求，则分派器服务将创建一个新的sessionID 。接下来，将给请求分配一个requestID，并将sessionID和requestID都添加到请求中。现在可以识别同一HTTP会话中的所有后续请求，因为它们共享相同的sessionID 。

由于服务在逻辑上是彼此独立的，因此实际上所有服务在处理请求之前都需要进行身份验证，以防止意外访问。在这种情况下，身份验证意味着对请求所属的会话进行身份验证，因此请求源自经过身份验证的发送方。

对于IBM Cognos 8，身份验证功能由内容管理器（CM）服务集中提供。因此，所有其他IBM Cognos 8服务都将使用CM Service来验证会话身份验证或触发尚未经过身份验证的会话的身份验证。

Dispatcher Service实例处理请求后，该服务将首先检查给定会话的身份验证状态。如果会话尚未通过身份验证，则分派器服务将使用CM Service运行身份验证过程并将请求传递给它。 CM服务会将请求传递给Cognos Access Manager（CAM）组件，该组件是CM的子组件，用于处理身份验证，授权和管理（AAA）和加密（CRP）。它是CAM的AAA子组件，它将使用为IBM Cognos 8配置的身份验证提供程序来访问身份验证源，以从中读取有关用户的信息，并最终对请求进行身份验证，从而对会话进行身份验证。

图1认证示意图

如果身份验证成功，则身份验证信息将保留在Content Store中，并且会将引用添加到会话中，因此后续请求将不会传递到CAM，因为所有服务现在都可以直接从会话中减去对身份验证信息的某些引用，并拥有CM服务部门在适用时对其进行验证。

经过一段可配置的空闲时间后，会话将超时，并且调度程序服务将请求CAM再次验证会话。

验证提供者

IBM Cognos 8身份验证提供程序是用Java或C ++实现的软件模块，可与Cognos Access Manager（CAM）组件连接。有两种类型的身份验证提供程序，如《自定义身份验证提供程序开发人员指南》中所述。

完整的身份验证提供程序实现一些功能，以针对某些身份验证源对提供的凭据进行身份验证，该身份验证源存储和管理用户，组和/或角色类型的条目。另外，它为搜索条目提供了支持，并且尊重身份验证源的层次结构。身份验证提供程序必须支持至少一种身份验证方法，可能是多种，并且还可以支持单点登录支持。

尽管受信任的登录提供程序（TSP）仅出于单一目的提供了非常有限的功能。在单点登录方案中，它从可能由标识用户的更高级别的身份验证层放置在会话中的会话中读取令牌。假定此令牌不能由任何其他IBM Cognos 8身份验证提供程序直接使用。 TSP将令牌中的信息转换为完全身份验证提供者可以使用的东西，并将身份验证过程传递给第二个完全身份验证提供者。它不对用户进行身份验证，仅中继和转换信息，因此不会导致名称空间条目出现在Cognos Connection的目录工具中。

下表描述了IBM Cognos 8开箱即用提供的身份验证提供程序。但是，并非每个提供商都可以在每个平台上使用。在Linux和HP-UX Itanium上，LDAP提供程序是唯一可用的。

除了开箱即用的提供程序之外，客户还可以使用仅为Java提供的Custom Authentication Provider SDK（IBM Cognos 8 SDK的一部分）来实现自己的身份验证提供程序。基于此SDK编码的身份验证提供程序称为自定义Java身份验证提供程序（CJAP），其类型可以为full或TSP 。实际上，产品中已经包含CJAP，用于单点登录门户网站服务器（共享密钥提供程序）。

	视窗	UNIX系统	Linux，HP-UX Itanium
活动目录	是	没有	没有
NTLM	是	没有	没有
树液	是	是	没有
系列7	是	是	没有
LDAP	是	是	是
CA Siteminder（TSP）	是	是	没有
共享秘密（CJAP，TSP）	是	是	是

除使用专有配置方法的CJAP之外，所有提供程序都通过在Cognos Configuration中创建的名称空间配置（资源）进行配置。在那里，可以配置特定于该提供程序实例的属性。 IBM Cognos 8 Content Manager启动后，将在配置中扫描名称空间配置，并根据配置的设置初始化各个提供程序。

从IBM Cognos 8开始，所有现成的提供程序都支持测试功能，通过右键单击Cognos Configuration的资源管理器树中的名称空间配置元素可以使用该功能。这是在一定程度上使用配置的设置初始化提供程序。但是，该测试可能并不对提供程序支持的所有功能都具有决定性的意义，它仅意味着捕获明显的配置错误和连接问题。

认证过程一般

当CAM接收到身份验证请求时，将基于配置做出有关身份验证类型的第一个决定。如果系统配置为允许匿名访问，则将使用特殊的匿名用户对会话进行身份验证，因为IBM Cognos 8中没有真正的匿名会话。内部身份验证提供程序用于实现既不可见也不可配置的功能。将使用一些既不包含用户名也不包含密码的硬编码虚拟用户凭据，因此不需要登录。

对于命名（=非匿名）访问，CAM将使用配置的身份验证提供程序对请求进行身份验证，因此将其传递给配置的提供程序之一。哪一个取决于可用性（哪些提供者正确初始化了）以及一些包含要使用的命名空间的namespaceID的参数。

尽管最容易期望单个请求一次包含所有登录数据（身份验证所需的信息），例如要进行身份验证的名称空间和凭据，这可能并不适用于所有用例。

为此，该体系结构实现了一种概念，即将合格的响应返回给发送方，从而触发发送方发送附加了附加信息的另一个新请求。这样，身份验证提供程序就可以从发送请求者（用户或SDK程序）甚至请求进入的入口点（网关或分派器）请求其他信息。这些回叫的典型应用是提示用户输入其凭据，让用户从几个已配置的身份验证提供者中选择一个，或者让入口点从其环境中检索一些SSO典型的受信任变量值。

发送给CAM的每个请求都被独立处理，但是一系列请求可以构成给定会话的登录过程。《定制身份验证提供程序开发人员指南》第2章“身份验证请求：流方案”中的三种方案对此进行了描述。

仅在单个请求包含所有必需的登录数据之后，提供者才会实际尝试对请求进行身份验证。在继续进行下一步的身份验证之前，让我们看一下提供者可以/将要接受/需要的登录数据的类型。

登录数据

有四种可能的方法可以将请求中的登录数据传递给身份验证提供程序。

可信凭证（TC）
过去，某些身份验证提供程序已为IBM Cognos 8用户创建了这种类型的凭证，并将其存储（加密）在Content Store中。例如，时间表将参考与之一起存储的TC（凭证路径）。从技术上讲，它们可以是二进制令牌或字符串，例如用户名（和密码）。尽管仅凭证路径在请求中传递，但TC从未离开内容存储库。
收到TC时，身份验证提供程序不会显式验证其来源或一致性，而只是隐式地。函数getTrustedCredentialValue()封装了从内容存储库检索实际凭证值并将其解密的过程，从而验证了完整性和来源。提供者只需对身份验证源运行身份验证。但是，TC可能会过期，例如，如果密码已存储在Content Manager中，则已在身份验证源中更改了密码。在这种情况下，必须由自己所属的用户通过Cognos Connection对其进行续订。
证书
凭证（也称为SDK凭证）是在对IBM Cognos 8进行身份验证时由SDK程序发送的。从技术上讲，它们将是字符串，可能是用户名，而且可能是（但不是强制性的）密码。除非使用SSL，否则凭据将以明文形式在请求中传递。
身份验证提供程序将对照身份验证源对其进行验证。
表单字段-用户名和密码
如果运行Basic Authentication ，则意味着提示用户输入用户名和密码，HTML代码将提交在两个预定义的FORM字段中输入的凭据。它们将在请求中显示给入口点，但是一旦网关对请求进行了解析，它将掩盖传递给CAM的请求中的密码。如果入口点是分派器，则不支持该功能。
（受信任的）环境变量，cookie或通用SSO令牌
身份验证提供程序可以允许从环境变量或某些二进制令牌读取用户身份信息。
这些变量或标记的值从不直接从请求中读取，而是由入口点组件通过前面提到的回调提供的。它演变为对这些回调的支持也需要入口点层组件中的代码。
当前支持的唯一二进制SSO令牌（仅在Windows网关上）是Microsoft Windows Kerberos令牌。但是，环境变量的相应代码（在Gateway和Dispatcher的任何平台上都受支持）接受通用变量，包括受信任的变量（例如REMOTE_USER，USER_PRINCIPAL）和任意变量（HTTP_REFERRER，HTTP_xxxx）。

产品随附的所有完全身份验证提供程序都支持这四种方式。定制Java身份验证提供程序可以选择仅支持其中一些或全部一起。

在会话中保留身份验证信息

在处理请求时，身份验证提供程序将联系其身份验证源并从中读取信息以验证传递的身份信息。如果身份验证成功，则提供程序将为用户/客户端进行身份验证的名称空间签发签证。

Visa维护用户的安全上下文，即登录数据（用于向IBM Cognos 8进行身份验证的任何数据）以及其身份（他所属的组和角色）。该签证将用于获取凭证（从先前的身份验证保存的登录数据，以传递给其他服务），每当另一个IBM Cognos 8服务请求身份验证时（例如，计划报告或对数据源进行身份验证时），将使用该签证。签证将添加到CAM内存表中，该表将保留所有有效签证。单个会话的所有签证，以及一个用户/客户端的所有签证，以及已成功完成身份验证的每个名称空间的签证，构成一个Passport 。他们在该表中共享相同的主键Passport ID 。仅将此Passport ID公开给CAM外部作为参考。就是将护照ID返回给CM和用户/客户端。

对于浏览器客户端， Passport ID存储在浏览器内存中的会话cookie中，对于SDK，应用程序有责任在会话持续时间内管理Passport ID 。

索取其他信息（身份验证舞）

如果请求所包含的信息不足以立即完成身份验证事务，则身份验证提供程序将使用前面提到的回调功能。此功能允许身份验证提供程序从用户或系统请求其他信息。

请求信息的方法称为“异常”，因为它使用类似Java异常的概念。调用者（在这种情况下为请求的发送者）负责处理异常。

IBM Cognos 8身份验证提供程序可以返回三种异常类型

UserRecoverable异常（ camAuthUserRecoverable, error -36 ）
向发送方发出信号，表明最终用户/客户端需要提供（附加）数据，这些数据应附加到新请求中。例如，这可能意味着用户需要选择用于认证的名称空间或输入凭据。
SystemRecoverable异常（ camAuthSystemRecoverable, error -37 ）
向入口点发送信号，要求系统在无需用户/客户端进一步交互的情况下必须获取的其他数据。附加信息必须附加到要发送给CAM的新请求上。例如，这可能意味着在网关处检索系统/环境变量的值。
不可恢复的异常（ camAuthUnRecoverable, error -38 ）
表示错误，无法采取任何进一步措施来纠正。这通常表明提供程序存在一些内部问题，并且使身份验证无法进行，在此身份验证事务中不必发送任何进一步的请求。

每个异常将携带其自己的特定附加信息集，以向发送方指示拒绝的根本原因或指示下一个可能的操作。

发送者有责任以适当的方式对这些异常做出React，例如重新发送带有附加数据的请求，或采用其他服务（例如演示服务）来推动行动。这可能意味着，如果最终通过身份验证或最终失败，则在请求之前，身份验证提供程序与入口点/客户端/用户之间会进行几轮往返。

CAM和调用者之间的这种来回交互可能是入口点（网关，分派器）或其他某些组件，例如SDS（计划提交用于身份验证的凭据以进行“运行”），这称为“ 身份验证舞步 ”。

如果需要用户提供其他信息（UserRecoverable Exception），系统将生成一个HTML页面，并将其作为例外的一部分返回给客户端/用户的浏览器。生成的页面将包含HTML表单，以提示用户输入所需的信息并将其提交回Cognos，或者对于SDK客户端，请命名必须由客户端传递的其他变量。

如果需要系统（环境）的其他信息，则过程会稍微复杂一些。

SystemRecoverable异常将包含一个加密的数据字段，其中包含身份验证提供程序正在请求的环境变量的名称。尽管变量可能是原始请求的一部分（即REMOTE_USER），但提供者不会接受原始请求中的值，因为它很容易被欺骗或注入，但它根本不信任该值。为了从可信源（如入口点）获取值，它从入口点请求此变量。发送者，在这种情况下，入口点将尝试从其本地环境读取变量，并提供扣除的值或NULL（如果提供者无法获得/发现）作为其响应的一部分。此响应是原始请求，入口点现在向该请求在相同的加密字段中添加了从其环境中扣除的信息。对于提供商来说，这是另一个新的身份验证请求，但是这次它将具有其他信息，并且可能现在可以成功。

单一登录与受信任的登录

为了获得无缝的登录体验，IBM Cognos 8支持两个概念。

单一登录（SSO）意味着IBM Cognos 8将采用从先前的身份验证层（例如身份验证代理）接收到的某些UserID。 Cognos将不会再次提示用户输入凭据。 IBM Cognos 8身份验证提供程序将调查一些（对于某些提供程序是可配置的）HTTP变量或cookie，该变量或cookie包含适用于SSO的登录数据。将使用认证舞来获取所需的信息。

对于受信任的登录（TSO），可以将一种特殊类型的IBM Cognos 8身份验证提供程序（即所谓的受信任的登录提供程序（TSP））编码为¹ 。该提供程序将消耗一些令牌，并从中扣除身份验证提供程序消耗的登录数据。 TSP不是完整的提供程序，它没有附加到LDAP之类的身份验证源，它只是使某些SSO令牌可访问的代理。在下一步中，使用REMOTE_USER标准标头将登录数据传递到完整的IBM Cognos 8身份验证提供程序，大多数标准的身份验证提供程序都支持SSO。但是，与SSO相反，在这种情况下，完整的提供程序将不使用身份验证操作，而是信任REMOTE_USER中传递的登录数据，因为它来自受信任的源TSP。

对于这两种情况，一如既往地为IBM Cognos 8无法验证用户本身，而是依赖于该^第三方认证来源。但是，在单点登录或受信任的登录中，IBM Cognos 8从不验证用户的凭证，而仅依靠查找并假定用户之前已经通过适当的凭证进行了身份验证。但是，对于查找，IBM Cognos 8必须有权访问身份验证源，如果根据标头/ cookie中传递的信息进行搜索，则会找到一个用户。但是，它不需要完全相同的身份验证源。

例如，如果用户已通过某个基于LDAP的身份验证代理进行了身份验证，该代理在REMOTE_USER中传递了一些值，那么对于IBM Cognos 8，可以利用OSSignon为Series7配置一些身份验证提供程序，从而允许基于用户查找关于传递的信息。不过，理想情况下，在这种情况下，应使用指向同一LDAP的LDAP身份验证提供程序来确保查找正确的用户，因为任何映射都可能导致错误。

1对于CA Siteminder，此提供程序是开箱即用的，对于其他身份验证代理，可以使用IBM Cognos8身份验证提供程序SDK进行开发。

为自定义Java身份验证提供程序实现SSO

上一章介绍了IBM Cognos中与身份验证有关的概念和组件。基于此，我们现在可以讨论在CJAP中实现SSO。

在本文档中，我们着重于完整的身份验证提供程序。为了支持SSO，提供者必须实现对^第四种类型的登录数据的支持，如第2.3.1节“登录数据”中所述。除了环境变量之外，提供者支持哪种其他类型的登录数据也无关紧要，但是，如果提供者应允许安排受信任的凭据，则是无关紧要的。如果用户应该能够输入凭据，那么还必须实现基于FORM的方法，最后，如果应该使用SDK应用程序和工具（如trigger.sh或/ bin / utilities文件夹中的诊断工具），则需要SDK凭据。

在本文档中，将基于作为IBM Cognos 8 SDK一部分提供的“ JDBCSample”的代码来演示该技术。我们将添加对所有类型的登录数据的支持，包括基于REMOTE_USER的SSO。

当请求传递给提供程序时，这意味着调用提供程序的authenticate（）方法。在这种方法中，提供者必须处理完整的身份验证序列，包括识别登录数据的类型，使用身份验证源运行身份验证并最终签发签证并将其添加到护照。对于本文档，我们将仅讨论识别登录数据类型的第一步，其余的仅针对受支持的身份验证源，因此不在主题之列。有关详细信息，请参考JDBC示例源代码。

处理登录数据类型标识的一种行之有效的做法是使用嵌套的IF语句，该语句将检查Trusted Credentials，Credentials，Forms并最终检查SSO。尽管不需要特定的序列，但坚持使用此简化程序可以使代码保持简单有一些好处。仅当未提供明确的登录数据时，代码才应尝试处理SSO。

每种类型的登录数据都有一个IBiBusHeader2类的匹配函数，可用于从传递给logon（）函数的请求中检索它。

有一个getTrustedCredentialValue（），可以使用参数用户名或密码来调用它，以从可信证书中读取相应的值。对于SDK凭据，存在类似的名为getCredentialValue（）的函数，该函数沿相同的方向运行。只需使用用户名或密码参数调用它即可从SDK凭据中检索值。

对于基于FORM的身份验证，即lgin页面，其中用户输入用户名和密码，使用两个FORM变量CAMUsername和CAMPassword。使用这些名称作为参数的GetFormFieldValue（）调用将检索请求中的表单字段。当然，也可以将这些字段作为GET URL的一部分传递。

最后，要读取环境变量，确实存在两个功能

getEnvVarValue（）
此函数将按原样从请求中读取HTTP标头的值。也就是说，它不会触发身份验证动作，而只是采用请求中传递的值。尽管这在某些情况下可能已足够，但会带来很大的欺诈风险。向请求注入HTTP标头非常容易，因此，任何人都可以向请求添加具有任何所需值的REMOTE_USER标头。因此，不建议将此功能用于SSO。
GetTrustedEnvVarValue（）
如2.3.3节所述，此函数可用于触发传递给该函数的参数中指定的变量的身份验证舞动。假定发送给提供者的请求中的HTTP标头填充了Web服务器将在本地存储为CGI环境变量的值。身份验证操作将使入口点从入口点的环境中读取该变量值，并将其发送回提供程序。由于该变量是从Cognos组件（入口点）中检索的，因此提供程序将信任扣除的值，因为它以签名和加密方式进行传输，因此足够安全。

显然，我们希望使用getTrustedEnvVarValue（）函数。在第2.3.3节中提到，要触发身份验证舞蹈，必须将异常返回到入口点。这是必须在提供程序代码中显式处理的内容。 getTrustedEnvVarValue（）函数将返回NULL或字符串。如果返回NULL，则表明还没有检索到可信值。这意味着提供者代码现在必须引发SystemRecoverable Exception并请求所需的变量。从提供者的角度来看，此请求已完成。当一个新请求到达并再次调用GetTrustedEnvVarValue（）时，它将返回一个字符串。如果此字符串为空（其长度= 0），则入口点无法检索所需变量的值，这意味着未设置该值。这意味着SSO失败，并且提供程序应通过抛出UserRecoverableException要求输入凭据或使用UnrecoverableException进行纾困而退回到基于FORM的身份验证。如果字符串不为空，它将包含所请求变量的值。

因此，提供程序本身必须抛出SystemRecoverable Exception，并在其中提供请求的变量名称。其余所有涉及的功能，例如加密值，对用于在提供者和入口点之间来回传输数据的专有标头进行签名，都不受开发人员的影响。

下面是JDBCSample示例应用程序源代码的一部分代码，该代码是Logon（）函数的一部分。它依次使用三个IF语句来检查不同类型的登录数据。仅当填充用户名或密码之一时，代码才会继续验证登录数据，甚至签发签证。如果用户名和密码均未从登录数据中获取分配的值，则该代码将引发UserRecoverable异常，如果浏览器是客户端，则该异常将导致显示登录屏幕。

在此代码段中，我们想添加对^第四种类型的登录数据（受信任的环境变量）的支持，在此示例中为REMOTE_USER。

String[] username = null;String[] password = null;//    1 - Look for trusted credentialsusername = theAuthRequest.getTrustedCredentialValue("username");password = theAuthRequest.getTrustedCredentialValue("password");if (username == null && password == null){//  2 - Look for credentials coming from SDK requestusername = theAuthRequest.getCredentialValue("username");password = theAuthRequest.getCredentialValue("password");}if (username == null && password == null){//   3 - Look for credentials in formfieldusername = theAuthRequest.getFormFieldValue("CAMUsername");password = theAuthRequest.getFormFieldValue("CAMPassword");}      if (username == null || password == null){UserRecoverableException e = new UserRecoverableException("Please type your credentials for authentication.","The provided credentials are invalid.");e.addDisplayObject(new TextDisplayObject("User ID:","CAMUsername"));e.addDisplayObject(new TextNoEchoDisplayObject("Password:","CAMPassword"));throw e;}

直接的方法是在从表单字段中查找凭证后添加第四个IF块。但是，这意味着该IF块中发生的任何事情都必须填充用户名和密码，以通过最终测试是否在最后的IF语句中已检索到某些内容。 SSO通常不提供密码，这是SSO的目的，以避免必须多次提供密码，并且无论如何都要以明文形式传递密码是安全隐患。因此可以安全地假设我们的SSO不提供密码。这意味着我们必须更改最终的if语句，以仅允许用户名，但仅在SSO情况下。

好吧，这并不完全正确。如果支持SSO，它也可以用于生成受信任的凭据。这意味着，如果用户通过SSO认证到IBM Cognos 8，则登录数据将只是某些用户名。因此，如果调用提供程序以生成TrustedCredential并按计划进行存储，则它只能基于用户名生成此凭据。现在，当稍后执行该计划时，将是那些仅由提供给提供者的用户名组成的TrustedCredentials。因此，一旦提供者确实支持SSO，它就必须处理（信任的）凭据，该凭据可能仅包含一个用户名，也就是说，即使基于信任的凭据的身份验证也必须仅允许使用用户名。

可以选择将其扩展到基于SDK凭据的身份验证，但是SDK客户端通常具有足够的功能来提供完整的凭据，即用户名和密码。作为建议，应保留完整的凭据。

声明了这一点后，更改该代码段的部分逻辑并将IF语句的结构从序列更改为嵌套变得合理。这将允许对每种类型分别扣除的登录数据的内容进行决策。为了通过最后一条IF语句，我们仅在使用SSO的情况下用用户名填充密码。

下面是解决此要求的一种示例。

String[] username = null;
String[] password = null;
//  1 - Look for trusted credentials
username = theAuthRequest.getTrustedCredentialValue("username");
password = theAuthRequest.getTrustedCredentialValue("password");
// since pw can be empty we scan for either username or password
if (username != null)
{// we found some value for username in TC, now lets see about pwif (password == null) password=username;// we simply set password= username in case we didn't get one from TC// possibly some log output here
}
else
{  //   2 - Look for credentials coming from SDK requestusername = theAuthRequest.getCredentialValue("username");password = theAuthRequest.getCredentialValue("password");if (username != null && password != null){// we found Sdk credential, all good// possibly some log output here}else{ //   3 - Look for credentials in form fieldusername = theAuthRequest.getFormFieldValue("CAMUsername");password = theAuthRequest.getFormFieldValue("CAMPassword");// Note: using AND here implies that the provider will check for SSO //       if a user typed in username and an empty password. Though//       it introduces overhead, this can be neglected as it enforces//       correct logic on the other hand. if (username != null && password != null){// found credentials in form field, all good// possibly some log output here }else{  // 4 - Look for REMOTE_USER header variableusername = theAuthRequest.getTrustedEnvVarValue("REMOTE_USER");if (username == null) {// null implies the provider has to start the dance so throw a SysRecov.// the SysRecov needs to have the name of the variable we look for in// the second parameterSystemRecoverableException e = new SystemRecoverableException("Challenge for REMOTE_USER","REMOTE_USER");throw e;}// username is != NULL so we have to investigate if we got something back // from the dance if (username[0].length() == 0){// this indicates the variable does not exist or is empty. Bail out by// erasing username and password. Final IF will cause UserRecoverableusername=null;password=null;}else {  // OK, we got something, so fake password, just to pass the // if clause further down.password = username;}}}
}

使用此逻辑，提供程序将触发身份验证舞蹈并检索REMOTE_USER。如果该变量在入口点环境中具有值，它将被传输到用户名和密码。

剩下要做的就是处理凭据，并使用身份验证源对其进行验证。请注意，如果用户名=密码，则它是SSO或受信任的凭据。在这两种情况下，提供程序都将遵循“可信登录”的概念，在该概念中，它不验证凭据，而仅运行查找。

可以采用此技术来使用任何HTTP标头变量。 Cookies cannot be used as the entry point doesn't support them. Using cookies should be handled in a TSP really which then passes on to a full authentication provider which uses REMOTE_USER based SSO as demonstrated here.

The above code snippet won't actually make the JDBCSample work. The sample code relies on passing user name and password to the JDBC driver and only if those credentials are successfully used to establish a DB connection the visa will be issued. However if one creates a user which has his user name as a password that would work. The JDBCSample was chosen for this document only because it's the only example of a full authentication provider. The important take away is the concept of calling GetTrustedEnvVarValue() twice depending on it's return code.

翻译自: https://www.ibm.com/developerworks/data/library/cognos/security/cognos8_platform/page511.html

cognos使用自定义函数