8、关于SSO和Weblogic Portal
本文讨论的只是基于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.1.3可以支持多个用户身份验证提供者，配置是在Server的控制台中进行，在Weblogic Portal的管理工具中，在管理用户和组的时候，可以在多个安全提供者之间切换，进行管理。 在Weblogic Server控制台中，点击Security > Realms > myrealm> Authentication Providers，可以看到DefaultAuthenticator，同时，还能看到可以新建很多种类的身份验证提供者，包括： Configure a new Default Identity Asserter... Configure a new MedRec Sample Authenticator... Configure a new Open LDAPAuthenticator... Configure a new Novell Authenticator... Configure a new iPlanet Authenticator... Configure a new RDBMSAuthenticator... Configure a new Default Authenticator... Configure a new Realm Adapter Authenticator... Configure a new WSRPIdentity Asserter... Configure a new LDAPX509Identity Asserter... Configure a new Active Directory Authenticator... 可以看到，Weblogic Server可以配置使用多种主流的LDAP服务器来存储用户和组，同时，也支持数据库和AD。通过设置，可以指定使用哪个身份验证提供者作为缺省的。也可以设置多个Provider直接的验证关系如何。 本文中不会对如何配置进行说明，感兴趣的朋友，可以查阅Weblogic Server关于Security的相关的帮助。使用数据库作为验证，可以参见笔者另外一个帖子：
http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=101&threadID=18563 由此可以看到，如果客户需要的SSO指的就仅仅是，能够使用他们企业内部已有的LDAP或者AD用户，进行Weblogic Portal登录和身份验证的话，那么，只要配置多个身份验证提供者就可以了，就可以使用那些已经存在的用户。但是，如果客户需要的SSO并不局限于此，还需要在Portal上登录以后，再访问其他一些基于Web的应用系统时，就不需要重复输入用户名和密码和重复登录了，那么，仅仅通过配置是无法实现的。即便那些系统和Portal理想状态下都使用相同的LDAP或者AD用户，由于每个系统验证用户是否登录以
后的机制不同，还是需要进行定制开发的。 四、自己开发实现SSO Portal作为统一的入口，将其他基于Web的应用集成到Portal中，方式可以是多种多样的，最简单的是Portal上提供链接，直接打开其他系统的界面，进行操作；再复杂一点的就是通过Frame或者Iframe的方法，将其他系统的界面嵌入到Portal中，但实质还是使用其他系统的界面，Portal只是从大范围（例如包含了其他应用的Portlet）来控制用户的访问权限，这两种主要解决的就是能够绕过其他系统的登录，然后让其他系统能够识别当前用户的对应身份，至于其他系统内部自己的个性化，权限等，还是由各个系统自己控制的。Weblogic Portal的Web应用集成还有其他方式，例如通过web clipping的方式，生成Portlet；或者通过HttpControl，取得Http回应的内容，组成Portlet；或者完全使用后端系统的API，重构Web内容，例如通过Lotus Domino的API，访问Lotus Domino的数据库，直接读取视图或者文档的信息等。但这几种方式都已经不再使用原来的系统界面，所以，涉及的内容在本文SSO讨论中没有包括。本节讨论的就是开始时提到的两种方式如何解决。 经过前面身份验证，Session，Cookie等方面的说明，我想，很多人大概已经知道如何自己编写程序来实现简单的SSO了，在论坛上笔者也看到有的朋友这样做了，其实说来很简单： 1、在数据库或者LDAP中存储Portal用户和其他系统用户的对应关系，包括其他系统用户名称和密码，根据不同系统的验证特点，有的可能还要存储密码的密文形式。 2、在Portal登录时，或者在切换到其他系统时，通过Iframe将用户名称和密码通过URL传递过去，进行后端的登录。 以后端系统为Dev2dev.bea.com.cn为例，可以通过查看登录页面的源文件，知道Form的action是login.jspa，那么，当Portal用户验证正确以后，可以在页面中加入 <iframe width=1 height=1 src='http://dev2dev.bea.com.cn/bbs/login.jspa?username=YOURUSERNAME&password=YOURPASSWORD'></iframe> <a href="
http://dev2dev.bea.com.cn/bbs/settings!default.jspa">Dev2dev.bea.com.cn</a> 将上面的YOURUSERNAME和YOURPASSWORD替换为Portal用户对应的用户名称和密码，打开页面后，点击该链接，可以看到，当前用户已经是登录以后的身份。 当然，可以去掉下面的连接，直接设置iframe的width和height为足够大，就可以将dev2dev.bea.com包括在其中。 以上应该是一个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登录验证后隐式登录所有的系统，可以在需要显示哪个系统时，再隐式登录。 五、小结 以上就是个人关于SSO和Weblogic Portal的实现的一些看法，经验和心得体会，希望能对相关朋友有所帮助。值得一提的是，Weblogic Portal通过Portlet源的多样性和灵活性，为自己开发编程实现SSO，提供了强有力的支持。