Q: 能不能用portal administration來管理已經(jīng)在workshop中創(chuàng)建好的portal和在這個創(chuàng)建好的portal上的內(nèi)容，在無需創(chuàng)建新的portal的條件。也就是說原來portal不變，但是可以管理原來portal 中的部分內(nèi)容。能不能實現(xiàn)？？行還是不行？？？為什么？？

A: weblogic portal完整的開發(fā)過程有兩個步驟：一在workshop中進行portlet和相關資源的開發(fā)，二、在admin tools中以此為基礎進行組裝

直接將你新建的JPF拖放到你的portal頁面上，就直接生成了jpf的portlet了

使用weblogic portal中的例子，需要完成以下步驟：

1。按照幫助系統(tǒng)中關于sample 的使用方法的提示將相應的文件import進自己的工程中。

2。在你安裝weblogic的時候有目錄\bea\weblogic81\portal\db\pointbase\44下有一個文件sample_portal_create_tables.sql在pointbase里面執(zhí)行它。

3。需要將web.xml中的相應配置拷入到你的web.xml中如果你按照上面的步驟執(zhí)行，就沒有問題了。

在portal8.1可head和footed位置是由shell文件控制的，你可以為一個desktop選擇一個shell文件，比如samportal中缺省的為header

FooterVisitor.shell

：

<?xml version="1.0" encoding="UTF-8"?>
<netuix:markupDefinition xmlns:netuix="http://www./servers/netuix/xsd/controls/netuix/1.0.0" 
xmlns:xsi="http://www./2001/XMLSchema-instance" 
xsi:schemaLocation="http://www./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./codelibrary/code/unified_up.jsp有一wlp7.0的例子你可以看看

bea portal支持jsr-168，如果用jsr-168寫portal移植應該沒問題，但是很多是用java page flow，估計要等到標準化以后才能移植

Q: 在編寫Portlet的時候，如果用session.setAttribute()，這個變量可以在各個Portlet中共享，有沒有辦法能夠讓session局限與一個portlet之內(nèi)，也就是在一個portlet的頁面流中，我如何傳遞自己的參數(shù)，別的portlet又看不到。request也是同樣

A: session本來就是用來在一段回話中共享數(shù)據(jù)得，你這樣的要求似乎太為難大家伙了。實在不行就在session中設定標志位區(qū)別吧；request的話，好像本來就是可以的吧，看看這個：

<%@page import="com.bea.wlw.netui.pageflow.scoping.ScopedServletUtils"%>

<%

HttpServletRequest outerRequest = ScopedServletUtils.getOuterRequest( request );

%>

本文討論的只是基于Web的其他應用系統(tǒng)與的Weblogic Portal的SSO。

一、應用系統(tǒng)的驗證

提到SSO，就不能不提到其他基于Web應用系統(tǒng)的身份驗證。我們透過現(xiàn)象看本質(zhì)，看看基于Web的身份驗證的實質(zhì)是什么。

無論后端是什么系統(tǒng)，例如Lotus Domino，BO等等，其實，基于Web的身份驗證的實質(zhì)無外乎就是有一個表單（FORM），表單里面讓用戶輸入用戶名稱和密碼，然后提交給驗證的頁面（Form中的action指定的），通過身份驗證后，通過Session來儲存用戶的一些信息，然后每次訪問頁面時，從session里面讀這些信息，如果存在，則進入登錄后的界面，否則，就認為沒有登錄。

而Session的機制呢，我想大多數(shù)人都應該知道，它是與Domain還有Path相關的，是存儲在服務器端的，服務器如何知道當前瀏覽器或者客戶端對應的是哪個Session呢，主要是通過Cookie中的sessionid來對應的，session是有失效時間的，服務器一般都可以設置，也可以通過程序來設置。

Cookie的生命周期可以是一關閉瀏覽器就滅亡，也可以設置存在的時間，如果設置了存在的時間，就會以文件的方式存在于客戶端，當客戶端再訪問服務器時，可以通過Domain對應關系從Cookie中讀取相應的信息，一般我們在其他網(wǎng)站時，登錄時如果設置了自動登錄或者記錄多長時間，就是使用的Cookie，一般會在Cookie中存儲登錄的用戶名稱和密碼的密文，訪問網(wǎng)站時，它如果讀取到這些信息，就會使用這些信息自動登錄了。

所以可以看出，無論對于什么Web應用程序，如果該瀏覽器曾經(jīng)登錄過，服務器端生成了session，客戶端Cookie中記錄了SessionID，該瀏覽器沒有關閉，那么，即便該瀏覽器訪問其他的站點后，再回到該應用系統(tǒng)，如果Session沒有失效，那么應用程序還會認為你是登錄的。

而對于身份驗證的頁面，一般是不做判斷，判斷你的用戶名稱和密碼是通過POST，還是URL中參數(shù)方式提交的。除此以外，有的應用程序會從URL中參數(shù)判斷你是否登錄，這種方式由于不安全目前已經(jīng)應用不多，早些年很多門戶網(wǎng)站的郵件就是這種機制，用戶登錄時會根據(jù)一些特性生成一個很長的字符串，通過該字符串來判斷是否登錄了，所以當時會發(fā)生，如果在另外一臺機器上拷貝了該URL，也會進入郵箱的情況。

還有一種特殊情況，這是HTTP協(xié)議支持的，就是BASIC認證方式，它會在用戶初次訪問時彈出對話框，用戶輸入用戶名和密碼后，瀏覽器會記住，然后每次HTTP請求時，在Header里面將用戶名稱和密碼的BASE64位形式傳給服務器，服務器就會知道該用戶的身份了，之所以在這里單獨提出這種方式，是因為下文介紹的自己編寫的SSO實現(xiàn)很難對付這種驗證方式，所以，如果后端系統(tǒng)（例如Lotus Domino）同時也支持Form身份驗證，就需要改過來，如果不支持或者不能改過來，將是很棘手的一件事情。

二、SSO的實現(xiàn)-第三方產(chǎn)品

本節(jié)討論的是基于第三方產(chǎn)品實現(xiàn)SSO。

目前，有很多產(chǎn)品支持SSO，使用Weblogic Portal，我們也主張用戶使用這些產(chǎn)品，因為他們能夠很好的通過配置，甚至是自學習的方式實現(xiàn)SSO，開發(fā)者需要完成的工作很少。

這些產(chǎn)品，一般實現(xiàn)的方式有兩類：第一類是通過Agent的方式，即在后端每個Web應用系統(tǒng)，或者其他系統(tǒng)都安裝一個Agent，由Agent來接管該系統(tǒng)的身份驗證和訪問控制，同時，需要有一臺策略服務器，里面會放置Weblogic Portal的用戶信息，以及這些用戶與其他系統(tǒng)的用戶對應信息，當然，Weblogic Portal也可以繼續(xù)保留自己的用戶，該策略服務器只是存放了用戶的對應關系。這類產(chǎn)品對于不同的系統(tǒng)，Agent不同，這些Agent能夠通過配置，輕松的接管了后面的系統(tǒng)的身份驗證和訪問控制，所以，舉例來說，如果Portal中用戶A對應系統(tǒng)1中的用戶B，那么策略服務器中有此配置后，當從Portal訪問系統(tǒng)1時，系統(tǒng)1的agent能夠辨別portal用戶A，就可以知道該系統(tǒng)對應的用戶是B，讓系統(tǒng)認為當前用戶就是B，然后使用B的身份來訪問和操作系統(tǒng)1。這類產(chǎn)品的使用方式還可以是，通過一個統(tǒng)一的LDAP，存放企業(yè)內(nèi)部的用戶信息，然后通過策略服務器，控制了后端所有系統(tǒng)的URL訪問權限，這樣也實現(xiàn)了單點登錄。

這種方式的優(yōu)點是：策略服務器不會存儲其他系統(tǒng)的密碼，密碼還是保存在各個系統(tǒng)中，同時，各個系統(tǒng)的訪問都由Agent控制，用戶必須經(jīng)過Portal作為入口，同時，可以通過策略服務器靈活的配置訪問控制。缺點在于：需要在各個系統(tǒng)安裝Agent；對于沒有Agent的系統(tǒng)，需要通過安裝Web Agent，然后進行一定的編碼實現(xiàn)；Portal作為單一入口，一旦當機，無法訪問后臺系統(tǒng)。缺點解決：Weblogic Portal可以通過構建集群實現(xiàn)負載均衡和容錯，避免單點故障。

第二類是通過Proxy的方式，即具有一個Proxy Server，由它來接管對于后端系統(tǒng)的訪問，提交請求和讀取數(shù)據(jù)，然后再返回給Portal，同時也有一個LDAP服務器或者策略服務器，該服務器可以存放用戶信息以及用戶的對應關系。Proxy Server的作用是接收Portal的請求，提交給后端系統(tǒng)，然后將返回的數(shù)據(jù)再寫給Portal，Proxy Server會通過存儲的用戶對應關系和用戶名和密碼，自動完成后端系統(tǒng)的登錄，然后就象一個瀏覽器一樣，提取數(shù)據(jù)，返回數(shù)據(jù)給后端系統(tǒng)。

該方法的優(yōu)點是：后端系統(tǒng)不用做任何改動。即便是沒有Portal，其他系統(tǒng)還可以照常使用。缺點是：需要在策略服務器中存儲用戶名稱和密碼，密碼會多處存放，同步困難；用戶可以繞開Portal，直接訪問后端系統(tǒng)。Proxy Server可能是單點故障。

缺點解決：目前有密碼同步產(chǎn)品；Proxy Server也大多支持集群。

由以上兩種方式可以看出，哪種方式的編程量都不是很大，大多可以通過配置來實現(xiàn)，而且功能也很強大，例如第一節(jié)說的BASIC登錄方式，這些產(chǎn)品都支持。而Weblogic Portal通過其支持多身份驗證提供者，以及良好的開發(fā)框架等的特點，能夠完全支持這兩種方式。如果客戶銀子大把，優(yōu)先應該考慮使用第三方產(chǎn)品。

可是如果客戶預算不大，后端系統(tǒng)又不多，有什么解決方法呢？答案當然是有，但不是萬能的。

三、Weblogic Portal的用戶

提到SSO，就不能不說說Weblogic Portal的用戶信息。作為一個統(tǒng)一，簡單，可擴展的企業(yè)級應用平臺Weblogic Platform中的一部分，Weblogic Portal被容納在Weblogic Platform統(tǒng)一的安全框架中，它使用的用戶和組，就是weblogic Server的用戶和組，但是與Weblogic Server不同的是，它的角色是Portal特有的，與Server是完全不同意義的，需要注意不要混淆了。

Weblogic Server安裝后缺省時是使用自帶的內(nèi)嵌的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服務器來存儲用戶和組，同時，也支持數(shù)據(jù)庫和AD。通過設置，可以指定使用哪個身份驗證提供者作為缺省的。也可以設置多個Provider直接的驗證關系如何。

本文中不會對如何配置進行說明，感興趣的朋友，可以查閱Weblogic Server關于Security的相關的幫助。使用數(shù)據(jù)庫作為驗證，可以參見筆者另外一個帖子：

http://dev2dev./bbs/thread.jspa?forumID=101&threadID=18563

由此可以看到，如果客戶需要的SSO指的就僅僅是，能夠使用他們企業(yè)內(nèi)部已有的LDAP或者AD用戶，進行Weblogic Portal登錄和身份驗證的話，那么，只要配置多個身份驗證提供者就可以了，就可以使用那些已經(jīng)存在的用戶。但是，如果客戶需要的SSO并不局限于此，還需要在Portal上登錄以后，再訪問其他一些基于Web的應用系統(tǒng)時，就不需要重復輸入用戶名和密碼和重復登錄了，那么，僅僅通過配置是無法實現(xiàn)的。即便那些系統(tǒng)和Portal理想狀態(tài)下都使用相同的LDAP或者AD用戶，由于每個系統(tǒng)驗證用戶是否登錄以后的機制不同，還是需要進行定制開發(fā)的。

四、自己開發(fā)實現(xiàn)SSO

Portal作為統(tǒng)一的入口，將其他基于Web的應用集成到Portal中，方式可以是多種多樣的，最簡單的是Portal上提供鏈接，直接打開其他系統(tǒng)的界面，進行操作；再復雜一點的就是通過Frame或者Iframe的方法，將其他系統(tǒng)的界面嵌入到Portal中，但實質(zhì)還是使用其他系統(tǒng)的界面，Portal只是從大范圍（例如包含了其他應用的Portlet）來控制用戶的訪問權限，這兩種主要解決的就是能夠繞過其他系統(tǒng)的登錄，然后讓其他系統(tǒng)能夠識別當前用戶的對應身份，至于其他系統(tǒng)內(nèi)部自己的個性化，權限等，還是由各個系統(tǒng)自己控制的。Weblogic Portal的Web應用集成還有其他方式，例如通過web clipping的方式，生成Portlet；或者通過HttpControl，取得Http回應的內(nèi)容，組成Portlet；或者完全使用后端系統(tǒng)的API，重構Web內(nèi)容，例如通過Lotus Domino的API，訪問Lotus Domino的數(shù)據(jù)庫，直接讀取視圖或者文檔的信息等。但這幾種方式都已經(jīng)不再使用原來的系統(tǒng)界面，所以，涉及的內(nèi)容在本文SSO討論中沒有包括。本節(jié)討論的就是開始時提到的兩種方式如何解決。

經(jīng)過前面身份驗證，Session，Cookie等方面的說明，我想，很多人大概已經(jīng)知道如何自己編寫程序來實現(xiàn)簡單的SSO了，在論壇上筆者也看到有的朋友這樣做了，其實說來很簡單：

1、在數(shù)據(jù)庫或者LDAP中存儲Portal用戶和其他系統(tǒng)用戶的對應關系，包括其他系統(tǒng)用戶名稱和密碼，根據(jù)不同系統(tǒng)的驗證特點，有的可能還要存儲密碼的密文形式。

2、在Portal登錄時，或者在切換到其他系統(tǒng)時，通過Iframe將用戶名稱和密碼通過URL傳遞過去，進行后端的登錄。

以后端系統(tǒng)為Dev2dev.為例，可以通過查看登錄頁面的源文件，知道Form的action是login.jspa，那么，當Portal用戶驗證正確以后，可以在頁面中加入

<iframe width=1 height=1 src=‘http://dev2dev./bbs/login.jspa?username=YOURUSERNAME&password=YOURPASSWORD‘></iframe>

<a href="http://dev2dev./bbs/settings!default.jspa">Dev2dev.</a>

將上面的YOURUSERNAME和YOURPASSWORD替換為Portal用戶對應的用戶名稱和密碼，打開頁面后，點擊該鏈接，可以看到，當前用戶已經(jīng)是登錄以后的身份。

當然，可以去掉下面的連接，直接設置iframe的width和height為足夠大，就可以將dev2dev.包括在其中。

以上應該是一個JSP頁面（因為你要動態(tài)的設置名稱和密碼），通過該JSP頁面產(chǎn)生Portlet，就可以嵌入到Portal中，正如我們前面所說，你不能通過Portal控制你登錄以后的樣式，個性化等屬性，但是你可以通過控制用戶訪問該Portlet的權限，從而實現(xiàn)Portal內(nèi)高層次的個性化和顯示控制。（其實，通過JavaScript，也完全可以改變Iframe中的內(nèi)容和樣式，這個超出本文的主題，略過）

以上就是一個SSO的自己編程的簡單實現(xiàn)，但是，這種方法具有很多需要注意的地方和局限性：

1、對方的登錄表單，可能不僅僅是傳遞了用戶名稱和密碼，可能還有其他的參數(shù)，需要多次嘗試，如果能夠看到對方驗證的代碼最好。

2、對方有可能進行了Form是POST還是GET提交的判斷（例如，驗證頁面是Servlet），如果一定需要使POST，那么可以使iframe中src是一個相同的form表單，action指向對方的驗證頁面，然后，通過Javascript，進行隱式提交；更有甚者，有的驗證頁面還判斷了是否是本服務器提交的請求，那么，就要嵌入對方的登錄表單，然后在iframe所在的頁面內(nèi)，通過Javascript使iframe內(nèi)的頁面提交，完成登錄。

3、有的系統(tǒng)為了安全，密碼傳輸前已經(jīng)在客戶端通過Javascript進行了加密，注意檢查。

4、有的系統(tǒng)很特別，一定要在瀏覽器的_top窗口中進行驗證，或者驗證以后在_top中打開后繼的頁面，對于這種系統(tǒng)，請修改對方的程序，否則很難解決。筆者曾經(jīng)就遇見過此類案例，嘗試多次無果，幸好后來發(fā)現(xiàn)對方系統(tǒng)能夠設置后繼的頁面，將后繼的頁面設置為Portal，再轉回Portal才可以。

5、Portal用戶會和多個系統(tǒng)的用戶有對應關系，需要設計一個好的數(shù)據(jù)結構，如果后端系統(tǒng)為多個，不一定非要在Portal登錄驗證后隱式登錄所有的系統(tǒng)，可以在需要顯示哪個系統(tǒng)時，再隱式登錄。

五、小結

以上就是個人關于SSO和Weblogic Portal的實現(xiàn)的一些看法，經(jīng)驗和心得體會，希望能對相關朋友有所幫助。值得一提的是，Weblogic Portal通過Portlet源的多樣性和靈活性，為自己開發(fā)編程實現(xiàn)SSO，提供了強有力的支持。

我們現(xiàn)在至少有三種以上的方案可以解決：

1、在JSP頁面上用netui:anchor 來實現(xiàn)頁面到action的跳轉，在action中進行處理之后，在回到本頁面。

2、如果將代碼寫到JSP中，我們可以通過取得當前的page的com.bea.portlet.PostbackURL 來進行定位。

3、參考workshop中由Control自動創(chuàng)建的JPF中的實現(xiàn)方式。

第一種方案思路如下：

頁面流開始，在Action中取出所有要顯示的數(shù)據(jù)，分頁，并顯示第一頁。當在jsp中點擊第二頁時，頁面流回到Action，在Action中首先得到頁數(shù)，然后計算第二頁應該load的數(shù)據(jù)，并load這些數(shù)據(jù)，然后跳向原先的jsp，但是在這個jsp中綁定的數(shù)據(jù)已經(jīng)是第二頁的數(shù)據(jù)了。

代碼詳見：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,自己調(diào)用自己的時候，url地址不要寫文件名，而是利用portlet的類，根據(jù)當前環(huán)境（request & response）先創(chuàng)建一個url，然后跳轉到這個url，置于不同頁需要不同的參數(shù)（page）值，則在代碼中使用url. addParameter方法，注意在add之前最好先清一下Parameter，否則可能加得很長。

代碼詳見：pageTest.jsp

Java page flow 是基于strus的，建議將邏輯代碼都寫到action中，使用workshop提供的NetUI，一般的功能都可以實現(xiàn)。在jsp中盡量不寫代碼，盡量不要jsp之間直接跳轉。

以上兩個例子您可以直接拖入您的工程，可以直接運行。形成portlet放入portal后也測試過了。

第三種方案思路：參考workshop中由Control自動創(chuàng)建的JPF中的實現(xiàn)方式。

附件：

http://dev2dev./bbs/servlet/D2DServlet/download/101-12443-65787-523/說明及實例.rar