專(zhuān)利名稱(chēng)：服務(wù)器裝置以及通信系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及具有網(wǎng)絡(luò)應(yīng)用程序的訪問(wèn)控制功能的服務(wù)器裝置以及通信系統(tǒng)。
背景技術(shù)：
以往，在一般使用的網(wǎng)絡(luò)應(yīng)用程序(web application)中，根據(jù)用戶(hù)的權(quán)限來(lái)限制 能夠訪問(wèn)(access)的畫(huà)面，或者限制畫(huà)面內(nèi)的鏈接等畫(huà)面項(xiàng)目的顯示。作為其具體的實(shí)現(xiàn) 方法，列舉了使用了伺服小程序過(guò)濾器(servlet filter)的功能的URL (統(tǒng)一資源定位器 Uniform Resource Locater)的許可、使用了 JSP (JAVA (注冊(cè)商標(biāo))Script)的標(biāo)簽庫(kù)(tag library)的畫(huà)面顯示項(xiàng)目的許可。圖10是表示URL許可設(shè)定信息的記載例子的圖。圖11是表示畫(huà)面顯示項(xiàng)目許可 設(shè)定信息的記載例子的圖。使用了過(guò)濾器功能的URL的許可的技術(shù)，是通過(guò)如圖10所示，在部署描述符 (deployment descriptor)、或?qū)Ｓ玫脑O(shè)定文件(file)中記載許可策略(policy)來(lái)實(shí)現(xiàn) 的。此外，關(guān)于使用了 JSP的自定義標(biāo)簽(custom tag)的畫(huà)面顯示項(xiàng)目的許可 的技術(shù)公開(kāi)例如“Spring SeCurity、“online”、“平成21年9月11日検索”、因特網(wǎng) (internet) <URL :http://static, springsource. org/spring_security/site/>“中。該技 術(shù)是如圖11所示通過(guò)分別在各畫(huà)面用的JSP文件中記載許可策略來(lái)實(shí)現(xiàn)的。此外，作為關(guān) 于該畫(huà)面顯示項(xiàng)目的許可的技術(shù)，如日本特開(kāi)2009-123062號(hào)公報(bào)中公開(kāi)的一樣，根據(jù)用 戶(hù)的權(quán)限來(lái)定義用于顯示或不顯示的內(nèi)容，按照該內(nèi)容來(lái)實(shí)現(xiàn)畫(huà)面顯示項(xiàng)目的許可。但是，用于對(duì)網(wǎng)絡(luò)應(yīng)用程序進(jìn)行訪問(wèn)控制的許可策略，在許可策略是URL許可的 情況下，是用部署描述符或URL許可用的策略記載文件來(lái)表示的。此外，許可策略是畫(huà)面顯 示項(xiàng)目的許可的情況是，該許可策略是用各JSP文件或畫(huà)面顯示項(xiàng)目許可用的策略記載文 件來(lái)表示的。因此，URL許可的許可策略的記載場(chǎng)所與畫(huà)面顯示項(xiàng)目的許可的許可策略的 記載場(chǎng)所分散。因此，為了進(jìn)行角色(Role)的追加或刪除、角色名的變更等許可策略的變 更，就需要分別對(duì)部署描述符或各文件進(jìn)行變更，這樣就提高了網(wǎng)絡(luò)應(yīng)用程序運(yùn)行的負(fù)擔(dān)。

發(fā)明內(nèi)容
本發(fā)明的目的在于提供一種服務(wù)器裝置以及通信系統(tǒng)，能夠容易地管理以及切換 對(duì)于網(wǎng)絡(luò)應(yīng)用程序的訪問(wèn)控制的許可策略。本發(fā)明提供一種服務(wù)器裝置，其特征在于，具備用戶(hù)信息存儲(chǔ)部，存儲(chǔ)對(duì)每個(gè)用 戶(hù)確定了角色信息的用戶(hù)信息，該角色信息表示網(wǎng)絡(luò)應(yīng)用程序的用戶(hù)的角色；許可執(zhí)行要 點(diǎn)存儲(chǔ)部，存儲(chǔ)許可執(zhí)行要點(diǎn)定義信息，該許可執(zhí)行要點(diǎn)定義信息是將與所述網(wǎng)絡(luò)應(yīng)用程 序的使用相關(guān)的許可的執(zhí)行要點(diǎn)的識(shí)別信息、用于識(shí)別與該執(zhí)行要點(diǎn)對(duì)應(yīng)的許可策略的許 可策略識(shí)別信息、以及多個(gè)種類(lèi)中任意許可類(lèi)別分別針對(duì)各種許可類(lèi)別關(guān)聯(lián)起來(lái)而得的許 可執(zhí)行要點(diǎn)定義信息；許可策略存儲(chǔ)部，存儲(chǔ)許可策略定義信息，該許可策略定義信息確定了與由所述許可執(zhí)行要點(diǎn)定義信息確定的許可策略識(shí)別信息相對(duì)應(yīng)、并且與所述多個(gè)種類(lèi) 的各個(gè)許可類(lèi)別相對(duì)應(yīng)的許可策略；屬性信息取得部，從所述用戶(hù)信息取得進(jìn)行了訪問(wèn)請(qǐng) 求的所述用戶(hù)的角色信息，并取得含有該角色信息的、與該訪問(wèn)請(qǐng)求相關(guān)的屬性信息；許可 策略評(píng)價(jià)部，根據(jù)從用戶(hù)的終端裝置對(duì)所述網(wǎng)絡(luò)應(yīng)用程序的訪問(wèn)請(qǐng)求來(lái)取得與所述使用相 關(guān)的許可的執(zhí)行要點(diǎn)的識(shí)別信息，從所述許可執(zhí)行要點(diǎn)定義信息取得與該識(shí)別信息相關(guān)聯(lián) 的許可策略識(shí)別信息以及許可類(lèi)別，從所述許可策略定義信息取得與該取得的許可策略識(shí) 別信息以及許可類(lèi)別相對(duì)應(yīng)的許可策略，將該取得結(jié)果與由所述屬性信息取得部取得的屬 性信息相對(duì)照，由此來(lái)評(píng)價(jià)所述取得的許可策略；以及訪問(wèn)控制執(zhí)行部，根據(jù)所述許可策略 評(píng)價(jià)部的評(píng)價(jià)結(jié)果來(lái)進(jìn)行對(duì)所述網(wǎng)絡(luò)應(yīng)用程序的訪問(wèn)控制。


圖1是表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)的畫(huà)面構(gòu)成的一個(gè)例子 的圖。圖2是以表格形式表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)管理的訪問(wèn) 控制信息的構(gòu)成例子的圖。圖3是表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)的功能構(gòu)成例子的框圖。圖4是以表格形式表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)管理的用戶(hù) 信息的構(gòu)成例子的圖。圖5是表示由本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)顯示的菜單(menu)畫(huà) 面的記載例子的圖。圖6是表示由本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)顯示的檢索結(jié)果畫(huà)面 的記載例子的圖。圖7是表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)管理的許可執(zhí)行要點(diǎn)定 義信息的記載例子的圖。圖8是表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)管理的許可策略定義信 息的記載例子的圖。圖9是表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)處理動(dòng)作的順序的一個(gè) 例子的圖。圖10是表示許可設(shè)定信息的記載例子的圖。圖11是表示顯示項(xiàng)目許可設(shè)定信息的記載例子的圖。
具體實(shí)施例方式以下參考附圖對(duì)本發(fā)明的實(shí)施方式進(jìn)行說(shuō)明。在本實(shí)施方式中，對(duì)管理工作人員信息的工作人員信息管理系統(tǒng)的訪問(wèn)控制進(jìn)行 說(shuō)明。圖1是表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)的畫(huà)面構(gòu)成的一個(gè)例子 的圖。圖2是以表格形式表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)管理的訪問(wèn)控制 信息的構(gòu)成例子的圖。該訪問(wèn)控制信息是將工作人員信息管理系統(tǒng)中的各畫(huà)面名、該畫(huà)面的請(qǐng)求路徑(request pass)、該畫(huà)面的可訪問(wèn)用戶(hù)(user)以及該畫(huà)面內(nèi)的畫(huà)面項(xiàng)目信息關(guān)聯(lián)起來(lái)的信 息。該畫(huà)面項(xiàng)目信息被區(qū)分為對(duì)每個(gè)畫(huà)面項(xiàng)目賦予的畫(huà)面項(xiàng)目ID和該畫(huà)面項(xiàng)目的可顯示 用戶(hù)的信息。該工作人員信息管理系統(tǒng)將用戶(hù)設(shè)定為一般用戶(hù)和管理者這兩類(lèi)，給一般用戶(hù)分 配角色I(xiàn)serRole”、給管理者分配角色“AdminRole”，根據(jù)進(jìn)行訪問(wèn)的用戶(hù)的角色來(lái)進(jìn)行 訪問(wèn)控制。工作人員信息管理系統(tǒng)的主(main)畫(huà)面是如圖1所示的菜單畫(huà)面Gl。如圖2所 示，菜單畫(huà)面Gl的請(qǐng)求路徑是“/empMenu”。如圖2的訪問(wèn)控制信息中可訪問(wèn)用戶(hù)欄中所示 的一樣，對(duì)于一般用戶(hù)和管理者雙方許可根據(jù)該請(qǐng)求路徑訪問(wèn)菜單畫(huà)面Gl的URL。此外，如圖1所示，在菜單畫(huà)面Gl中具有鏈接到工作人員信息檢索畫(huà)面G2的鏈接 “工作人員信息檢索”和鏈接到工作人員信息登錄畫(huà)面G4的鏈接“工作人員信息登錄”。根 據(jù)用戶(hù)是一般用戶(hù)還是管理者來(lái)對(duì)是否顯示這些鏈接進(jìn)行切換。如圖2所示，賦予菜單畫(huà)面Gl的第一個(gè)鏈接“工作人員信息檢索”的畫(huà)面項(xiàng)目ID 是“l(fā)ink_Search”。此外，賦予菜單畫(huà)面Gl的第二個(gè)鏈接“工作人員信息登錄”的畫(huà)面項(xiàng)目 ID 是“l(fā)ink_regist”。這里，工作人員信息管理系統(tǒng)如圖2的訪問(wèn)控制信息中畫(huà)面項(xiàng)目欄中所示，對(duì)于 具有角色“AdminRole”的管理者訪問(wèn)菜單畫(huà)面Gl時(shí)，將鏈接“工作人員信息檢索”以及鏈 接“工作人員信息登錄” 一起作為該菜單畫(huà)面Gl的顯示對(duì)象。另一方面，工作人員信息管 理系統(tǒng)對(duì)于不具有角色“AdminRole”的一般用戶(hù)訪問(wèn)菜單畫(huà)面Gl時(shí)，將鏈接“工作人員信 息檢索”作為該菜單畫(huà)面Gl的顯示對(duì)象，而不將鏈接“工作人員信息登錄”作為該菜單畫(huà)面 Gl的顯示對(duì)象。此外，工作人員信息管理系統(tǒng)，如圖2的訪問(wèn)控制信息中可訪問(wèn)用戶(hù)欄所示，對(duì)于 工作人員信息檢索畫(huà)面G2以及檢索結(jié)果畫(huà)面G2，設(shè)為一般用戶(hù)和管理者雙方都可訪問(wèn)，對(duì) 于工作人員信息登錄畫(huà)面G4、工作人員信息刪除畫(huà)面G5以及工作人員信息更新畫(huà)面G6設(shè) 為僅有管理者可訪問(wèn)。此外，管理者能夠在檢索結(jié)果畫(huà)面G3中，通過(guò)在終端裝置1的操作選擇檢索結(jié)果 一覽中的工作人員的信息，在此基礎(chǔ)上在工作人員信息更新畫(huà)面G6上進(jìn)行工作人員信息 的更新，或者能夠在工作人員信息刪除畫(huà)面G5上進(jìn)行工作人員信息的刪除。因此，工作人 員信息管理系統(tǒng)在圖2所示的檢索結(jié)果畫(huà)面G3中，僅對(duì)管理者將向工作人員信息更新畫(huà)面 G6的鏈接“更新”和向工作人員信息刪除畫(huà)面G5的鏈接“刪除”來(lái)組合進(jìn)行顯示，對(duì)于不是 管理者的一般用戶(hù)不顯示任何鏈接。此外，如圖2的訪問(wèn)控制信息的畫(huà)面項(xiàng)目ID欄所示，對(duì)檢索結(jié)果畫(huà)面G3的第一個(gè) 鏈接“更新”以及第二個(gè)鏈接“刪除”集中賦予畫(huà)面項(xiàng)目ID "link_update_delete"0圖3是表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)的功能構(gòu)成例子的框圖。本實(shí)施方式中的工作人員信息管理系統(tǒng)具有終端裝置1以及網(wǎng)絡(luò)應(yīng)用程序服務(wù)2 ο終端裝置1例如是個(gè)人計(jì)算機(jī)(personal computer)，具有用于使用網(wǎng)絡(luò)應(yīng)用程 序服務(wù)器2提供的服務(wù)(service)的任意的網(wǎng)絡(luò)瀏覽器(browser)的執(zhí)行功能。網(wǎng)絡(luò)應(yīng)用程序服務(wù)器2具有訪問(wèn)控制執(zhí)行裝置3。該訪問(wèn)控制執(zhí)行裝置3具備掌6管整個(gè)裝置的處理動(dòng)作的控制部31、存儲(chǔ)裝置32、通信接口(interface) 33、認(rèn)證部34、訪 問(wèn)檢測(cè)部35、屬性信息取得部36、許可策略評(píng)價(jià)部37以及訪問(wèn)控制執(zhí)行部38，分別經(jīng)由總 線(bus)而相互連接。存儲(chǔ)裝置32例如是硬盤(pán)驅(qū)動(dòng)器(hard disc drive)或非易失性存儲(chǔ)器(memory) 等存儲(chǔ)介質(zhì)。該存儲(chǔ)裝置32除了存儲(chǔ)用于認(rèn)證部34、訪問(wèn)檢測(cè)部35、屬性信息取得部36、 許可策略評(píng)價(jià)部37以及訪問(wèn)控制執(zhí)行部38的處理動(dòng)作的程序之外，還具有用戶(hù)信息存儲(chǔ) 部41、許可執(zhí)行要點(diǎn)存儲(chǔ)部42、許可策略存儲(chǔ)部43。圖4是以表格形式表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)管理的用戶(hù) 信息的構(gòu)成例子的圖。用戶(hù)信息存儲(chǔ)部41存儲(chǔ)圖4所示的形式的用戶(hù)信息。該用戶(hù)信息是將各用戶(hù)的 用戶(hù)ID、密碼(password)以及角色關(guān)聯(lián)起來(lái)的信息。該用戶(hù)信息能夠通過(guò)管理者在終端裝 置1的規(guī)定的操作來(lái)進(jìn)行變更。在圖4所示的用戶(hù)信息中，用戶(hù)ID為“taro”的用戶(hù)的角色是“AdminRole”，用戶(hù) ID為“ jiro”或“saburo”的用戶(hù)的角色是IserRole”。即，用戶(hù)ID為“taro”的用戶(hù)具有 管理者的權(quán)限。此外，用戶(hù)ID為“jiro”或“saburo”的用戶(hù)是不具有管理者權(quán)限的一般用戶(hù)。通信接口 33被連接成可以對(duì)終端裝置1進(jìn)行通信。認(rèn)證部34確認(rèn)利用系統(tǒng)的用 戶(hù)是否認(rèn)證完畢，當(dāng)該用戶(hù)是未認(rèn)證的情況下，根據(jù)以用戶(hù)信息定義的用戶(hù)ID以及密碼進(jìn) 行認(rèn)證處理。認(rèn)證部34，在認(rèn)證成功了的情況下，在存儲(chǔ)裝置32內(nèi)管理的HTTP會(huì)話(session) 中存儲(chǔ)角色。在本實(shí)施方式中，雖然記載了在網(wǎng)絡(luò)應(yīng)用程序服務(wù)器2中進(jìn)行認(rèn)證的構(gòu)成，但 是也可以利用例如認(rèn)證服務(wù)器或訪問(wèn)管理服務(wù)器等、別的中間件(middleware)進(jìn)行認(rèn)證。訪問(wèn)檢測(cè)部35檢測(cè)來(lái)自用戶(hù)的訪問(wèn)。具體地，訪問(wèn)檢測(cè)部35為了分別進(jìn)行URL的 許可和畫(huà)面顯示項(xiàng)目的許可，分別利用過(guò)濾器功能和JSP的標(biāo)簽庫(kù)來(lái)進(jìn)行訪問(wèn)檢測(cè)。此外， 訪問(wèn)檢測(cè)部35在訪問(wèn)檢測(cè)時(shí)取得許可執(zhí)行要點(diǎn)ID，該許可執(zhí)行要點(diǎn)ID表示是在哪個(gè)執(zhí)行 要點(diǎn)的許可。在本實(shí)施方式中，為了 URL許可，在將規(guī)定的過(guò)濾器名作為許可執(zhí)行要點(diǎn)ID的基 礎(chǔ)上，訪問(wèn)檢測(cè)部35從設(shè)定文件取得許可執(zhí)行要點(diǎn)ID，該設(shè)定文件是在文件功能初始化時(shí) 定義了文件名的文件。在本實(shí)施方式中，將過(guò)濾器功能的許可執(zhí)行要點(diǎn)ID設(shè)為“filter”。圖5是表示由本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)顯示的菜單(menu)畫(huà) 面的記載例子的圖。圖6是表示由本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)顯示的檢索 結(jié)果畫(huà)面的記載例子的圖。如圖5、圖6所示的記載例子是各畫(huà)面的JSP過(guò)濾器的記載例子。在本實(shí)施方式中， 為了進(jìn)行畫(huà)面顯示項(xiàng)目的許可，如圖5、圖6所示，將對(duì)各畫(huà)面的JSP過(guò)濾器中的畫(huà)面顯示項(xiàng) 目的記載部分中顯示或非顯示進(jìn)行切換的部分用authorize標(biāo)簽進(jìn)行封裝，指定許可執(zhí)行 要點(diǎn)ID作為該標(biāo)簽的屬性。在本實(shí)施方式中，將指定為authorize標(biāo)簽的ID屬性(id)的 “taglib”設(shè)為用于畫(huà)面顯示項(xiàng)目許可的許可執(zhí)行要點(diǎn)ID。標(biāo)簽庫(kù)在顯示各畫(huà)面時(shí)，取得該 畫(huà)面的JSP文件內(nèi)的許可執(zhí)行要點(diǎn)ID。此外，屬性信息取得部36根據(jù)來(lái)自用戶(hù)的訪問(wèn)要求，取得在許可中使用的主題(subject)、資源(resource)、動(dòng)作(action)即屬性信息。在本實(shí)施方式中，屬性信息取得 部36取得由認(rèn)證部34存儲(chǔ)到HTTP會(huì)話中的角色來(lái)作為主題。此外，屬性信息取得部36，在進(jìn)行URL的許可時(shí)，從HTTP請(qǐng)求中取得成為資源的請(qǐng) 求目的地URL，從該HTTP請(qǐng)求中取得成為動(dòng)作的HTTP方法(method)。此外，屬性信息取得 部36，在進(jìn)行畫(huà)面顯示項(xiàng)目的許可時(shí)，取得畫(huà)面項(xiàng)目ID作為資源。該畫(huà)面項(xiàng)目ID如圖5、圖6所示，被指定為JSP文件中所示的authorize標(biāo)簽的 "resld"屬性，屬性信息取得部36在JSP文件顯示時(shí)取得該值。在本實(shí)施方式中，為了將 進(jìn)行畫(huà)面顯示項(xiàng)目許可時(shí)的動(dòng)作限定為“顯示”，屬性信息取得部36取得缺省(default)值 “DISP”作為動(dòng)作。在本實(shí)施方式中，雖然將由屬性信息取得部36取得的屬性信息作為主題、資源以 及動(dòng)作，但是在進(jìn)行使用了時(shí)間或連接源ID地址(address)的許可時(shí)，屬性信息取得部36 例如也可以重新取得這些信息作為環(huán)境條件(條件(condition))。圖7表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)管理的許可執(zhí)行要點(diǎn)定義 信息的記載例子的圖。許可執(zhí)行要點(diǎn)存儲(chǔ)部42存儲(chǔ)圖7所示的形式的許可執(zhí)行要點(diǎn)定義信息。該許可 執(zhí)行要點(diǎn)定義信息是定義了許可執(zhí)行要點(diǎn)的識(shí)別信息即許可執(zhí)行要點(diǎn)ID(id)、在該許可執(zhí) 行要點(diǎn)中適用的許可策略(policyid)、和許可類(lèi)別(type)的信息。該信息是能夠通過(guò)來(lái)自 終端裝置1的規(guī)定的操作進(jìn)行改寫(xiě)的信息。在圖7所示的例子中，作為許可執(zhí)行要點(diǎn)定義信息中的許可執(zhí)行要點(diǎn)ID，定義有 用于執(zhí)行URL許可的所述“filter”和用于執(zhí)行畫(huà)面顯示項(xiàng)目許可的所述“taglib”這兩種。 此外，如圖7所示，作為與各自的許可執(zhí)行要點(diǎn)ID相對(duì)應(yīng)的許可策略，指定有通用的許可策 略 ID “policy_001”。此外，許可執(zhí)行要點(diǎn)定義信息中的許可類(lèi)別是如前所述的多個(gè)類(lèi)別，在許可執(zhí)行 要點(diǎn)ID是“filter”的情況下指定“url”為許可類(lèi)別，在許可執(zhí)行要點(diǎn)ID是“taglib”的 情況下指定“gitem”為許可類(lèi)別。這些許可類(lèi)別是為了在進(jìn)行許可策略評(píng)價(jià)時(shí)區(qū)別作為評(píng) 價(jià)對(duì)象的資源和動(dòng)作而定義的。圖8是表示本發(fā)明的實(shí)施方式中工作人員信息管理系統(tǒng)管理的許可策略定義信 息的記載例子的圖。許可策略存儲(chǔ)部43存儲(chǔ)圖8所示的形式的許可策略定義信息。該許可策略定義 信息是表示誰(shuí)(主題)對(duì)什么(資源)能夠做什么(動(dòng)作)的信息。如圖8所示，許可策略定義信息是記載在XML文件中、能夠通過(guò)來(lái)自終端裝置1的 規(guī)定動(dòng)作進(jìn)行改寫(xiě)的信息。在本實(shí)施方式中，雖然許可策略定義信息記載在XML文件中，但 也可以是使用RDB來(lái)描述的信息。在該許可策略定義信息中，能夠設(shè)定多個(gè)許可策略。這 些許可策略由圖7中所示的許可執(zhí)行要點(diǎn)定義信息表示的許可策略ID來(lái)識(shí)別。在圖8所 示的例子中，許可策略定義信息中的許可策略ID由Policy標(biāo)簽封裝，該許可策略中，定義 有第1許可策略和第2許可策略。第1許可策略是被賦予許可策略ID “pOliCy_001”的許 可策略。此外，第2許可策略是被賦予許可策略ID "policy_002的許可策略。此外，與許可策略ID對(duì)應(yīng)的各許可策略由一個(gè)或多個(gè)規(guī)則(rule)構(gòu)成，在該規(guī)則 中指定主題、資源、動(dòng)作。許可策略定義信息中的各許可策略中的各規(guī)則用rule標(biāo)簽封裝。各規(guī)則的主題用Subject標(biāo)簽封裝。各規(guī)則的資源用Resource標(biāo)簽封裝。各規(guī)則的動(dòng)作 用Action標(biāo)簽封裝。對(duì)于主題、資源、動(dòng)作是否與屬性信息取得部36中取得的主題、資源、 動(dòng)作一致的判定，是按照eval屬性中指定的方法來(lái)進(jìn)行的。在本實(shí)施方式中，evalType屬 性中設(shè)定的“full ”表示進(jìn)行全文一致的判定，“part”表示進(jìn)行部分一致的判定。如果評(píng)價(jià)對(duì)象的許可策略的一個(gè)規(guī)則中的主題、資源以及動(dòng)作與屬性信息取得部 36取得的主題、資源以及動(dòng)作一致，那么該規(guī)則的評(píng)價(jià)結(jié)果就是“true”。S卩，如果評(píng)價(jià)對(duì)象 的許可策略中含有的規(guī)則的任意一個(gè)的評(píng)價(jià)結(jié)果是“ture”，則在許可策略定義信息中的評(píng) 價(jià)對(duì)象的許可策略的Policy要素的effect屬性中指定的值“permit”就是許可策略的評(píng) 價(jià)結(jié)果。另一方面，如果評(píng)價(jià)對(duì)象的許可策略中含有的任何規(guī)則都不是“ture”，則“deny” 就是評(píng)價(jià)結(jié)果。在圖8所示的例子中，在許可策略定義信息的賦予許可策略ID "policy_001"的 許可策略中定義了兩個(gè)規(guī)則。第1個(gè)規(guī)則指定了含有以下的3個(gè)條件的規(guī)則。第1條件是 主題是具有IserRole”或“AdminRole”的用戶(hù)。第2條件是在許可類(lèi)別是“url ”時(shí)，資源 中含有向菜單畫(huà)面Gl的請(qǐng)求路徑“/empMenu”、向工作人員信息檢索畫(huà)面G2的請(qǐng)求路徑“/ empkarch”、或向檢索結(jié)果畫(huà)面G3的請(qǐng)求路徑“/empkarchResult”。第3條件為許可類(lèi)別 "url ”的動(dòng)作是“GET”或者“POST”。此外，第2規(guī)則指定含有以下6個(gè)條件的規(guī)則。第1條件是主題是具有 "AdminRole"的用戶(hù)。第2條件是在許可類(lèi)別是“url ”時(shí)，資源中含有向工作人員信 息登錄畫(huà)面G4的請(qǐng)求路徑“/empRegist”、向工作人員信息刪除畫(huà)面G5的請(qǐng)求路徑“/ empDelete”、或向工作人員信息更新畫(huà)面G6的請(qǐng)求路徑“/empUpdate”。第3條件是許可 類(lèi)別是“taglib”。第4條件為資源含有圖2所示的鏈接“工作人員信息登錄”的畫(huà)面項(xiàng)目 ID “l(fā)ink_regist”、或鏈接“更新”以及鏈接“刪除”中通用的畫(huà)面項(xiàng)目ID "link_update_ delete”。第5條件是在許可類(lèi)別是“url”時(shí)動(dòng)作是“GET”或“POST”。第6條件是在許可 類(lèi)別是“taglib”時(shí)動(dòng)作是“DISP”。S卩，在本實(shí)施方式中，在單一文件中記載用于許可是否訪問(wèn)通過(guò)網(wǎng)絡(luò)應(yīng)用程序顯 示的畫(huà)面的許可策略、以及用于許可是否顯示畫(huà)面內(nèi)的畫(huà)面顯示項(xiàng)目的許可策略。雖然在本實(shí)施方式中如圖8 一樣定義了許可策略，但是許可策略的定義方法不是 特別現(xiàn)定于此，也可以是其它定義方法。此外，許可策略評(píng)價(jià)部37從圖7所示的許可執(zhí)行要點(diǎn)定義信息取得與由訪問(wèn)檢測(cè) 部35取得完畢的許可執(zhí)行要點(diǎn)ID對(duì)應(yīng)的許可策略ID以及許可類(lèi)別。并且，許可策略評(píng)價(jià) 部37從圖8所示的許可策略定義信息取得與該取得的許可策略ID對(duì)應(yīng)的許可策略的主 題、取得完畢的許可類(lèi)別的資源、取得完畢的許可類(lèi)別的動(dòng)作。進(jìn)一步，許可策略評(píng)價(jià)部37 通過(guò)將從該許可策略定義信息取得的信息與由屬性信息取得部36取得的主題、資源、動(dòng)作 的屬性信息相對(duì)照，來(lái)評(píng)價(jià)許可策略。訪問(wèn)控制執(zhí)行部38根據(jù)許可策略評(píng)價(jià)部37的評(píng)價(jià)結(jié)果來(lái)執(zhí)行訪問(wèn)控制。在本實(shí) 施方式中，訪問(wèn)控制執(zhí)行部38，當(dāng)URL的許可時(shí)，在許可成功時(shí)使得訪問(wèn)用戶(hù)所要求的URL， 在許可失敗時(shí)將顯示畫(huà)面遷移到許可錯(cuò)誤(error)畫(huà)面。此外，訪問(wèn)控制執(zhí)行部38，當(dāng)許可畫(huà)面顯示項(xiàng)目時(shí)，在許可成功時(shí)在顯示畫(huà)面上顯9示用戶(hù)所要求的畫(huà)面項(xiàng)目，在許可失敗時(shí)不顯示用戶(hù)所要求的畫(huà)面項(xiàng)目。此外，服務(wù)邏輯(service logic)執(zhí)行裝置14是執(zhí)行提供給用戶(hù)的服務(wù)功能的裝置。然后，對(duì)上述所示的構(gòu)成的系統(tǒng)中的訪問(wèn)控制的動(dòng)作進(jìn)行說(shuō)明。圖9是表示本發(fā) 明的實(shí)施方式中工作人員信息管理系統(tǒng)處理動(dòng)作的順序的一個(gè)例子的圖。首先，說(shuō)明在URL許可時(shí)的作用。網(wǎng)絡(luò)應(yīng)用程序服務(wù)器2的訪問(wèn)控制執(zhí)行裝置3 的認(rèn)證部34，接受通過(guò)終端裝置1的網(wǎng)絡(luò)瀏覽器來(lái)自用戶(hù)ID是“taro”的用戶(hù)的請(qǐng)求，檢 查(check)用戶(hù)是否認(rèn)證完畢。如果未認(rèn)證，網(wǎng)絡(luò)應(yīng)用程序服務(wù)器2就在終端裝置1的網(wǎng) 絡(luò)瀏覽器的顯示畫(huà)面中顯示登陸(log-in)畫(huà)面，使用戶(hù)從終端裝置1的網(wǎng)絡(luò)瀏覽器來(lái)輸入 用戶(hù)ID以及密碼。然后，認(rèn)證部34經(jīng)由通信接口 33取得用戶(hù)輸入的用戶(hù)ID以及密碼，將該取得結(jié) 果與圖2所示的用戶(hù)信息中存儲(chǔ)的用戶(hù)ID以及密碼進(jìn)行比較，由此來(lái)進(jìn)行認(rèn)證。如果認(rèn)證 成功，則認(rèn)證部34在HTTP會(huì)話中存儲(chǔ)角色。在本實(shí)施方式中，在認(rèn)證后，與圖2所示的用 戶(hù)信息表示的所述用戶(hù)ID “taro”相關(guān)聯(lián)的角色“AdminRole”被存儲(chǔ)到HTTP會(huì)話中(步 驟 Si)。訪問(wèn)檢測(cè)部35檢測(cè)來(lái)自終端裝置1的用戶(hù)的訪問(wèn)，這里就是檢測(cè)在網(wǎng)絡(luò)瀏覽器上 指定菜單畫(huà)面Gl的請(qǐng)求路徑“/empMenu”作為URL的訪問(wèn)。這種情況下，訪問(wèn)檢測(cè)部35取 得存儲(chǔ)裝置32中預(yù)先存儲(chǔ)的許可執(zhí)行要點(diǎn)ID “filter”，來(lái)作為檢測(cè)到指定請(qǐng)求路徑的訪 問(wèn)時(shí)的過(guò)濾器名(步驟S2)。然后，訪問(wèn)檢測(cè)部35對(duì)屬性信息取得部36請(qǐng)求取得屬性信息。接受了屬性信息 取得請(qǐng)求的屬性信息取得部36取得在URL許可中使用的主題、資源以及動(dòng)作來(lái)作為屬性 信息，將該取得的屬性信息返回給訪問(wèn)檢測(cè)部35。具體地，屬性信息取得部36取得在步 驟Sl的處理中存儲(chǔ)在HTTP會(huì)話中的用戶(hù)的角色“AdminRole”作為主題，從該HTTP請(qǐng)求 取得 “http://xxx. XXX. co. jp/empManage/empMenu” 作為資源，取得 HTTP 方法中的 “GET”、 “POST”作為動(dòng)作，將這些取得結(jié)果作為屬性信息返回給訪問(wèn)檢測(cè)部35(步驟S3)。然后，訪問(wèn)檢測(cè)部35向許可策略評(píng)價(jià)部37請(qǐng)求許可策略評(píng)價(jià)。在該請(qǐng)求時(shí)，訪問(wèn) 檢測(cè)部35將在步驟S2的處理中取得的許可執(zhí)行要點(diǎn)ID、在步驟S3的處理中由屬性信息取 得部36取得的屬性信息即主題、資源以及動(dòng)作轉(zhuǎn)交給許可策略評(píng)價(jià)部37。許可策略評(píng)價(jià)部37參照?qǐng)D7所示的許可執(zhí)行要點(diǎn)定義信息的內(nèi)容，取得與從訪問(wèn) 檢測(cè)部35轉(zhuǎn)交的許可執(zhí)行要點(diǎn)ID“filter”相對(duì)應(yīng)的許可策略的許可策略ID“pOlicy_001” 以及許可類(lèi)別“url”。然后，許可策略評(píng)價(jià)部37通過(guò)參照?qǐng)D8所示的許可策略定義信息，來(lái)取得如上 所述地取得完畢的許可策略ID “pOlicy_001”的許可策略。并且，許可策略評(píng)價(jià)部37將 根據(jù)步驟S3的處理從屬性信息取得部36作為屬性信息而取得的主題“AdminRole”、資 源 “http://xxx. XXX. co. jp/empManage/empMenu”、動(dòng)作 “GET”、“POST” 與取得完畢的許可 策略中定義的規(guī)則相對(duì)照。此時(shí)，關(guān)于該規(guī)則內(nèi)的資源、動(dòng)作，將許可策略定義信息中的 Resource要素、Action要素的屬性中定義了許可類(lèi)別“url”的內(nèi)容作為對(duì)照對(duì)象。在本實(shí)施方式中，對(duì)照的結(jié)果，從屬性信息取得部36作為屬性信息取得的主題、 資源、動(dòng)作的組合和與許可策略定義信息中的許可策略ID “pOlicy_001”對(duì)應(yīng)的許可策略的第1個(gè)規(guī)則一致，因此，規(guī)則的評(píng)價(jià)結(jié)果是“true”，最終的策略評(píng)價(jià)結(jié)果是“permit” (步 驟 S4)。許可策略評(píng)價(jià)部37將該評(píng)價(jià)結(jié)果返回訪問(wèn)檢測(cè)部35。訪問(wèn)檢測(cè)部35將從許可策 略評(píng)價(jià)部37取得的策略評(píng)價(jià)結(jié)果轉(zhuǎn)交給訪問(wèn)控制執(zhí)行部38，請(qǐng)求執(zhí)行訪問(wèn)控制。訪問(wèn)控制執(zhí)行部38接受來(lái)自訪問(wèn)檢測(cè)部35的策略評(píng)價(jià)結(jié)果“permit”，許可訪問(wèn) 用戶(hù)請(qǐng)求的“http://xxx. XXX. co. jp/empManage/empMenu”。在許可訪問(wèn)之后，網(wǎng)絡(luò)應(yīng)用程 序服務(wù)器2使服務(wù)邏輯執(zhí)行裝置4起動(dòng)。另一方面，訪問(wèn)控制執(zhí)行部38，當(dāng)許可策略評(píng)價(jià)的結(jié)果和所述的取得完畢的許可 策略的任何規(guī)則都不一致、策略評(píng)價(jià)的結(jié)果為“deny”時(shí)，將終端裝置1的顯示畫(huà)面遷移到 許可錯(cuò)誤畫(huà)面(步驟S5)。然后，作為畫(huà)面顯示項(xiàng)目的許可的作用，對(duì)一般用戶(hù)訪問(wèn)菜單畫(huà)面Gl時(shí)的作用進(jìn) 行說(shuō)明。網(wǎng)絡(luò)應(yīng)用程序服務(wù)器2的訪問(wèn)控制執(zhí)行裝置3的認(rèn)證部34，接受通過(guò)終端裝置1 的網(wǎng)絡(luò)瀏覽器來(lái)自用戶(hù)ID為“jiro”的用戶(hù)的請(qǐng)求，檢查用戶(hù)是否認(rèn)證完畢。如果未認(rèn)證， 網(wǎng)絡(luò)應(yīng)用程序服務(wù)器2就在終端裝置1的網(wǎng)絡(luò)瀏覽器的顯示畫(huà)面中顯示登陸畫(huà)面，使用戶(hù) 從終端裝置1的網(wǎng)絡(luò)瀏覽器來(lái)輸入用戶(hù)ID以及密碼。然后，認(rèn)證部34經(jīng)由通信接口 33取得用戶(hù)輸入的用戶(hù)ID以及密碼，將該取得結(jié) 果與圖2所示的用戶(hù)信息中存儲(chǔ)的用戶(hù)ID以及密碼進(jìn)行比較，由此來(lái)進(jìn)行認(rèn)證。如果認(rèn)證 成功，則認(rèn)證部34在HTTP會(huì)話中存儲(chǔ)角色。在本實(shí)施方式中，在認(rèn)證后，與圖2所示的用 戶(hù)信息表示的所述用戶(hù)ID “jiro”相關(guān)聯(lián)的角色“herRole”被存儲(chǔ)到HTTP會(huì)話中(步驟 Si)。訪問(wèn)檢測(cè)部35檢測(cè)通過(guò)菜單畫(huà)面Gl內(nèi)的JSP的標(biāo)簽庫(kù)對(duì)畫(huà)面顯示項(xiàng)目的訪問(wèn)。 在本實(shí)施方式中，通過(guò)圖5所示的JSP文件的authorize標(biāo)簽檢測(cè)訪問(wèn)，取得該標(biāo)簽的屬性 中設(shè)定的許可執(zhí)行要點(diǎn)ID “taglib” (步驟S2)。然后，訪問(wèn)檢測(cè)部35對(duì)屬性信息取得部36請(qǐng)求取得屬性信息。接受了屬性信息 取得請(qǐng)求的屬性信息取得部36取得在畫(huà)面顯示項(xiàng)目許可中使用的主題、資源以及動(dòng)作來(lái) 作為屬性信息，將該取得的屬性信息返回給訪問(wèn)檢測(cè)部35。具體地，屬性信息取得部36取 得在步驟Sl的處理中存儲(chǔ)在HTTP會(huì)話中的角色“herRole”作為主題，取得菜單畫(huà)面Gl 的JSP文件的authorize標(biāo)簽中設(shè)定的資源即畫(huà)面顯示項(xiàng)目ID “l(fā)ink_regiSt”，取得存儲(chǔ) 裝置32中預(yù)先存儲(chǔ)為缺省值的“DISP”作為動(dòng)作，將這些取得結(jié)果作為屬性信息返回給訪 問(wèn)檢測(cè)部35 (步驟S3)。然后，訪問(wèn)檢測(cè)部35向許可策略評(píng)價(jià)部37請(qǐng)求許可策略評(píng)價(jià)。在該請(qǐng)求時(shí)，訪問(wèn) 檢測(cè)部35將在步驟S2的處理中取得的許可執(zhí)行要點(diǎn)ID、在步驟S3的處理中由屬性信息取 得部36取得的屬性信息即主題、資源以及動(dòng)作轉(zhuǎn)交給許可策略評(píng)價(jià)部37。許可策略評(píng)價(jià)部37參照?qǐng)D7所示的許可執(zhí)行要點(diǎn)定義信息的內(nèi)容，取得與 從訪問(wèn)檢測(cè)部35轉(zhuǎn)交的許可執(zhí)行要點(diǎn)ID “taglib”相對(duì)應(yīng)的許可策略的許可策略 ID “policy_001，，、許可類(lèi)別 “gitem”。然后，許可策略評(píng)價(jià)部37通過(guò)參照?qǐng)D8所示的許可策略定義信息，來(lái)取得與如上 所述地取得完畢的許可策略ID “pOlicy_001”對(duì)應(yīng)的許可策略。并且，許可策略評(píng)價(jià)部37將根據(jù)步驟S3的處理從屬性信息取得部36作為屬性信息而取得的主題“herRole”、資源 “l(fā)ink_regist”、動(dòng)作“DISP”與取得完畢的許可策略中定義的規(guī)則相對(duì)照。此時(shí)，關(guān)于該規(guī) 則內(nèi)的資源、動(dòng)作，將許可策略定義信息中的Resource要素、Action要素的屬性中定義了 許可類(lèi)別“gitem”的內(nèi)容作為對(duì)照對(duì)象。在本實(shí)施方式中，對(duì)照的結(jié)果是，從屬性信息取得部36作為屬性信息取得的主 題、資源、動(dòng)作的組合和與許可策略定義信息中的許可策略ID “pOlicy_001”對(duì)應(yīng)的許可策 略的兩個(gè)規(guī)則的任意一個(gè)都不一致，因此，規(guī)則的評(píng)價(jià)結(jié)果是“false”，最終的策略評(píng)價(jià)結(jié) 果是“deny”(步驟S4)。許可策略評(píng)價(jià)部37將策略的評(píng)價(jià)結(jié)果“deny”返回訪問(wèn)檢測(cè)部35。訪問(wèn)檢測(cè)部 35將從許可策略評(píng)價(jià)部37取得的策略評(píng)價(jià)結(jié)果轉(zhuǎn)交給訪問(wèn)控制執(zhí)行部38，請(qǐng)求執(zhí)行訪問(wèn) 控制。訪問(wèn)控制執(zhí)行部38接受策略評(píng)價(jià)結(jié)果“deny”，將以用戶(hù)請(qǐng)求的菜單畫(huà)面Gl的JSP 文件的authorize標(biāo)簽封裝的區(qū)域的顯示項(xiàng)目設(shè)為不顯示(步驟S5)。以上，在本實(shí)施方式中，通過(guò)將與網(wǎng)絡(luò)應(yīng)用程序的URL許可和畫(huà)面顯示項(xiàng)目許可 這樣的多個(gè)種類(lèi)的許可類(lèi)別相關(guān)的許可策略作為相同的許可策略存儲(chǔ)在單一文件中集中 管理，就能夠減輕許可策略的變更等操作時(shí)的負(fù)擔(dān)。例如，在將角色的名稱(chēng)從“AdminRole” 變更成了 “AdRole”時(shí)，僅修正一個(gè)許可策略即可。此外，在想從某個(gè)許可策略暫時(shí)或永久地切換到別的許可策略的情況下，在將切 換前以及切換后的許可策略一起設(shè)定在許可策略定義信息中的前提下，僅通過(guò)對(duì)終端裝置 1的操作在必要時(shí)改寫(xiě)許可執(zhí)行要點(diǎn)定義信息中設(shè)定的許可策略ID，就能夠容易且迅速地 切換在許可策略定義信息中用于許可策略評(píng)價(jià)的許可策略。即，能夠?qū)⒁酝稚⒃诙鄠€(gè)場(chǎng)所的許可策略集中在一個(gè)場(chǎng)所進(jìn)行管理，就能夠容 易地切換許可策略。另外，本發(fā)明不限定于所述實(shí)施方式，而是能夠在實(shí)施階段在不脫離其主旨的范 圍內(nèi)對(duì)構(gòu)成要素進(jìn)行變形來(lái)具體化。此外，通過(guò)適當(dāng)?shù)亟M合所述實(shí)施方式中公開(kāi)的多個(gè)構(gòu) 成要素能夠形成多種發(fā)明。例如，可以從實(shí)施方式中所示的全部構(gòu)成要素中省略幾個(gè)構(gòu)成 要素。進(jìn)一步，也可以適當(dāng)?shù)亟M合不同的實(shí)施方式中的構(gòu)成要素。另外，所述實(shí)施方式中記載的方法也能夠作為可使計(jì)算機(jī)執(zhí)行的程序(program) 而存儲(chǔ)在磁盤(pán)(軟盤(pán)(floppy)(注冊(cè)商標(biāo))、硬盤(pán)等)、光盤(pán)(⑶-ROM、DVD等)、磁光盤(pán)(MO)、 半導(dǎo)體存儲(chǔ)器等存儲(chǔ)介質(zhì)中來(lái)發(fā)布。此外，作為該存儲(chǔ)介質(zhì)，可以是能夠存儲(chǔ)程序并且可讀取程序的存儲(chǔ)介質(zhì)，該存儲(chǔ) 形式可以是任意方式。此外，也可以根據(jù)從存儲(chǔ)介質(zhì)安裝(install)在計(jì)算機(jī)中的程序的指示，由 計(jì)算機(jī)上運(yùn)行的OS(操作系統(tǒng)(operating system))、數(shù)據(jù)庫(kù)(data base)管理軟件 (software)、網(wǎng)絡(luò)(network)軟件等MW(中間件)等來(lái)執(zhí)行用于實(shí)現(xiàn)上述實(shí)施方式的各處 理中一部分處理。進(jìn)一步，本發(fā)明中的存儲(chǔ)介質(zhì)不限于計(jì)算機(jī)和獨(dú)立的介質(zhì)，也含有將通過(guò)LAN或 因特網(wǎng)等傳送的程序下載(download)并存儲(chǔ)或暫時(shí)存儲(chǔ)的存儲(chǔ)介質(zhì)。此外，存儲(chǔ)介質(zhì)不限于一個(gè)，從多個(gè)介質(zhì)執(zhí)行所述實(shí)施方式中的處理的情況也包 含在本發(fā)明的存儲(chǔ)介質(zhì)中，介質(zhì)結(jié)構(gòu)可以是任意結(jié)構(gòu)。
此外，本發(fā)明的計(jì)算機(jī)根據(jù)存儲(chǔ)介質(zhì)中存儲(chǔ)的程序，來(lái)執(zhí)行所述實(shí)施方式中的各 處理，該計(jì)算機(jī)可以是由個(gè)人計(jì)算機(jī)等一個(gè)計(jì)算機(jī)構(gòu)成的裝置、也可以是多個(gè)裝置被網(wǎng)絡(luò) 連接后而得的系統(tǒng)等任意結(jié)構(gòu)。此外，本發(fā)明中的計(jì)算機(jī)不限于個(gè)人計(jì)算機(jī)，還包含信息處理設(shè)備中含有的運(yùn)算 處理裝置、微型計(jì)算機(jī)(microcomputer)等，將能夠通過(guò)程序?qū)崿F(xiàn)本發(fā)明的功能的設(shè)備、裝 置總稱(chēng)為本發(fā)明中的計(jì)算機(jī)。
權(quán)利要求
1.一種服務(wù)器裝置，其特征在于，具備用戶(hù)信息存儲(chǔ)部(41)，存儲(chǔ)對(duì)每個(gè)用戶(hù)確定了角色信息的用戶(hù)信息，該角色信息表示 網(wǎng)絡(luò)應(yīng)用程序的用戶(hù)的角色；許可執(zhí)行要點(diǎn)存儲(chǔ)部G2)，存儲(chǔ)許可執(zhí)行要點(diǎn)定義信息，該許可執(zhí)行要點(diǎn)定義信息是 將與所述網(wǎng)絡(luò)應(yīng)用程序的使用相關(guān)的許可的執(zhí)行要點(diǎn)的識(shí)別信息、用于識(shí)別與該執(zhí)行要點(diǎn) 對(duì)應(yīng)的許可策略的許可策略識(shí)別信息、以及多個(gè)種類(lèi)中任意許可類(lèi)別分別針對(duì)各種許可類(lèi) 別關(guān)聯(lián)起來(lái)而得的許可執(zhí)行要點(diǎn)定義信息；許可策略存儲(chǔ)部(43)，存儲(chǔ)許可策略定義信息，該許可策略定義信息確定了與由所述 許可執(zhí)行要點(diǎn)定義信息確定的許可策略識(shí)別信息相對(duì)應(yīng)、并且與所述多個(gè)種類(lèi)的各個(gè)許可 類(lèi)別相對(duì)應(yīng)的許可策略；屬性信息取得部(36)，從所述用戶(hù)信息取得進(jìn)行了訪問(wèn)請(qǐng)求的所述用戶(hù)的角色信息， 并取得含有該角色信息的、與該訪問(wèn)請(qǐng)求相關(guān)的屬性信息；許可策略評(píng)價(jià)部(37)，根據(jù)從用戶(hù)的終端裝置對(duì)所述網(wǎng)絡(luò)應(yīng)用程序的訪問(wèn)請(qǐng)求來(lái)取得 與所述使用相關(guān)的許可的執(zhí)行要點(diǎn)的識(shí)別信息，從所述許可執(zhí)行要點(diǎn)定義信息取得與該識(shí) 別信息相關(guān)聯(lián)的許可策略識(shí)別信息以及許可類(lèi)別，從所述許可策略定義信息取得與該取得 的許可策略識(shí)別信息以及許可類(lèi)別相對(duì)應(yīng)的許可策略，將該取得結(jié)果與由所述屬性信息取 得部取得的屬性信息相對(duì)照，由此來(lái)評(píng)價(jià)所述取得的許可策略；以及訪問(wèn)控制執(zhí)行部(38)，根據(jù)所述許可策略評(píng)價(jià)部的評(píng)價(jià)結(jié)果來(lái)進(jìn)行對(duì)所述網(wǎng)絡(luò)應(yīng)用程 序的訪問(wèn)控制。
2.根據(jù)權(quán)利要求1所述的服務(wù)器裝置，其特征在于，在所述許可策略存儲(chǔ)部^幻中存儲(chǔ)許可策略定義信息，該許可策略定義信息與由所 述許可執(zhí)行要點(diǎn)定義信息確定的許可策略識(shí)別信息相對(duì)應(yīng)、并且與所述多個(gè)種類(lèi)的各個(gè)許 可類(lèi)別相對(duì)應(yīng)、并且具有多個(gè)規(guī)則，所述許可策略評(píng)價(jià)部(37)，從所述許可策略定義信息取得與所述取得的許可策略識(shí) 別信息以及許可類(lèi)別相對(duì)應(yīng)的許可策略的各規(guī)則，將該取得結(jié)果與由所述屬性信息取得部 取得的屬性信息相對(duì)照，判別所述取得的屬性信息與所述取得的規(guī)則中的任意一個(gè)是否一 致，由此來(lái)評(píng)價(jià)所述取得的許可策略。
3.根據(jù)權(quán)利要求1所述的服務(wù)器裝置，其特征在于，所述許可類(lèi)別是通過(guò)所述網(wǎng)絡(luò)應(yīng)用程序?qū)ο蛩鼋K端裝置顯示的畫(huà)面的訪問(wèn)許可、或 是否顯示畫(huà)面顯示項(xiàng)目的許可，所述許可策略存儲(chǔ)部中存儲(chǔ)的許可策略是將以下兩種許可策略組合而得的許可策略， 其中，一種許可策略是用于為了所述訪問(wèn)許可與通過(guò)所述屬性信息取得部取得的屬性信息 相對(duì)照的許可策略，另一種許可策略是用于為了是否顯示所述畫(huà)面顯示項(xiàng)目的許可與通過(guò) 所述屬性信息取得部取得的屬性信息相對(duì)照的許可策略。
4.一種通信系統(tǒng)，該通信系統(tǒng)具有網(wǎng)絡(luò)應(yīng)用程序的用戶(hù)使用的終端裝置(1)和提供該 網(wǎng)絡(luò)應(yīng)用程序的服務(wù)器裝置O)，所述通信系統(tǒng)的特征在于，所述服務(wù)器裝置具有用戶(hù)信息存儲(chǔ)部(41)，存儲(chǔ)對(duì)每個(gè)用戶(hù)確定了角色信息的用戶(hù)信息，該角色信息表示 所述用戶(hù)的角色；許可執(zhí)行要點(diǎn)存儲(chǔ)部G2)，存儲(chǔ)許可執(zhí)行要點(diǎn)定義信息，該許可執(zhí)行要點(diǎn)定義信息是 將與所述網(wǎng)絡(luò)應(yīng)用程序的使用相關(guān)的許可的執(zhí)行要點(diǎn)的識(shí)別信息、用于識(shí)別與該執(zhí)行要點(diǎn) 對(duì)應(yīng)的許可策略的許可策略識(shí)別信息、以及多個(gè)種類(lèi)中任意許可類(lèi)別分別針對(duì)各種許可類(lèi) 別關(guān)聯(lián)起來(lái)而得的許可執(zhí)行要點(diǎn)定義信息；許可策略存儲(chǔ)部(43)，存儲(chǔ)許可策略定義信息，該許可策略定義信息確定了與由所述 許可執(zhí)行要點(diǎn)定義信息確定的許可策略識(shí)別信息相對(duì)應(yīng)、并且與所述多個(gè)種類(lèi)的各個(gè)許可 類(lèi)別相對(duì)應(yīng)的許可策略；屬性信息取得部(36)，從所述用戶(hù)信息取得進(jìn)行了訪問(wèn)請(qǐng)求的所述用戶(hù)的角色信息， 并取得含有該角色信息的、與該訪問(wèn)請(qǐng)求相關(guān)的屬性信息；許可策略評(píng)價(jià)部(37)，根據(jù)從所述終端裝置對(duì)所述網(wǎng)絡(luò)應(yīng)用程序的訪問(wèn)請(qǐng)求來(lái)取得與 所述使用相關(guān)的許可的執(zhí)行要點(diǎn)的識(shí)別信息，從所述許可執(zhí)行要點(diǎn)定義信息取得與該識(shí)別 信息相關(guān)聯(lián)的許可策略識(shí)別信息以及許可類(lèi)別，從所述許可策略定義信息取得與該取得的 許可策略識(shí)別信息以及許可類(lèi)別相對(duì)應(yīng)的許可策略，將該取得結(jié)果與由所述屬性信息取得 部取得的屬性信息相對(duì)照，由此來(lái)評(píng)價(jià)所述取得的許可策略；以及訪問(wèn)控制執(zhí)行部(38)，根據(jù)所述許可策略評(píng)價(jià)部的評(píng)價(jià)結(jié)果來(lái)進(jìn)行對(duì)所述網(wǎng)絡(luò)應(yīng)用程 序的訪問(wèn)控制。
全文摘要
本發(fā)明提供一種服務(wù)器裝置以及通信系統(tǒng)。該服務(wù)器裝置具備用戶(hù)信息存儲(chǔ)部，存儲(chǔ)對(duì)每個(gè)用戶(hù)確定了角色信息的用戶(hù)信息，該角色信息表示網(wǎng)絡(luò)應(yīng)用程序的用戶(hù)的角色；許可執(zhí)行要點(diǎn)存儲(chǔ)部，存儲(chǔ)許可執(zhí)行要點(diǎn)定義信息；許可策略存儲(chǔ)部，存儲(chǔ)許可策略定義信息；屬性信息取得部，從所述用戶(hù)信息取得進(jìn)行了訪問(wèn)請(qǐng)求的所述用戶(hù)的角色信息，并取得含有該角色信息的、與該訪問(wèn)請(qǐng)求相關(guān)的屬性信息；許可策略評(píng)價(jià)部，評(píng)價(jià)所述取得的許可策略；訪問(wèn)控制執(zhí)行部，根據(jù)所述許可策略評(píng)價(jià)部的評(píng)價(jià)結(jié)果來(lái)進(jìn)行對(duì)所述網(wǎng)絡(luò)應(yīng)用程序的訪問(wèn)控制。
文檔編號(hào)H04L29/06GK102045341SQ201010511750
公開(kāi)日2011年5月4日 申請(qǐng)日期2010年10月14日 優(yōu)先權(quán)日2009年10月16日
發(fā)明者向山弘樹(shù), 橋本和也, 江崎裕一郎, 西澤實(shí), 采泰臣 申請(qǐng)人:東芝解決方案株式會(huì)社, 株式會(huì)社東芝