PKIとPMIを融合させる次世代言語XACML：Webサービスのセキュリティ（5）

　「第1回 Webサービスのセキュリティ概要」はWebサービス・セキュリティのフレームワークについて、「第2回 XMLデジタル署名とXML暗号」はXML署名とXML暗号について述べた。「第3回 XML鍵管理サービスとXMLプロトコル」は鍵情報の登録と鍵情報の検証サービス（XKMS）と、これらの情報を伝達するためのXMLプロトコルSOAPについて、「第4回 強力なSSOを実現するXML認証・認可サービス」はシングルサインオン（SSO）と属性情報やアクセス制御情報を伝達するプロトコルSAML（Security Assertion Markup Language）について述べた。今回からは本連載の最終段階として、柔軟で拡張性のあるアクセス制御を実現するためのポリシー記述言語XACML（eXtensible Access Control Markup Language）について述べる。SAMLやXACMLはPKIと権限管理のインフラストラクチャであるPMI（Privilege Management Infrastructure）を融合させる次世代のフレームワークである。

　XACMLは11月8日にXACML 1.0としてOASISのComittee Specificationになり、1カ月のパブリックレビューを受けて正式のOASIS標準となることになった。XACML1.0の仕様書はOASIS eXtensible Access Control Markup Language TCを参照してほしい。

XML認可サービス（XACML）

　前回述べたSAMLは、認証を受けた主体がその資格や属性によってあるルールの下に資源へのアクセス権限を証明する仕組みを定めたものである。XACMLは、このSAMLのフレームワークの上で特にポリシー決定点（PDP：Policy Decision Point）に対する認可決定を判断させるためのポリシーおよびルール規定の仕様を定め、併せてポリシー決定点に対する認可要求やその応答のプロトコルを定めたものである。PDPはこの柔軟なポリシー規定と認可要求の適合性を判断し、要求者の資源へのアクセスの許可、拒否を決定する。

　XACMLは、以前IBMの定めたXACL（XML Access Control Language）をベースとし、ポリシー記述の柔軟性と拡張性を高めたものとなっている。XACLはファイルの読み、書き、生成、削除を制御する仕様を規定したものでシンプルな構造であったが、柔軟なポリシー記述やより多様な資源へのアクセスを制御する点では拡張性に欠けるものであった。XACLの初めの文字XはXMLを指しているが、XACMLのXはeXtensible（拡張性）としており、XACLの持っていた制約をできるだけ排除し、多様な資源へのアクセス制御を実現させる拡張性のある柔軟なポリシー仕様を規定できるようにした。

　またXACMLは、XACLをベースにSAMLのフレームワークの中で認可決定のためのポリシー記述言語としてSAMLの仕組みを拡張するものとして企画されたが、現在の仕様はSAML環境以外にも適用できるように独立した認可決定の仕様としてまとめられている。例えばXACMLはSAMLのほかにJ2SE、CORBAなどにも用いることができる。

　XACMLではこの仕様の記述のために特有の用語を使用しているので、ここではXACMLで用いられる用語について解説しておく。

データフロー・モデル

　図1はXACMLのデータフロー・モデルを示している。XACMLのキープレーヤは図の中央に示している認可決定のPDP、認可ポリシーをまとめてポリシーを提供するPAP（Policy Administration Point）、認可決定要求を出し、認可決定応答を受けてアクセス制御を実行するPEP（Policy Enforcement Point）である。

図1 アクセス制御のデータフロー・モデル

　PEPの資源へのアクセス要求に対し、この認可決定を判断するためのルールやポリシーを定める部署は1つとは限らない。例えばある部署は主体の資格に対するルールを定めるかもしれず、ある部署は資源に対するアクセス条件を定めるかもしれない。XACML仕様では、複数の部署が提供するルールやポリシーをPAPが結合してポリシーやポリシー集合を作るとしている。PAPは一定のルールに従って複数あるルールを結合してポリシーを作り、またポリシーがさらに複数あればこれらを結合してポリシー集合を作りリポジトリに登録する。PDPはLDAPなどでポリシーを検索し、このポリシーやポリシー集合とPEPが示した属性を含む要求とのマッチングを図り認可決定を下すのである。

　XACMLは図1で示した3つの赤矢印、すなわちPAPからPDPに示すルールやポリシーを記述するためのXMLスキーマ、PEPがアクセス要求者の属性情報を記述してPDPに提示する要求Context、およびPDPがPEPに返す認可決定の応答Contextのスキーマを定めている。SAMLではこのような要求や応答をプロトコルといっていたが、XACMLではContextと呼んでいる。

　図1ではPDPに対する要求ContextはPEPから直接PDPに出され、応答ContextもPDPからPEPに直接返されるように示しているが、PEPは認可決定を受けて実際に資源に対するアクセス制御を実行するところで、具体的にはPEPは業務のアプリケーションであるかもしれない。このようなアプリケーションは独自のアクセス制御要求を出し、独自の応答で処理するようになっており、XACMLで定めた要求や応答のContextを処理できないかもしれない。従って実際のXACMLの実装に当たっては図2に示すようにXACMLの仕様で定める正規化されたContextとPEPの独自のプロトコルを変換するcontext handlerを設けることになろう。

図2 XACMLの実装でのXACML ContextとPEPの関係

Context構文

　PEPからPDPへのアクセス要求やPDPからPEPに対する応答をそれぞれ要求Context、応答Contextという。XACMLの要求と応答のContextの概要を図3に示す。

図3 XACMLの要求と応答のContextの概要

　PEPは要求Contextでアクセスを要求する主体の資格などの属性、アクセスしたい資源についての属性情報をPIPに問い合わせて収集し、資源に対してのアクセス方法（Read、Write）などを指定した要求をPDPに送る。PDPはこれらの要求をあらかじめ登録されたポリシーを検索して要求Contextと比較評価し、許可（Permit）または拒否（Deny）をPEPに応答する。ポリシーに責務＜Obligation＞があれば責務もPEPに示される。PEPはこれらの応答メッセージに従って資源へのアクセス制御を実行することになる。

●XACML 要求Context＜Request＞

　XACML要求Contextの＜Request＞要素はリスト1の例に示す構文で構成される。

　要求Contextは主体＜Subject＞がどのような資格や属性を持っているか、アクセスしたい資源＜Resource＞は何なのか、資源に対してどんな動作＜Action＞を要求するのかを、それぞれの属性＜Attribute＞要素に記述する。オプションとして主体、資源、動作以外の要求条件をオプションとしての環境＜Environment＞に与えることもできる。

●XACML 応答Context＜Response＞

　リスト1に示す要求Contextに対してPDPは要求Contextの主体、資源、動作についてのそれぞれの属性をポリシーの対象＜Target＞のそれぞれ主体、資源、動作の規則と比較評価し、要求とポリシーがマッチすれば、リスト2に示すような応答Contextを返す。

　応答Contextはリスト2に示すように資源に対してのアクセスの認可決定＜Decision＞要素でPermitまたはDenyを指定する。PDPが要求に対するポリシーを評価する際、適用できるルールがなかった場合の決定＜Decision＞はNotApplicableとなり、評価でエラーが起こった場合の決定＜Decision＞はIndeterminateとなる。

　もし評価するポリシーに責務＜Obligations＞が記載されていれば、応答Contextに責務＜Obligations＞をそのまま含める。責務＜Obligations＞を指定されたPEPは責務を実行しなければならない。

　今回は、XACMLのデータフロー・モデルとそれに関連してContext構文の解説を行った。次回は、引き続きXACMLポリシーでのアクセス制御ルールの例やポリシー言語の仕様に関して解説をする。