OpenAM １１．０．０ インストール

現時点（１２/２２）で最新版であるOpenAM 11.0.0のインストール方法について説明する。

①以下のForgeRockサイトからopenamのwarファイルをダウンロードする。

 https://backstage.forgerock.com/#/downloads

②warファイルをglassfishに配備する
※ここではアプリケーションサーバとしてGlassfish ｖ２．２を使用。
※ポートは８０８０とする。

③以下のURLにアクセスする。
http://localhost:8080/OpenAM-11.0.0

「設定オプション」において、「カスタム設定」にある「新しい設定の作成」を選択する。

④ OpenAMの管理ユーザのパスワードを指定する（パスワード長は8文字以上）。
「次へ」ボタンを押す。

⑤「サーバー設定」において、以下を入力する。「次へ」ボタンを押す。
・サーバーURL:　OpenAMを配備するURL
・Cookieドメイン：　クッキーのドメイン（※先頭に"."を付け忘れないこと）
・プラットフォームロケール：en_US
・設定ディレクトリ：OpenAMの設定ファイルを格納するディレクトリ

 ⑥OpenAMの設定データストアの情報を設定する。OpenAM付属のOpenDJを選択し、「次へ」を押す。

⑦OpenAMのユーザーデータストアの情報を設定する。OpenAM付属のOpenDJを使用するため、「OpenAMのユーザーストア」を選択し、「次へ」を押す。
※本稼動環境は未サポートである旨の警告メッセージが表示されるが、無視。

⑧「サイト設定」において、「いいえ」を選択し、「次へ」を押す。
※今回はロードバランサで負荷分散はしないため。

 

⑨「デフォルトのポリシーエージェントユーザ」において、パスワードを入力する。「次へ」を押す。

⑩「設定ツールの概要と詳細」において、「設定の作成」ボタンを押す。
インストールが開始される。

⑪インストール完了後、以下のURLにアクセスし、ログイン画面が表示されることを確認する。また、OpenAMの管理ユーザでログインできることを確認する。

http://localhost:8080/OpenAM-11.0.0

SAML 2.0 Single Logout

SAML2.0規約で規定するシングルログアウトについて勉強する。

下図で示すように、複数のSP（Service　Provider)とIdP間でシングルサインオンした場合、ログアウト時には、すべてのSP/IdPとクライアントとの間で確立した認証セッションを安全に終了させることが重要となる。SAML２．０仕様では、この仕組みを規定している。

 

SAML２．０仕様では、大きく以下の2種類のシングルログアウトの方法を規定する。

• SP Initiated
  SPがシングルログアウトの起点になる方法。
  たとえば、利用者はSP Aの業務アプリケーションを利用中であり、ログアウトボタンを押す。まず、SP AからIdPにシングルログアウト要求を出す。IdPでは利用者とのセッションを終了させた後、現在利用者とセッションを確立中であるSP　Bに対してシングルログアウト要求を出す。
• IdP Initiated
  IdPがシングルログアウトの起点になる方法。
  たとえば、利用者はIdPを利用中であり、ログアウトボタンを押す。IdPでは、現在利用者とセッションを確立中であるSP AおよびSP Bに対してシングルログアウト要求を出す。

上記の2種類のシングルログアウトでは、IdPにおいて、どのSPが利用者との認証セッションを確立しているのかを管理することが必要となる。SAMLでは、Session Indexという識別子を用いて実現する。
IdPでは、シングルサインオン時にSPに対して認証アサーションを発行する。このとき、認証アサーションには、Session　Indexも含めて発行する。SPでは、IdPから受信した認証アサーション内のSession Indexと、利用者とのローカルセッションのマッピング情報を管理する。
シングルログアウト時には、Session Indexを設定することにより、どのセッションを終了させたいのかを指定することが可能となる。

■シングルログアウトのメッセージ例
※<SessionIndex>要素の値としてSession Indexを指定してシングルログアウト要求を出す。

<samlp:LogoutRequest  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="s239dcd741931119aa038e59df6b080c4b8581faae" Version="2.0" IssueInstant="2012-01-07T14:03:15Z" Destination="http://openam.yasuyasu.com:38080/openam/IDPSloRedirect/metaAlias/idp"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://openam.yasuyasu.com:28080/openam</saml:Issuer><saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NameQualifier="http://openam.yasuyasu.com:38080/openam" SPNameQualifier="http://openam.yasuyasu.com:28080/openam" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">fdnShhUunBzV4YXtq4U+i8/c+IG6</saml:NameID>

<samlp:SessionIndex xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
s22d9e5d52b4a97720268e30cc09e02257f42c5d01
</samlp:SessionIndex>
</samlp:LogoutRequest>

XACML 2.0とXACML3.0の違い

認可関連の標準プロトコルであるXACML2.0と3.0の違いを簡単にまとめる。

<参照先URL>
http://xacmlinfo.com/2012/07/12/what-is-new-with-xacml-3-0/

1. 属性情報のカスタマイズ
   XACML 2.0では、カテゴリは、subject(主体者）、resource（リソース)、action(操作）、enviromentの４つに分かれていた。XACML3.0では、カテゴリを自由にカスタマイズできるようになった。
   たとえば、XACML2.0では、以下のポリシーを使用できるが、事前に定義されたカテゴリしか使用できない。
   
   

   1	<ResourceAttributeDesignatorAttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"DataType="http://www.w3.org/2001/XMLSchema#string"/>

   
   XACML3.0のポリシーでは、以下のように、Category属性にカテゴリの種類を指定する。これにより、新しいカテゴリを定義できるようになった。
   
   

   1	<AttributeDesignatorAttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"Category="resource" DataType="http://www.w3.org/2001/XMLSchema#string"/>

2. 義務情報（Obligation)の表現の向上
   PDPからPEPに伝える義務情報の表現が向上した。
   たとえば、PDPは、認可拒否した理由をPEPからユーザにメールで通知したかったとしよう。この場合、XACML2.0では、静的にユーザのメードアドレスをobligation要素に設定する必要がある。
   

   1	<Obligation ObligationId="send-email" FulfillOn="Deny">

   2	<AttributeAssignment AttributeId="email"DataType="http://www.w3.org/2001/XMLSchema#string">user@foo.com</AttributeAssignment>

   3	</Obligation>

   しかし、すべてのXACMLリクエストに対して同じユーザになることはないと考えられる。そのため、現実的には、obligation要素にメールアドレスのような静的な情報を含めることはできない。Obligation要素としては、「ユーザにメールアドレスで認可結果を連絡してください」という旨の情報を含めることになる。
   
   

   1	<Obligation ObligationId="send-email" FulfillOn="Deny">

   2	<AttributeAssignment AttributeId="text"DataType="http://www.w3.org/2001/XMLSchema#string">please send email to user</AttributeAssignment>

   3	</Obligation>

   
   XACML3.0では、動的な手法により、PIPから属性情報を取得することが可能である。それゆえ、Obligation要素としては、PDPはPEPに対して、「user@foo.com宛のEメールを送信してください」という情報を含めることが可能である。
   

   1	<ObligationExpression ObligationId="send-email" FulfillOn="Deny">

   2	<AttributeAssignmentExpression AttributeId="email"DataType="http://www.w3.org/2001/XMLSchema#string">

   3	<AttributeDesignator AttributeId="email"Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>

   4	</AttributeAssignmentExpression>

   5	</ObligationExpression>

3. Adviceの新規追加
   XACML3.0では、Obligationと同様の要素としてAdvice要素が新規に規定された。Obligation要素との違いは、ObligationはPEPでは義務として必ず従う必要があったが、Adviceの場合、PEPは従うか否かを選択することが可能となった。
   
4. Ｔａｒｇｅｔの表現の向上
   XACML2.0では、Ｔａｒｇｅｔ要素において、同じ種類のカテゴリ同士でしか、ORとANDの関係を定義できない。しかし、XACML3.0では、AllOf要素とAnyOf要素を使用することにより、異なるカテゴリに関してもORとANDの関係を定義できるようになった。
   
   たとえば、XACML2.0では、resourceとしてfoo1とfoo2をAND関係とし、bar1とbar2のactionをOR関係として定義できる。しかし、foo1のresourceとbar1のactionをOR関係として定義することはできない。
   XACML3.0では、以下のように、fooのresourceとbar1のactionのAND関係を定義することが可能である。
   

   01

   <Target>

   02

   <AnyOf>

   03	<AllOf>　←AND関係

   04	<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">

   05	<AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">foo</AttributeValue>

   06	<AttributeDesignator MustBePresent="false"

   07	Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

   08	AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"

   09	DataType="http://www.w3.org/2001/XMLSchema#string"/>

   10

   </Match>

   11	<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

   12	<AttributeValue

   13	DataType="http://www.w3.org/2001/XMLSchema#string">bar1</AttributeValue>

   14	<AttributeDesignator MustBePresent="false"

   15	Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"

   16	AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

   17	DataType="http://www.w3.org/2001/XMLSchema#string"/>

   18

   </Match>

   19

   </AllOf>

   20

   <AllOf>

   21	<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

   22	<AttributeValue

   23	DataType="http://www.w3.org/2001/XMLSchema#string">bar2</AttributeValue>

   24	<AttributeDesignator MustBePresent="false"

   25	Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"

   26	AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

   27	DataType="http://www.w3.org/2001/XMLSchema#string"/>

   28

   </Match>

   29

   </AllOf>

   30

   </AnyOf>

   31

   </Target>

5. 評価関数および判定アルゴリズムの追加
   文字列の評価関数について、以下が追加された。
   
   urn:oasis:names:tc:xacml:3.0:function:string-starts-with
   urn:oasis:names:tc:xacml:3.0:function:string-ends-with
   urn:oasis:names:tc:xacml:3.0:function:string-contains
   urn:oasis:names:tc:xacml:3.0:function:string-substring
   時刻を扱う評価関数について、以下が追加された。
   
   urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-equal
   urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-equal
   urn:oasis:names:tc:xacml:3.0:function:dateTime-add-dayTimeDuration
   
   既存の判定アルゴリズム（deny-overrides , permit-overrides, ordered-deny-overrides and ordered-permit-overrides）に加えて、以下の判定アルゴリズムが追加された。
   
   urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit
   urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit
   urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-unless-denyurn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-unless-deny
6. XPathデータタイプの対応
   XACML 3.0では、XPathデータタイプが追加された。XACML2.0では、XPathは文字列としてしか扱われていなかった。
7. XACMLリクエスト／レスポンスの表現の向上
   XACML2.0では、Subject、Resource、ActionおよびEnvironmentしか認可要求のリクエストに含めることができなかった。XACML 3.0では、多様な属性のカテゴリを定義できるため、リクエストに多様なカテゴリを含むことができる。
8. XACMLリクエストの一括認可要求対応
   PEPは、PDPに対する認可要求において、複数のリクエストを含めることが可能である。PEPとPDP間の性能向上につながると考える。
9. ポリシー管理プロファイルの追加
   XACML3.0では、だれが認可ポリシーを管理することができるかを規定するポリシーを定義することができる。
   たとえば、太郎は、リソースＸに関するXACMLポリシーのみを発行することができるなど。