SAML
4.4 プロトタイプシステム
4.4.1. 概要
75
取り出した複数の文字列の中に，指定した文字列が含まれるかどうかの存在 判定を行う場合には，まず，取り出した文字列の個数を指定する判定文（図
4.13）
を実施する．その後，該当する文字列を引数として，string-is-inを演算子とす る条件判定文を実行する（図
4.14）
．例：４つの文字列を所得する場合の文字列個数の指定
引数（値：0x04(binary)） 演算子（string-bag）
文字列取得 文字列取得
4つの文字列を取得
0x04, 0x01, 0x04
T L V
0x04, 0x01, 0x23
T L V
図
4.13 文字列個数を指定する条件判定文
例：４つの取得した文字列の中に“ABCD”と一致する文字列があるかどうか
T L V
引数（値：“ABCD‖） 演算子（string-is-in）
データ数指定 文字列取得 文字列取得
0x04, 0x04, 0x41,0x42,0x43,0x44 0x04, 0x01, 0x23
T L V
図
4.14 指定した文字列の存在判定のための条件判定文
今回開発したプロトタイプシステムにおける資源は，ブラウザを具備したイ ンターネット接続可能な端末である．それぞれ
Resource Policy Decision
とPolicy Enforcement Point
をWindows OS
上にJava
で実装した．外部ネットワークとの間でパケットをフィルタリングするゲートウェイ装置 上にサービス認可装置の機能である
Usage Decision
を実装した．また，サービ ス提供者サーバにUse-right Policy Issuing
をそれぞれLINUX OS
上にJava
で実装した．インターネット端末には，利用権をサービス提供者サーバから取 得する際のインターフェース機能(Request for Use-right Policy)を実装してい る．さらに，利用権の行使判定のためのIC
カードとサービス認可装置間のイン ターフェース機能(Use-right Policy Execution)として資源表示機能やAPDU(Application Protocol Data Unit)伝達機能を実装している．Request for Use-right Policy
やUse-right Policy Execution
は，利用権の入手やその利用の 際のユーザインターフェース及びIC
カードとサービス提供者サーバやサービス 認可装置とのインターフェース機能である．これらは，資源が持つべきResource Policy Decision
やPolicy Enforcement Point
とは独立な機能であるため，必ず しも資源であるインターネット端末上に実装する必要はない．しかし，今回は，機能や性能検証が目的であるため，同一の端末に
Interface Function
としてこ れらの機能を実装した．IC
カードの発行機能やIC
カードへのアプリケーションダウンロード機能等 については，マルチアプリケーションIC
カード管理プラットフォームであるNICE[28][29][30]を用いた．
Assertion
については，拡張性を持たせるために用意した可変長の予備領域等を持つデータ構造(128byte～,内利用権
ID:66byte)を独自に定義した． Assertion
には，利用権ID
やアクセス制御ポリシに対する判定結果が含まれる．これらのAssertion
には，生成元でデジタル署名が付与される．そたのめ，分散認証認可フレームワークに基づきその正当性の確認が可能である．
IC
カード内のUser Policy Decision
には，4.3.4.節で示した条件判定に関わる
処理系や利用権取得・削除などの利用権管理機能を実装した．さらに，利用権77
発行・利用権行使に伴うサービス提供者サーバやサービス認可装置とのインタ ーフェース機能を
C
言語で実装した．プログラムサイズは，約20Kbyte
であっ た．ハードウェアとしては，インターネット端末として，Pentium4 2.8GHz相当 の
PC
を用いた．また，ゲートウェイとして，Pentium M 1.6GHz相当のPC
を用いた．ICカードとしては，非接触型大容量マルチアプリケーションIC
カ ードであるeLWISE[24][25]カードを用いた．これは，暗号処理プロセッサが具
備されていること，複数のアプリケーションが搭載可能なことなどの要求に合 致していたためである．Gateway as Service Permission Equipment
Service Provider Server
Usage Decision
Packet Filter
Internet Use-right
Policy Issuing Not mandatory
User Policy Decision
IC Card
Internet Terminal Resource Policy Decision
Policy Enforcement
Point
Web Browser Request for Use-right
Policy Use-right
Policy Execution Interface Function
Gateway as Service Permission Equipment
Service Provider Server
Usage Decision
Packet Filter
Internet Use-right
Policy Issuing Not mandatory
User Policy Decision
IC Card
Internet Terminal Resource Policy Decision
Policy Enforcement
Point
Web Browser Request for Use-right
Policy Use-right
Policy Execution Interface Function
図 4.15 システム構成
4.4.2. 動作シーケンス
動作シーケンス（図
4.16）を以下に示す．
（前提条件）ICカード内の
User Policy Decision
には，“ISP Xの会員”とい う利用者属性が格納されている．インターネット端末内の Resource PolicyDecision
には，“画面サイズ20
インチ”という資源属性が格納されている．①“ISP
X
の会員が20
インチ以上のインターネット端末を使用して1
時間イ ンターネットアクセスが利用可能”という利用権取得時に，利用者属性に関 する判定がカード内で行われる．（図4.16
では，省略）②インターネット端末に
IC
カードが挿入されると，IC
カードから利用権ID
が 取得され，資源一覧を表示する．それとともに，ICカードとゲートウェイ間 で公開鍵証明書（それぞれ133byte）が交換される．
③インターネット端末選択により，ゲートウェイの
Usage Decision
が中心とな り，User Policy Assertion
など（Data set1）の取得検証が行われる．その後，Resource Policy
の判定依頼(Data set2)とその結果(Data set3)の検証により，行使判定を行い，Decision Assertionが作成される．
④Decision Assertion がインターネット端末の
Policy Enforcement Point
に送 信（Data set4）される．それにより，インターネット端末から外部インター ネットへのアクセスが可能になる．具体的には，Packet Filterにルーティン グ情報とタイマが設定され，インターネット端末のWeb Browser
が起動され る．その結果(Data set5)がUsage Decision
に送信されることで，利用権の削 除指示(Data set6)が発出され利用権が削除される．79 Internet Terminal IC card
Use-right Policy Execution User
Packet Filter Gateway
User Policy Decision Insert IC card
Use-right Policy ID Acquisition
Public Key Certification Request Public Key Certification Exchange Select Internet Terminal
Authentication Process Start Order Data set1
Resource Policy Decision
Data set2 Resource Policy
Decision
Verification &
usage decision Data set3
Data set4 Verification &
Execution
APDU Relay Data set6
Resource Display
APDU Relay
APDU Relay
Verification
Start OK
Routing Information &
Timer Setting OK Data set5
Verification & Use-right policy deletion
Usage Decision
Web Brower
Policy Enforcement Point
②
③
④
Internet Terminal IC card
Use-right Policy Execution User
Packet Filter Gateway
User Policy Decision Insert IC card
Use-right Policy ID Acquisition
Public Key Certification Request Public Key Certification Exchange Select Internet Terminal
Authentication Process Start Order Data set1
Resource Policy Decision
Data set2 Resource Policy
Decision
Verification &
usage decision Data set3
Data set4 Verification &
Execution
APDU Relay Data set6
Resource Display
APDU Relay
APDU Relay
Verification
Start OK
Routing Information &
Timer Setting OK Data set5
Verification & Use-right policy deletion
Usage Decision
Web Brower
Policy Enforcement Point
②
③
④
図 4.16 インターネット端末一時利用シーケンス
4.4.3. 性能測定
図
4.7
の①の処理に含まれるIC
カード内の利用者属性判定処理（User policydecision）と図 4.16
の②～④で示される分散認証認可処理は非同期で実行される．そのため，それぞれ，独立に性能測定を実施した．
（１）ICカード内の利用者属性判定処理
4.3.4.節で示した条件判定種別毎の処理時間を図 4.17
に示す．また，参考で，同じ条件判定を
XACML
で記述した場合の条件判定文のデータサイズの比較を 表4.9
に示す．性能に関しては，条件判定種別によって多尐のばらつきがあるものの，おお
むね
100msec
前後であった．実際の利用シーンを想定すると問題の無い範囲である．これは，ICカードという計算リソースが限られている環境では，逆ポー ランド記法による条件判定文を処理可能な仮想スタックマシンが適しているこ とを表している．
一方，表
4.9
より，逆ポーランド記法では，XACMLで記述した場合に比べ，2～15％程度のサイズに収まっていることが分かる．これは，今回，処理可能な
判定条件を限定したこと，可変長データ記述形式であるTLV
を用いて変数名等 を符号化したことなどが効果を表していると考える． XACMLでは，条件を記 述しないことで，条件なしと判定させることができる．一方，逆ポーランド記 法では，最終的にスタックに何らかの値が積まれている必要がある．そのため，条件なしの場合，条件が真であることを示す値を最低限スタックに積んでおく 必要がある．条件なしの場合，XACMLが
0byte
になっているのは，この理由 によるものである．81 0
20 40 60 80 100 120 140 160
条件なし 利用者ID限定 年齢制限 会員限定 グループ限定 処理時間（msec)
条件判定種別
図
4.17 条件判定種別毎の処理時間
表
4.9 条件判定文のデータサイズ比較
条件
XACML（byte）
逆ポーランド記法(byte) 比率（％）条件なし
0 3
―利用者
ID
限定434 24 6
年齢制限
752 22 3
会員限定
514 12 2
グループ限定
545 84 15
（２）分散認証認可処理
実際に資源を利用する場面である図
4.16
の②から④までの動作時間と3
章で 示した自律的資源利用認証方式における動作時間を図4.18
に示す．分散認証認 可方式は，約2.6s
で処理が完了しており顕著な改善が見られる．自律的資源利 用認証方式では，利用権や利用者属性をIC
カードから資源に集約後，認証認可を実施する形態であった．そのための暗号通信路構築が性能に影響していた．
今回は，暗号通信路を前提としなかったことが性能向上に貢献している．特に，
分散認証認可プロトコルの中核である異なる装置間の行使判定処理③に関して
は，約
600ms
で完了しており，その高速性が確認できた．今回のプロトタイプでは，Usage Decisionをインターネットとの接続制御機 能としてのゲートウェイ装置に実装している．そのため，設置される端末台数 によっては，行使判定時にサービス認可装置であるゲートウェイ装置に負荷が かかり，処理性能が劣化する可能性がある．そこで，スケーラビリティに関す る評価実験を行った．
5
台の実機（Real Terminal）にそれぞれ10
台の仮想端末(Virtual Terminal) を実装した．計50
台の仮想端末に対して，指数分布に基づく利用者の到着率λ（到着利用者数／ms）により仮想的な利用者を生成するシミュレータ(図
4.19)
を実装した．それぞれの装置スペックを表4.10
に示す．本シミュレータを用いて，行使判定処理③のスケーラビリティを評価した結 果を図
4.20
に示す．本実験では，サービス認可装置のスケーラビリティ評価が 目的である．そのため，サービス利用による待ち時間の影響を抑えてサービス 認可装置に負荷をかける必要があり，サービス利用時間を2
秒と固定して評価 を行った．その結果，λ＝0.0003の時，つまり3
秒当たり1
人の利用者が到着 する場合，行使判定処理時間は，約1.2
秒であった．また，λ＝0.001の時，す なわち1
秒当たり1
人の利用者が到着する場合，行使判定処理時間は，約3
秒 であった．以上より，分散認証認可プロトコルの中核である異なる装置間の行使判定処 理③に関わるスケーラビリティ上の問題は無いと言える．これは，空港やカフ ェでのネットワーク資源を一時利用するような想定する利用シーンを前提とし ている．