查看: 3629|回复: 2
基于SAP EP的单点登录
主题帖子积分
马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
才可以下载或查看，没有帐号？
& && &1.介绍
& && &&&几乎所有的门户系统在实施的过程中都会出现门户系统和后台Web应用集成的场景。有一些应用系统可能就是SAP系统（这些提供Web访问的工具包括：ITS、BSP或者Web Dynpro），同时有些系统也可能是non-SAP系统。
& && &&&该文档针对两种基于SAP NetWeaver EP的实现单点登录的方法：SAP Logon Ticket（SAP登录票）和User Mapping（用户映射）。
& && &&&[注：本文档不描述针对数字证书的方式和非浏览器环境的后台系统]
& && &2.什么是Single-Sign-On
& && &&&Single-Sign-On简称SSO，通常被描述为允许终端用户只进行一次验证就可以登录多个应用。
& && &&&SAP NetWeaver EP允许多种方式来实现于Web应用的单点登录，该文档假设用户的业务场景是采用门户系统来代替后台Web应用来实现用户的认证。
& && &3.Portal到Web的单点登陆策略
& && &&&3.1.SAP Logon Ticket
& && &&&这种策略是采用存放在用户浏览器端的cookie来实现认证信息的存放。一旦在浏览器中存放了cookie以后，cookie会随着用户访问Portal中的各个业务系统转发到各个后台系统中，但这里有个前提，就是Portal和各个后台系统是分布在同一个域里面的。
& && &&&当后台Web应用获取到cookie信息以后，它必须知道如何来处理认证信息。如果后台是SAP系统，那么两者的集成是有先天的优势的，SAP系统之间已经内建了相互的认证机制，可以很方便的解析这些加密的认证信息，如果是non-SAP系统，SAP也提供了多种可以处理加密认证信息的工具和管理SAP Logon Ticket cookie的框架。
& && &&&优点：
& && &&&降低企业IT系统的维护成本：使用SAP Logon Ticket后，后台系统完全“信任”SAP Portal的认证信息，portal不在cookie中传递用户的密码给后端Web应用。所以后端系统就不需要手工管理用户密码，也不需要在各个业务系统之间同步密码，大大降低了IT系统的维护成本。
& && &&&SAP标准的单点登陆（SSO）机制：所有新发布的SAP系统（包括一些旧的SAP系统）内建了基于SAP Logon Ticket实现单点登陆的机制，所以当我们集成SAP系统时，需要作很少的工作，通过简单的配置就可以实现。
& && &&&限制：
& && &&&用户存储策略：SAP的企业门户只能为每个登陆用户建立一个存放用户信息的Cookie，所以当采用SAP Logon Ticket这种方式来连接多个后台系统时，先决条件是所有的这些系统必须要有一个相同的用户存储（在门户系统项目中，统一用户存储将是一个项目的难点）。使用登陆票来实现单点登陆最简单的场景是：门户系统的用户名与各后台系统的用户名相同。
& && &&&与用户映射的冲突：某些SAP开发框架，例如BSP，支持SAP Logon Ticket或者User Mapping，一个后端系统一旦采用了SAP Logon Ticket cookie来传送用户信息就不能使用User Mapping。原因是一个采用相同用户名来建Session，一个是不一样的用户名。
分享我们积累的技术、经验、人生，让更多的人富足。
主题帖子积分
& && &&&3.2 User Mapping
& && &&&用户映射是一种单点登录的实现方式，它的实现过程是portal服务器向后台系统传递用户名和密码，从而完成登录过程。当连接到web应用系统时，用户映射意味着通过请求的POST或GET方法传递用户名和密码。
有两种主要的用户映射实现方法——单独的用户映射和一般的用户映射& && &&&
& && &&&单独的用户映射
& && &&&单独的用户映射中每个Portal用户被指定到一个唯一的后台系统用户。用户自己或管理员都可以完成指定。& && &&&
& && &&&一般的用户映射
& && &&&一般的用户映射中多个用户被映射到一个后台系统的用户。用这种方法时，为了避免多个用户用同一个后台系统用户而产生冲突，通常由管理员来维护用户名和密码的映射。
& && &&&用户映射的好处和优点
& && &&&最小的技术调整：只要后台系统能从请求中接受用户名和密码，就不需要在后台系统上做任何配置。在portal端，也只需很少的配置，只需要创建一个系统对象并选好用户映射类型（“UIDPW”代表用户名和密码）。
& &简化后台用户管理（用一般用户映射时）：用凭票方式实现单点登录，需要后台系统管理所有可能登录进该系统的用户。这可能需要在后台系统中创建成千上万个与portal系统对应的用户。
& && &&&在这种情况下，用后台系统中的几个一般性的用户来代表几种不同访问权限，而不需要为每个Portal用户建立单独的用户将更有吸引力。举个例子，假设后台系统有两种显示数据的级别——经理和员工。用一般性用户映射时，只需要建立两个后台系统的用户——用户“经理”和用户“员工”。每个portal用户映射到这两个用户之一。这种方法简化了后台系统的用户管理（只需管理两个用户）。
& && &&&缺点和局限性
& && &&&映射的维护量大：需要在portal系统中维护后台系统的用户名/密码。这个维护的工作量可能比较大，比如假如后台系统的密码需要每个月换一次，则portal里也需要做相应的修改。此外，如果允许用户维护自己的用户映射属性，就需要成立一个支持团队来处理用户锁定、忘记密码等情况。
& && &&&安全：portal中存储密码始终是一个安全隐患。在两个地方（portal和后台系统中）维护密码也是不安全的。另外，用户映射方式在网路上传输用户名和密码到后台系统，在网络上也可能监听到密码。
用户映射需要的扩展或工作方式
& && &&&安全通信：当使用用户映射方式时必须强制使用SSL和后台系统进行通信，否则密码会被完全暴露给网上进行监听的不怀好意的人。
基于组或角色的映射：映射portal中的组或角色到后台系统会减少管理员的工作量。尽管如此，需要指出的是用户映射不容易管理，同时只要一个用户能管理自己用户映射到单个系统，他就能对portal中所有被映射的系统进行管理。
& && &&&改进的个性化：SAP Portal为每个可以进行用户映射的用户提供了标准的个性化窗口。但是，个性化工具有一个明显的缺点：需要用户知道portal中的系统别名和后台系统的关系。
在广泛使用用户映射，并且以上描述情况很可能会发生的情况下，建议创建一个可以被用来为特别系统处理用户映射的定制iView。这个iView可以嵌进相关的workset，因此最终用户会更加清楚他正在管理的是什么用户映射。从技术的角度，上面所描述的iView只需要简单地使用UME（用户管理引擎）的API。API提供了的storeLogonData方法，提供了存储用户映射数据到UME的功能。
分享我们积累的技术、经验、人生，让更多的人富足。
主题帖子积分
注册会员, 积分 76, 距离下一级还需 124 积分
注册会员, 积分 76, 距离下一级还需 124 积分
Powered by单点登录的简单实现
我的图书馆
单点登录的简单实现
在门户项目中，经常会遇到如何实现单点登录的问题，下面就本人的经验做个总结。欢迎大家进行补充讨论。单点登录的具体实现有很多种选择：包括：a) &采用专门的SSO商业软件： &主要有：Netgrity的Siteminder，已经被CA收购。Novell &公司的iChain。RSA公司的ClearTrust等。b) &采用门户产品供应商自己的SSO产品，如：IBM &的Tivoli &Access &Manager，Sun &公司的identity &Server，Oracle公司的OID等。c) &这些商业软件一般适用于客户对SSO的需求很高，并且企业内部采用COTS软件如：Domino,SAP,Sieble的系统比较多的情况下采用。并结合身份管理。统一认证等项目采用。采用这些软件一般都要对要集成的系统做些改造，如在要集成的系统上安装AGENT。现在一般只提供常见软件如：Domino,SAP,Sieble，常见应用服务器：weblogic,websphere等的AGENT。要先统一这些系统的认证。一般采用LDAP或数据库。然后才能实现SSO。比较麻烦。d) &另外，如果不想掏银子，也有OPEN &SOURCE的SSO软件可选：主要有：http://www.josso.org/ & &https://opensso.dev.java.net/ & &http://www.sourceid.org &等。具体怎么样就不清楚了。如果项目对SSO的要求比较低，又不想对要被集成的系统做任何改动，可采用下面介绍的方式简单实现：下面我们通过一个例子来说明。假如一个门户项目要对下面的几个系统做SSO。&用户在这些系统中的用户名，密码各不相同，如：员工号为001的员工在这些系统中的用户名，密码分别如下： &用户 &系统 &用户名 &密码 &001 &Portal系统 &A &1234 &001 &邮件系统 &B &23456 &001 &DOMINO系统 &C &ABCDE &001 &报销系统 &D &CCCCC &001 &工资系统 &E &DDDDD &首先，建立员工在PORTAL系统中的用户名和其他系统中的用户名之间的对应关系要建立员工在PORTAL系统中的用户名和其他系统中的用户名之间的对应关系并保存。可保存在表中或LDAP中或文件系统中。当然要考虑这些系统之间的数据同步问题。比较好的方式是找到用户在这些系统中的都存在的唯一信息（如员工号，MAIL地址，姓名等）。通过唯一信息实时到各个系统中去取认证所需要的信息。就不需要考虑数据同步问题。比较实用。可以建立类似下面的表：密码可采用加密保存。 &&create &table &sso_info & & & & &&(&&user & &varchar2(20), & & & &/*用户名*/&app_name &varchar2(20), & & &/*应用系统*/&architect &varchar2(4), & & & &/*应用系统的架构BS或CS*/&app_company &varchar2(50), & & & & & & & & & &/*用户所属分公司*/&app_department &varchar2(50), & & & & & &/*用户所在的部门*/&app_user &varchar2(15), & & & & & & & & & & & & & & & & &/*在该系统中的用户名*/&app_passwd &varchar2(15), & &/*在该系统中的密码*/&app_cookie &varchar2(30), & & & & & & & & & & & & & &/*COOKIE名称*/&form_user &varchar2(20), & & & & & & & & & & & & & & & &/*认证页面中FORM的用户名字段*/&form_passwd &varchar2(20), & & & & & & & & & &/*认证页面中FORM的密码字段*/&app_special & &varchar2(20) & & & & & & & & & & &/*其他*/&);通过IFRAME或超连接方式集成目标系统，并进行SSO&通过IFRAME或超连接方式集成目标系统,并在URL中带上用户名和密码。如集成DOMINO可采用如下方式： &&iframe &style="BACKGROUND-COLOR: &#f7f7ff" &align="middle" &marginwidth="0" &marginheight="0" &src="http://host1/names.nsf?Login&Username=***&Password=pass&RedirectTo=/names.nsf" &frameborder="0" &width="100%" &scrolling="yes" &height="100%" &/&或：&Href &src=“http:// &host1/names.nsf?Login&Username=***&Password=pass&RedirectTo=/names.nsf” &/&以上采用的是在HTTP中直接传递明码，为提高安全性，可采用HTTPS来传递用户名和密码。另外采用这种方式被集成的系统必须支持FORM方式认证。J2EE应用，DOMINO等都支持FORM认证。这两种方式如果SSO成功，就自动进入目标系统的界面，如果实现会显示目标系统的登录界面。其效果图如下：&这种方式，必须维护对应关系表，如上面的sso_info。更好的方式是提供界面，让最终用户自己维护这种对应关系，可模仿Compoze &portlets &for &lotus的做法，在用户第一次进入要与之做SSO的系统时，如DOMINO系统，显示一个界面，让用户自己输入他在该系统中的用户名/密码等信息。并保存到表中或LDAP等其他数据源中。以后用户要进入这些系统时，就直接从表中或其他数据源中取用户的用户名/密码等信息，帮助用户做认证。建议采用这种方式。如下图所示。如果用户改变了自己在DOMINO系统中的用户名，密码。从门户系统进入DOMINO系统时，认证会失败，就重新显示类似下面的界面。让用户重新输入他在DOMINO系统中新的用户名，密码并保存。&以上这种实现方式，一般需要浏览器支持COOKIE，所以要注意浏览器的配置，在开发阶段，为方便调试，可设置IE，让它显示COOKIE的名称。如下所示：&采用这种方式，对要集成的系统不需要做任何的改动。如果PORTAL系统中的用户在被集成的系统中的权限都一样，可采用建立一个通用用户的做法。也就是所有在PORTAL系统中的用户都采用这个通用用户进入目标系统。这种方式等于是采用页面集成方式做集成。比较方便使用。另外，有时候需要采用调用API，或配置Adapter等应用集成方式来集成其他系统，一般也是通过定义一个连接专用的用户。在API中或在配置Adapter的时候写死。如采用JAVA &API方式集成DOMINO：lotus.domino.Session &dominoSession &= &NotesFactory.createSession(dominoServer, &“***”, &“password”);CS结构实现方式经常有人问CS结构的应用如何实现SSO，本人的建议是对这种系统不要自己去实现SSO。很麻烦，其实输个用户名，密码没什么大不了的。如果要实现，一是采用商业软件。另外也可以采用以下方式：在PORTAL的PORTLET上建立超连接。并通过APPLET方式启动CS结构的应用系统的登录界面。然后通过如下的方式把用户名/密码传递过去。&-不能做任何改动的客户端 &- &WIN消息（给登录窗口发送用户名，密码等登录所需要的信息）,模拟键盘（java有模拟键盘输入的API）&-可以做改动的客户端 &- &参数传递，并让登录的EXE文件读取参数进行认证。因为要让APPLET执行本地的EXE文件，所以必须对IE中的JRE的安全进行设置。 & &其他：在采用以上方式实现了SSO后，要注意LOGOUT，可采用与LOGIN相同的方式。也可以通过被集成系统的超时设置来实现。
发表评论：
TA的最新馆藏[转]&[转]&[转]&转载（25）
转载至:http://blog.csdn.net/lifetragedy/article/details/
啊。。。。。。it's quite a long time。
好久没更新博客了，有一年之久了，一直在忙于公司的一些项目。2014年到2015年工作太忙，我也接触到了新的领域，认识了新的同事。
对于一些经常跟我博客的读者们深深说一声抱歉。
同时，也在新的一年将到之际，祝各位新春愉快，羊年洋洋洋。
好了，废话少说，开始我们架构师之路的新的历程，SSO-单点登录。
另外想以此SSO系列教程献给我那身体不太好的同事-小白同志，祝小白同志身体一直健康
& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & ——叫你废话少说你还再啰嗦，你还说，好了，关掉，开始正经话题。
什么是单点登录？什么是SSO？
SSO就是单点登录！！！
SSO即Single Sign On。
可是为什么我们要单点登录呢？为什么不能把所有的系统做成一个war包里呢？
道理很简单啊，如果这个银行这个企业全是你一家公司里的一个项目组包下来了，然后是从头开始开发，你当然可以把所有的功能模块做到一个WAR工程中啊。
可是很多时侯我们是做一个工程或者是两个工程然后需要和另一个工程去做结合，每个工程都有一个入口地址，对吧？那么我们从用户的角度出发来说：
如果一个企业的工作人员需要操作4，5个不同的系统如：HR系统、报销系统、进销存系统还有企业内的eLearning系统和SAP系统，那么他要登录5次对不对？要登录5次？
那么有人说了，为什么这么麻烦呢？我们不能把所有的系统除了一个主系统，然后让用户只要登录一次，再把其它系统的链接以菜单的形式挂在主系统的菜单点，然后去除登录功能，这样用户不就可以只需要登录一次了呢？
答案当然是：你可以这样做。
可是安全性呢？
因此我们引入了单点登录的概念，我们可以想一下，用户面对10几个系统，这10几个系统只有一个“表皮”（主页），在这个主页中有许多的外挂连接，连向10几个子系统，这10几个子系统每个都需要根据用户名和密码来判断用户是否对于本系统有无操作权限？但是用户只需要在这个“表皮”上登录一次，当他点每一个菜单链接时，系统会自动把用户名和密码做一次匹配然后根据权限系统来判断该用户是否具有相应的权限，进而使得用户可以通过主页再链入不同的子系统中，这就是单点登录。
或许是中文翻译的问题，我们就从Single Sign On这3个字来理解，只需登录一记，啊。。。这就对了，多个系统我只需要登录一次。
我们进一步设想一下，其实用户还是登录了两次，为什么呢？
对于正规的企业来说都有一个“域登录”，即WINDOWS域我们又称之为Active Directory，简称AD域，用户打开WIN7,WIN8, WINDOWS SERVER。。。bla...bla...bla...what every啦。
此时他需要输入域帐号，登录一次。
然后他进入WINDOWS桌面后，打开IE，点开公司内部OA系统，做报销或者是做请假，又登录一次。
其实是两次登录。
因此做的好的SSO，因该是怎么样啊？
即让用户登录一次，就是用户一旦登录了公司的AD域后，他在IE里打开公司内部的一些网址都无需再做登录了，因为用户的AD域帐户就是它的系统帐户。
如：公司内每个员工的邮箱帐号，它打开OUTLOOK后就自动连上了相关的MAIL服务器，然后该员工的AD域帐号加上@xxx.xxx这样的格式，这不就是他公司的邮件地址了，对吧？
对不对？这就是一个SSO的活生生的例子。
那么很多时候，确实，为了安全，我们可以让员工在登录了AD域后再打开IE，然后输入公司内的OA网址时再登录一次，这样做其实也是可以，而公司内的OA一般不仅仅只是一个系统，它一定一定是连接着多个子系统。
比如说我们一个公司的OA系统是一个EAR，它下挂有10多个WAR。
甚至一些公司还会外接如：SalesForce, SAP等其它系统，因此我们把员工打开的这层公司OA系统的最外面的这层“皮”，称之为PORTAL。
对的，PORTAL里一定含有SSO，在此先提一下。
下面是一些著名的调查公司显示的统计数据：
用户每天平均16分钟花在身份验证任务上 - 资料来源：IDS频繁的IT用户平均有21个密码 - 资料来源：NTA Monitor Password Survey49%的人写下了其密码，而67%的人很少改变它们每79秒出现一起身份被窃事件 - 资料来源：National Small Business Travel Assoc全球欺骗损失每年约12B - 资料来源：Comm Fraud Control Assoc
使用“单点登录”整合后，只需要登录一次就可以进入多个系统，而不需要重新登录，这不仅仅带来了更好的用户体验，更重要的是降低了安全的风险和管理的消耗。
请看下面的统计数据：
提高IT效率：对于每1000个受管用户，每用户可节省$70K帮助台呼叫减少至少1/3，对于10K员工的公司，每年可以节省每用户$75，或者合计$648K生产力提高：每个新员工可节省$1K，每个老员工可节省$350 - 资料来源：GigaROI回报：7.5到13个月 - 资料来源：Gartner &&
另外，使用“单点登录”还是SOA时代的需求之一。在面向服务的架构中，服务和服务之间，程序和程序之间的通讯大量存在，服务之间的安全认证是SOA应用的难点之一，应此建立“单点登录”的系统体系能够大大简化SOA的安全问题，提高服务之间的合作效率。
以下是一个标准的企业内通过SSO来集成各个系统间的认证与权限的模型图
好了，以上基本知识普及完毕开始我们的SSO实现。
SSO实现有很多产品，我们今天选用的这个是耶鲁大学发明的CAS SSO服务器。这个CAS SSO是目前我看到过的功能较全的，使用也是最简单的配置式SSO服务器，它基于SPRING的原理，因此这个配置文件我们看起来因当是相当的熟悉的。
它分为Server版和Client版2个模块，同时它对于一些其它功能特性如：数据库、LDAP协议（就是WINDOWS AD域使用的协议）、安全等还提供了一系列的插件。因此，在本例中，我使用的是:
Server端：
Cas Server 3.5.2
Client端：
Cas Client 3.2.1
请严格按照我的版本号进行试验。
什么叫Server端 ，什么叫Client端？
看上图，假设我们有3个War包。
一个叫cas-server.war，它放在tomcat里；一个叫cas-sample-site1.war，它放在jboss里；一个叫cas-sample-site2.war，它放在jboss里；
那么位于tomcat里的cas-server.war，它就是我们的CAS的Server端，位于jboss里的两个war就是我们CAS的client端。
SSO中的Server端与Client端概念搞清后，我们现在就开始布署吧。
布署cas-server
先说一下我们的环境：
我们把Server端解压得到以下这样的一个文件夹
它里面含了一堆的东西，关键在于以下这个文件夹
进入该文件夹，找到这样一个war包。
把这个war包解压后重命名成cas-server.war，放于tomcat的webapp目录中去，启动tomcat一切无误后即可。
然后我们打开一个ie，输入http://localhost:9090/cas-server会得到以下这个界面，那就说明你的cas sso已经安装成功了。
配置CAS SERVER
添加依赖包
在本例中我们将使用Oracle数据库中自建一个用户表来管理我们的用户名和密码，因此：
将oracle的ojdbc6.jar放入tomcat的lib目录内D:\tomcat\lib将cas-server-3.5.2-release\cas-server-3.5.2\modules下的这几个文件拷入tomcat\webapp\cas-server\web-inf\lib目录内
修改配置文件
CAS SSO的好处在于它的配置文件是完全spring的，你只要懂spring就可以非常容易的在里面去添加修改自己的一些功能，我们在第一天的教程中为了尽量简单，我们只需要改动一个文件，它就是：
tomcat\webapps\cas-server\WEB-INF目录下的
deployerConfigContext.xml文件
我们用纯文件编辑器打开它，找到下面这行：
把它注释掉
然后再在它下面添加如下内容
好，这边我们看到了一个dataSource对吧，EASY，来。。。
注意我加的这个dataSource的bean和刚才那段配置代码之间的位置对应关系哦，别胡乱搞一个回车就乱加一行哦。
全加完了，怎么样啦？完成了吗？
还没，CAS SSO严格意义上来说需要J2EE APP SERVER里实现HTTPS即SSL的双向认证模式才能正常使用，但是我们因为这个是教程，因此不想搞了太麻烦，我们可以在“不使用HTTPS认证”的情况下也可以使用CAS SSO。
为此，我们要关闭CAS SSO的HTTPS认证模式，编辑：
tomcat\webapps\cas-server\WEB-INF\spring-configuration目录下的
ticketGrantingTicketCookieGenerator.xml文件
找到下面这行
把这边的p:cookieSecure从true改为false即可。
然后我们在oracle中建一个用户表吧，建表语句如下：
该表中含有一条记录：
这就是我们的用于测试的单点登录的用户名和密码了，很简单吧？
全部保存后，重启tomcat，一切无误，然后我们打开一个ie，输入http://localhost:9090/cas-server会得到以下这个界面，那就说明你的cas sso已经安装成功了。
我们在用户名中输入sso， 在密码一栏中输入aaaaaa，然后看到下面这个界面，即代表我们的cas server和我们的数据库已经完全连上了。
如果我们不按照sys_user表中的用户名和密码就随意输入用户名和密码，那我们便会得到这样的结果：
将不同的工程连接上cas server以实现单点登录
按照这个图，我们将会有2个不同的war包
一个叫cas-sample-site1.war，它放在jboss里；一个叫cas-sample-site2.war，它放在jboss里；
我们在我们的eclipse里创建两个这样的war工程即可，这是非常简单的事，这2个工程都含有一个index.jsp文件。
cas-sample-site1
在它的index.jsp文件中含有如下内容：
cas-sample-site2
在它的index.jsp文件中含有如下内容：
这两个war工程都有一个lib目录，确保它们的lib目录里都有这样几个jar
look, 注意要有cas-client-core-3.2.1.jar哦，它来自于：cas-client-3.2.1-release\cas-client-3.2.1\modules即cas-client-3.2.1-release.zip解压出来的内容。
这两个工程的web.xml可以说是完全一模一样，我们来看：
看到了没有，有这么一堆的listener和filter，而且它们一个不能漏，并且它们的顺序也是绝对不能够错的，一定要按照下面这个从上至下的顺序：
org.jasig.cas.client.session.SingleSignOutHttpSessionListener
org.jasig.cas.client.session.SingleSignOutFilter
org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter
org.jasig.cas.client.authentication.AuthenticationFilter
org.jasig.cas.client.util.HttpServletRequestWrapperFilter
漏了一个，或者顺序错了，你将会发生下列情况：
可以正常登录，无法统一注销，即然是单点登录，那么我在任意一个站点上点“注销“是不是也因该是统一注销啊？可以登录，可以统一注销，但是拿不到cas-server上登录的用户的user session，如果我们是两个系统，那么这两个系统是不是都有web sesssion？较常用的就是user session，那么如果你的顺序配错了，或者是你漏配了一个，你是得不到cas-server上传过来的用户的一些登录信息的，这个很糟糕，这将会为我们后面的编程开发带来烦恼不能登录
至于为什么会得到这样的一些结果？
我们在后面的课程中会来分析cas 单点登录的源码（这个过程一点不变态，很简单的，一说就通，跟着我的教程一步步走不难的），在深入源码中后你就可以看出为什么这几个东西它们有严格意义上的顺序的关系了。
在这个web.xml文件里我们可以看到有两处出现了下面的这样的东西：
记住，上面的那行代表我们的cas server的服务器所在的地址，当用户用上面的cas-server的登录界面登录成功后，cas server 会自动跳回用户在ie地址里输入的子系统地址的首页。
如：我们先输入http://localhost:8080/cas-sample-site1，此时系统会先跳到http://localhost:9090/cas-server/login的画面要求用户先去做一次登录。
那么cas server它是怎么知道子系统地址的首页位于哪个地址（哪台服务器上）的呢，那么你要”注册“这个地址给cas server。
因此，第二行就是我们的具体的子系统的首页所在的地址。
这样的地方在我们的web.xml文件中一共出现了两处：
一处位于org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter一处位于org.jasig.cas.client.authentication.AuthenticationFilter
这2处如果没配好，你会遇到下列问题：
登录后无法正常跳回子系统的首页无法正常退出无法做系统间切换时的跳转
因此一定要注意啦！！！
我们把两个工程通过ECLIPSE布署在JBOSS7上，然后运行起来吧。
别忘了启动我们的Tomcat里的cas server哦。
全部启动完毕后我们在IE浏览器里输入：http://localhost:8080/cas-sample-site1&
此时浏览器显示如下画面
我们在cas server的登录画面输入我们数据库表sys_user中的相应的用户名与密码后，再来看此时的浏览器它会跑到哪儿去？
点击cas-sample-site2这个链接呢？
然后点击“退出”这个链接
此时我们再在浏览器里输入：http://localhost:8080/cas-sample-site2--有时浏览器有缓存，它还是会显示cas-sample-site2的首页，这时你可以点一下F5或者是刷新按钮（这个可以通过代码来避免jsp或者是html页中使用缓存来做到）
由于是统一注销，因此一旦注销，两个WEB都无法访问了，必须要求“统一登录一下”，于是我们再次输入用户名和密码
好了，第一天不讲太多，从明天开始我们会依次开始讲：
1. 如何使用LDAP即模拟WINDOWS AD域的登录模式
2. 如何在不同的web工程间获取“统一登录”时的用户信息即userprincipal
3. 如何改造CAS SSO自带的登录界面
4. 如何使得我们的CAS SSO可以支持类似于淘宝这种“多租户”的概念
差不多所有内容预计在5-6课左右，敬请期待。&
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：14876次
排名：千里之外
原创：56篇
转载：30篇
(1)(21)(8)(6)(4)(12)(17)(3)(4)(1)(11)