JP4489634B2 - JavaサーブレットによるWebサーバシステム - Google Patents

JavaサーブレットによるWebサーバシステム Download PDF

Info

Publication number
JP4489634B2
JP4489634B2 JP2005139969A JP2005139969A JP4489634B2 JP 4489634 B2 JP4489634 B2 JP 4489634B2 JP 2005139969 A JP2005139969 A JP 2005139969A JP 2005139969 A JP2005139969 A JP 2005139969A JP 4489634 B2 JP4489634 B2 JP 4489634B2
Authority
JP
Japan
Prior art keywords
tag
server system
jsp
operator
jsp file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2005139969A
Other languages
English (en)
Other versions
JP2006318203A (ja
Inventor
浩之 前大道
幹介 玉城
龍太郎 川村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2005139969A priority Critical patent/JP4489634B2/ja
Publication of JP2006318203A publication Critical patent/JP2006318203A/ja
Application granted granted Critical
Publication of JP4489634B2 publication Critical patent/JP4489634B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

本発明は、Java(登録商標)ベースのWebサーバを用いて、複数の事業者がそれぞれの顧客に対してサービスを提供するサーバシステムに関する。
従来、Web技術を利用したサービスの提供が盛んに行なわれている。そのサービスを実現する手法の一つとして、Java技術をベースとしたサーブレット(Servlet)、JSP(Java Server Pages)、またはタグリブ(Taglib)が利用されている(例えば、非特許文献1、2を参照)。このようなJava技術により、ネットワークの顧客に対し、Web技術を利用したサービスを提供する事業者が多い。従来、複数の事業者がそれぞれのサービスを提供する場合、それぞれの事業者が、異なる計算機上にシステムを構築し、運用していた。または、それぞれの事業者が、サービスの機能を制限し、カスタマイズ性を大きく制限することにより、一台の計算機上に複数のサービスを集約してシステムを構築し、運用していた。
"JavaServer Pages(TM) Specification.1.1"、[online]、Sun microsystems,Inc.[平成17年4月28日検索]、インターネット<URL:http://java.sun.com/products/jsp/reference/api/index.html> "JSRs:Java Specification Requests JSR 53:JavaTM Servlet 2.3 and JavaServer PagesTM 1.2 Specifications"、[online]、Sun microsystems,Inc.[平成17年4月28日検索]、インターネット<URL:http://www.jcp.org/en/jsr/detail?id=53>
しかしながら、複数の事業者がそれぞれのサービスを提供するに際し、それぞれの事業者が異なる計算機上にシステムを構築した場合には、事業者毎に計算機を必要とし、余分なハードウェアのリソースが必要になるという問題があった。
また、事業者の提供するサービスの機能を制限し、カスタマイズ性を大きく制限することにより、一台の計算機上に複数のサービスを集約したシステムを構築した場合には、事業者がサービスを自由にカスタマイズできないという問題があった。
また、事業者がサービスを自由にカスタマイズできるようにし、かつ、一台の計算機上に複数のサービスを集約したシステムを構築した場合には、ある事業者により提供されるサービスに関する機能等の情報に、他の事業者がアクセスする可能性があり、いわゆる「事業者間のセキュリティ」を確保できないという問題があった。
さらに、複数のサービスを複数の計算機で提供する場合には、顧客からのログインの管理が困難になる。このため、顧客は、各サービス毎に認証手順を踏む必要があり、利便性が低下するという問題があった。この問題に対し、シングルサインオンのシステムを利用することにより、ログイン管理の困難性を解決することができるが、このシステムは高価になるため、導入が難しいという問題があった。
そこで、本発明は、上記課題を解決するためになされたものであり、その目的は、同一の計算機上で複数の事業者によりそれぞれのサービスを提供する場合に、事業者間のセキュリティを担保することが可能なサーバシステム及びサービス提供プログラムを提供することにある。
Javaを用いたWebサーバシステムにおいて、静的な情報を記述したHTMLファイルに加え、動的なコンテンツを生成するサーブレットやJSPを用いることにより、サービスの提供を実現することができる。事業者毎のサービスに対する要望を満たすため、カスタマイズが必要な場合は、これらのサーブレットやJSPを新規に開発したり、既存のものを変更したりする。
ここで、サーブレット及びJSPは、Javaのプログラムそのものであり、特定のプログラムが「許されたリソースのみにアクセスしていること」を調べることは困難であった。
本発明は、
(1)文法を制限したJSPを用いてカスタマイズを実現する、
(2)アクセス権限を確認した後にタグライブラリが動作する、
(3)タグライブラリにより、ログインしているユーザの種別に応じて、アクセスするオブジェクトの名前空間を分けて管理する、
(4)JSPファイルの記述が予定したルールに従っていることを確認する、
ことにより、前記課題を解決する。
〔カスタマイズの実現〕
事業者(事業者が操作する装置)は、その操作者が、文法の制約されたJSP(Limited JSP:以下、LJSPという。)を用いてサービスのロジックや表示方法を記述すると、当該LJSPファイルをサーバシステムへ送信する。サーバシステムは、LJSPファイルを受信すると、その事業者に割り当てた領域に当該LJSPファイルを配置することを、当該サーバシステムの運用者が許可するか否かを判断する。ここで、LJSPファイルには、プログラムを自由に書くことが許された「スクリプトレットタグ」を始め、JSPで定義されたタグのうちのいくつかのタグの利用が禁止されている。サーバシステムは、利用が禁止されたタグが格納されている禁止タグテーブルを参照し、受信したLJSPファイルに、利用が禁止されたタグが存在するか否かを判断し、存在する場合は、そのLJSPファイルの配置を行わない。また、利用が可能なタグライブラリのインデックスが格納された許可管理テーブルを参照し、受信したLJSPファイルにおいて、利用が許可されたタグライブラリを使用するか否かを判断し、利用が許可されていないタグライブラリを使用する場合は、そのLJSPファイルの配置を行わない。
このように、事業者は、後述するサーバ運用者が提供したタグを用いて、LJSPファイルを作成することになるから、事業者間のセキュリティを確保することができると共に、事業者毎のカスタマイズを実現することができる。そして、事業者は、作成したLJSPファイルをサーバシステムにアップロードしてサーバシステムに組み込む。この場合、サーバシステムは、LJSPファイルを事業者に割り当てられた領域に配置すべきか否かについて、LJSP検査を行い、LJSP検査の条件が満たされているか否かのチェックを行なう。条件が満たされていない場合は、LJSPファイルを配置しない。尚、サーバ運用者が提供するタグ及びLJSP検査の詳細については後述する。
〔タグライブラリ〕
タグライブラリは、JSP仕様で規定された概念であり、複数のタグの定義と、そのタグが評価された際に実行する複数のプログラムとをまとめたものである。LJSPによって動的なコンテンツを生成する場合は、スクリプトレットで行なわず、タグライブラリ中に記載されたタグを呼び出すことで実現する。サーバシステムは、LJSPファイルに記述されたタグの実行に際し、LJSPファイルに記述されたタグライブラリを呼び出し、まず最初に、ログインしている利用者の権限を調べる。利用者の権限に応じて、当該タグの動作が許可された場合は、そのプログラムに従って動作を行なう。一方、許可されない場合は、エラーページを転送する、タグの出力としてワーニングメッセージを出力する等の処理を行なう。
タグライブラリにおいて、JSP仕様では、タグに関連付けられたプログラム中に、任意のJavaコードを記載することができる。このプログラム中に、サーバ運用者が事業者間のセキュリティを維持できるように配慮して記載したコードを埋め込むものとする。この場合、事業者間のセキュリティに配慮して記述したコードの埋め込みは、サーバ運用者のみに限定されるものとする。つまり、サーバ運用者が事業者間のセキュリティを維持できるように配慮してコードを埋め込んだタグライブラリを、事業者により利用が認められるタグライブラリとする。
〔LJSP検査手順〕
図3(a)は、LJSPファイルの正当性を検証する手順を説明するフローチャート図である。サーバシステムは、禁止タグテーブル64を参照し、事業者から受信したLJSPファイルの中に、禁止されたタグの文字列の記述がないかを調べる(ステップ302〜304、306、307)。禁止されたタグがあった場合はエラーとする(ステップ305)。文字列の検査は周知の方法で行なうことができる。
また、サーバシステムは、事業者から受信したLJSPファイルの中に、サーバ運用者により利用が認められていないタグライブラリの使用宣言が存在するかを調べる(ステップ308〜311、313)。利用が認められているタグライブラリが存在した場合はエラーとする(ステップ312)。
また、サーバシステムは、事業者から受信したLJSPファイルの中に、ログインユーザ検査タグが記述されていることを確認する。そして、記述されている場合は、当該事業者のIDがこのタグのspid(事業者ID)として記載されているかチェックを行なう。当該事業者のIDがspidとして記載されていない場合はエラーとする。ここで、ログインユーザ検査タグのspidには、当該LJSPファイルが属する事業者のIDを記載するようになっている。
〔認証の単一性〕
本発明では、一つの計算機で複数のサービスを提供するため、セッション情報を一元的に管理することができる。これにより、顧客は一度認証手段を踏むことにより、複数の異なるサービスを享受することができる。
本発明によれば、複数の事業者が、それぞれのサービスを開発し、同一の計算機(Webサーバ)を用いて、それぞれの顧客にサービスを提供することが可能となる。このため、サーブレットコンテナやEJBコンテナのサーバソフトウェア群も複数用意する必要がない。したがって、単一の計算機、単一のサーバソフトウェアを用いて、複数の事業者によるそれぞれのサービスを提供できるから、余分なハードウェアのリソースが不要となり、リソースを無駄に費やすこともない。
また、事業者が作成したJSPファイルについて、種々の判断を行うようにしたから、セキュリティを考慮したタグの使用が求められることになり、新たなタグの追加に伴う事業者間のセキュリティを担保することができる。このため、複数の事業者のサービスを実現するソフトウェア群を同一の計算機、サーバソフトウェア上に配置しても、事業者間でデータの秘匿性が保たれる。
また、異なる事業者により複数のサービスを享受する顧客は、同じウェブサイトで複数のサービスを享受することが可能となり、利便性が高くなる。これに対し、本発明を用いない場合は、事業者毎に計算機を設ける必要があり、顧客は、事業者毎再ログインする必要があるため、利便性が低くなる。また、本発明を用いない場合は、シングルサインオンを実現するソフトウェアやハードウェアを用いる必要があるため、システムが高価になるというデメリットがある。
以下、本発明の実施の形態について図面を用いて詳細に説明する。
図1は、本発明の実施の形態によるサーバシステムを含む概念的なシステム構成図である。このシステムは、サーバシステム1、サーバ運用者2、事業者6〜8及び顧客9〜11により構成される。サーバシステム1とサーバ運用者2との間、サーバシステム1と事業者6〜8との間、及び、サーバシステム1と顧客9〜11との間は、インターネット等のネットワークにより接続される。サーバシステム1は、Webサーバを含み、複数の事業者6〜8が同一の当該サーバシステム1においてそれぞれ独自のサービスを提供するためのソフトウェア群3〜5を備えている。サーバ運用者2は、サーバシステム1の保守、管理、運用を行う。事業者6〜8は、顧客9〜11にサービスを提供するためのソフトウェアを開発し、カスタマイズする。事業者6〜8により開発及びカスタマイズされたソフトウェア群3〜5は、サーバシステム1の所定の領域に配置される。顧客9〜11は、事業者6〜8の顧客であり、サーバシステム1にアクセスし、ソフトウェア群3〜5により、それぞれ所定のサービスを享受する。尚、ソフトウェア群3,4は、事業者6により開発及びカスタマイズされたものであり、ソフトウェア群5は、事業者2により開発及びカスタマイズされたものである。また、顧客9,10は事業者6の顧客であり、顧客11は事業者7の顧客である。
このように構成されたシステムの下で、サーバシステム1は、顧客9〜11からのサービス提供要求を受信し、サービスを提供するためのソフトウェア群3〜5を実行し、所定のサービスを顧客9〜11に提供する。尚、図1において、サーバ運用者2、事業者6〜8及び顧客9〜11は主体の概念を示しており、実際は、それぞれの主体が操作するパーソナルコンピュータ等の通信装置である。
図2は、図1に示したサーバシステム1の構成図である。図2には、事業者Aがサービスを提供するためのソフトウェア群、及び、事業者Bがサービスを提供するためのソフトウェア群の機能が示されている。サーバシステム1は、J2EE(Java2 Enterprise Edition)サーバにより、一般的なサーブレットコンテナ21、EJBコンテナ42及びデータベースシステム39に基づいて構成されている。サーブレットコンテナ21は、サーバ運用者2が提供するソフトウェア要素が格納された領域24、事業者22(事業者A)がサービスを提供するためのソフトウェア要素が格納された領域33、及び、事業者B(図示せず)がサービスを提供するためのソフトウェア要素が格納された領域34を備えている。尚、領域33にはLJSPファイル36,37を配置することが、また、領域34にはLJSPファイル38を配置することが、サーバ運用者2により許可される。データベースシステム39は、事業者A用のデータ40及び事業者B用のデータ41を管理している。EJBコンテナ42は、Enterprise JavaBeans(EJB)44,45を備えている。
サーブレットコンテナ21の領域24には、JSPファイル25,26、サーブレット27,28、及びタグライブラリ30〜32が格納されている。領域33には、LJSPファイル36,37及びJavaBeans35が格納されている。領域34には、LJSPファイル38及びJavaBeans29が格納されている。ここで、サーバシステム1のサーブレットコンテナ21は、サーバ運用者2からJSPファイル25,26、サーブレット27,28、及びタグライブラリ30〜32を受信し、サーブレットコンテナ1の領域24に配置する。また、サーブレットコンテナ21は、事業者AからLJSPファイル36,37を受信し、サーバ運用者2により配置が許可されるか否かを判断し、許可された場合は、これらのソフトウェア要素を領域33に配置する。同様に、サーブレットコンテナ21は、事業者BからLJSPファイル38を受信し、サーバ運用者2により配置が許可されるか否かを判断し、許可された場合は、これらのソフトウェア要素を領域34に配置する。JavaBeans29,35は、LJSPファイルにJavaBeansを利用するタグの記載がされており、そのタグが実行された際に、領域33,34(この場合はメモリ領域)に作成される。
〔認証〕
事業者6〜8,22、顧客9〜11,23、及びサーバ運用者2は、サーバシステム1を利用する前にログインする必要がある。サーバシステム1のサーブレットコンテナ21は、事業者6〜8,22、顧客9〜11,23、またはサーバ運用者2からログインがあると、ログインした事業者、顧客またはサーバ運用者の認証情報をセッション変数として、図示しない領域に格納する。この場合、サーブレットコンテナ21がログインの認証処理を行なう場合もあれば、認証機能を有するサーブレット(例えばサーブレット27)が行う場合もある。このログインの認証処理は、広く利用されている公知技術により実現することができるため、詳細な内容についての説明は省略する。
〔LJSP〕
LJSPは、本明細書において定義された用語であり、前述のように、文法が制約されたJSPをいう。つまり、JSPで規定されている記法を制限したものである。
〔利用を禁止するタグ一覧〕
図2及び図3を参照して、事業者6〜8,22は、サービスを提供するためのソフトウェアをタグを用いてLJSPファイル36〜38に記述し、サーバシステム1は、このLJSPファイル36〜38を領域33,34に配置する。この場合、サーバシステム1のサーブレットコンテナ21は、事業者AからLJSPファイル36,37を受信し、領域33に配置する際に、利用が禁止されたタグが存在するか否かを判断し、利用が禁止されたタグの利用を禁止する。同様に、サーブレットコンテナ21は、事業者BからLJSPファイル38を受信し、領域34に配置する際に、利用が禁止されたタグが存在するか否かを判断し、利用が禁止されたタグの利用を禁止する。このLJSPファイル36〜38は、前述のように、JSPで規定されているタグを制限したものであり、具体的には以下のタグの利用が禁止される。
<jsp:declaration>
<%! %>
<jsp:expression>
<%= %>
<jsp:scriptlet>
<% %>
<jsp:getProperty>
<jsp:setProperty>
<jsp:useBean>
<%@ include %>
<jsp:directive.include>
<jsp:include>
サーバシステム1は、これらの利用が禁止されたタグが登録されたタグ禁止テーブル64(図3(b)を参照)を保持し、サーブレットコンテナ21は、当該タグ禁止テーブル64に基づいて、利用が禁止されたタグが存在するか否かを判断する。また、サーバ運用者2は、タグ禁止テーブル64に対するタグの登録、修正、削除等の管理を行う。
また、LJSPでは、サーバ運用者2によって利用を認められたタグライブラリを利用することができるが、認めていないタグライブラリを利用することはできない。JSPファイルの中にはタグライブラリの仕様宣言を次のようなフォーマットで記述することになっている。
<%@ taglib uri=“URIForLibrary” prefix=“tagPrefix” %>
サーブレットコンテナ21は、事業者AからLJSPファイル36,37を受信し、領域33に配置する際に、この宣言をチェックし、サーバ運用者2により認められていないタグライブラリの利用を禁止する。同様に、サーバシステム1のサーブレットコンテナ21は、事業者BからLJSPファイル38を受信し、領域34に配置する際に、この宣言をチェックし、サーバ運用者2により認められていないタグライブラリの利用を禁止する。サーバシステム1は、利用が認められているタグライブラリのインデックスが登録された許可管理テーブル65(図4を参照、詳細については後述する。)を保持し、サーブレットコンテナ21は、当該許可管理テーブル65に基づいて、利用が認められているタグライブラリであるか否かを判断する。また、サーバ運用者2は、許可管理テーブル65に対するライブラリインデックスの登録、修正、削除等の管理を行う。
また、JSPにおいては、スクリプトレットの形でJavaコードを自由に埋め込むことが可能であるが、LJSPファイル36〜38の作成に関しては、Javaコードの埋め込みを禁止する。具体的には、サーバシステム1のサーブレットコンテナ21は、事業者AからLJSPファイル36,37を受信し、領域33に配置する際に、Javaコードが埋め込まれているか否かを判断し、Javaコードが埋め込まれている場合は、その利用を禁止する。同様に、サーバシステム1のサーブレットコンテナ21は、事業者BからLJSPファイル38を受信し、領域34に配置する際に、Javaコードが埋め込まれているか否かを判断する。これにより、アプリケーションの記述性はJSPと比較して若干限定されるが、事業者6〜8,22間のセキュリティを実現することができる。
〔サーバ運用者が提供するタグの例〕
次に、サーバ運用者2が提供するタグについて説明する。具体的には、サーバシステム1のサーブレットコンテナ21は、サーバ運用者2から、タグを実行するための処理が規定された情報を受信し、タグライブラリ30〜32として領域24に配置する。事業者6〜8,22は、サーバ運用者2により提供されたタグをLISPファイル36〜38に記述して利用することができる。
(1)ログインユーザ検査タグ
次のように定義されたタグが実行される。
<sap:usercheck spid=[事業者のID] type=“enduser”|“operator”|“administrator”|“provider”|“all”/>
サーブレットコンテナ21は、事業者6〜8,22によりこのタグが記述されたLJSPファイル36〜38を所定の領域33,34に配置することにより、このタグの実行に際し、ログインしたユーザがWebページを閲覧する権利を有しているか否かを調べ、権利がないと判断した場合に、ユーザの画面にエラーページを表示させる。ログインユーザ検査タグには、spid属性として、当該タグの記述されたLJSPファイルがどの事業者に属するものか(どの事業者により作成されたファイルであるか)について規定される。また、Type属性として、どの種類のユーザならばこのWebページを閲覧することができるかについて規定される。つまり、特定の事業者のエンドユーザ(enduserに対応)であるか、事業者の作業者(operatorに対応)であるか、事業者の管理者であるかが規定される。Type属性として、providerが規定されていた場合は、ログインしたユーザが事業者の作業者(operatorに対応)または事業者の管理者のときに、このWebページを閲覧することが可能となる。また、Type属性として、“all”が規定されていた場合は、ログインしたユーザが特定の事業者のエンドユーザ(enduserに対応)、事業者の作業者(operatorに対応)、または事業者の管理者(administratorに対応)のときに、このWebページを閲覧することが可能となる。
つまり、サーブレットコンテナ21は、タグライブラリ30〜32によりこのタグに関連付けられたプログラムを実行する際に、ログインしたユーザの属性を調べ、タグに指定された条件に合うか否かを判断し、条件に合わない場合はエラーページをユーザへ転送する。このタグを利用することにより、図2におけるアクセス46,49を、閲覧する権利を有しないアクセスであるとし、エラーとすることが可能となる。
例えば、事業者B用の領域34に配置されたLJSPファイル38に、ログインユーザ検査タグのタイプ属性として、このページを閲覧することができるユーザの種類(事業者Bの顧客)が規定されているとする。この場合、事業者22(事業者A)からLJSP38にアクセスがあると、サーブレットコンテナ21は、このログインユーザ検査タグに対応付けられたプログラムを実行する際に、ログインした事業者22とType属性とにより、このアクセス46をエラーとし、エラーページを事業者22へ転送する。同様に、事業者Aの顧客23からLJSP38にアクセスがあると、サーブレットコンテナ21は、このログインユーザ検査タグに対応付けられたプログラムを実行する際に、ログインした顧客23とType属性とにより、このアクセス49をエラーとし、エラーページを顧客23へ転送する。
(2)データベースアクセスタグ
次のように定義されたタグが実行される。
<sap:table variable=“xx” dbname=“db” tablename=“sample” columns=“a,b,c,d” searchcolumn=“a” columnvalue=“al”>
サーブレットコンテナ21は、事業者6〜8,22によりLJSPファイル36〜38に記述されたこのタグの実行に際し、ログインしたユーザが、タグにより指定されたデータベース(abname属性)、テーブル(tablename属性)、または、少なくとも1つ以上のカラム(columnname属性)にアクセスする権利を有するか否かを調べ、権利を有すると判断した場合に、その検索したデータをタグのvariable属性で指定された変数に格納する。データベースを検索して複数の結果を得た場合も、Java言語に用意されているjava.util.Mapクラスや、java.util.ArrayList等の複数の値を格納できるクラスを利用することにより、前述した同じ方法で実現することができる。
つまり、サーブレットコンテナ21は、タグライブラリ30〜32によりこのタグに対応付けられたプログラムを実行する際に、ログインしたユーザのアクセス権利を調べ、権利があることを確認した後に、検索したデータを変数に格納する。このタグを利用することにより、図2におけるアクセス48を、アクセスする権利を有しないアクセスであるとして、エラーとすることが可能となる。これにより、他の事業者用のデータへのアクセスを防ぐことが可能となる。
また、アクセスする領域についてはさまざまな粒度が想定され、DB、テーブル、カラム、または特定のレコードに限りアクセスすることが可能である。このアクセス制御は、図6に示すデータベースアクセス制御テーブル81を用いることにより実現することができる。図6のデータベースアクセス制御テーブル81を参照して、「占有タイプ」の種別には、db、table、column、recordbySP及びrecordbyEUがある。それぞれデータベース、テーブル、カラム、レコード、レコードの単位でアクセス制御を行なうものである。レコード82は、「占有タイプ」としてdb単位でアクセスを許可することを示しており、「SP」の事業者Aに対して、データベースdb1への全体のアクセスを許可している。レコード84は、「占有タイプ」としてtable単位でアクセスを許可することを示しており、「SP」の事業者Bに対して、データベースdb2中にあるテーブルatableへのアクセスを許可している。レコード85は、「占有タイプ」としてカラム単位でアクセスを許可することを示しており、「SP」の事業者Bに対して、任意のデータベース中にあるテーブルbtableのカラムAREACODEへのアクセスを許可している。尚、*は、任意のもの(全てのもの)にマッチすることを意味する。
また、レコード86は、事業者からのアクセスに対して、レコード単位でアクセスを許可することを示しており、「ID_COLUMN」で指定されたカラムSPNAME中に、サーバシステム1にアクセスしているユーザの所属する事業者識別情報が記載されているレコードについてアクセスを許可している。この条件が整う場合(ユーザの所属する事業者識別情報が記載されている場合)は、「dbname」「tablename」「columnname」について上記と同様に判断し、全てのデータベース中にあるテーブルatable2の全てのカラムへのアクセスを許可する。つまり、SPNAMEのカラムにA(アクセスしているユーザの事業者識別情報)の値が記載されていると判断した場合に、そのレコードについてアクセスすることができ、全てのデータベース中にあるテーブルatable2の全てのカラムへのアクセスを許可する。
また、レコード87は、顧客からのアクセスに対して、レコード単位でアクセスを許可することを示しており、「ID_COLUMN」で指定されたカラムEUNAME中に、サーバシステム1にアクセスしているユーザの識別情報が記載されているレコードについてアクセスを許可している。この条件が整う場合(ユーザの識別情報が記載されている場合)は、「dbname」「tablename」「columnname」について上記と同様に判断し、全てのデータベース中にあるテーブルatable2の全てのカラムへのアクセスを許可する。
尚、図6に示したデータベースアクセス制御テーブル81を用いることにより、DB、テーブル、カラム、または特定のレコードに限りアクセスすることが可能となるが、アクセス制御は、これに制限されるものではない。例えば、IPアドレスやポート番号を図6に示したデータベースアクセス制御テーブル81に追加することにより、複数のデータベースサーバに対応することができる。また、「READ/WRITE種別」のようなカラムを追加することにより、書き込み/読み込みを区別して許可することができる。このようにして、細かなアクセス制御を実現することが可能となる。
(3)EJBアクセスタグ
次のように定義されたタグが実行される。
<sap:ejbsession variable=“myreturn” jndiname=“xxx” methodname=“call1” argname1=“find” argname2=“myobj”>
サーブレットコンテナ21は、事業者6〜8,22によりLJSPファイル36〜38に記述されたこのタグの実行に際し、ログインしたユーザのアクセス権を判断し、タグの属性で指定されたJNDI名を有するEJBオブジェクトに対して、指定されたメソッドを指定された引数を伴って呼び出しを行い、メソッドの戻り値をタグのvariable属性に指定された変数に格納する。
このEJBアクセスタグにより、EJBのメソッドに対してもアクセス制御が可能となり、さらに、前述した(2)データベースアクセスタグの説明で示した図6のデータベースアクセス制御テーブル81のようなテーブルを用いることにより、アクセスする領域の粒度を想定した細かなアクセス制御を実現することが可能となる。
また、サーブレットコンテナ21は、このタグの実行に際し、当該タグを実現するタグライブラリ30〜32のプログラム中にて、図6に示したデータベースアクセス制御テーブル81のようなテーブルを参照し、ログインしたユーザにアクセス権があるか否かを判断し、アクセス権があると判断した場合にのみ、メソッドの呼び出しを行なうことが記載されたプログラムを実行する。これにより、事業者間におけるセキュリティを担保することができる。また、図2におけるアクセス50を、アクセスする権利を有しないアクセスであるとし、エラーとすることが可能となる。これは、顧客からの要求により、EJBへのアクセスを許可しないという方針に従ったアクセス制御の例である。
(4)JavaBeansアクセスタグ
前述のように、LJSPファイルにおいて、以下のタグの利用は禁止されている。これは、javaBeansのアクセス制御を実現できないからである。
<jsp:getProperty>
<jsp:setProperty>
<jsp:useBean>
ここで、以下に示すように、これらのタグと同様の機能を有する別名のタグを用意する。
(4.1)<sap:useBean>タグ
<sap:useBean>タグは、JSP仕様で定められており、<jsp:useBean>タグと同様の動作を行なう。例えば、次のように記述して定義されたタグが実行される。
<sap:useBean id=“obj1” class=“MyDate” scope=“request”/>
ここでは、obj1という名前でMyDate型のインスタンスを生成することを宣言している。JSP仕様では、scope属性でオブジェクトインスタンスのライフタイムを指定できることになっている。ただし、scope属性としてApplicationのライフタイムは認めないこととする。サーブレットコンテナ21は、このタグの実行に際し、scope属性が“Application”であった場合は、何も処理を行なわない。<jsp:useBean>タグでは、obj1がこのオブジェクトの名前として管理されるが、<sap:useBean>タグでは、サーブレットコンテナ21が、この名前の前に事業者のコード(識別子)とコロンを入れて、“A:obj1”という名前でアクセスを管理する。事業者のコードは、ログイン時の認証情報により得ることができる。これにより、他の事業者の管理するオブジェクトと名前が重複することはない。ただし、タグ内に指定するid属性中に“:”を使用することは禁止される。サーブレットコンテナ21は、このタグに関連づけられたプログラムを実行し、“:”が入っていないことを確認し、入っていた場合は処理を中断する。このタグを実行した際に、この名前を有したJavaBeansインスタンスが存在しない場合は、JavaBeansインスタンスを生成し、前記の名前を付与して格納する。
(4.2)<sap:getProperty>タグ、<sap:setProperty>タグ
<sap:getProperty>タグは、JSP仕様で定められており、<jsp:getProperty>タグと同様の動作を行なう。また、<sap:setProperty>タグもJSP仕様で定められており、<jsp:setProperty>タグと同様の動作を行なう。<sap:getProperty>タグ及び<sap:setProperty>タグでは、<sap:useBean>タグと同様に、サーブレットコンテナ21が、id属性の前に事業者のコードとコロンを入れて、例えば、“A:obj1”という名前で管理する。
尚、顧客の識別子も入れて管理することにより、さらに細かい粒度のアクセス制御を行なうバリエーションのタグを導入することもできる。例えば、“事業者:顧客ID:obj1”という名前で管理する。これにより、タグに記述されているアクセス対象のオブジェクトに対し、ログインしているユーザの種別によりそのユーザのコードを付加するから、オブジェクトの名前空間を分けた管理が可能となる。
このように、<sap:getProperty>タグ,<sap:setProperty>タグ及び<sap:useBean>タグを利用したLJSPファイルにおいて、サーブレットコンテナ21が、そのタグの実行に際し、認証情報に基づいてアクセスする権利を有するか否かを判断し、アクセス権利を有する場合にのみ、所定の機能を実行するようにした。これにより、図2におけるアクセス47を、アクセス権利を有しないアクセスであるとし、エラーとすることが可能となる。つまり、サーブレットコンテナ21は、LJSPファイル36の前記タグの実行に際し、他の事業者の領域34に配置されたJavaBeans29へのアクセス47を禁止することにより、事業者間の領域を跨ったJavaBeanへのアクセスを行なうことが不可能となる。
(5)画面表示タグ
前述の(1)〜(4)のタグでは、処理の結果、変数にさまざまな値を代入する処理が行なわれる。サーブレットコンテナ21は、LJSPファイル36〜38に記述された画面表示タグの実行に際し、処理結果である変数を、ログインしたユーザの画面にそのまま値として出力する。この場合、表形式で出力したりグラフを作成して出力するようにしてもよい。
(6)その他のタグ
(1)〜(5)のタグは、比較的簡単な処理を実現するタグの種類に属するものであるが、その他の処理を実現するタグを排除するものではない。サーバ運用者2が同様の多種多様なタグを開発して提供することができることは、同一の技術分野の技術者には容易に理解できる。サーバ運用者2が、タグライブラリを開発した場合は、通常のサーブレットコンテナ21でタグライブラリを開発する手法に加えて、図4に示す許可管理テーブル65に新たなレコードを追加することにより、本サーバシステム1において、タグライブラリを利用することが可能となる。また、サーバ運用者2がタグの種類を増やし、充実させていくことにより、事業者6〜8,22は、顧客に提供するサービスを実現するためのLJSPファイル36〜38を効率的に記述することが可能となる。
〔LJSP検査手順〕
サーバシステム1のサーブレットコンテナ21は、事業者6〜8,22の管理者の操作により送信されたLJSPファイル36〜38を受信し、LJSPファイル36〜38中に、禁止されたタグの文字列の記載があるか否かを調べる。禁止されたタグが存在すると判断した場合はエラーとし、エラー情報を事業者6〜8,22へ転送する。文字列の検査は周知の方法で行なうことができる。サーブレットコンテナ21は、図3(b)に示した禁止タグテーブル64を管理し、この禁止タグテーブル64を参照して禁止されたタグの存在を判断する(図3(a)に示したステップ302〜307を参照)。
JSP仕様は、継続してメンテナンスされており、今後バージョンアップされることが想定される。また、サーブレットコンテナベンダが独自の仕様を追加することにより、利用可能なタグが増えることも想定される。事業者間のセキュリティが保たれないような新しいタグが追加された場合には、図3(b)に示した禁止タグテーブル64にそのタグを追加することにより、新たなJSP仕様やベンダ独自の仕様等に対して、セキュリティの確保を実現することができる。
また、サーブレットコンテナ21は、LJSPファイル36〜38中に、禁止されたタグの文字列の記述があるか否かを調べることに加えて、使用するタグライブラリがサーバ運用者2により利用が認められているか否かを調べる。サーブレットコンテナ21は、LJSP36〜38中に、利用が認められているタグライブラリ以外のタグライブラリが宣言されていた場合はエラーとする。利用が認められているタグライブラリであるか否かの検査は、図4に示した許可管理テーブル65をサーバシステム1に保持しておき、このテーブルを参照して行う。LJSPファイル36〜38を順に調べ、「<%@ taglib uri=“...” prefix=“...” %>」の記述を検索し、許可管理テーブル65のデータと照らし合わせる(図3(a)に示したステップ308〜314を参照)。図4において、「利用を認める事業者」の欄が“*”のレコードは、全ての事業者に対して認めていることを示しており、特定のID(「A」「B」)が記載されていた場合は、そのIDに対応する事業者にのみ認めていることを示している。利用を認めていないと判断した場合はエラーとし、エラー情報を事業者6〜8,22へ転送する。
また、サーブレットコンテナ21は、ログインユーザー検査タグがLJSPファイル36〜38に記述されていることを確認する。この場合、当該事業者のIDがspidとして記載されているかチェックを行なう。条件が満たされない場合はエラーとし、LJSPファイル36〜38の配置を中止する。または、事業者6〜8,22の画面に警告を表示するのみとして、処理を継続する。
尚、前述のログインユーザ検査タグがLJSPファイル36〜38に記述されており、当該事業者のIDがspidとして記載されていることの条件は、「他の事業者の関係者に本LJSPファイルを実行させないため」に用いられるものであり、「他の事業者の情報を本事業者が脅かすことを禁止するため」に用いられるものではないため、必須ではない。しかし、このチェックを行なうことで、他の事業者からの不正なアクセスを禁止できるという点でメリットが得られる。
次に、ホームアプリケーションサービスの利用事例について説明する。図5は、ホームゲートウェイを管理するサーバシステムの実施例を示すネットワーク構成図である。このホームアプリケーションサービスは、サーバシステム1の中に閉じて完結するのではなく、EJB73,74配下に複数のホームゲートウェイ70〜72を接続し、家庭内のホームゲートウェイ70〜72を管理するものである。また、ホームゲートウェイ70〜72配下に接続されたデバイス群(図示せず)に対しても制御を行なうことができる。尚、図5において、図2と共通する部分には図2と同一の符号を付し、その詳しい説明は省略する。
図5を参照して、EJB73は、事業者6に対してホームゲートウェイ70,71の情報を提供する機能を有する。このEJB73は、メソッド呼び出しの引数の一つとして事業者の識別情報が渡される構成となっており、その事業者の加入しているホームゲートウェイにしかアクセスを許さないコーディングがなされている。このため、EJBコンテナ42は、サーブレットコンテナ21によりLJSPファイル36、タグライブラリ75及びEJB73から他の事業者2のホームゲートウェイ72へのアクセス78を禁止する。
また、EJB74は、顧客9に対してホームゲートウェイ70の情報を提供する機能を有する。このEJB74は、メソッド呼び出しの引数の一つとして顧客の識別情報が渡される構成となっており、顧客9の保有するホームゲートウェイ70にしかアクセスを許さないコーディングがなされている。このため、EJBコンテナ42は、サーブレットコンテナ21によりLJSPファイル37、タグライブラリ76及びEJB74から他の顧客10の保有するホームゲートウェイ71へのアクセス77を禁止する。つまり、事業者6の顧客9は、自分の保有するホームゲートウェイ70にしかアクセスが許されない。
尚、図2に示した領域24,33,34とは、ディスク領域及びメモリ領域のことを指す。事業者6〜8,22が配置するLJSPファイル36〜38は、まず、ディスク領域に配置され、その後、サーブレットコンテナ21の機能において、メモリ領域に読み込まれ、実行可能状態となる。また、JavaBeansインスタンスは、メモリ領域に配置される。JavaBeansオブジェクトクラスは、サーバ運用者2により提供されるもののみしか利用することができない。
尚、上記サーバシステム1は、CPU、RAM等の揮発性の記憶媒体、ROM等の不揮発性の記憶媒体、キーボード等の入力装置、データを表示する表示装置、及び外部の装置と通信するためのインターフェースを備えたコンピュータ装置によって構成される。この場合、サーバシステム1に備えた各種ソフトウェア要素の各機能は、当該機能を記述したプログラムをCPUに実行させることにより実現される。また、これらのプログラムは、磁気ディスク(フロッピィーディスク、ハードディスク等)、光ディスク(CD−ROM、DVD等)、半導体メモリ等の記憶媒体に格納して頒布することもできる。
本発明の実施の形態によるサーバシステムを含む概念的なシステム構成図である。 図1のサーバシステムを示す構成図である。 LJSPファイルの正当性を検証する手順を説明するフローチャート図である。 利用タグの許可情報を格納する許可管理テーブルを示す図である ホームゲートウェイを管理するサーバシステムの実施例を示すネットワーク構成図である。 データベースアクセス制御テーブルを示す図である。
符号の説明
1 サーバシステム
2 サーバ運用者
3〜5 ソフトウェア要素
6〜8,22 事業者
9〜11,23 顧客
21 サーブレットコンテナ
24,33,34 領域
25,26 JSPファイル
27,28 サーブレット
29,35 JavaBeans
30〜32 タグライブラリ
36〜38 LJSPファイル
39 データベースシステム
40 事業者A用データ
41 事業者B用データ
42 EJBコンテナ
44,45,73,74 EJB
46〜50,77,78 禁止されるアクセス
64 禁止タグテーブル
65 許可管理テーブル
70〜72 ホームゲートウェイ
81 データベースアクセス制御テーブル
82〜87 レコード

Claims (8)

  1. 事業者が顧客にサービスを提供するWebサーバを備え、サーブレット及びJSPを用いて構成されるサーバシステムにおいて、
    前記サービスの提供に関する処理が記述されたJSPファイルのタグを実行するに際し、ログインしているユーザの権限を確認した後に、所定の処理を行う機能を有するタグライブラリと、
    前記事業者により作成されたJSPファイルを、前記事業者の端末から受信し、該JSPファイルに記述されたタグが、利用が禁止されているか否か、及び、該タグによる所定の処理を行う機能を有するタグライブラリの利用が許可されているか否かを判断し、該タグの利用が禁止されておらず、かつ、そのタグライブラリの利用が許可されている場合に、前記受信したJSPファイルを、前記事業者毎に区別された領域に配置する制御手段とを備えたことを特徴とするサーバシステム。
  2. 請求項1に記載のサーバシステムにおいて、
    前記タグライブラリは、JSPファイルを作成した事業者の情報を含むログインユーザ検査タグにより、ログインしたユーザの権限を確認する処理を行う機能を有し、
    前記制御手段は、さらに、受信したJSPファイルに、前記ログインユーザ検査タグが記述されているか否かを判断し、該ログインユーザ検査タグが記述されている場合に、該タグに、受信したJSPファイルを作成した事業者の情報が含まれるか否かを判断し、該事業者の情報が含まれる場合に、前記受信したJSPファイルを、前記事業者毎に区別された領域に配置する制御手段とを備えたことを特徴とするサーバシステム。
  3. 請求項1に記載のサーバシステムにおいて、
    前記タグライブラリは、オブジェクト名を含むオブジェクトアクセスタグにより、アクセスするオブジェクトを、ログインしたユーザの識別子及び前記オブジェクト名により管理する機能を有することを特徴とするサーバシステム。
  4. 請求項1から3までのいずれか一項に記載のサーバシステムにおいて、
    さらに、該サーバシステムに接続されるホームゲートウェイを管理するEJBを備えたことを特徴とするサーバシステム。
  5. 事業者が顧客にサービスを提供するWebサーバを備え、サーブレット及びJSPを用いて構成されるサーバシステムの下で、前記サービスの提供に関する処理をタグにより記述されたJSPファイル、及び、該タグにより所定の処理を行う機能を有するタグライブラリにより、前記サービスを提供するプログラムであって、前記Webサーバを構成するコンピュータに、
    前記事業者により作成されたJSPファイルを、前記事業者の端末から受信する処理と、
    該JSPファイルに記述されたタグが、利用が禁止されているか否か、及び、該タグによる所定の処理を行う機能を有するタグライブラリの利用が許可されているか否かを判断する処理と、
    該タグの利用が禁止されておらず、かつ、そのタグライブラリの利用が許可されている場合に、前記受信したJSPファイルを、前記事業者毎に区別された領域に配置する処理と、
    該事業者毎に区別された領域に配置されたJSPファイルに記述されたタグを実行するに際し、ログインしているユーザの権限を確認する処理とを実行させるサービス提供プログラム。
  6. 請求項5に記載のサービス提供プログラムにおいて、
    前記タグライブラリは、JSPファイルを作成した事業者の情報を含むログインユーザ検査タグにより、ログインしたユーザの権限を確認する処理を行う機能を有し、
    前記Webサーバを構成するコンピュータに、
    受信したJSPファイルに、前記ログインユーザ検査タグが記述されているか否かを判断する処理と、
    該ログインユーザ検査タグが記述されている場合に、該タグに、受信したJSPファイルを作成した事業者の情報が含まれるか否かを判断する処理と、
    該事業者の情報が含まれる場合、及び、前記タグの利用が禁止されておらず、かつ、そのタグライブラリの利用が許可されている場合に、前記受信したJSPファイルを、前記事業者毎に区別された領域に配置する処理とを実行させるサービス提供プログラム。
  7. 請求項5に記載のサービス提供プログラムにおいて、
    前記タグライブラリは、オブジェクト名を含むオブジェクトアクセスタグにより、アクセスするオブジェクトを管理する機能を有し、
    前記Webサーバを構成するコンピュータに、
    前記タグライブラリのオブジェクトアクセスタグの機能により、アクセスするオブジェクトを、ログインしたユーザの識別子及び前記オブジェクト名により管理する処理を実行させるサービス提供プログラム。
  8. 請求項5から7までのいずれか一項に記載のサービス提供プログラムにおいて、
    前記Webサーバは、さらにEJBを備え、該Webサーバを構成するコンピュータに、
    該EJBにより、前記サーバシステムに接続されるホームゲートウェイを管理する処理を実行させるサービス提供プログラム。
JP2005139969A 2005-05-12 2005-05-12 JavaサーブレットによるWebサーバシステム Expired - Fee Related JP4489634B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2005139969A JP4489634B2 (ja) 2005-05-12 2005-05-12 JavaサーブレットによるWebサーバシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005139969A JP4489634B2 (ja) 2005-05-12 2005-05-12 JavaサーブレットによるWebサーバシステム

Publications (2)

Publication Number Publication Date
JP2006318203A JP2006318203A (ja) 2006-11-24
JP4489634B2 true JP4489634B2 (ja) 2010-06-23

Family

ID=37538832

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005139969A Expired - Fee Related JP4489634B2 (ja) 2005-05-12 2005-05-12 JavaサーブレットによるWebサーバシステム

Country Status (1)

Country Link
JP (1) JP4489634B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102144216A (zh) 2009-02-19 2011-08-03 日本三菱东京日联银行股份有限公司 应用开发支援装置、程序以及记录介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004362000A (ja) * 2003-05-30 2004-12-24 Internatl Business Mach Corp <Ibm> ウェブアプリケーション開発支援装置、コンポーネント呼び出し監視装置、データ処理方法及びプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004362000A (ja) * 2003-05-30 2004-12-24 Internatl Business Mach Corp <Ibm> ウェブアプリケーション開発支援装置、コンポーネント呼び出し監視装置、データ処理方法及びプログラム

Also Published As

Publication number Publication date
JP2006318203A (ja) 2006-11-24

Similar Documents

Publication Publication Date Title
US11451442B2 (en) System and method for generic configuration management system application programming interface
US10489424B2 (en) Different hierarchies of resource data objects for managing system resources
US8239954B2 (en) Access control based on program properties
US11574070B2 (en) Application specific schema extensions for a hierarchical data structure
US9152796B2 (en) Dynamic analysis interpreter modification for application dataflow
US7908610B2 (en) Multi-threaded business programming library
EP1625691B1 (en) System and method for electronic document security
US20110276674A1 (en) Resolving information in a multitenant database environment
US20110239293A1 (en) Auditing access to data based on resource properties
US11095648B2 (en) Dashboard as remote computing services
US9560121B2 (en) Provisioning a web hosting resource using a cloud service
CN101441688A (zh) 一种用户权限分配方法和一种用户权限控制方法
US11443067B2 (en) Restricting access and edit permissions of metadata
US20090031396A1 (en) METHOD OF AND APPARATUS FOR MANAGING ACCESS PRIVILEGES IN CLDC OSGi ENVIRONMENT
US9582776B2 (en) Methods and systems for providing a comprehensive view of it assets as self service inquiry/update transactions
US20110154455A1 (en) Security management framework
US20220067170A1 (en) Automated code analysis tool
US20220385596A1 (en) Protecting integration between resources of different services using service-generated dependency tags
JP4489634B2 (ja) JavaサーブレットによるWebサーバシステム
Freeman et al. Using Roles and Claims
Mayank et al. Multitenancy
Lee et al. Development of a User Management Module for Internet TV Systems
Stoecker et al. Exam Ref 70-518 Designing and Developing Windows Applications Using Microsoft. NET Framework 4 (MCPD): Designing and Developing Windows Applications Using Microsoft. NET Framework 4
Rossberg et al. The Enterprise Application Architecture

Legal Events

Date Code Title Description
RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20070614

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20070614

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070807

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20081017

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100330

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100331

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130409

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140409

Year of fee payment: 4

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees