TAM研修2日目

2日目。細かい内容に突入してきた。
主にポリシーと呼ばれる権限付与の設定に関して。昨日の1日目のWebSEALと許可DB(ポリシーサーバ)の部分に相当する。

ポリシー

以下３つの種類がある

1. ACL(Access Control List)
2. POP(保護オブジェクト・ポリシー)
3. 許可ルール

POPと許可ルールはオプション

┌──┐OK  ┌──┐OK　┌─────┐
│ACL │┬→│POP │┬→│許可ルール│→アクセス許可
└──┘│　└──┘│　└─────┘
　　　　↓NG　　　　↓NG
　　　拒否　　　　　拒否

ACL

ユーザやグループにおけるパーミッションの設定を行う。

• ユーザ
• グループ
• 特殊グループ
  • any_other(全ての認証ユーザー)
  • unauthenticated(非認証ユーザー)

権限確定順序

以下の順序で一致次第確定

1. ユーザID
2. グループID
3. any_other
4. unauthenticated

つまり、ユーザで許可してたら許可。グループで許可しててもユーザで拒否していたら拒否が返る。

POP

設定は任意。時刻による許可・拒否ができる。深夜は拒否とか。あまり使わないと思われ。ただ、デバッグ目的でACLの設定を無視できる項目があり、違反していればログだし出来る。

許可ルール

より細かい設定が可能。LDAPサーバに格納されているオブジェクトが〜だったら、とか。
しかし、何故かXSLで書かないといけない。
何故か、XSLで設定。ポリシーサーバがJAVAプログラムで、内部的にXMLで処理しているからか？

<xsl:if test="azn_cred_principal_name='jadmin'">
!TRUE!
</xsl:if>

みたいな感じ。出力が!TRUE! or !FALSE!なら良いのかな。
面白そうだが、プロジェクトで実際に使うとなった時、泣きをみそうだ。謎が多いし出来れば避けたい。

WebSEAL

• マルチスレッドのWebサーバ
• リバースプロクシ

なのは1日目で触れていた。

冗長構成

WebSEALサーバは複数設置でき、ロードバランサで負荷分散する事が多い。

• ただし、WebSEAL同士でセッション情報の共有はされないので、セッション継続中は同一WebSEALサーバへ割り振る必要がある(ぉぃ
• セッション継続中、WebSEALが落ちた場合、他方に割り振られるがセッション情報がない。回避法としてCookieの設置(ぉぃぉぃ

何だか一般的なロードバランサの注意点の様な気がするぞ。セッション情報の共有までやってくれてこそ高い金払って製品を買う意味がありそうなのに...。

ここら辺で2日目終わり