Portal精华帖整理（四）：Portal开发
Portal开发 1、WebLogic Portal的portlet开发步骤
Q: 能不能用portal administration来管理已经在workshop中创建好的portal和在这个创建好的portal上的内容，在无需创建新的portal的条件。也就是说原来portal不变，但是可以管理原来portal 中的部分内容。能不能实现？？行还是不行？？？为什么？？
A: weblogic portal完整的开发过程有两个步骤：一在workshop中进行portlet和相关资源的开发，二、在admin tools中以此为基础进行组装
2、在workshop 中怎样让portlet使用新建的*.jpf
直接将你新建的JPF拖放到你的portal页面上，就直接生成了jpf的portlet了
3、如何在weblogic portal中配置calender portlet
使用weblogic portal中的例子，需要完成以下步骤：
1。按照帮助系统中关于sample 的使用方法的提示将相应的文件import进自己的工程中。
2。在你安装weblogic的时候有目录\bea\weblogic81\portal\db\pointbase\44下有一个文件sample_portal_create_tables.sql在pointbase里面执行它。
3。需要将web.xml中的相应配置拷入到你的web.xml中如果你按照上面的步骤执行，就没有问题了。
4、如何把header.jsp和footer.jsp拖到相应的位置
在portal8.1可head和footed位置是由shell文件控制的，你可以为一个desktop选择一个shell文件，比如samportal中缺省的为header
FooterVisitor.shell
：
<?xml version="1.0" encoding="UTF-8"?>
<netuix:markupDefinition xmlns:netuix="http://www.bea.com/servers/netuix/xsd/controls/netuix/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/servers/netuix/xsd/controls/netuix/1.0.0 markup-netuix-1_0_0.xsd">
<netuix:locale language="en"/>
<netuix:markup>
<netuix:shell
title="Header-Footer Visitor Shell" description="A header with a link and footer is included in this shell." markupType="Shell" markupName="headerFooterVisitor">
<netuix:head/>
<netuix:body>
<netuix:header>
<netuix:jspContent contentUri="/portlets/header/header.jsp"/>
</netuix:header>
<netuix:break/>
<netuix:footer/>
</netuix:body>
</netuix:shell>
</netuix:markup>
</netuix:markupDefinition>5、在Portal 7.0中怎样在usermgt.jar中指向一个新生成EntityPropertyManager
修改ejb-jar.xml and weblogic-ejb-jar.xml.
在ejb-jar.xml中添加；
<ejb-ref>
<ejb-ref-name>ejb/LdapPropertyManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.property.EntityPropertyManagerHome</home>
<remote>com.bea.p13n.property.EntityPropertyManager</remote>
</ejb-ref>
在weblogic-ejb-jar.xml也作对应的修改就可以了
在http://dev2dev.bea.com/codelibrary/code/unified_up.jsp有一wlp7.0的例子你可以看看
6、请问workshop开发的portlet是否能移植到websphere portal上？
bea portal支持jsr-168，如果用jsr-168写portal移植应该没问题，但是很多是用java page flow，估计要等到标准化以后才能移植
7、Portal与Portlet中的Session与Request
Q: 在编写Portlet的时候，如果用session.setAttribute()，这个变量可以在各个Portlet中共享，有没有办法能够让session局限与一个portlet之内，也就是在一个portlet的页面流中，我如何传递自己的参数，别的portlet又看不到。request也是同样
A: session本来就是用来在一段回话中共享数据得，你这样的要求似乎太为难大家伙了。实在不行就在session中设定标志位区别吧；request的话，好像本来就是可以的吧，看看这个：
<%@page import="com.bea.wlw.netui.pageflow.scoping.ScopedServletUtils"%>
<%
HttpServletRequest outerRequest = ScopedServletUtils.getOuterRequest( request );
%>
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，提供了强有力的支持。
9、Weblogic Portal8.1中实现分页显示
我们现在至少有三种以上的方案可以解决：
1、在JSP页面上用netui:anchor 来实现页面到action的跳转，在action中进行处理之后，在回到本页面。
2、如果将代码写到JSP中，我们可以通过取得当前的page的com.bea.portlet.PostbackURL 来进行定位。
3、参考workshop中由Control自动创建的JPF中的实现方式。
第一种方案思路如下：
页面流开始，在Action中取出所有要显示的数据，分页，并显示第一页。当在jsp中点击第二页时，页面流回到Action，在Action中首先得到页数，然后计算第二页应该load的数据，并load这些数据，然后跳向原先的jsp，但是在这个jsp中绑定的数据已经是第二页的数据了。
代码详见：testpageflow
第二种方案思路：
<%
PostbackURL url = PostbackURL.createPostbackURL(request, response);
int i = 1;
while(i<10)
{
url.removeParameter("page");
url.addParameter("page",new Integer(i).toString());
%>
<a href=<%=url%>>第<%=i%>页</a>
<%
i++;
}
%>
当jsp,自己调用自己的时候，url地址不要写文件名，而是利用portlet的类，根据当前环境（request & response）先创建一个url，然后跳转到这个url，置于不同页需要不同的参数（page）值，则在代码中使用url. addParameter方法，注意在add之前最好先清一下Parameter，否则可能加得很长。
代码详见：pageTest.jsp
Java page flow 是基于strus的，建议将逻辑代码都写到action中，使用workshop提供的NetUI，一般的功能都可以实现。在jsp中尽量不写代码，尽量不要jsp之间直接跳转。
以上两个例子您可以直接拖入您的工程，可以直接运行。形成portlet放入portal后也测试过了。
第三种方案思路：参考workshop中由Control自动创建的JPF中的实现方式。
Q: 能不能用portal administration来管理已经在workshop中创建好的portal和在这个创建好的portal上的内容，在无需创建新的portal的条件。也就是说原来portal不变，但是可以管理原来portal 中的部分内容。能不能实现？？行还是不行？？？为什么？？
A: weblogic portal完整的开发过程有两个步骤：一在workshop中进行portlet和相关资源的开发，二、在admin tools中以此为基础进行组装
2、在workshop 中怎样让portlet使用新建的*.jpf
直接将你新建的JPF拖放到你的portal页面上，就直接生成了jpf的portlet了
3、如何在weblogic portal中配置calender portlet
使用weblogic portal中的例子，需要完成以下步骤：
1。按照帮助系统中关于sample 的使用方法的提示将相应的文件import进自己的工程中。
2。在你安装weblogic的时候有目录\bea\weblogic81\portal\db\pointbase\44下有一个文件sample_portal_create_tables.sql在pointbase里面执行它。
3。需要将web.xml中的相应配置拷入到你的web.xml中如果你按照上面的步骤执行，就没有问题了。
4、如何把header.jsp和footer.jsp拖到相应的位置
在portal8.1可head和footed位置是由shell文件控制的，你可以为一个desktop选择一个shell文件，比如samportal中缺省的为header
FooterVisitor.shell
：
<?xml version="1.0" encoding="UTF-8"?>
<netuix:markupDefinition xmlns:netuix="http://www.bea.com/servers/netuix/xsd/controls/netuix/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/servers/netuix/xsd/controls/netuix/1.0.0 markup-netuix-1_0_0.xsd">
<netuix:locale language="en"/>
<netuix:markup>
<netuix:shell
title="Header-Footer Visitor Shell" description="A header with a link and footer is included in this shell." markupType="Shell" markupName="headerFooterVisitor">
<netuix:head/>
<netuix:body>
<netuix:header>
<netuix:jspContent contentUri="/portlets/header/header.jsp"/>
</netuix:header>
<netuix:break/>
<netuix:footer/>
</netuix:body>
</netuix:shell>
</netuix:markup>
</netuix:markupDefinition>5、在Portal 7.0中怎样在usermgt.jar中指向一个新生成EntityPropertyManager
修改ejb-jar.xml and weblogic-ejb-jar.xml.
在ejb-jar.xml中添加；
<ejb-ref>
<ejb-ref-name>ejb/LdapPropertyManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.property.EntityPropertyManagerHome</home>
<remote>com.bea.p13n.property.EntityPropertyManager</remote>
</ejb-ref>
在weblogic-ejb-jar.xml也作对应的修改就可以了
在http://dev2dev.bea.com/codelibrary/code/unified_up.jsp有一wlp7.0的例子你可以看看
6、请问workshop开发的portlet是否能移植到websphere portal上？
bea portal支持jsr-168，如果用jsr-168写portal移植应该没问题，但是很多是用java page flow，估计要等到标准化以后才能移植
7、Portal与Portlet中的Session与Request
Q: 在编写Portlet的时候，如果用session.setAttribute()，这个变量可以在各个Portlet中共享，有没有办法能够让session局限与一个portlet之内，也就是在一个portlet的页面流中，我如何传递自己的参数，别的portlet又看不到。request也是同样
A: session本来就是用来在一段回话中共享数据得，你这样的要求似乎太为难大家伙了。实在不行就在session中设定标志位区别吧；request的话，好像本来就是可以的吧，看看这个：
<%@page import="com.bea.wlw.netui.pageflow.scoping.ScopedServletUtils"%>
<%
HttpServletRequest outerRequest = ScopedServletUtils.getOuterRequest( request );
%>
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，提供了强有力的支持。
9、Weblogic Portal8.1中实现分页显示
我们现在至少有三种以上的方案可以解决：
1、在JSP页面上用netui:anchor 来实现页面到action的跳转，在action中进行处理之后，在回到本页面。
2、如果将代码写到JSP中，我们可以通过取得当前的page的com.bea.portlet.PostbackURL 来进行定位。
3、参考workshop中由Control自动创建的JPF中的实现方式。
第一种方案思路如下：
页面流开始，在Action中取出所有要显示的数据，分页，并显示第一页。当在jsp中点击第二页时，页面流回到Action，在Action中首先得到页数，然后计算第二页应该load的数据，并load这些数据，然后跳向原先的jsp，但是在这个jsp中绑定的数据已经是第二页的数据了。
代码详见：testpageflow
第二种方案思路：
<%
PostbackURL url = PostbackURL.createPostbackURL(request, response);
int i = 1;
while(i<10)
{
url.removeParameter("page");
url.addParameter("page",new Integer(i).toString());
%>
<a href=<%=url%>>第<%=i%>页</a>
<%
i++;
}
%>
当jsp,自己调用自己的时候，url地址不要写文件名，而是利用portlet的类，根据当前环境（request & response）先创建一个url，然后跳转到这个url，置于不同页需要不同的参数（page）值，则在代码中使用url. addParameter方法，注意在add之前最好先清一下Parameter，否则可能加得很长。
代码详见：pageTest.jsp
Java page flow 是基于strus的，建议将逻辑代码都写到action中，使用workshop提供的NetUI，一般的功能都可以实现。在jsp中尽量不写代码，尽量不要jsp之间直接跳转。
以上两个例子您可以直接拖入您的工程，可以直接运行。形成portlet放入portal后也测试过了。
第三种方案思路：参考workshop中由Control自动创建的JPF中的实现方式。