IBM / Lotus Domino 与 WebSphere Portal: 单点登录(2)

针对Domino的浏览器

涉及SSO的第二组事务出现在用户浏览器和Domino服务器之间。当用户从WebSpherePortal界面打开一个LotusNotes文档，如果在iFrameportlet中打开任何Domino应用流程时，这种事宜就会发生。如果您查看一下NotesMailportlet或者Notesviewportlet中的词条，您会提醒到HTML链接被定向到Domino服务器并穿过了WebSpherePortal。

因为WebSpherePortal没有包括在事务中，所以用户的身份是借助LTPAcookie来传递的，这个LTPAcookie是在用户借助WebSpherePortal的认证时创建的。该LTPAcookie包含用户的DN，这个DN是登陆时从LDAP目录查询到的。经过加密的LTPAcookie信息连同HTTP请求一起传递到Domino服务器。

要用SSO处理由WebSphere创建的LTPAcookie，必须合成一个在Domino服务器上合成一个有效的键密钥（Key）。WebSphereAdministrator’sConsole在SecurityCenter有一个工具，该工具可以导入一个LTPA键密钥，以后这个键密钥可以被导出Domino中，因而在两个环境之间提供了公共键密钥。虽然Domino服务器可以购物由WebSphere创建的键密钥，所以Domino不能导入它自己的LTPA键密钥。

本文件的剩余部分涵盖如何配置WebSpherePortal和Domino，以便支持这两种类型的SSO。

单用户目录环境

后面早已讨论过，这两种情景适用于两种不同的顶配；一种是应用DominoLDAP作为这些的主目录的环境，另一种是将一切使用流程，包含Domino指向另一个支持的LDAP目录的环境。

应用Domino目录

Domino服务器提供了一种LDAP服务。WebSpherePortal可以被配置为应用DominoLDAP服务进行认证。这是最简单的环境，所以用户凭证和密钥是从同一个源造成的（借助LDAP或者原始Domino）。

惟一需要的顶配步骤就是从WebSphere服务器上将LTPA键密钥导出并将它导入Domino服务器的这一过程。相同的键密钥必须在一切的WebSphere服务器之间共享，这种WebSphere服务器将要是该SSO域的一部份。基本的安全设置，譬如超时、LDAP服务器和DNS域在一切的WebSphere服务器中必须是一致的。

Domino服务器在该键密钥被导出后当然要配置为Multi-ServerSSO针对多服务器SSO。要获得有关怎么配置服务器的更多资料，参考当前的WebSpherePortalInfoCenter以及Readme文件。

Sametime3.x和QuickPlace3.x服务器可配置为应用原始的DominoDirectory或者DominoDAP服务。

应用非Domino目录

WebSpherePortal支持IBM的DirectoryServer、Microsoft的ActiveDirectory、iPlanet以及Novell的eDirectory。Domino可被配置为在特殊条件下支持各种目录。

为了使邮箱在Domino环境内部进行路由，就必须有包括短信信息（譬如邮件文件和针对每位用户的短信服务器）的目录记录。该文件既可以是DominoDirectory中的Person文档，也可以是Mail-inDatabase文档，如果是LDAP目录中的拓展Schema。

Domino和DirectoryAssistance

Domino服务器有一种用来链接到一个内部的名为DirectoryAssistance(DA)的LDAP目录的制度。该制度允许Domino服务器在为用户身份认证搜索Domino目录后搜索一个或多个LDAP目录。DA通过从所提供的模版中创建DirectoryAssistance，在服务器文件中输入名称，然后在该中加入一个文件而被激发。

接着组和用户管理可以从LDAP目录完成，唯一的受限就是短信路由。在ACL中对用户名的摘录，组成员还有其它的上下文环境才能是用户的LDAPDN的经过修订的版本。修改是在Domino环境中完成的，在Domino环境中，LDAP所应用的空格被/符号代替。所以

 cn=Elizabeth Somebody,ou=users,o=YourCo 

变为

 cn=Elizabeth Somebody/ou= users/o=yourco.com 

如果配置好了DirectoryAssistance，要提供单点登陆的系统，您一直需要配置WebSpherePortal和Domino之间的LTPA关系。QuickPlace环境和Sametime环境都觉得被配置为按照与WebSpherePortal相同的目录进行身份认证。要获得更多的资料，请察看与其他品牌一起提供的文件。通过QuickPlace3.0可以直接访问LDAP，而无需DirectoryAssistance。Sametime3.0依赖于Directory帮助Assistance从LDAP获得资料。为了最灵巧地实现人员感知，Sametime应该配置为应用原始DominoDirectory。

在这些环境中应用DirectoryAssistance是奏效的，在这种环境中相似的用户不会被列在LDAP目录中，也不会被列在Domino目录中。如果只为了支持QuickPlace和Sametime而执行Domino，所以可以应用这种类型的顶配。在更繁杂的环境中那么已经存在Domino基础设备，才能应用更多的Domino功能，就有必要配置多个目录。

分离多目录环境

但是大多数组织的最后目标是获得一个单独的目录，但是更典型的现象是，最少存在两个目录，甚至存在更多的目录作为很常用的。对于非Domino应用流程，也是应用DominoDirectory以及针对非Domino应用流程的通用LDAP目录。通常就会有一个附加的专门针对这些特殊使用流程的LDAP目录。

WebSpherePortal依赖于上层的WebSphereApplication服务器进行认证。WebSphereApplication服务器被限制为按照单独的用户库（userrepository）进行身份认证。这意味着一切正在应用WebSpherePortal的用户必须紧邻主目录（往往是LDAP）中的一个单独实例中。

Domino的目录需求则基本不同。为了获得Domino服务器的完整系统，包含短信路由，在针对每位用户的Domino目录中才能有一个词条。在梦想的现象下，拥有现存的Domino环境的组织将应用Domino目录在WebSpherePortal中进行身份认证。然而，在现实中，DominoLDAP实现中的受限、多邮箱功能、特殊于使用的LDAP需求还有其它许多原因避免了这样情况导致这些方法行不通。

多身份

将用来WebSpherePortal和Domino的目录分开，还有在二者之间提供SSO，这种的在现实中种现实的需求直接造成了一种情况的形成，我们称这些情况为MultipleIdentitiesProblem（多身份问题）。要明白怎么配置不同部份以便解决相关的难题，明白这个难题的实质是很重要的。

我们将借助概念一个实例环境来谈论多身份问题，该环境与通常的环境所能看见的东西相似。我们的实例公司名称为YourCo。YourCo有一个主LDAP目录，在针对用户的ou下，有分布在每位城市的分企业中的用户。所以对于我们的实例雇员ElizabethSomebody，在她的LDAP记录中有下列资料，我们摘录这样的LDAP记录也是她的LDAP身份。

函数

ElizabethSomebody,ou=Boston,ou=users,dc=yourco,dc=com

esomebody

在现有的Domino环境中，Elizabeth的Person文档包含上面的值，我们将引用其他值也是她的Domino身份。

函数

FirstName

Elizabeth

LastName

Somebody

UserName

ElizabethSomebody/Boston/YourCoElizabethSomebody

ShortName

esomebody

Elizabeth用她的LDAPuid（即esomebody）登陆到WebSpherePortal中。作为身份认证过程的一部份，WebSphereApplicationServer从LDAP目录中寻找她的完整DN，并用它构建LTPAcookie。当她也是经过认证的用户访问WebSpherePorta页面时，WebSpherePortal的LotusCollaborativeComponents（LCC）从WebSpherePortal收集她的（公用名、LDAPuid和DN）。然后LCC尝试初始化与Sametime服务器的SametimeLinks连接。在构建这个链接的过程中，将公用名提供给Sametime，以便初始化Elizabeth，并为Elizabeth提供人员感知。当Elizabeth访问某个包括Notesportlet的WebSpherePortal页面时，她的DN通过HTTP传递给Domino服务器。然后Domino服务器搜索DominoDirectory以期找出DN，所以在DominoDirectory中是找不到DN的（在这儿没有应用LTPAcookie）。

表面上显而易见的解决方案是启用Domino上的DirectoryAssistance以便将LDAP服务器加入到认证路径中。当该任务完成时，对DN的搜索现在将转移到该LDAP目录，在该目录中您将发现一个匹配的项但是用户也会借助认证。问题在于Elizabeth是以上面的身份进行认证的：

 cn=Elizabeth Somebody,ou=Boston,ou=users,dc=yourco,dc=com 

而Domino不明白这和上面所指的用户是同一用户

 Elizabeth Somebody/Boston/YourCo 

Elizabeth在Domino环境中所做的每一件事都将以她的LDAP身份进行。比如，当Elizabeth发送短信时，则From字段都会包括她的LDAPDN。她将希望找出地址并发送短信，所以即使接收者回复该短信，你们将收到一个名称不在目录中错误（namenotfoundindirectoryerror），所以不存在具有DN的Domino个人文件。

当Elizabeth在Domino中创建文件时，创建者元数据将包括她的LDAPDN。如果字段按照Authors字段进行归类，所以她借助WebSpherePortal创建的文件与借助Notes客户机创建的文件相比将排在不同的位置，也不同于这些在从一个Web浏览器访问DominoApplicationDirectly时创建的文件。

因为在这些中Elizabeth的Domino身份被列在ACL中，无论是显式地列举还是借助组成员，她都将不能访问其他。这一规则对于这些具备限制的文件来说其实适用，这样限制可以是借助Reader字段施加的，也可以是借助Author字段施加的。

如果有了各种受限，我们可以不再应用DA作为对该问题的解决方案。真正才能的是用来将LDAP身份映射到Domino身份的一种方式。幸运的是DominoR5服务器提供了这样系统。

个人文件的UserName字段是一个多值函数，就能有必要，它可以包括用户名称的许多变异。作为最好的绝佳实践，Directory中每位条目应该是唯一的。当按照该函数中的一个词条找到一个匹配项时，为了接近认证目的，Domino将身份映射到该函数的第一个词条。这往往是用户名的分层版本。要借助这些系统并解决先前在Domino和DirectoryAssistance部分讨论过的难题，我们才能变化DA，然后在UserName字段的第二行以后添加用户LDAPDN（用/代替空格）。

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-118930-2.html