監(jiān)理公司管理系統(tǒng) | 工程企業(yè)管理系統(tǒng) | OA系統(tǒng) | ERP系統(tǒng) | 造價咨詢管理系統(tǒng) | 工程設(shè)計管理系統(tǒng) | 甲方項目管理系統(tǒng) | 簽約案例 | 客戶案例 | 在線試用
X 關(guān)閉

授權(quán)

申請免費試用、咨詢電話:400-8352-114

AMTeam.org

授權(quán)

在上周的專欄文章(英文)中,我們討論了設(shè)計收藏 Web 服務(wù)時的用戶保密問題。根據(jù)對用戶保密問題的初步調(diào)查,我們決定在收藏服務(wù)的初版中集中討論三個主要的使用方案:

Web 站點(如 msdn.microsoft.com)在每一個頁面上均提供一個按鈕,用戶可以通過單擊此按鈕將該頁面添加至存儲在收藏服務(wù)的用戶收藏夾中。

msdn.microsoft.com 提供一個網(wǎng)頁用以顯示用戶的收藏,這些收藏最初由 msdn.microsoft.com 代表用戶存儲在收藏服務(wù)中。

msdn.microsoft.com 提供一個 Web 應(yīng)用程序,使用戶可以管理最初由 msdn.microsoft.com 代表用戶存儲在收藏服務(wù)中的收藏。
實際上,每個使用收藏服務(wù)的 Web 站點都可以獲取自己的有關(guān)用戶收藏的專用存儲區(qū)。即使在這套有限的方案中,我們?nèi)詻Q定將對服務(wù)的訪問限定在已知用戶范圍內(nèi),也就是說,我們需要對服務(wù)進行授權(quán)。

在本期專欄中,我們將詳細討論授權(quán)問題:定義 Web 服務(wù)的業(yè)務(wù)模型時需要考慮的問題;如何建立業(yè)務(wù)模型與授權(quán)的關(guān)聯(lián);選擇用于收藏服務(wù)的模式及其理由;以及所選模式對設(shè)計和實現(xiàn)的影響。

意見反饋

在開始之前,我想就上周專欄中讀者提出的幾個問題進行說明。

第一,就用戶保密問題,有讀者詢問我們將如何看待歐盟 (EU) 的數(shù)據(jù)保護條例。如果想知道“什么是歐盟數(shù)據(jù)保護條例?”,請訪問 http://europa.eu.int/comm/internal_market/en/media/dataprot/(英文)。由于我們的項目組服務(wù)于 Microsoft,同時我們計劃在 Microsoft 擁有的設(shè)備上承載收藏服務(wù),所以我們所展開的服務(wù)必須符合 Microsoft 在 EU 數(shù)據(jù)指令方面的政策。

我們的項目組目前正在與 Microsoft 的公司政策小組協(xié)同工作,以確保在我們的產(chǎn)品服務(wù)器上展開的收藏服務(wù)符合 Microsoft 的政策。如果我們最終為滿足 EU 的要求而采取了某些“特別”措施,我們一定會通知大家。但是,請注意:我們?yōu)榉?Microsoft 的政策而需要采取的措施并不等同于讀者為符合其公司的政策而需要采取的措施。這個例子說明了為什么在整個項目周期中您始終需要法律顧問的協(xié)助,以確保無論您的客戶、員工和服務(wù)器位于何處,您的保密政策均符合當前的法律。

第二,有讀者詢問如果將收藏服務(wù)與某些其他功能結(jié)合起來并展開一項新的服務(wù),應(yīng)該如何處理 Logon 組件。簡單地說,Logon 組件的方法是通過收藏 Web 服務(wù)公開的??蛻舳藨?yīng)用程序(在此處為新服務(wù))必須先調(diào)用 Logon 方法,然后才能使用用戶收藏管理方法。下期專欄將討論身份驗證和授權(quán)問題,請在下周閱讀詳細內(nèi)容。

Web 服務(wù)業(yè)務(wù)模型

大多數(shù)與最終用戶直接進行交互的 Web 站點都采用幾種業(yè)務(wù)模型。從用戶角度考慮,有以下幾個選項:

用戶可以隨意訪問站點的全部功能。

用戶必須先申請一個免費帳戶,才能訪問站點的部分或全部功能。

用戶必須先支付訂閱費,才能訪問站點的部分或全部功能。訂閱方式通常使用戶可以在指定的時間段內(nèi)無限制地訪問某些功能。

用戶必須先按次支付使用費用,才能訪問某些內(nèi)容。

業(yè)務(wù)模型的另一方面是如何收回站點的開發(fā)和運行費用:

將開發(fā)和運行費用簡單地計為業(yè)務(wù)成本。

用戶支付站點訪問費。

將站點空間出售給廣告商或其他站點。

就現(xiàn)狀而言,這些模型并不能真正有效地為 Web 服務(wù)效力。通常,最終用戶并不直接使用 Web 服務(wù)。而且 Web 服務(wù)的使用是有規(guī)劃的,因此不能完全靠廣告來獲取收益。但是,在定義 Web 服務(wù)的業(yè)務(wù)模型時,用于 Web 站點的模式可以幫助我們確定某些要考慮的因素。這些需要確定的因素包括:客戶、定價、付款方式、訂閱、通知和付帳、寬限期、身份驗證、審核以及客戶服務(wù)。

客戶

您需要了解的第一個問題是:您想與哪些客戶建立業(yè)務(wù)協(xié)議。通常,Web 服務(wù)提供商會與要在應(yīng)用中使用 Web 服務(wù)的應(yīng)用程序開發(fā)人員建立業(yè)務(wù)協(xié)議。如果 Web 服務(wù)用于存儲針對用戶的數(shù)據(jù),那么除了與應(yīng)用開發(fā)人員建立協(xié)議之外,Web 服務(wù)還可能會與最終用戶建立協(xié)議(或者不與應(yīng)用程序開發(fā)人員建立協(xié)議)。另一種可能是 Web 服務(wù)提供商與一個或多個應(yīng)用提供者 (ASP) 建立業(yè)務(wù)協(xié)議,以駐留服務(wù)。而 ASP 又與應(yīng)用程序開發(fā)人員和/或最終用戶(如果需要)建立關(guān)系。

定價

一旦確定了客戶,您便可以開始考慮這些客戶對您的服務(wù)的價值,以及他們愿意付多少錢來獲取服務(wù)。有一點您應(yīng)當考慮,即,是應(yīng)當根據(jù)申請的次數(shù)(每次查閱收費模式)來指定價格,還是規(guī)定在某一時間段內(nèi)無限制使用(租用模式)。其他因素包括:是否對各類申請的價格都一樣;是否對所有客戶的價格都一樣;以及對每個用戶的價格是否始終不變。

付款方式

如果您打算對服務(wù)收費,您需要考慮客戶支付服務(wù)費用的機制。直接與最終用戶進行交互的 Web 站點通常接受信用卡方式。但是,有些訪問您的 Web 服務(wù)的公司不希望使用信用卡作為付款方式。您可能需要接受支票或電匯的付款方式。

另一個需要考慮的因素是,客戶是必須預(yù)先付款、現(xiàn)購現(xiàn)付還是事后付款。如果客戶可以事后付款,您可能需要設(shè)置未付費用的上限。您可能會對所有客戶實行標準限制,或針對每個客戶設(shè)置不同的限制。

訂閱

無論您是否對您所提供的服務(wù)收取費用,您都需要使用某種方式來確定誰正在調(diào)用服務(wù)。在這種情況下,每個客戶都需要與您建立一個帳戶(或訂閱)關(guān)系。他們?nèi)绾闻c您建立這種關(guān)系呢?

您需要考慮:是立即為申請帳戶的客戶授予帳戶,還是在授予帳戶前先執(zhí)行一定的審批程序。如果需要審批過程,客戶是否可以通過 Web 進行申請,或者需要致電客戶服務(wù)代表?是否需要指定員工調(diào)查和批準新帳戶申請?

您還應(yīng)當考慮在授予帳戶前需要哪些信息,以及詢問用戶哪些可選信息。這些信息可能會歸入個人可識別信息類別,需要通過應(yīng)有的信息條例(如上周的專欄所述)進行保護。

另一個要考慮的因素是,是否允許客戶選擇自己的帳戶標識符和密碼(如果有),或者隨機生成標識符和密碼。如果客戶可以選擇自己的帳戶標識符,您可能需要處理標識符重復的問題。

您還需要考慮用戶如何維護自己的帳戶信息(包括密碼)??蛻羰欠袷褂媚?Web 站點,以及他們是否能夠致電客戶服務(wù)代表?如果客戶忘記了帳戶標識符或密碼怎么辦?

通知和付帳

如果您的訂閱有時間限制,您需要定義流程來通CRM/zhike/ target=_blank class=infotextkey>知客戶其訂閱即將到期。如果您對服務(wù)收費,而客戶并非現(xiàn)購現(xiàn)付,您會遇到同樣的問題。您應(yīng)當考慮用哪種介質(zhì)來通知客戶。例如,可以發(fā)電子郵件、打電話或發(fā)送發(fā)票。您還應(yīng)當考慮通知客戶的次數(shù),以及每次是否使用同一種介質(zhì)。您計劃在訂閱到期前預(yù)先通知幾次?

如果對服務(wù)收取費用,尤其是按申請次數(shù)收費,則應(yīng)當考慮要求客戶多長時間付一次帳。客戶不會希望收到一張有成千上萬項獨立費用(每次申請服務(wù)一項)的帳單。也許您想按天、按周或按月匯總費用,并為需要費用細目的客戶提供詳細的使用報告。

寬限期

您應(yīng)當考慮:如果訂閱已過期或付款期限已過,是否允許存在寬限期。如果指定寬限期,則需要考慮寬限期的長短,以及寬限期間是否對帳戶進行限制。例如,客戶只能查詢現(xiàn)有信息,而不能保存新信息。另一個需要考慮的因素是,寬限期間是否向客戶發(fā)送其他通知。

身份驗證

從更側(cè)重技術(shù)的層次來說,如果客戶需要通過帳戶來訪問您的服務(wù),則您需要考慮當客戶申請服務(wù)時如何驗證他們的身份。目前所使用的身份驗證機制有三種基本類型:通信協(xié)議身份驗證功能、應(yīng)用級別身份驗證功能以及第三方身份驗證。最直接的方法是,借助用于與 Web 服務(wù)交換消息的通信協(xié)議的功能。例如,Microsoft Internet Information Server 5.0 支持幾種 HTTP 身份驗證機制。另一個選擇是在 Web 服務(wù)中實行自定義身份驗證機制。例如,如果您的 Web 服務(wù)可以接受 SOAP 消息,則客戶憑據(jù)可以在 SOAP 標題中傳遞或作為 SOAP 正文中的元素傳遞。最后,您可以使用第三方服務(wù)(例如 Microsoft Passport)來解決身份驗證問題。

每一種可用的機制都有其優(yōu)劣之處。某些機制相對其他機制而言更加安全。某些機制不能受到用于創(chuàng)建 Web 服務(wù)的開發(fā)人員工具的廣泛支持。某些機制要求客戶從第三方獲取證書或帳戶。某些機制具有顯著的性能額外開銷。您需要針對客戶權(quán)衡這些機制的利弊,以確定哪種機制適合您的 Web 服務(wù)。有關(guān)當前可用的 Web 服務(wù)身份驗證選項的進一步信息,請參閱 Web 服務(wù)安全性(英文)。

審核

您要考慮的另外一個問題是,收集審核所需的信息。請考慮如果發(fā)生帳單或客戶保密問題的爭端,您需要掌握哪些信息。如果按申請次數(shù)收費,則可能會存在大量數(shù)據(jù)。請考慮每天要收集的數(shù)據(jù)量以及如何存檔數(shù)據(jù)。是否應(yīng)當創(chuàng)建標準報表以幫助避免或解決爭端?

客戶服務(wù)

最后,請考慮您需要提供什么樣的客戶服務(wù)。例如,您可能需要提供客戶服務(wù)以便申請和管理訂閱。您很可能需要為客戶提供報告問題的途徑,以便他們在訪問或使用服務(wù)遇到問題時使用。您還可能需要為開發(fā)人員提供某種途徑,以幫助他們編寫使用您的服務(wù)的程序。

對于每一種客戶服務(wù),您都需要考慮提供該服務(wù)的方式??蛻羰欠裥枰褂?Web 站點來獲取幫助?客戶是否能夠發(fā)送電子郵件?客戶是否可以通過電話進行聯(lián)系?無論您決定使用哪種選項,您需要準備什么工具和設(shè)施,才能提供有效支持?

業(yè)務(wù)模型和授權(quán)

考慮好這九個方面的問題后,您應(yīng)當對您的 Web 服務(wù)采用的業(yè)務(wù)模型有了一個清晰的概念。如何將這一模型與授權(quán)聯(lián)系起來呢?

當我們使用術(shù)語“許可協(xié)議”時,我們指的是客戶與 Web 服務(wù)提供商之間就 Web 服務(wù)的使用所達成的協(xié)議。除非您的業(yè)務(wù)模型是匿名的且任何人都可以訪問,否則很可能會涉及許可協(xié)議。例如,建立帳戶或訂閱時可能會要求客戶接受一定的使用條款。在某些情況下會要求客戶先閱讀或簽署許可協(xié)議,才能批準其訂閱。在談到僅允許授權(quán)客戶訪問的 Web 服務(wù)時,我們通常使用術(shù)語“授權(quán)模型”而不是“業(yè)務(wù)模型”。

收藏授權(quán)模型

根據(jù)第一版的收藏服務(wù)中選定使用的方案,我們已經(jīng)定義了客戶群:打算使用收藏服務(wù)的應(yīng)用開發(fā)人員(或更確切地說,開發(fā)機構(gòu))。下一個要關(guān)注的問題是客戶在使用服務(wù)前是否要先進行訂閱。先考慮如果不要求訂閱會怎么樣。

假設(shè)某個應(yīng)用打算開始使用收藏服務(wù)保存收藏。出于用戶保密的考慮,我們決定每個調(diào)用方都可以獲得自己的數(shù)據(jù)存儲區(qū)。應(yīng)當如何識別存儲區(qū)?如果調(diào)用方為存儲區(qū)指定了名稱,則可能兩個調(diào)用方會指定相同的名稱,我們無法將他們區(qū)分開來。我們可以提供一種 CreateStore 方法,用于返回唯一的數(shù)據(jù)存儲區(qū)標識符。但是,如果唯一標識符丟失或被盜怎么辦?由于我們沒有將唯一標識符綁定到特定調(diào)用方的信息,因此我們無法檢索丟失的標識符。對被盜的標識符,我們也將束手無策。事實上,我們甚至無法確認報告標識符被盜的人與創(chuàng)建數(shù)據(jù)存儲區(qū)的調(diào)用方有任何關(guān)系。

總之,我們最好要求客戶登錄后進行訂閱。這樣,我們便可以收集足夠的聯(lián)系信息,以處理丟失或被盜的帳戶標識符或密碼。如果我們檢測到某個特定應(yīng)用使用收藏服務(wù)的方法有問題,我們還可以通過這些聯(lián)系信息與之取得聯(lián)系。

到此為止,我們可以確定我們的授權(quán)模型應(yīng)該為:為提供了聯(lián)系信息(并或許已閱讀了保密政策或其他聲明)的開發(fā)機構(gòu)授予免費、終生無限制的使用許可協(xié)議。但是,我們決定將系統(tǒng)設(shè)計為能夠支持更復雜的業(yè)務(wù)模型,以便查看對整個系統(tǒng)設(shè)計的影響。

在第一階段中,收藏服務(wù)被授權(quán)給打算在其應(yīng)用中使用該服務(wù)的開發(fā)機構(gòu)。授權(quán)的規(guī)則如下:

在指定的時間段內(nèi)被授權(quán)者可以無限制地訪問服務(wù)。

被授權(quán)者必須預(yù)先支付服務(wù)費用。收費比率將根據(jù)授權(quán)時間的長短以及被授權(quán)者管理其收藏的最終用戶的總數(shù)量決定。

許可協(xié)議到期前一個月,將通過電子郵件通知被授權(quán)者。

許可協(xié)議到期前一周,將通過電話通知被授權(quán)者。

許可協(xié)議期滿后,將給予被授權(quán)者十天的寬限期。

授權(quán)流程如下圖所示:


圖 1:收藏授權(quán)流程

開始授權(quán)過程時,必須與客戶帳戶代表取得聯(lián)系。許可協(xié)議生效前,所有費用都將以發(fā)票方式通知被授權(quán)者,同時必須收到被授權(quán)者支付的費用。許可協(xié)議生效后,將通過電子郵件將使用收藏服務(wù)所需的所有信息通知被授權(quán)者的業(yè)務(wù)聯(lián)系人。協(xié)議生效后,24 小時之內(nèi)收藏服務(wù)可能無法識別新的被授權(quán)者。

所有新許可協(xié)議的有效期為三個月,收費比例為每位用戶 $0.00。三個月期滿后,許可協(xié)議可以更新為三個月、六個月、一年或兩年。費用的收取將根據(jù)被授權(quán)者管理其收藏的用戶數(shù)量來決定。功能規(guī)格(英文)定義了費用的計算方法。

為了計算續(xù)訂許可協(xié)議的費用,以及在發(fā)生付帳糾紛時保護我們的權(quán)益,收藏服務(wù)會將每一次調(diào)用及其結(jié)果(成功、客戶端錯誤或服務(wù)器錯誤)都記錄到 Web 服務(wù)。

請注意,要求 MSDN 公布其實際實現(xiàn)該授權(quán)模型所有功能的示例服務(wù)是不切實際的。例如,我們沒有客戶帳戶代表(他們答復新的許可協(xié)議申請,或在許可協(xié)議到期前一周通知被授權(quán)者)。我們也并不想對使用示例服務(wù)的人收取費用。但是,我們認為設(shè)計一個可以支持此授權(quán)模型的系統(tǒng)是非常重要的。在實際的實施過程中,我們將作出一些修改,以便嘗試已開展的服務(wù),而不必為獲取許可協(xié)議而爭論不休。當然,我們會指出我們在設(shè)計和實施上的不同之處。但愿這不會太復雜。

實現(xiàn)收藏中的授權(quán)

您可能會想,為支持授權(quán)模型,收藏服務(wù)的復雜性一定增加了不少。僅僅實現(xiàn)一個 COM 組件并將其發(fā)布為 Web 服務(wù),這當然是不夠的。我們需要采用某種方式,讓潛在的客戶申請訂閱;讓客戶維護其帳戶信息;還需要某些工具來生成續(xù)訂通知。我們需要收集每次調(diào)用服務(wù)的數(shù)據(jù),以便計算續(xù)訂許可協(xié)議的費用。我們還需要實現(xiàn)身份驗證機制。下圖顯示了我們的系統(tǒng)結(jié)構(gòu)的高層次視圖:


圖 2:第一階段的收藏服務(wù)授權(quán)體系結(jié)構(gòu)

客戶通過收藏 Web 站點申請訂閱或更改帳戶信息。Web 站點將驗證輸入的數(shù)據(jù),將申請傳遞到 Licensing 組件,并顯示已收到申請的確認信息。一般來說,收藏服務(wù)不會立即批準訂閱或更改帳戶信息,而是將掛起的申請保存起來,由客戶帳戶代表進行驗證。當接受申請后,將向被授權(quán)者的聯(lián)系人發(fā)送電子郵件,確認申請已完成。

Licensing 組件實現(xiàn)了授權(quán)模型的業(yè)務(wù)邏輯。每種授權(quán)組件方法的基本結(jié)構(gòu)都相同:初始化 Audit 對象以創(chuàng)建審核日志項,驗證輸入的參數(shù),調(diào)用存儲的過程以更新相應(yīng)的數(shù)據(jù)庫,在需要時發(fā)送電子郵件通知,用方法的結(jié)果更新 Audit 對象,并保存審核日志項。某些業(yè)務(wù)規(guī)則是在存儲過程(而不是 Licensing 組件)中強制執(zhí)行的。電子郵件通過 IIS SMTP 服務(wù)發(fā)送。

我們的授權(quán)模型流程通過存儲在 Licensee 和 Notifications 數(shù)據(jù)庫中的一套狀態(tài)標志來實施。例如,當某個潛在客戶申請新許可協(xié)議時,新的被授權(quán)者記錄將寫入 Licensees 數(shù)據(jù)庫,其狀態(tài)設(shè)為 pending。同樣,發(fā)送許可協(xié)議續(xù)訂通知時,該通知也將記錄在 Notifications 數(shù)據(jù)庫中。

在業(yè)務(wù)模型的真實實現(xiàn)過程中,在批準新的許可協(xié)議或更改聯(lián)系人信息之前,客戶帳戶代表將驗證客戶的聯(lián)系信息。“收藏許可協(xié)議管理系統(tǒng) (FLMS)”是基于 Web 的應(yīng)用,客戶帳戶代表可以使用該應(yīng)用查看掛起的申請,并接受或拒絕這些申請。由于沒有客戶帳戶代表,我們僅實現(xiàn)了對幾個申請的支持。您可以看看這是如何實現(xiàn)的。與外部客戶 Web 站點一樣,F(xiàn)LMS 依靠 Licensing 組件完成大部分工作。

在我們展開的 MSDN 服務(wù)中不存在任何客戶帳戶代表,因此我們實施了稱為 AutoAdmin 的進程,該進程檢查掛起的申請,并使用 Licensing 組件的服務(wù)自動批準申請。我們還需要一種自動生成續(xù)訂通知的方法。這在另一個稱為 Renewals 的進程中實現(xiàn),該進程每天運行一次。

為了計算續(xù)訂的許可協(xié)議費用,以及記錄必要的信息以解決付帳或客戶保密問題的爭端,我們使用前面提到的 Audit 組件,將每次申請收藏 Web 服務(wù)和 Web 站點的結(jié)果都記錄在 Audit Log 數(shù)據(jù)庫中。每個審核日志記錄都包含以下信息:提出申請的被授權(quán)者、代表其創(chuàng)建申請的用戶、申請的操作類型、申請操作的時間、處理申請所需的時間以及申請的結(jié)果。這些信息用于計算日常使用統(tǒng)計數(shù)字,這些統(tǒng)計數(shù)字構(gòu)成了“報表”服務(wù)的核心。一旦計算出日常使用的統(tǒng)計數(shù)字,便可以將原始審核日志報表存檔。

最后,如果我們沒有適當?shù)姆椒▉眚炞C Web 服務(wù)的調(diào)用者身份,所有這些支持基礎(chǔ)設(shè)施將不會給我們帶來任何好處。我們?yōu)槭詹胤?wù)選擇了實施應(yīng)用級別的身份驗證。要使用收藏服務(wù)的應(yīng)用必須首先調(diào)用 Logon 服務(wù)以獲取密鑰。每次申請使用收藏和報表 Web 服務(wù)時,都必須提供此密鑰。如果密鑰有效,才會允許繼續(xù)操作。否則,訪問將被拒絕。

總結(jié)

由此可見,Web 服務(wù)所使用的業(yè)務(wù)模型將對系統(tǒng)的整體要求產(chǎn)生重大影響。您應(yīng)當盡早定義業(yè)務(wù)模型,以免將來發(fā)現(xiàn)需要對系統(tǒng)體系結(jié)構(gòu)作大幅度的修改。另一方面,描述您的客戶愿意接受什么樣的業(yè)務(wù)模型可能比較困難。您應(yīng)當考慮使用靈活的設(shè)計,以便順應(yīng)業(yè)務(wù)模型的變化。

下周,我們將繼續(xù)探討在實現(xiàn)收藏服務(wù)過程中所遇到的設(shè)計問題,進一步討論身份驗證和授權(quán)問題。

發(fā)布:2007-03-25 13:54    編輯:泛普軟件 · xiaona    [打印此頁]    [關(guān)閉]
相關(guān)文章:
太原OA系統(tǒng)
聯(lián)系方式

成都公司:成都市成華區(qū)建設(shè)南路160號1層9號

重慶公司:重慶市江北區(qū)紅旗河溝華創(chuàng)商務(wù)大廈18樓

咨詢:400-8352-114

加微信,免費獲取試用系統(tǒng)

QQ在線咨詢