分享到一键分享QQ空间新浪微博百度搜藏人人网腾讯微博百度相册开心网腾讯朋友百度贴吧豆瓣网搜狐微博百度新首页QQ好友和讯微博更多...百度分享
个人中心我的展示应用博客相册视频圈子留言小游戏问答育儿自选股微博秀场设置
搜狐首页欢迎访问登录 注册跟随你暂时没有新的跟随者，查看跟随者登录并查看
消息你暂时没有新消息，查看消息登录并查看
金币 [最新活动] 兴业银行精彩e生活 好礼天天送>>
商品兑换 查看金币 怎么挣金币 请选择您的用户帐号类型
搜狐通行证上搜狐，知天下帐　号 密　码 记住登录状态注册新用户忘记密码帮助中心.林洋9987 林洋9987被访问过 5823 次 男
查看更多>>送TA礼物 发短消息 查看留言>> 跟随留言: 对他说点什么 验证码  看不清验证码？ 发表 .
首页我说两句博客相册视频微博圈子添加导航模块首页 我说两句 相册 视频 博客 微博 圈子 育儿 问答 添加自定义链接(仅限搜狐网链接)网址： 名称： 确认  使用新窗口打开
关于SSO和Weblogic Portal (hbwind )收藏到手机    转发  评论 2007-01-17 15:25 本文讨论的只是基于Web的其他应用系统与的Weblogic Portal的SSO。
一、应用系统的验证
提到SSO，就不能不提到其他基于Web应用系统的身份验证。我们透过现象看本质，看看基于Web的身份验证的实质是什么。
无论后端是什么系统，例如Lotus Domino，BO等等，其实，基于Web的身份验证的实质无外乎就是有一个表单（FORM），表单里面让用户输入用户名称和密码，然后提交给验证的页面（Form中的action指定的），通过身份验证后，通过Session来储存用户的一些信息，然后每次访问页面时，从session里面读这些信息，如果存在，则进入登录后的界面，否则，就认为没有登录。
而Session的机制呢，我想大多数人都应该知道，它是与Domain还有Path相关的，是存储在服务器端的，服务器如何知道当前浏览器或者客户端对应的是哪个Session呢，主要是通过Cookie中的sessionid来对应的，session是有失效时间的，服务器一般都可以设置，也可以通过程序来设置。
Cookie的生命周期可以是一关闭浏览器就灭亡，也可以设置存在的时间，如果设置了存在的时间，就会以文件的方式存在于客户端，当客户端再访问服务器时，可以通过Domain对应关系从Cookie中读取相
应的信息，一般我们在其他网站时，登录时如果设置了自动登录或者记录多长时间，就是使用的Cookie，一般会在Cookie中存储登录的用户名称和密码的密文，访问网站时，它如果读取到这些信息，就会使用这些信息自动登录了。
所以可以看出，无论对于什么Web应用程序，如果该浏览器曾经登录过
，服务器端生成了session，客户端Cookie中记录了SessionID，该浏览器没有关闭，那么，即便该浏览器访问其他的站点后，再回到该应用系统，如果Session没有失效，那么应用程序还会认为你是登录的。
而对于身份验证的页面，一般是不做判断，判断你的用户名称和密码是通过POST，还是URL中参数方式提交的。
除此以外，有的应用程序会从URL中参数判断你是否登录，这种方式由于不安全目前已经应用不多，早些年很多门户网站的邮件就是这种机制，用户登录时会根据一些特性生成一个很长的字符串，通过该字符串来判断是否登录了，所以当时会发生，如果在另外一台机器上拷贝了该URL，也会进入邮箱的情况。
还有一种特殊情况，这是HTTP协议支持的，就是BASIC认证方式，它会在用户初次访问时弹出对话框，
用户输入用户名和密码后，浏览器会记住，然后每次HTTP请求时，在Header里面将用户名称和密码的BASE64位形式传给服务器，服务器就会知道该用户的身份了，之所以在这里单独提出这种方式，是因为下文介绍的自己编写的SSO实现很难对付这种验证方式，所以，如果后端系统（例如Lotus Domino）同时也支持Form身份验证，就需要改过来，如果不支持或者不能改过来，将是很棘手的一件事情。
二、SSO的实现-第三方产品
本节讨论的是基于第三方产品实现SSO。
目前，有很多产品支持SSO，使用Weblogic Portal，我们也主张用户使用这些产品，因为他们能够很好的通过配置，甚至是自学习的方式实现SSO，开发者需要完成的工作很少。
这些产品，一般实现的方式有两类：
第一类是通过Agent的方式，即在后端每个Web应用系统，或者其他系统都安装一个Agent，由Agent来接管该系统的身份验证和访问控制，同时，需要有一台策略服务器，里面会放置Weblogic Portal的用户信息，以及这些用户与其他系统的用户对应信息，当然，Weblogic Portal也可以继续保留自己的用户，该策略服务器只是存放了用户的对应关系。
这类产品对于不同的系统，Agent不同，这些Agent能够通过配置，轻松的接管了后面的系统的身份验证
和访问控制，所以，举例来说，如果Portal中用户A对应系统1中的用户B，那么策略服务器中有此配置后，当从Portal访问系统1时，系统1的agent能够辨别portal用户A，就可以知道该系统对应的用户是B，让系统认为当前用户就是B，然后使用B的身份来访问和操作系统1。
这类产品的使用方式还可以是，通过一个统一的LDAP，存放企业内部的用户信息，然后通过策略服务器，控制了后端所有系统的URL访问权限，这样也实现了单点登录。
这种方式的优点是：策略服务器不会存储其
他系统的密码，密码还是保存在各个系统中，同时，各个系统的访问都由Agent控制，用户必须经过Portal作为入口，同时，可以通过策略服务器灵活的配置访问控制。
缺点在于：需要在各个系统安装Agent；对于没有Agent的系统，需要通过安装Web Agent，然后进行一定的编码实现；Portal作为单一入口，一旦当机，无法访问后台系统。
缺点解决：Weblogic Portal可以通过构建集实现负载均衡和容错，避免单点故障。
第二类是通过Proxy的方式，即具有一个Proxy Server，由它来接管对于后端系统的访问，提交请求和读取数据，然后再返回给Portal，同时也有一个LDAP服务器或者策略服务器，该服务器可以存放用户信息以及用户的对应关系。
Proxy Server的作用是接收Portal的请求，提交给后端系统，然后将返回的数据再写给Portal，Proxy Server会通过存储的用户对应关系和用户名和密码，自动完成后端系统的登录，然后就象一个浏览器一样，提取数据，返回数据给后端系统。
该方法的优点是：后端系统不用做任何改动。即便是没有Portal，其他系统还可以照常使用。
缺点是：需要在策略服务器中存储用户名称和密码，密码会多处存放，同步困难；用户可以绕开Portal，直接访问后端系统。Proxy Server可能是单点故障。
缺点解决：目前有密码同步产品；Proxy Server也大多支持集。
由以上两种方式可以看出，哪种方式的编程量都不是很大，大多可以通过配置来实现，而且功能也很强大，例如第一节说的BASIC登录方式，这些产品都支持。而Weblogic Portal通过其支持多身份验证提供者，以及良好的开发框架等的特点，能够完全支持这两种方式。如果客户银子大把，优先应该考虑使用第三方产品。
可是如果客户预算不大，后端系统又不多，有什么解决方法呢？
答案当然是有，但不是万能的。
三、Weblogic Portal的用户
提到SSO，就不能不说说Weblogic Portal的用户信息。作为一个统一，简单，可扩展的企业级应用平台Weblogic Platform中的一部分，Weblogic Portal被容纳在Weblogic Platform统一的安全框架中，它使用的用户和组，就是weblogic Server的用户和组，但是与Weblogic Server不同的是，它的角是Portal特有的，与Server是完全不同意义的，需要注意不要混淆了。
Weblogic Server安装后缺省时是使用自带的内嵌的LDAP来进行用户，组和角的管理的，在身份验证提供者中，有一个DefaultAuthenticator，就是对这部分用户，组和角来进行管理的提供者。
Weblogic Portal8.13可以支持多个用户身份验证提供者，配置是在Server的控制台中进行，在Weblogic Portal的管理工具中，在管理用户和组的时候，可以在多个
安全提供者之间切换，进行管理。
在Weblogic Server控制台中，点击Security > Realms > myrealm> Authentication Providers，可以看到DefaultAuthenticator，同时，还能看到可以新建很多种类的身份验证提供者，包括：
Configure a new Default
Configure a new MedRec
Configure a new
Configure a new
Configure a new
Configure a
Configure a new
Configure a new Realm
Configure a new
Configure a new
Configure a new Active
可以看到，Weblogic Server可以配置使用多种主流的LDAP服务器来存储用户和组，同时，也支持数据库和AD。
通过设置，可以指定使用哪个身份验证提供者作为缺省的。也可以设置多个Provider直接的验证关系如何。
本文中不会对如何配置进行说明，感兴趣的朋友，可以查阅Weblogic Server关于Security的相关的帮助。
使用数据库作为验证，可以参见笔者另外一个帖子：
dev2dev.bea/bbs/thread.jspa?forumID=101&threadID=18563
由此可以看到，如果客户需要的SSO指的就仅仅是，能够使用他们企业内部已有的LDAP或者AD用户，进行Weblogic Portal登录和身份验证的话，那么，只要配置多个身份验证提供者就可以了，就可以使用那些已经存在的用户。
但是，如果客户需要的SSO并不局限于此，还需要在Portal上登录以后，再访问其他一些基于Web的应用系统时，就不需要重复输入用户名和密码和重复登录了，那么，仅仅通过配置是无法实现的。即便那些系统和Portal理想状态下都使用相同的LDAP或者AD用户，由于每个系统验证用户是否登录以后的机制不同，还是需要进行定制开发的。
iframe参数传递四、自己开发实现SSO
Portal作为统一的入口，将其他基于Web的应用集成到Portal中，方式可以是多种多样的，最简单的是Portal上提供链接，直接打开其他系统的界面，进行操作；再复杂一点的就是通过Frame或者Iframe的方
法，将其他系统的界面嵌入到Portal中，但实质还是使用其他系统的界面，Portal只是从大范围（例如包含了其他应用的Portlet）来控制用户的访问权限，这两种主要解决的就是能够绕过其他系统的登录，然后让其他系统能够识别当前用户的对应身份，至于其他系统内部自己的个性化，权限等，还是由各个系统自己控制的。
Weblogic Portal的Web应用集成还有其他方式，例如通过web clipping的方式，生成Portlet；或者通过HttpControl，取得Http回应的内容，组成Portlet；或者完全使用后端系统的API，重构Web内容，例如通过Lotus Domino的API，访问Lot
us Domino的数据库，直接读取视图或者文档的信息等。但这几种方式都已经不再使用原来的系统界面，所以，涉及的内容在本文SSO讨论中没有包括。本节讨论的就是开始时提到的两种方式如何解决。
经过前面身份验证，Session，Cookie等方面的说明，我想，很多人大概已经知道如何自己编写程序来实现简单的SSO了，在论坛上笔者也看到有的朋友这样做了，其实说来很简单：
1、在数据库或者LDAP中存储Portal用户和其他系统用户的对应关系，包括其他系统用户名称和密码，根据不同系统的验证特点，有的可能还要存储密码的密文形式。
2、在Portal登录时，或者在切换到其他系统时，通过Iframe将用户名称和密码通过URL传递过去，进行后端的登录。
以后端系统为Dev2dev.bea为例，可以通过查看登录页面的源文件，知道Form的action是login.jspa，那么，当Portal用户验证正确以后，可以在页面中加入
<iframe width=1 height=1 src='dev2dev.bea/bbs/login.jspa?username=YOURUSERNAME&password=YOURPASSWORD'></iframe>
<a href="dev2dev.bea/bbs/settings!default.jspa">Dev2dev.bea</a>
将上面的YOURUSERNAME和YOURPASSWORD替换为Portal用户对应的用户名称和密码，打开页面后，点击该链接，可以看到，当前用户已经是登录以后的身份。
当然，可以去掉下面的连接，直接设置iframe的width和height为足够大，就可以将dev2dev.bea包括在其中。
以上应该是一个JSP页面（因为你要动态的设置名称和密码），通过该JSP页面产生Portlet，就可以嵌入到Portal中，正如我们前面所说，你不能通过Portal控制你登录以后的样式，个性化等属性，但是你可以通过控制用户访问该Portlet的权限，从而实现Portal内高层次的个性化和显示控制。（其实，通过JavaScript，也完全可以改变Iframe中的内容和样式，这个超出本文的主题，略过）
以上就是一个SSO的自己编程的简单实现，但是，这种方法具有很多需要注意的地方和局限性：
1、对方的登录表单，可能不仅仅是传递了用户名称和密码，可能还有其他的参数，需要多次尝试，如果能够看到对方验证的代码最好。
2、对方有可能进行了Form是POST还是GET提交的判断（例如，验证页面是Servlet），如果一定需要使POST，那么可以使iframe中src是一个相同的form表单，action指向对方的验证页面，然后，通过Javascript，进行隐式提交；更有甚者，有的验证页面还判断了是否是本服务器提交的请求，那么，就要嵌入对方的登录表单，然后在iframe所在的页面内，通过Javascript使iframe内的页面提交，完成登录。
3、有的系统为了安全，密码传输前已经在客户端通过Javascript进行了加密，注意
检查。
4、有的系统很特别，一定要在浏览器的_top窗口中进行验证，或者验证以后在_top中打开后继的页面，对于这种系统，请修改对方的程序，否则很难解决。笔者曾经就遇见过此类案例，尝试多次无果，幸好后来发现对方系统能够设置后继的页面，将后继的页面设置为Portal，再转回Portal才可以。
5、Portal用户会和多个系统的用户有对应关系，需要设计一个好的数据结构，如果后端系统为多个，不一定非要在Portal登录验证后隐式登录所有的系统，可以在需要显示哪个系统时，再隐式登录。
分享到： 编辑  删除  阅读(33)  转发  评论 来自我的搜狐 在博客中查看 分类： 编程 标签： 系统 用户 密码 身份验证 服务器 .上一篇： 语法 下一篇： 要加息了......... 我要评论：此处评论内容会与搜狐博客同步哦！
评论0 / 300 同时转发
暂时没有评论
跟随 8跟随者 5新鲜事 0等级 0金币 0勋章 暂无勋章！礼物 暂无礼物！  TA推荐的人正在加载...
博客分类全部分类
链接
灯具
经济法
会计
管理
财经
日语
编程
博客标签
更多>>精彩博文姚树洁盘点任内贡献
叶永烈实拍朝鲜停战协定签订现场
刘杉新一届政府"接棒"四大挑战
那小兵美国对百姓自住房增值免税
琴兽好声音学员为音乐梦弃学
育儿70后辣妈谈家有俩宝的好处
帮助 - - 意见建议 - 举报 - 搜狐首页
Copyright ? 2013 Sohu Inc. All rights reserved. 搜狐公司 版权所有 
意见反馈

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。