单点登录
1、单点登录概述
单点登录的英文名称为Single Sign-On，简写为SSO，它是一个用户认证的过程，允许用户一次性进行认证之后，就访问系统中不同的应用；而不需要访问每个应用时，都重新输入密码。IBM对SSO有一个形象的解释“单点登录、全网漫游”。
SSO将一个企业内部所有域中的用户登录和用户帐号管理集中到一起，SSO的好处显而易见：
1. 减少用户在不同系统中登录耗费的时间，减少用户登录出错的可能性
2. 实现安全的同时避免了处理和保存多套系统用户的认证信息
3. 减少了系统管理员增加、删除用户和修改用户权限的时间
4. 增加了安全性：系统管理员有了更好的方法管理用户，包括可以通过直接禁止和删除用户来取消该用户对所有系统资源的访问权限
对于内部有多种应用系统的企业来说，单点登录的效果是十分明显的。很多国际上的企业已经将单点登录作为系统设计的基本功能之一。
1.1 单点登录产品商业SSO软件
l 专门的SSO商业软件
n 主要有：Netgrity的Siteminder，已经被CA收购。Novell 公司的iChain。RSA公司的ClearTrust等。
l 门户产品供应商自己的SSO产品，
n 如：BEA的WLES，IBM 的Tivoli Access Manager，Sun 公司的identity Server，Oracle公司的OID等。
上述商业软件一般适用于客户对SSO的需求很高，并且企业内部采用Domino、SAP、Sieble等系统比较多的情况下。单点登录产品通常需要在应用软件中增加代理模块，而商业SSO产品主要针对大型软件制作了代码模块。
因此，商业SSO软件除了价格问题外，另一个重要问题就是对客户自己的应用系统支持未必十分完善。
开源SSO软件
l Opensso
n https://opensso.dev.java.net/
n OpenSSO基于Sun Java System Access Manager，是Sun公司支持的一个开源的SSO项目。
n OpenSSO体系结构设计合理，功能比较强大。然而缺点是客户端支持不够广泛，似乎只是对基于J2EE的应用支持的比较好。
l josso
n 这是另一个Java写的单点登录产品，通常认为比OpenSSO更成熟一些。
n JOSSO支持的客户端包括Java，PHP和ASP。
l CAS
n http://www.ja-sig.org/products/cas/
n 这是耶鲁大学开发的单点登录产品，也是我们最后选定的单点登录产品。
n CAS的优点很多，例如设计理念先进、体系结构合理、配置简单、客户端支持广泛、技术成熟等等。以后我们还要仔细介绍。
经过广泛分析和比较，最后我们选定CAS作为我们的单点登录产品。我们确信这是目前能够找到的最好的开源单点登录产品。
1.2 单点登录的实现机制SSO的实现机制不尽相同，大体分为Cookie机制和Session机制两大类。
WebLogic通过Session共享认证信息。Session是一种服务器端机制，当客户端访问服务器时，服务器为客户端创建一个惟一的SessionID，以使在整个交互过程中始终保持状态，而交互的信息则可由应用自行指定，因此用Session方式实现SSO，不能在多个浏览器之间实现单点登录，但却可以跨域。
WebSphere通过Cookie记录认证信息。Cookie是一种客户端机制，它存储的内容主要包括: 名字、值、过期时间、路径和域，路径与域合在一起就构成了Cookie的作用范围，因此用Cookie方式可实现SSO，但域名必须相同。
目前大部分SSO产品采用的是Cookie机制，CAS也是如此。
注意，这种机制要求实现单点登录的应用，其余名必须是相同的。例如：a.chinacreator.com,b.chinacreator.com就可以经过配置后实现SSO。
以CAS为例，使用Cookie实现单点登录的原理图如图1所示。
l 首先，单点登录分为“服务端”和“客户端”。服务端就是单点登录服务器，而客户端通常是“函数库”或者“插件”。需要使用单点登录的应用程序，需要把客户端插件安装到自己的系统中，或者将客户端函数库包括在代码中。单点登录的客户端通常替换了原来应用程序的认证部分的代码。
l 某个应用程序首先要发起第1次认证。大部分情况下，应用程序中嵌入的客户端会把应用程序原来的登录画面屏蔽掉，而直接转到单点登录服务器的登录页面。
单点登录服务器
Cookie
Web应用
单点登录客户端
Web应用
单点登录客户端
Web应用
单点登录客户端
某种授权机制
LDAP
首次登录
认证
图 1 使用Cookie实现单点登录的原理图
l 用户在单点登录服务器的登录页面中，输入用户名和密码。
l 然后单点登录服务器会对用户名和密码进行认证。认证本身并不是单点登录服务器的功能，因此，通常会引入某种认证机制。认证机制可以有很多种，例如自己写一个认证程序，或者使用一些标准的认证方法，例如LDAP或者数据库等等。在大多数情况下，会使用LDAP进行认证。这是因为LDAP在处理用户登录方面，有很多独特的优势，这在本文的后面还会比较详细地进行介绍。
l 认证通过之后，单点登录服务器会和应用程序进行一个比较复杂的交互，这通常是某种授权机制。CAS使用的是所谓的Ticket。具体这点后面还会介绍。
l 授权完成后，CAS把页面重定向，回到Web应用。Web应用此时就完成了成功的登录（当然这也是单点登录的客户端，根据返回的Ticket信息进行判断成功的）。
l 然后单点登录服务器会在客户端创建一个Cookie。注意，是在用户的客户端，而不是服务端创建一个Cookie。这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。
l 如果用户此时希望进入其他Web应用程序，则安装在这些应用程序中的单点登录客户端，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。登录之后，CAS重定向回到用户的应用程序。
这样，就不再需要用户继续输入用户名和密码，从而实现了单点登录。
注意，这种单点登录体系中，并没有通过http进行密码的传递（但是有用户名的传递），因此是十分安全的。
1.3 单点登录、统一用户和单一用户管理很多人谈论单点登录时，常常和统一用户，以及单一用户管理混淆了，要么误认为单点登录自然实现了单一用户管理；要么误认为统一用户或者单一用户管理就是单点登录。实际上，这三个概念是有明确的区别的。
统一用户就是指不同的系统，使用同一套用户处理的机制。
l 用户ID全局惟一，用户登录名，密码全局唯一，并且统一存储在单一系统中。
l 用户的一些属性，如姓名、电话、地址、邮件等，统一存储在单一系统中。尽管各应用系统还可以自行增加一些属性，但是基本的属性应该统一存储和管理。
l 应用系统不应该直接对用户信息的进行增加、修改和删除，但是可以进行查询。对用户信息的增加、修改和删除，应该由专门的系统进行统一的管理。
目前比较标准的做法，是使用LDAP服务器，对用户信息进行统一管理。
很显然，统一用户是单点登录的基础，但是统一用户并不意味着实现了单点登录。
例如，如果我们在LDAP服务器中实现了用户的统一管理。然后我们可以设置应用程序A和B都使用LDAP进行用户认证。虽然此时A和B用以认证的用户，其用户名和密码都是一样的（都是从LDAP服务器中读出的），但是对应用A进行了登录之后，应用B还需要再次输入用户名和密码。因此，统一用户并不意味着单点登录。
在图1中可以很清楚地看到，用于统一用户管理的LDAP服务器，只是单点登录系统中的一个部分，主要用于认证。
单一用户管理则指所有的用户管理工作都在唯一的地方进行处理，而每个应用程序不再保留自己的用户管理功能。单一用户管理和统一用户管理的最大区别在于，统一用户管理之后，每个应用程序仍然保留自己的用户管理功能，用于额外的属性设置；而单一用户管理时，每个应用程序不再保留自己的用户管理功能。
我们举例来进行说明，最好的例子是“组”。大家都知道，“组”通常包含若干个用户，用以方便地进行一些设置，例如权限设置等等。
在LDAP服务器上可以设置组，但是如果某个应用程序希望使用自己设定的组怎么办？只能让该应用程序保留设定组的功能。那么又带来下面的问题。
如果应用程序中的组GroupA中，例如包含了用户User1和User2。而在LDAP服务器进行统一用户管理时，把用户User1删除了，增加了User3。此时GroupA中包含了一个无效的用户，并且缺少了一个有效的用户。此时怎么办呢？
也没有什么好的办法，只能进行用户的同步。在LDAP中进行用户操作之后，有某种同步的机制，在应用程序中进行相应的修改。
再举一个例子，Zope中的用户，是具有不同的权限的。而LDAP服务器中的用户，则通常没有权限这个属性。那么，如果Zope使用LDAP作为自己的用户源，如何设定用户的属性呢？
目前的解决方法是，在Zope中复制一个LDAP中的用户，然后手工设置用户的权限。此时，由于用户被复制了，因此又带来了同步的问题。
因此，即使实现了统一用户管理，仍然可能需要在应用程序之间，设置大量的用户管理的同步操作（尽管比没有统一用户管理之前简单多了）。这样，实际上没有达到所谓的“单一用户管理”，即在统一的地方进行全部的用户管理操作。
单一用户管理和应用程序的具体处理机制关系很大，因此目前还没有统一的方法进行处理。这需要在设计应用程序，以及设计LDAP服务器时，进行仔细的设计，并有大量的代码改造工作。
2 、 LDAP 和 CAS由于LDAP是单点登录的基础，因此，本章先对LDAP做一个介绍，然后再介绍我们采用的单点登录产品CAS。
2.1 LDAP 简述LDAP是英文“Lightweight Directory Access Protocol”的简称，中文翻译为轻量级目录访问协议。它是一种因特网上的访问协议，主要用于从服务器上检索信息。
LDAP服务器用来保存信息，中文有时候也称为目录服务。既然LDAP服务器用于保存信息，那么它和普通的数据库有什么区别呢？
数据库使用“表”来储存数据，可以把一个数据库想象为日常生活中的“表格”。而LDAP用“树”来存储数据，可以把它想象为日常生活中的“电话号码簿页”，或者干脆把LDAP想象为大家常用的文件系统，就是由文件夹和文件组成的那种树形结构。
由于LDAP的结构方式不同，因此LDAP有一个很多特殊的特性，就是查询数据的速度特别快，但是写数据的速度较慢。LDAP的另一个特性就是比较适合于按照层次组织信息，例如企业的组织结构等。
由于LDAP的查询速度比数据库快，因此经常用于诸如地址簿、用户帐号存储、组织结构信息、域名解析系统等需要大量查询的领域。
2.2 LDAP 的结构图2是一个很简单的LDAP结构示意图。
首先，我们可以很清楚地看到，LDAP是按照树形目录进行组织的。
假设公司的域名是macromedia.com，则LDAP首先使用域名作为整个树的根，并且用dc=com，dc=macromedia这样的标记来进行标注。dc的意思指“Domain Component”。LDAP中以后会大量使用这些令人费解的缩写。
假设某天macromedia.com这个公司和apple.com这个公司合并，按照LDAP的树形结构，只不过多了一个分叉，而不会导致整棵树需要重新组织，这就是LDAP的好处之一。
dc节点的后面，就是ou节点。ou是Organizational Unit的缩写，可以把ou想象为文件夹，它是用来容纳其他节点的。ou可以对应部门、组或者任何要包含其他节点的东西。
ou下面的节点，可以是另一个ou，也可以是cn节点。cn是“Common Name”的缩写，它是树叶节点，可以把它对比为文件系统中的文件。cn节点通常用来存储用户的信息，例如某个用户的地址等。
这样，各个节点按照树形组织起来，就变成了图2的样子。
图 2 LDAP结构示意图
2.3 权限和纲要和数据库一样，LDAP可以设置权限，例如允许某些用户可以访问某些特定的树枝。权限的概念大家都很熟悉，这里就不再叙述了。
LDAP的纲要（Schema）用来描述保存在服务器中的数据的格式和属性。例如，我们希望在某个cn节点中保存用户的地址簿，那么到底地址簿中包含哪些信息呢？如何指定地址簿中只包含了工作电话，还是同时包含工作电话和家庭电话？
此时就需要使用schema。我们以一个例子进行说明。
#
# mozillaOrgPerson schema v. 0.6.3
#
# req. core
# req. cosine
# req. inetorgperson
# attribute defs
attributetype ( 1.3.6.1.4.1.13769.2.1.5
NAME 'mozillaPostalAddress2'
EQUALITY caseIgnoreListMatch
SUBSTR caseIgnoreListSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
attributetype ( 1.3.6.1.4.1.13769.2.1.6
NAME 'mozillaHomePostalAddress2'
EQUALITY caseIgnoreListMatch
SUBSTR caseIgnoreListSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
attributetype ( 1.3.6.1.4.1.13769.2.1.10
NAME ( 'mozillaHomeFriendlyCountryName' )
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# defined in "A Summary of the X.500(96) User Schema for use with LDAPv3" - RFC 2256
#
# attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' )
# DESC 'RFC2256: ISO-3166 country 2-letter code'
# SUP name SINGLE-VALUE )
# defined in "The COSINE and Internet X.500 Schema" - RFC 1274
#
# attributetype ( 0.9.2342.19200300.100.1.43
# NAME ( 'co' 'friendlyCountryName' )
# DESC 'RFC1274: friendly country name'
# EQUALITY caseIgnoreMatch
# SUBSTR caseIgnoreSubstringsMatch
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# objectClass defs
objectclass ( 1.3.6.1.4.1.13769.2.2.1
NAME 'mozillaOrgPerson'
SUP top
AUXILIARY
MAY (
sn $
givenName $
cn $
displayName $
mozillaNickname $
title $
telephoneNumber $
facsimileTelephoneNumber $
mobile $
pager $
homePhone $
street $
postalCode $
mozillaPostalAddress2 $
mozillaHomeStreet $
mozillaHomePostalAddress2 $
l $
mozillaHomeLocalityName $
st $
mozillaHomeState $
mozillaHomePostalCode $
c $
mozillaHomeCountryName $
co $
mozillaHomeFriendlyCountryName $
ou $
o $
mail $
mozillaSecondEmail $
mozillaUseHtmlMail $
nsAIMid $
mozillaHomeUrl $
mozillaWorkUrl $
description $
mozillaCustom1 $
mozillaCustom2 $
mozillaCustom3 $
mozillaCustom4 ) )
上面的例子是Mozill地址本的schema。attributetype用来定义一个属性的名称、类型、限制条件等。objectclass则用来定义节点包含了哪些属性，每个属性的名称是什么。
objectclass类似于数据库中，定义表的字段。
LDAP中的节点，可以是任何一种objectclass，例如，同一个ou下面的节点A，可能是objectclassA，而节点B，可能是objectclassB。这就类似于文件系统中，一个文件夹下面可以有多种不同的文件。
LDAP的节点，允许指定多种不同的objectclass。例如，如果我们希望用户地址本中，同时还包含用户的登录密码。一种方法是我们重新创建一个objectclass，另一种方法就是我们同时指定节点，具有地址簿信息的inetOrgPerson，以及密码信息的simpleSecurity。实际上，通过组合不同的objectclass来实现自己想要的节点类型，用得更普遍一些。
2.4 LDIFLDIF是一种文件格式，它用来导入和导出LDAP中的数据，类似于数据库中的SQL。
新建了一个LDAP服务器之后，如何向其中输入数据呢？答案就是使用LDIF。尽管有些图形化界面的工作，可以直接通过图形界面操作LDAP服务器，然而一些初始化的数据，通常还是通过LDIF文件输入。
LDIF是纯文本的文件格式，一个例子如下：
dn: ou=shichangtuozhanbu,ou=Leader,dc=anystep,dc=com
ou: shichangtuozhanbu
objectClass: organizationalUnit
objectClass: top
description:: 5biC5Zy65ouT5bGV6YOo
dn: ou=dakehubu,ou=Leader,dc=anystep,dc=com
objectClass: top
objectClass: organizationalUnit
ou: dakehubu
description:: 5aSn5a6i5oi36YOoAE3jnKjCow==
dn: cn=user,ou=xitongshi,ou=ITzhichengbu,ou=Leader,dc=anystep,dc=com
sn:: 6JSh6Z+1
cn: user
mail: [email protected]
telephoneNumber: 81889012
objectClass: inetOrgPerson
objectClass: top
objectClass: simpleSecurityObject
userPassword: {MD5}4QrcOUm6Wau+VuBX8g+IPg==
uid: 4540
我们先看第1部分，蓝色文字标出的区域。
首先需要说明的，是“dn”。dn是Distinguished Name的缩写，可以简单地将其想象为LDAP上某个节点的路径，只不过路径的写法刚好和文件路径的写法相反，dn是根节点在最后，各个分支节点依次向前排列。例如
dn: ou=shichangtuozhanbu,ou=Leader,dc=anystep,dc=com
表明当前节点是dc=com -> dc=anystep -> ou=Leader -> ou= shichangtuozhanbu。
下一行ou: shichangtuozhanbu表明当前节点是一个ou类型的容器，名字是shichangtuozhanbu。
后面指明当前节点的objectclass，有多个objectclass，这里就会都列出来。
description是节点的描述名称，这里的一长串字符，实际上对应的是中文字。
绿色文字标出的，是一个地址簿节点。sn是名，也是中文。后面是一些电子邮件、电话之类的信息。
LDIF对于批量化地创建或者导入LDAP数据，是非常有用的。
2.5 LDAP 相关软件LDAP的服务器软件很多，除了商业软件之外，比较常用的是开源的OpenLDAP。
完全使用LDIF文件来生成LDAP数据，除了使用软件之外，手工操作会显得比较麻烦。因此，也出现了很多图形界面客户端。
一个比较好的LDAP客户端是phpldapadmin，这是一个PHP编写的LDAP客户端，基本上具备了所有常用的功能，缺点就是执行比较慢，操作有点麻烦。
phpldapadmin的一个屏幕截图如图3所示。
图 3 phpldapadmin的一个屏幕截图
2.6 CAS 基本情况CAS单点登录系统最早由耶鲁大学开发。2004年12月，CAS成为JA-SIG中的一个项目。JA-SIG的全称是Java Architectures Special Interest Group，是在高校中推广和探讨基于Java的开源技术的一个组织。
CAS的服务端是使用Java写的，基于Tomcat5来运行。
CAS的客户端很多，包括：
l Apache客户端AuthCAS
n 如果用户的认证是通过Apache来实现的，那么使用这个客户端就能够实现单点登录。有些网页邮件系统是通过Apache来实现认证的。
l uPortal客户端
n uPortal是Java写的一个门户系统。
l Java客户端
n CAS本身是使用Java写的，因此对Java客户端的支持也最完善。
l Acegi客户端
n Acegi是Spring Framework的安全机制，而Spring Framework是一个应用较广的J2EE应用程序框架。
l .NET C# 客户端CASP
n 这是一个使用C#写的CAS客户端，用于.NET程序的单点登录。
l ASP.NET的例子
n ASP.NET没有专门的客户端，但是有一个例子来说明如何在ASP.NET中使用CAS。这个例子直接校验CAS的ticket，而不是校验用户名和密码。
l Perl 客户端PerlCAS
n Perl语言的客户端
l PHP客户端phpCAS
n 这个不用说了，让PHP支持CAS的客户端，用得很广泛。
l Zope客户端ACASUserFolder
n 让Zope和Plone系统支持CAS的客户端，也用得很广泛。
l Prado、Ruby、Seraph、WebObjects等客户端。
n 这些国内用得比较少，就不一一描述了。
CAS还有一个列表，列出了经过CAS认证的应用程序，包括：
CASifying Oracle Applications ESUP-Portail CASified ApplicationsESUP-Portail has CASified and re-distributes many open source applications:
CASifying Misc. Applications
- Sakai
- PeopleSoft
- Tomcat Manager
- Apache Pluto Poral Driver
- Outlook Web Access
- WebCalendar
- Magnolia CMS
这个列表中没有包含SAP、Lotus Domino、WebSphere、Weblogic等常用的商业系统，这可能就是CAS和商业单点登录产品相比最大的弱项了吧。
2.7 CAS 原理简介CAS被设计为一个独立的Web应用，目前是通过若干个Java servlets来实现的。CAS必须运行在支持SSL的web服务器至上。应用程序可以通过三个URL路径来使用CAS，分别是登录URL（login URL），校验URL（validation URL）和登出URL（logout URL）。
CAS的工作原理如图4所示。
图 4 CAS的工作原理
l 应用程序一开始，通常跳过原来的登陆界面，而直接转向CAS自带的登录界面。当然也可以在应用程序的主界面上增加一个登录之类的按钮，来完成跳转工作。
n 如果用户喜欢的话，也可以手工直接进入CAS的登录界面，先进行登录，在启动其他的应用程序。不过这种模式主要用于测试环境。
l CAS的登录界面处理所谓的“主体认证”。它要求用户输入用户名和密码，就像普通的登录界面一样，如图5所示。
图 5 CAS的登录界面
l 主体认证时，CAS获取用户名和密码，然后通过某种认证机制进行认证。通常认证机制是LDAP。
l 为了进行以后的单点登录，CAS向浏览器送回一个所谓的“内存cookie”。这种cookie并不是真的保存在内存中，而只是浏览器一关闭，cookie就自动过期。这个cookie称为“ticket-granting cookie”，用来表明用户已经成功地登录。
l 认证成功后，CAS服务器创建一个很长的、随机生成的字符串，称为“Ticket”。随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。这个ticket是一次性使用的一种凭证，它只对登录成功的用户及其服务使用一次。使用过以后立刻失效。
l 主体认证完成后，CAS将用户的浏览器重定向，回到原来的应用。CAS客户端，在从应用转向CAS的时候，同时也会记录原始的URL，因此CAS知道谁在调用自己。CAS重定向的时候，将ticket作为一个参数传递回去。
n 例如原始应用的网址是http://www.yale.edu/tp，在这个网址上，一开始有如下语句，转向CAS服务器的单点登录页面https://secure.its.yale.edu/cas/login?service=http://www.yale.edu/tp/auth.jsp。
n CAS完成主体认证后，会使用下面URL进行重定向http://www.yale.edu/tp/authenticate.jsp?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。
l 收到ticket之后，应用程序需要验证ticket。这是通过将ticket 传递给一个校验URL来实现的。校验URL也是CAS服务器提供的。
l CAS通过校验路径获得了ticket之后，通过内部的数据库对其进行判断。如果判断是有效性，则返回一个NetID给应用程序。
l 随后CAS将ticket作废，并且在客户端留下一个cookie。
l 以后其他应用程序就使用这个cookie进行认证（当然通过CAS的客户端），而不再需要输入用户名和密码。
2.8 选择 CAS 的理由经过对开源SSO软件进行全面考察之后，我们认为CAS是目前最好的选择：
l 完全开放的、有完整文档的协议
l 开源软件，代码尽在掌握
l 有着对Java，.Net，PHP，Zope，Apache等多种客户端的成熟支持
l 并且有良好的社区支持，和不断升级的版本
l 大量的实际部署，成熟可靠
不过同时也应该看到，CAS目前还不支持SAP、Lotus Domino、WebSphere、Weblogic等常用的商业系统，因此如果希望对上述系统进行单点登录，那么只能选择商业软件了。
3 、单点登录系统安装尽管CAS已经算比较容易安装和调试的了，然而将整个单点登录系统完全安装并运行起来，仍然是一个复杂的工作。以笔者为例，尽管非常熟悉Linux系统，仍然花了整整12天才全部调通。
下面的安装步骤尽可能详细，但如果您仍然无法安装成功，或者根本没有兴趣执行这些繁琐的操作，那么请直接下载虚拟机使用。虚拟机上所有的软件都处于“Ready”状态，而且下载尺寸比Linux服务器更小。
3.1 安装 Linux 服务器我们选择SuSE Enterprise Server 10作为基本的Linux服务器。为什么选择这个服务器？理由如下：
l 目前国际通行的高品质Linux服务器，实际上只有Novell公司的SLES（SuSE Enterprise Server）和RedHat公司的RHEL（RedHat Enterprise Linux）。
l SLES 10包含的各种软件包版本比RHEL 4.3新。例如PHP5、Tomcat5等，在SLES中都是默认的，而在RHEL中需要自己去配。
l SLES的图形界面非常值得称道，笔者认为用起来更简单，很有一些像Windows服务器那样易于使用的感觉，如图6所示。
图 6 SLES 10及其Yast管理界面
SLES可以从Novell公司的网站上下载，网址为http://www.novell.com/products/server/eval.html。下载时需要先填写一个注册表单。
下载的版本虽然是60天试用版，然而这个60天试用的意思是试用SLES的在线升级和技术支持服务，并不是说SLES服务器只能用60天。SLES产品本身是基于GPL的，可以免费下载和持续使用。
当然，对于商业公司，也许购买服务更合适一些，毕竟在线升级对于系统的安全和保持最新状态还是很有意义的。
另一个国内的下载站点是http://download.chinaunix.net/download/0013000/12357.shtml。至少在写本文的时候，这个站点是有效的，并且其下载速度是非常快的。
下载了之后，就可以进行安装了。这里要特别说明的是，除非您熟悉Linux，否则不要轻易尝试Linux系统的直接安装。特别是如果您希望在Windows机器上的某个分区上安装Linux，那么就要特别小心了，各种误操作很容易把硬盘上的数据毁掉。所以对于不太熟悉的用户，我们高度推荐您使用虚拟机而不是直接安装Linux系统。
如果您是Linux高手，那么按照提示安装SLES 10，应该不会有难于理解的地方。如果您的硬盘空间足够的话，最好把所有的包都装进去，这样省得以后缺这个、少那个的。如果您按照本文进行操作，而有些莫名其妙的错误的话，最大的可能就是缺少了某个软件包。
在安装中，您需要输入您的IP地址。这里假设服务器的IP地址是192.168.1.6（当然您可以按照您的喜好设置成任何IP地址）。
安装完成后，就要开始检查软件包，并进行一些基本的配置。
首先在开始菜单中，单击Yast，进入管理界面。SLES的管理软件称为Yast，这是一个非常好用的图形界面管理软件。
单击“软件”>“软件管理”，进入软件包管理界面，如图7所示。
图 7 软件管理
搜索PHP，此时会列出所有PHP的扩展软件包。特别检查一下php5-ldap是否安装进去了，这个软件包是使用LDAP必不可少的。推荐将所有的扩展都安装进去，例如php5-mysql之类，这样避免以后的麻烦。
随后，再检查一下tomcat5是否安装了，如果没有安装，则安装它。如果您很熟悉tomcat5的话，可以只安装基本的包，否则可以同时安装管理包和例子包。
软件包安装完成后，在Yast中，单击“网络服务”>“http服务器”，修改Apache2的配置，如图8所示。将Apache2服务的端口号修改为8091。这一步并不是必须的操作，只不过在我们的系统中提供Web服务的程序比较多。为了方便管理，将apache2服务设定为8091端口。在实际的应用系统中，您仍然可以根据需要，设定80等端口。
下面设置服务的运行级别，这样使得系统启动时，服务自动启动，而不再需要一个一个地手工启动。进入“系统”>“系统服务（运行级别）”，在弹出的窗口中，选择“专家方式”如图9所示。
选择apache2服务，然后在窗口的底部，选中“3”和“5”。这个意思是在Linux的启动模式3（字符界面启动）和启动模式5（图形界面启动）中，默认启动apache2服务。
同样的方法，设置tomcat5和ldap服务。
图 8 修改apache2配置
图 9 设置服务的运行级别
重新启动Linux系统。在浏览器中输入http://192.168.1.6:8091，此时应该出现“It works”字样，表明apache2服务正常工作了。
此时还不用测试tomcat5和ldap服务器，因为后面还要对它们进行配置。
3.2 LDAP 服务器SLES中，默认安装的是OpenLDAP，这是一个开放源代码的LDAP服务器。
配置LDAP服务器的第1步，是修改slapd.conf配置文件。通常在默认的slapd.conf的基础上进行修改。
打开/etc/openldap/slapd.conf文件，进行编辑，结果如下：
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/yast.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
# Load dynamic backend modules:
modulepath /usr/lib/openldap/modules
# moduleload back_ldap.la
# moduleload back_meta.la
# moduleload back_monitor.la
# moduleload back_perl.la
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access to user password
# Allow anonymous users to authenticate
# Allow read access to everything else
# Directives needed to implement policy:
access to dn.base=""
by * read
access to dn.base="cn=Subschema"
by * read
access to attrs=userPassword,userPKCS12
by self write
by * auth
access to attrs=shadowLastChange
by self write
by * read
access to *
by * read
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# BDB database definitions
#######################################################################
loglevel 0
TLSCertificateFile /etc/ssl/servercerts/servercert.pem
TLSCACertificatePath /etc/ssl/certs/
TLSCertificateKeyFile /etc/ssl/servercerts/serverkey.pem
database bdb
suffix "dc=anystep,dc=com"
rootdn "cn=Manager,dc=anystep,dc=com"
#rootpw secret
rootpw {SSHA}64Zasvn23ICx14ql4Y8vdghly3ovK7zQ
directory /var/lib/ldap
checkpoint 1024 5
cachesize 10000
index objectClass,uidNumber,gidNumber eq
index member,mail eq,pres
index cn,displayname,uid,sn,givenname sub,eq,pres
在上面的slapd.conf文件中。只有蓝色的文字，是我们修改的，其他地方保持默认值即可。
l suffix "dc=anystep,dc=com"
n 这是用来指定LDAP所属的域，应该换成您自己单位的域名。例如，您的域名是my.org则这里应该写为suffix “dc=my,dc=org”。
l rootdn "cn=Manager,dc=anystep,dc=com"
n 这是指定LDAP的根。除了域名要换成您自己的域名之外，Manage也可以改成您自己喜欢的某个根用户名称，例如root，admin之类。
l rootpw {SSHA}64Zasvn23ICx14ql4Y8vdghly3ovK7zQ
n 这是指定LDAP根的密码。这个密码是采用SSHA编码的，其实际的值是“secret”，以后要求您输入LDAP的密码时，就输入“secret”。
n 当然您可以换成您自己喜欢的密码，只不过要自己去生成SSHA的编码。LDAP也接受md5等其他格式的加密方式。
然后，您还需要自己创建一个LDIF文件，例如可以将它放在root下，名字为base.ldif。
dn: dc=anystep, dc=com
objectClass: top
objectClass: domain
domainComponent: anystep
dn: cn=Manager, dc=anystep, dc=com
objectClass: top
objectClass: organizationalRole
cn: Manager
dn: o=hosting, dc=anystep, dc=com
objectClass: top
objectClass: organization
o: hosting
dn: ou=postfix, dc=anystep, dc=com
objectclass: top
objectclass: organizationalUnit
ou: postfix
dn: ou=PloneGroup, dc=anystep, dc=com
objectclass: top
objectclass: organizationalUnit
ou: PloneGroup
dn: ou=Leader, dc=anystep, dc=com
objectclass: organizationalUnit
objectclass: top
ou: Leader
这里的LDIF只包含到第1级的组织名称。其他的我们可以用图形界面来生成。同样，您可以根据自己的需要，修改域名和组织名称。
然后在Linux终端执行下面语句：
service ldap restart
ldapadd -x -D "cn=Manager,dc=anystep,dc=com" -W -f base.ldif
这样首先重新启动LDAP服务，然后将base.ldif文件添加到LDAP中，对其进行初始化。
然后对LDAP服务器进行测试，看看其是否运行正常。首先测试LDAP的389端口，是否处于监听状态。输入语句：
netstat -an | grep 389
正确的结果应该类似：
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN
tcp 0 0 :::389 :::* LISTEN
然后测试LDAP的搜索功能。
ldapsearch -x -b ' ou=Leader, dc=anystep, dc=com'
正确的话，应该列出搜索的结果：
# extended LDIF
#
# LDAPv3
# base < ou=Leader, dc=anystep, dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 32 No such object
matchedDN: dc=anystep,dc=com
# numResponses: 1
LDAP测试正确后，就可以开始安装图形界面的管理工具。当然，您也可以不用这个管理工具，而直接使用LDIF文件导入数据。
首先从http://phpldapadmin.sourceforge.net/中下载软件。然后将其解压缩到/srv/www/htdocs路径下，这个路径是apache2的应用路径。如果您觉得文件phpldapadmin后面的版本号碍事的话，可以修改文件夹的名字，去掉版本号。
然后进入/srv/www/htdocs/phpldapadmin/config，将config.php.example复制为config.php，然后打开config.php文件，对配置进行修改。
config.php将需要的配置都注释起来，如果用户想修改，就去掉注释，并进行修改。我们一共修改了如下语句。
$ldapservers->SetValue($i,'server','name','NewChoice LDAP Server');
$ldapservers->SetValue($i,'server','host','192.168.1.6');
$ldapservers->SetValue($i,'server','base',array('ou=Leader, dc=anystep, dc=com'));
$ldapservers->SetValue($i,'server','auth_type','cookie');
第1句用来对这个LDAP服务器起一个名字，名字是什么无所谓，喜欢就好。
第2句用来指定服务器的地址。
第3句用来指定希望操作的分枝的路径。例如，我们只希望在ou=Leader这个分支下面，增加或者修改我们的LDAP节点，就指定这个分支。指定分支之后，该分支以外的其他分支，在图形界面中是不出现的。
第4句设置使用cookie登录。
修改完配置文件后，在浏览器中输入http://192.168.1.6:8091/phpldapadmin，此时应该出现如图10所示的界面。
图 10 phpldapadmin的登录界面
单击“Login…”，进入登录画面。输入用户名为cn=Manager,dc=anystep,dc=com，密码为secret，单击Authenticate按钮，就进入了LDAP服务器。
图 11 phpldapadmin的登录界面
界面的左边，是按照树形结构列出的LDAP的内容。单击一个节点，在右边列出其值。这个可以增加、修改属性，或者删除节点等。
在左边单击“Create new entry here”，可以增加一个新的节点。此时右边的窗口会显示出很多预设的节点类型，选择您希望添加的节点类型，按照提示进行操作即可。
phpldapadmin的详细使用方法超出了本文的范围，反正这个软件也不复杂，您自己尝试一下，很快就能掌握。
注意必须创建admin或者root这样的用户，很多单点登录的应用程序必须使用这样的用户进行管理员账户的登录。
然后至少您还需要创建一些用于测试（或者实际使用）的账户。其LDIF的例子如下：
dn: cn=user,ou=xitongshi,ou=ITzhichengbu,ou=Leader,dc=anystep,dc=com
sn:: 6JSh6Z+1
cn: user
mail: [email protected]
telephoneNumber: 81570112
objectClass: inetOrgPerson
objectClass: top
objectClass: simpleSecurityObject
userPassword: {MD5}4QrcOUm6Wau+VuBX8g+IPg==
uid: 4540
注意，其至少有两个objectClass，一个是inetOrgPerson，这是标准的地址簿类型，另一个是simpleSecurityObject，这是标准的用户密码类型。
3.3 安装 SSL 和 TomcatCAS需要SSL（安全套接字层）才能正常工作。SSL是一套提供身份验证、保密性和数据完整性的加密技术，最常用来在Web浏览器和Web服务器之间建立安全通信通道。
为支持SSL通信，必须为Web服务器配置 SSL 证书。SSL证书最好由专业的CA机构颁发。http://www.microsoft.com/china/technet/security/guidance/secmod30.mspx上有一篇很好的文档，介绍如何申请证书。
不过如果只是自己使用的话，也可以自己生成一个证书。
在Linux的终端中，输入：
rm .keystore
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA -validity 365
第1步操作用于删除原来的SSL文件（如果有的话）。第2步操作用于生成一个新的证书，最后的365代表证书有效的时间。
输入第2步的指令后，会提示很多问题：
l 首先要求输入密码，目前密码是changeit，这是SSL证书默认的密码。
l 随后要求输入“公用名”。注意这个参数是很重要的，公用名应该和您的服务器网站的名称一致。对于内部网络，可以使用IP地址。例如我们就使用192.168.1.6。
l 随后要求输入证书的“组织单位”和“组织”，这个输入您的公司名称或者其他什么的，都可以。
l 随后输入“城市”、“省”、“国家”。国家输入的是代码，中国是cn。
l 最后列出您输入的信息，并要求确认。输入“y”。
n 例如我们输入的信息是：CN=192.168.1.6, OU=newchoice, O=newchoice, L=Beijing, ST=Beijing, C=cn correct?
l 最后输入回车，确认密码。
这样就创建了一个证书。此时，在/root下面，生成一个.keystore文件，这个文件就是证书文件。
然后执行命令：
cp .keystore /usr/share/tomcat5/
这一步将.keystore文件复制到/usr/share/tomcat5/下面。注意，这一步非常重要，否则不成功。因为tomcat5默认指定的是这个位置下的证书文件，而如何指定路径则需要进一步尝试。为了简单起见，将文件复制过去。
如果您希望将证书导出为文件，可以执行下面的操作：
$JAVA_HOME/bin/keytool -export -alias tomcat -keypass changeit -file server.crt
最后一个参数是文件名。
完成了证书创建之后，还需要修改tomcat的配置。
编辑/srv/www/tomcat5/base/conf中的server.xml文件，将
<Connector port="8443"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" debug="0" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
这个语句前后的注释去掉，这样就设置了tomcat支持SSL连接。另外，还需要将
<Connector port="8082"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />
这个语句中的端口号由原来的8080修改为8082。因为我们后面的Plone系统默认会使用8080端口号，为了避免冲突，因此需要修改tomcat的端口号。
修改完成后，输入下面的命令，重新启动tomcat服务：
Service tomcat5 restart
在浏览器中输入https://192.168.1.6:8443就可以通过SSL访问tomcat了。如果是IE的话，首先会弹出一个对话框，提示你证书不是由信任的机构颁发的。这个是很自然的，因为证书是自己生成的。
单击“查看证书”，单击“安装证书”，在向导种选择“将所有的证书放在下面存储区”，然后单击“浏览”，选择“受信任的根证书颁发机构”。单击确定安装证书。这样IE以后就会认为证书是由受信任的机构颁发的。
如果不想安装，也可以直接在对话框中单击“是”。之后应该出现tomcat的主页，如图12所示。
出现这个主页，就表明tomcat运行正常，并且已经支持SSL了。
图 12 tomcat的主页
3.4 CAS 安装首先，访问http://www.ja-sig.org/products/cas/downloads/index.html下载CAS的最新版本。目前我们使用的版本是cas-server-3.0.5.tar.gz。
在root终端下，输入：
tar –zvxf cas-server-3.0.5.tar.gz
这样解开压缩包。进入cas-server-3.0.5/webapp/WEB-INF文件夹，编辑deployerConfigContext.xml文件。这个文件是用来配置CAS的认证方式的，默认的方式是CAS自己写的演示代码，我们需要将其修改为使用LDAP认证。
这个文件修改如下：
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<!--
| deployerConfigContext.xml centralizes into one file some of the declarative configuration that
| all CAS deployers will need to modify.
|
| This file declares some of the Spring-managed JavaBeans that make up a CAS deployment.
| The beans declared in this file are instantiated at context initialization time by the Spring
| ContextLoaderListener declared in web.xml. It finds this file because this
| file is among those declared in the context parameter "contextConfigLocation".
|
| By far the most common change you will need to make in this file is to change the last bean
| declaration to replace the default SimpleTestUsernamePasswordAuthenticationHandler with
| one implementing your approach for authenticating usernames and passwords.
+-->
<beans>
<!--
| This bean declares our AuthenticationManager. The CentralAuthenticationService service bean
| declared in applicationContext.xml picks up this AuthenticationManager by reference to its id,
| "authenticationManager". Most deployers will be able to use the default AuthenticationManager
| implementation and so do not need to change the class of this bean. We include the whole
| AuthenticationManager here in the userConfigContext.xml so that you can see the things you will
| need to change in context.
+-->
<bean id="authenticationManager"
class="org.jasig.cas.authentication.AuthenticationManagerImpl">
<!--
| This is the List of CredentialToPrincipalResolvers that identify what Principal is trying to authenticate.
| The AuthenticationManagerImpl considers them in order, finding a CredentialToPrincipalResolver which
| supports the presented credentials.
|
| AuthenticationManagerImpl uses these resolvers for two purposes. First, it uses them to identify the Principal
| attempting to authenticate to CAS /login . In the default configuration, it is the DefaultCredentialsToPrincipalResolver
| that fills this role. If you are using some other kind of credentials than UsernamePasswordCredentials, you will need to replace
| DefaultCredentialsToPrincipalResolver with a CredentialsToPrincipalResolver that supports the credentials you are
| using.
|
| Second, AuthenticationManagerImpl uses these resolvers to identify a service requesting a proxy granting ticket.
| In the default configuration, it is the HttpBasedServiceCredentialsToPrincipalResolver that serves this purpose.
| You will need to change this list if you are identifying services by something more or other than their callback URL.
+-->
<property name="credentialsToPrincipalResolvers">
<list>
<!--
| UsernamePasswordCredentialsToPrincipalResolver supports the UsernamePasswordCredentials that we use for /login
| by default and produces SimplePrincipal instances conveying the username from the credentials.
|
| If you've changed your LoginFormAction to use credentials other than UsernamePasswordCredentials then you will also
| need to change this bean declaration (or add additional declarations) to declare a CredentialsToPrincipalResolver that supports the
| Credentials you are using.
+-->
<bean
class="org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver" />
<!--
| HttpBasedServiceCredentialsToPrincipalResolver supports HttpBasedCredentials. It supports the CAS 2.0 approach of
| authenticating services by SSL callback, extracting the callback URL from the Credentials and representing it as a
| SimpleService identified by that callback URL.
|
| If you are representing services by something more or other than an HTTPS URL whereat they are able to
| receive a proxy callback, you will need to change this bean declaration (or add additional declarations).
+-->
<bean
class="org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver" />
</list>
</property>
<!--
| Whereas CredentialsToPrincipalResolvers identify who it is some Credentials might authenticate,
| AuthenticationHandlers actually authenticate credentials. Here we declare the AuthenticationHandlers that
| authenticate the Principals that the CredentialsToPrincipalResolvers identified. CAS will try these handlers in turn
| until it finds one that both supports the Credentials presented and succeeds in authenticating.
+-->
<property name="authenticationHandlers">
<list>
<!--
| This is the authentication handler that authenticates services by means of callback via SSL, thereby validating
| a server side SSL certificate.
+-->
<bean
class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler" />
<!--
| This is the authentication handler declaration that every CAS deployer will need to change before deploying CAS
| into production. The default SimpleTestUsernamePasswordAuthenticationHandler authenticates UsernamePasswordCredentials
| where the username equals the password. You will need to replace this with an AuthenticationHandler that implements your
| local authentication strategy. You might accomplish this by coding a new such handler and declaring
| edu.someschool.its.cas.MySpecialHandler here, or you might use one of the handlers provided in the adaptors modules.
+-->
<!--<bean
class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" />-->
<bean
class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler">
<property name="filter" value="cn=%u" />
<property name="searchBase" value="ou=Leader,dc=anystep,dc=com" />
<property
name="contextSource"
ref="contextSource" />
</bean>
</list>
</property>
</bean>
<bean id="contextSource" class="org.jasig.cas.adaptors.ldap.util.AuthenticatedLdapContextSource">
<property name="authenticatedReadOnly" value="true" />
<property name="password" value="secret" />
<property name="pooled" value="true" />
<property name="urls">
<list>
<value>ldap://192.168.1.6:389/</value>
</list>
</property>
<property name="userName" value="cn=Manager, dc=anystep, dc=com" />
<property name="baseEnvironmentProperties">
<map>
<entry>
<key><value>java.naming.security.authentication</value></key>
<value>simple</value>
</entry>
</map>
</property>
</bean>
</beans>
蓝色的文字是您应该根据自己的LDAP设置进行修改的。至于这个文件具体每个部分为什么这么写，您可以在CAS的网站上自己研究。
然后在终端中执行命令：
cd cas-server-3.0.5/ localPlugins
rm build -rf
rm target/ -rf
ant war
cp target/cas.war /srv/www/tomcat5/base/webapps/
service tomcat5 restart
上述命令的作用，就是修改了配置文件后，对CAS重新打包。并且把打包之后的cas.war文件复制到tomcat的web应用文件夹下。
这里还需要说明一点，如果您觉得CAS的默认登录页面不满足需要，可以修改其登录页面的样式。这主要是修改cas-server-3.0.5/webapp/WEB-INF/view/jsp/default/ui中的jsp文件，以及/cas-server-3.0.5/webapp/css中的样式表文件。
修改完成后，还是执行上面的操作进行打包。
在浏览器中，输入https://192.168.1.6:8443/cas/login，进入CAS的登录画面，如图5所示。注意这个登录画面是重新定制过的，并不是原始的CAS登录画面。
输入用户名和密码，例如user:123456。这里的用户名和密码，就是在3.2节LDAP中输入的用户名和密码。
单击“登录”按钮，此时应该提示“登录成功”。这就表明CAS安装成功了。
3.5 安装 Zope 和 Plone单点登录系统本身安装成功之后，下一步就是要安装各种应用。这里我们安装一个基于Zope的门户系统Plone，以及一个基于PHP的论坛系统phpBB2。
注意，在实际使用中，单点登录服务器最好和应用服务器分开。不过在测试的时候，也可以安装在同一个服务器中。
在下面的网址http://prdownloads.sourceforge.net/plone/Plone-2.1.2-SUSE_10.0_bundle.tar.bz2?download中，下载Plone的2.1.2版本。
虽然有更新的版本，但是新版本各种插件还不完善，因此笔者还是喜欢使用旧的2.1.2版本，功能够用并且很稳定。
下载完成后，解开压缩包，把其中的rpm包都安装进去。
下面有一个很奇怪但是非要不可的步骤。
在Yast的软件包管理中，按照类似于图7的方法，安装python-ldap包。安装完成后，将/usr/lib/python2.4中的site-packages文件夹，复制到/opt/python23/lib/python之中。重新启动zope，此时才能正常使用LDAP功能。
还需要按照类似图9的方法，设置zope服务在开机时自动启动。
在Linux终端下，执行：
zpasswd
按照提示，输入一个用户名和密码。这个用户名和密码是紧急用户的用户名和密码，通常用于在出现意外之后，管理系统。平常时候这个用户用不上。
在终端中输入
service zope restart
重新启动zope服务器。
在浏览器中输入http://192.168.1.6:8080/manage，在弹出的对话框中输入紧急用户的用户名和密码，即可进入Zope的管理界面，如图13所示，这就表明Zope安装成功。
图 13 Zope的管理界面
3.6 安装 phpBB2phpBB是目前全球使用最广的论坛系统，当然它也是一个开源的软件。目前其版本是phpBB2，而新的版本phpBB3已经出了测试版。考虑到系统的稳定性，这里我们还使用phpBB2。
在http://www.phpbb.com/downloads.php下载phpBB 2.0.21。将其解压缩到/srv/www/htdocs之中。
在安装phpBB之前，首先要对MySQL数据库进行配置，因为phpBB将其信息保存在数据库中。
在Linux终端中，输入：
mysqladmin create bbs
mysql
这样首先创建名为bbs的数据库，然后进入mysql数据库。随后在mysql提示符下面，输入：
GRANT ALL PRIVILEGES ON *.* TO [email protected] IDENTIFIED BY '123456' WITH GRANT OPTION;
在浏览器中输入http://192.168.1.6:8091/phpBB2/进入phpBB的安装界面。一个可参考的参数设置如图14所示。
图 14 phpBB的安装参数
按照提示进行安装，安装完成后，回到Linux终端中，在/srv/www/htdocs/phpBB2中，删除install文件夹，否则无法进入运行界面。
在浏览器中，再次输入http://192.168.1.6:8091/phpBB2/，此时应该进入phpBB2的浏览界面。单击顶部的login按钮，使用图14中设置的用户名和密码登录。登录之后，单击底部的“Go to Administration Panel”，可以进入管理面板。
3.7 其他 CAS 客户端其他客户端的安装大同小异，只要根据系统的授权机制，按照CAS网站上的说明进行安装和改造即可。
4 、单点登录系统配置第3章，将单点登录需要的系统都安装进去了，并且每个系统都进行了测试，确保其正常运行。本章则对应用程序进行配置，使得其能够完成单点登录操作。注意如果某个系统不能正常工作，最好不要继续本章的操作，否则一定不能成功。
4.1 配置 Plone 支持 CASZope/Plone对CAS的支持，是通过一个Zope的插件ACASUserFolder实现的。可以在http://www.zope.org/Members/mrlex/ACUF/index_html/ACASUserFolder/swpackage_releases下载这个插件。
下载了插件之后，将其复制到/var/opt/zope/default/Products文件夹下，然后输入命令：
tar-zvxf ACASUserFolder-2.0.2.tar.gz
将其解压缩。解压缩后，重新启动zope服务。
进入图13所示的管理界面，单击“acl_users (User Folder)”，进入用户管理界面，单击“add”按钮，添加一个用户。在随后的页面中，输入用户名和密码，例如creator:123456，注意在Roles列表中，选择“Manager”，然后单击Add按钮。这样又添加一个管理员帐户。（因为紧急用户不能用于系统操作，所以需要额外添加一个管理员帐户）
关闭浏览器。再次进入管理界面，这次使用新添加的管理员帐户creator:123456登录。登录完成后，在右上角的下拉列表中选择“Plone Site”。在随后的页面中，输入Id为Plone，单击“Add Plone Site”按钮，添加一个Plone站点。
等待一会，如果一些正常的话，会出现如图15所示的画面，表明已经创建了Plone站点。
图 15 创建一个Plone站点
在左边的窗格中单击“Plone”，回到管理员界面，然后再由边的窗格中单击acl_users (Group-aware User Folder)，进入用户管理界面。注意，这次单击的是Plone站点下面的acl_users文件夹，和前面创建管理员用户时不是一个文件夹。
单击“Sources”文件夹，在“User source #1”后面，首先选中“I am sure”复选框，然后在列表中选择“ACAS User Folder”，单击“Ok”按钮，如图16所示。这一步操作的意思，是使用CAS认证的用户，作为Plone的用户来源。
图 16 设定CAS作为用户来源
在随后出现的页面中，单击“acl_users (Alt. CAS User Folder)”，这是新创建的用户管理层次，注意和前面的文件夹也是不一样的。
单击“Properties”，设置参数如图17所示。
图 17 设定参数
注意CAS的路径应该根据用户自己的CAS服务器设定进行调整。
单击“Save Changes”保存设置，然后进入“Test”选项卡，可以测试CAS单点登录的效果。如图18所示。
图 18 测试CAS
单击“Test CAS Login”按钮，此时应该转向CAS登录界面，输入LDAP中设置的用户名和密码，然后单击“登录”按钮，此时应该自动转向，回到图17所示的页面，并且将CAS认证通过的用户名显示在顶部。
再次单击“Test CAS Login”按钮，此时应该不再出现CAS登录界面，而只是刷新页面。这表明系统已经使用Cookie在进行登录了。
注意，IE里有一个Bug，就是如果Plone和CAS位于同一个服务器，并且SSL的证书不规范的话，可能要重复刷新1~2次页面，才能登录成功。如果使用Firefox浏览器，或者Plone和CAS位于不同的服务器地址，则不会出现此问题。
4.2 配置 phpBB 支持 CASphpBB对CAS的支持分为两个部分：
l 首先需要安装PHP支持CAS的插件esup-phpcas。
l 然后还要安装phpBB自己的插件CasLdapAuthBB。
在http://esup-phpcas.sourceforge.net/中，下载esup-phpcas。下载完成后，将其解压缩。然后将CAS文件夹复制到PHP的搜索路径中，例如/usr/share/php5。注意，只是CAS文件夹。这样就完成了其安装。
安装CasLdapAuthBB就麻烦得多。phpBB的插件安装十分复杂，如果您手工安装CasLdapAuthBB，当然未尝不可，不过还有另一个插件easyMOD，可以大大简化安装。
从http://sourceforge.net/projects/easymod/中下载easyMOD，然后按照说明进行安装。注意安装之前，首先使用chmod 777 phpBB2 –R，修改phpBB2路径下所有文件的权限为可写，否则easyMOD无法操作。
从http://sourcesup.cru.fr/projects/casldapauthbb/中可以下载CasLdapAuthBB。然后将CasLdapAuthBB_1.2.1_RC1.zip解压缩到/srv/www/htdocs/phpBB2/admin/mods文件夹下，然后使用easyMOD安装这个插件。easyMOD自身的安装以及其安装其他插件的方法，虽然有点复杂，但是超出了本文的范畴。您可以自己多尝试一下，最后应该没有太大的问题。
使用安装phpBB时创建的管理员帐户登录，单击底部的“Go to Administration Panel”，可以进入管理面板，在gereral的configuration中，设置Authentication Settings，设置参数如图19所示。
首先注意第1个选项。如果允许guest浏览BBS，则应该选No。不过内部网站，大部分应该选Yes。这样只允许会员浏览BBS。
注意最后的TLS support一定要设置为Yes，因为我们的LDAP版本是3。
另外， 组的设置目前空着的，因为在目前版本的LDAP中，还没有搞清楚如何很好地控制组。以后我们研究清楚了，再增加这一部分。
有一些LDAP的属性也是空着的，因为LDAP没有完全设计好。
还有一点要注意，LDAP中一定要有一个和root对应的用户，否则PHP的管理面板就进不去了。
图 19 设置phpBB的认证参数
设置好了参数之后，单击“Submit”按钮，提交参数。
注意：这里将phpBB的登录系统完全换成了CAS，如果您的配置出现了问题，导致CAS不成功，那么就没有任何方法再进入phpBB的管理界面了。此时请参考http://casldapauthbb.univ-paris1.fr/，如何解决这个问题。
4.3 测试单点登录使用FireFox浏览器，或Plone，phpBB与CAS不是一台服务器时使用IE浏览器
l 输入http://192.168.1.6:8080/Plone，此时会并提示用户接受证书。
l 单击“是”，系统应该自动重定向到CAS登录画面。
l 输入LDAP中定义的用户名和密码。
l 单击“登录”按钮，系统提示离开安全连接。单击“是”。
l 此时回到Plone系统，并使用CAS中输入的用户完成了登录。
l 在地址栏中输入http://192.168.1.6:8091/phpBB2，可以看到，系统此时自动使用上面的用户进行了登录。
这表明已经实现了单点登录。如果关闭浏览器，并重新进入，则需要重新登录。这是因为cookie是绑定在当前的session上的。
Plone，phpBB与CAS位于一台服务器，并使用IE浏览器
l 输入https://192.168.1.6:8443/cas/login，直接进入cas的登录页面。
l 输入LDAP中定义的用户名和密码。
l 单击“登录”按钮，系统提示登录成功。
l 在地址栏中输入http://192.168.1.6:8080/Plone，可以看到此时不再需要输入用户名和密码，而自动使用上面的用户登录了。
l 在地址栏中输入http://192.168.1.6:8091/phpBB2，可以看到，系统此时自动使用上面的用户进行了登录。
实际上这也实现了单点登录，而之所以在这种情况下，不能采用和上面一样的操作方法，是IE和证书配合的Bug导致的。好在绝大部分情况下，单点登录服务器和应用服务器都是分开的，因此这个Bug也不太会遇到。
4.4 定制 CAS定制CAS主要是定制其登录界面。如果您很熟悉JSP的话，倒也不难。请参考http://www.ja-sig.org/products/cas/server/views/index.html关于如何定制CAS登录界面。
5 、深入开发前面介绍过，单点登录的基础是统一用户管理，但是统一用户管理和单点登录并不意味着“单一用户管理”。要实现但一用户管理，还需要对单点登录系统和应用系统本身做一些开发。
5.1 设计 LDAPLDAP还需要进行一些仔细的设计。
l LDAP用户，除了包含地址簿和登录信息以外，是不是还要包含其他一些应用程序需要使用的信息，例如角色（领导或者员工）？
l LDAP如何反映单位的组织结构？采用容器还是采用组对象？
l LDAP的组和单位的组织结构如何对应？
l 能否实现组的嵌套？这在描述组织结构中是十分有用的。
l 组能否指定不包含下属组，和包含下属组两种状态。这两种状态在应用系统中都会经常用到。
5.2 统一用户管理界面就是在单一的管理界面中，对LDAP进行操作。
l 能否有一个易用的图形界面，能够很方便地构建组织结构，并且将其写入LDAP。
l 在上面的管理界面基础上，能否有一个简单的图形界面，能够很方便的实现组织内部的“地址簿”功能？
l 在上面的基础上，能够有一个简单易用的图形界面，用于应用程序中，任何需要选择用户或者组的地方？这些地方包括“邮件选择用户”、“权限设置”等。
l 能否扩展LDAP，使得其支持用户自定义的通讯簿？（也可能用户自定义通讯部放在数据库中比较好，这一点需要研究）
5.3 用户的检索在很多应用程序中，大量使用用户的检索功能。例如Plone的工作流中，需要找到下一个流程的用户，再例如phpBB的权限设置中，需要知道用户到底属于哪个组。
在默认的插件中，查找用户时，都不会去搜索整个LDAP，而只是搜索缓存中的用户。这就导致很多关于用户的操作，实际上无法使用。
因此，应用程序不能简单地停留在使用LDAP进行登录上，而是需要更进一步地利用单点登录的各种资源，来完整地实现自己的功能。只有这样，才能真正地使用单点登录系统和LDAP，彻底替换原来的用户机制，实现单一的用户管理。