\chapter{組織の中の許認可を管理するアプリケーションmaTrix}

maTrixとはSymphonies社が開発しているアカウント管理、許諾判定システムのことである。
人や組織の情報などを保持しており、それらの情報を関連付けることで組織の構造を表現している。
\label{chap:concept}

\section{maTrixの保持するデータ構造}
matrixは人、役職、役割、権限といった木構造の組織、許認可の判断に用いるポリシーファイルの２つのデータを持っている。
また、組織のデータは、ユニークなIdを保持しており、それを利用しお互いに参照しあっている。
maTrixは、過去のデータも構成情報モデルとして全て保持し、版管理している。
\begin{figure}[h]
\begin{center}
\includegraphics[height = 6cm , bb=0 0 463 271]{fig/maTrixVersion1.pdf}
\caption{maTrixの構成情報例1}
\label{fig:maTrixVersion1}
\end{center}
\end{figure}

人物と役職のTreeのversionが共に1の時、構成情報モデルのversionも1とする。

\begin{figure}[h]
\begin{center}
\includegraphics[height = 6cm , bb=0 0 463 271]{fig/maTrixVersion2.pdf}
\caption{maTrixの構成情報例1}
\label{fig:maTrixVersion2}
\end{center}
\end{figure}
構成情報モデルのversion:1の人物Treeを更新した場合、version:2の構成情報が構築され、maTrixはversion:1の構成情報とversion:2の構成情報の両方を保持し、両方の構成情報にアクセスすることが可能である。

maTrixのデータ構造は、組織のTreeをxmlやjson形式で出力することができる。
以下に人物Treeをxml形式で出力したデータの一部として、1人分のデータを記述する。

\begin{itembox}[l]{}
\begin{verbatim} 
<Persons> 
<Person id="p:1" type="Person"> 
<accountId>a:26</accountId> 
<lastName>東</lastName> 
<name>東俊一</name> 
<nameReading>あずましゅんいちくん</nameReading> 
<roleRefIds>
<roleRefId>r:10</roleRefId> 
<roleRefId>r:34</roleRefId> 
</roleRefIds> 
<parentOrganizations type="OrganizationMappedByRole"> 
<OrganizationMappedByRole type="OrganizationMappedByRole"> 
<organizationRefId>o:2</organizationRefId> 
<roleRefId>r:10</roleRefId> 
</OrganizationMappedByRole> 
<OrganizationMappedByRole type="OrganizationMappedByRole"> 
<organizationRefId>o:11</organizationRefId> 
<roleRefId>r:34</roleRefId> 
</OrganizationMappedByRole> 
</parentOrganizations> 
<priorities type="PriorityMappedByRole"> 
<PriorityMappedByRole type="PriorityMappedByRole"> 
<priority>0</priority> 
<roleRefId>r:10</roleRefId> 
</PriorityMappedByRole> 
<PriorityMappedByRole type="PriorityMappedByRole"> 
<priority>1</priority> 
<roleRefId>r:34</roleRefId> 
</PriorityMappedByRole> 
</priorities> 
</Person> 
</Persons>
\end{verbatim}
\end{itembox}

\clearpage

\begin{table}
\caption{Person.xmlの要素}
\label{list:TreeNode}
\begin{center}
\begin{tabular}{|l|l|} \hline
Persons   & この要素以下にPersonの情報があることを意味する~ \\ \hline
Person    & 人の情報が以下にあることを示す。uniqueIdが割り振られている ~\\ \hline
accontId  & そのPersonのアカウントId ~ \\ \hline
lastName  & 苗字   ~ \\ \hline
name      & フルネーム ~\\ \hline
nameReading & 名前のふりがな ~\\ \hline
roleRefIds &  この要素以下にその人が保持する役割を記述する ~\\ \hline
roleRefId  &  役割のIdを記述する　 ~\\ \hline
parentOrganizations & この要素以下にその人が所属している組織のIdを記述する　 ~\\ \hline
OrganizationMappedByRole & この要素以下に組織と、その組織の役割を記述する ~\\ \hline
organizationRefId & 所属している組織のId ~\\ \hline
priorities & 人物に割り振られている役割の優先順位を以下に記述する ~\\ \hline
PriorityMappedByRole & この要素以下に役割と優先順位をペアで記述する ~\\ \hline
priority & 役割の優先順位を記述する \\ \hline
\end{tabular}
\end{center}
\end{table}

Person.xmlを例で上げたが、役職Treeや役割Treeも同じような構造でデータを保持している。
人物や役割等のデータ同士の参照はIdを用いて行っている。
また、maTrixには、組織情報からデータを取得するFunctionが15種類実装されている。


\clearpage

\section{アカウント管理}

maTrixは、一度の利用者認証で複数のサービスを利用できるサービスであるSSOを採用している。
maTrixを使用しなかった場合、図\ref{fig:maTrix1}のようにアプリケーションごとにアカウントを作る必要があり、userの
権限等が変わった際に、全てのアカウントの更新を行う必要があるため、手間がかかったり、ミスが発生するなど、業務に支障をきたすおそれがある。

\begin{figure}[h]
\begin{center}
\includegraphics[height = 6cm , bb=0 0 538 339]{fig/maTrix1.pdf}
\caption{maTrixにおけるアカウント管理例1}
\label{fig:maTrix1}
\end{center}
\end{figure}

しかしmaTrixを用いることで図\ref{fig:maTrix2}の様に、maTrixのアカウント１つで全ての業務アプリケーションにアクセ
スできる。そのため、userの権限が変わったとしてもmaTrixのアカウントの更新だけしか行う必要がないので、手間もかからず、ミスも発生しづらい。


\begin{figure}[h]
\begin{center}
\includegraphics[height = 6cm , bb=0 0 538 301]{fig/maTrix2.pdf}
\caption{maTrixにおけるアカウント管理例2}
\label{fig:maTrix2}
\end{center}
\end{figure}


この様に実際の業務で、複数のアプリケーションを使用する際は、maTrixの様なアカウント管理サービスは必須とも言える。

\section{申請の許認可}
maTrixを用いた許認可は、アクセス管理のルールを表現方法を定義するXACMLという言語で記述された、ポリシーファイルを用いて行う。
ポリシーファイルは、リポジトリで管理されており、アクセス要求にあったポリシーファイルが利用される。
以下にmaTrixでの申請の許認可の流れを記述する。

\begin{enumerate}
\item Aさんが、資料Bを閲覧するために、maTrixにアクセス許可を求める。
\item maTrixはリポジトリから、権限を決定するためのポリシーを取得する。
\item 保持している組織構造のデータにアクセスを行い、ポリシーファイルを元に権限を与えるかどうかを判断する。
\item maTrixは権限に応じて、資料BをAさんに与える。
\end{enumerate}
といった流れになる。

maTrixの許認可を使用するメリットとして、許認可のログをとっておくことで、いつ、誰が、どのポリシーを元に、どんなことをしたか、の情報がいつでも取得可能であるため、不正アクセス等の問題発生時の解決等役立つ。
といったメリットも有る。

\clearpage
\section{XACML}
本節ではmaTrixのポリシーファイルの記述に用いられているXACMLについての説明を行う。
XACMLは、データに関するアクセス要求について、その要求元の情報と要求の内容、アクセス対象の組み合わせから、その
アクセス要求が許可されるか否認されるかを判断するためのルールを記述できる。
実際に使用する際は、XACML自体がアクセス制御を行うのではなく、アクセス管理アプリケーションがXACMLを参照しアクセス制御を行う。XACMLは以下の様なデータ構造を持つ(図\ref{fig:xacml})

%\begin{figure}[h]
%\begin{center}
%\includegraphics[height=10cm,bb=0 0 439 610]{fig/XACMLDataflow.pdf}
%\caption{アクセス制御のデータフロー}
%\label{fig:xacmlDataflow}
%\end{center}
%\end{figure}

\begin{figure}[h]
\begin{center}
\includegraphics[height=10cm,bb=0 0 439 610]{fig/XACML.pdf}
\caption{XACMLのデータ構造}
\label{fig:xacml}
\end{center}
\end{figure}


Targetは、誰に対して(Subject)、どのような資源を(Resource)、どのように扱うか(Action)の3つの要素を持ち、それぞれの要素で、評価関数を用いて評価を行う。評価の結果は、Match、No-Match、Indeterminate(評価不能)の3つである
。


Ruleは、Targetに対する規則を定めるもので、ルールの方針にそってアクセス要求がこのルールに適合した場合に決定する値(Permit、Deny)を、Effectとして設定しておく。
また、Targetとは別にオプションとして条件(Conditions)を付けることも可能である(条件の例としては、アクセスを許可する時間の指定などがある)。
ルールの評価は、Targetの評価関数の結果とConditionの、ルール結合アルゴリズム(表\ref{list:rule})にそって結合する。

\begin{table}[h]
\caption{Ruleの評価}
\label{list:rule}
\begin{center}
\begin{tabular}{|l|l|l|} \hline
Target   & Condition & 評価　~ \\ \hline
Match   & true & Efferct(Permit or Deny)  ~\\ \hline
Match& false & NotApplicable ~ \\ \hline
Match& Indeteminate & Indeteminate ~ \\ \hline
No-Macth & - & NotApplicate ~ \\ \hline
Indeterminate & - & Indeteminate \\ \hline
\end{tabular}
\end{center}
\end{table}
\newpage

Policy

複数のRuleをまとめたものをPolicyという。
Policyの子要素には、Target、Rule、Obligations(責務)がある。
もしも、PolicyにObligationsが規定された場合は、たとえ、ルール結合後の結果がpermitであったとしても、Obiligationsに記述されていることを同時に実施することが出来なかった場合、承認を拒否する必要がある。
またPolicyが複数のRuleを評価するときは、ルール結合アルゴリズム(表\ref{list:policy})を用いる。

\begin{table}[h]
\caption{XACMLのルール結合アルゴリズム}
\label{list:policy}
\begin{center}
\begin{tabular}{|l|l|} \hline
Deny-overrides   & どれか１つのルールのEffectがDenyであれば結果はDenyとする　~ \\ \hline
Permit-overrides    & どれか１つのルールのEffectががPermitであれば結果はPermitとする ~\\ \hline
First-applicable  & ポリシー内のすべてのルールについて順番に評価して、対象がマッチした場合、\\
& 対象の評価結果をMatchとし、次にConditionを評価し、これがTrueなら\\
&結果はEffectで指定されたPermitまたはDenyとする。 ~ \\ \hline
\end{tabular}
\end{center}
\end{table}