この章では、OWLCS へのデプロイ時に SIP サーブレット リソースにセキュリティ制約を適用する方法について説明します。以下の節で構成されています。
SIP サーブレット API 仕様では、SIP サーブレットの宣言型セキュリティおよびプログラムに基づくセキュリティの提供に使用できるデプロイメント記述子要素のセットを定義します。セキュリティ制約を宣言するための主要な方法は、sip.xml
デプロイメント記述子の中で 1 つまたは複数の security-constraint
要素を定義することです。security-constraint
要素は保護対象である resource-collection の要素
で定義された SIP サーブレットで実際のリソースを定義します。security-constraint
はリソースにアクセスするため公認されたロール名も識別します。security-constraint
内で使用されるすべてのロール名は、sip.xml
の security-role
要素内の他の場所で定義されます。
SIP Servlet では、サーブレット コード内でロール名をプログラム的に参照し、そのハードコード化されたロール名をデプロイメント時に sip.xml
の security-role-ref
要素内で別のロールにマップすることもできます。security-role-ref
要素内でハードコード化された名前にマップしようとするロールは、security-role
要素内の他の場所で定義しておく必要があります。
SIP Servlet 仕様によると、サーブレットでは run-as
要素を使って呼び出し先のエンタープライズ JavaBean (EJB) にセキュリティ ロールを伝播することもできます。run-as
要素内で使用するロールは、sip.xml
の別個の security-role
要素内で定義する必要があります。
SIP Servlet API 仕様の第 14 章には、SIP サーブレットで使用できるセキュリティのタイプに関して、さらに詳しい記述があります。SIP Servlet のセキュリティ機能は、HTTP Servlet で使用できるセキュリティ機能に似ています。Oracle WebLogic Communication Services ドキュメントの下記の節には、HTTP Servlet セキュリティについての情報が記載されています。
「WebLogic セキュリティのプログラミング」の「Web アプリケーションのセキュリティ対策」では、サーブレットの宣言によるセキュリティ モデルとプログラムによるセキュリティ モデルについて概説されています。
「エンタープライズ JavaBean (EJB) のセキュリティ対策」の「EJB のセキュリティ関連のデプロイメント記述子」には、EJB のセキュリティ関連のデプロイメント記述子の全要素が記述されています。呼び出し先の EJB にロールを伝播する際に使用する run-as
要素についても、ここで解説されています。
例 6-1「sip.xml 内の宣言によるセキュリティ制約」に示す、サンプルの sip.xml
の抜粋も参照してください。
401 SIP 応答コードまたは 407 SIP 応答コードのどちらか適切な SIP 応答コードをトリガするようコンテナをコンフィグレーションすることで、プロキシ アプリケーションまたは UAS アプリケーションを識別できます。インビテーションをプロキシする必要がある場合は、407 コードが適切です。レジストラ アプリケーションの場合は、401 コードを使用する必要があります。
401 応答コードの代わりに 407 応答コードで応答するようコンテナをコンフィグレーションするには、セキュリティ制約に <proxy-authentication>
要素を追加する必要があります。
sip.xml ファイル内の現在のセキュリティ レルムの名前を以下のように指定する必要があります。
<login-config> <auth-method>DIGEST</auth-method> <realm-name>myrealm</realm-name> </login-config>
SIP サーブレットをデプロイするときは、宣言およびプログラムによるセキュリティとして作成した security-role
定義を、サーブレット コンテナで使用できる実際のプリンシパルやロールに割り当てる必要があります。OWLCS では実際のプリンシパルやロールに security-role
定義をマップする際に weblogic.xml
で security-role-assignment
要素を使用します。security-role-assignment
は後でロール割り当てを変更する際に必要な柔軟性の程度によって、2 通りのセキュリティロールのマップ方法を備えています。
security-role-assignment
要素では、sip.xml
内で定義されたロールにマップするプリンシパル名とロールのリストを定義することができます。この方法ではロール割り当てをデプロイメント時に定義しますが、柔軟性が犠牲になります。たとえばロールにプリンシパルを追加したり逆に削除したりするためには、weblogic.xml
を編集して、SIP サーブレットを再デプロイしなければなりません。
security-role-assignment
内で externally-defined
要素を使用する方法では、Administration Console からいつでもプリンシパル名とロールを sip.xml
のロールに割り当てることができます。externally-defined
要素を使用した場合、プリンシパルとロールを sip.xml
のロールに追加したり削除したりしても SIP サーブレットを再デプロイする必要はありません。
さらに、sip.xml
の run-as
要素へのロールの割り当てに使用できる XML 要素が 2 つあります。それは run-as-principal-name
と run-as-role-assignment
です。これらのロール割り当て要素を使用した場合は、security-role-assignment
要素よりも優先されます。これについては、「run-as ロールの割り当て」で説明します。
また、weblogic.xml
内でロール マッピング要素を指定せずに、暗黙的なロール マッピングを使用することもできます。これについては、「暗黙的なロール割り当ての使用」で説明します。
以下の節では、OWLCS のロール割り当てについて詳しく説明します。
暗黙的なロール割り当てを使用すると、OWLCS は sip.xml
内の security-role
名を同名のロールに割り当てます。このロールは OWLCS セキュリティ レルムでコンフィグレーションする必要があります。暗黙的なロール マッピングを使用するには、weblogic.xml
で security-role-assignment
要素を省略します。run-as
ロールをマップするための run-as-principal-name
および run-as-role-assignment
要素も省略します。
weblogic.xml
内に使用できるロール マッピング要素がなければ、OWLCS は sip.xml
の security-role
要素を同名のロールに自動的にマップします。なお、暗黙的なロール マッピングは、sip.xml
で定義されたロール名が実際にセキュリティ レルムにあるかどうかに関係なく行われます。OWLCS で暗黙的なロール割り当てが使用されるときは常に警告メッセージが表示されます。たとえば、sip.xml
で「everyone」ロールを使用し、weblogic.xml
でこのロールを明示的に割り当てなかった場合、次のような警告メッセージが表示されます。
web.xml で定義された <Webapp: ServletContext(id=id
,name=application
,context-path=/context
), the role:everyone
が weblogic.xml の security-role-assignment のプリンシパルにマップされていません。ロール名をそのままプリンシパル名として使用します。>
対応するロールを OWLCS セキュリティ レルムで定義してあれば、この警告メッセージは無視できます。weblogic.xml
で明示的なロール マッピングを定義すれば、このメッセージを無効にすることができます。
暗黙的なロール割り当ては、デプロイメント時のロール マッピングを既知のプリンシパル名にハードコード化したい場合に使用してください。
weblogic.xml
内で security-role-assignment
要素を使用すると、ロールの割り当てをデプロイメント時に行えるほか、Administration Console でいつでも行えます。以下の節で、それぞれのアプローチについて説明します。
weblogic.xml
内で security-role-assignment
要素を指定する場合、OWLCS では web.xml
デプロイメント記述子内でも security-role
要素を定義することが必要です。この要件は純粋な SIP サーブレットをデプロイする場合にも適用されます。通例、純粋な SIP サーブレットをデプロイする場合には web.xml
デプロイメント記述子は必要とされません (一般に HTTP Web アプリケーション用に確保されています)。
注意 : weblogic.xml 内で security-role-assignment を指定した場合に、web.xml 内に対応する security-role 要素がないと、OWLCS では次のようなエラー メッセージが表示されます。security-role-assignment は無効な security-role: rolename を参照します。 その後、「暗黙的なロール割り当ての使用」で述べたように、sip.xml 内で定義されている security-role が同名のロールに自動的にマップされます。 |
例として、例 6-1 にロール roleadmin
でセキュリティ制約を定義する sip.xml
デプロイメント記述子の一部を示します。例 6-2 は roleadmin
にプリンシパルとロールを割り当てるため、weblogic.xml
で定義された security-role-assignment
要素を示します。OWLCS では、このサーブレットを、例 6-3 のように、roleadmin
ロールも定義した web.xml
デプロイメント記述子でデプロイする必要があります。
もし web.xml
の内容が使用できなければ、OWLCS は暗黙的なロール割り当てを使用し、セキュリティ レルムで roleadmin
ロールが定義されているものと見なします。その場合、weblogic.xml
で割り当てられたプリンシパルとロールは無視されます。
... <security-constraint> <resource-collection> <resource-name>RegisterRequests</resource-name> <servlet-name>registrar</servlet-name> </resource-collection> <auth-constraint> <javaee:role-name>roleadmin</javaee:role-name> </auth-constraint> </security-constraint> <security-role> <javaee:role-name>roleadmin</javaee:role-name> </security-role> ...
weblogic.xml
内の基本的な security-role-assignment
要素定義は、sip.xml
内で定義された security-role
と OWLCS セキュリティ レルム内で使用できる 1 つまたは複数のプリンシパルやロールとの間でのマッピングを宣言します。security-role
を sip.xml
の run-as
要素と組み合わせて使用した場合、OWLCS は security-role-assignment
で指定された最初のプリンシパル名またはロール名を run-as
ロールに割り当てます。
例 6-2「weblogic.xml 内の security-role-assignment の例」は、security-role-assignment
要素の例を示しています。この例では、例 6-1「sip.xml 内の宣言によるセキュリティ制約」で定義されている roleadmin
ロールに 3 人のユーザを割り当てています。このロール割り当てを変更するには、weblogic.xml
記述子を編集し、SIP サーブレットを再デプロイする必要があります。
<principal-name>
要素の代わりに externally-defined
要素を使用すると、sip.xml
の role-name
要素で定義したセキュリティ ロールに、Administration Console で割り当てるマッピングを適用することを指定できます。externally-defined
要素を使用すると、デプロイメント時にセキュリティ ロールごとに特定のセキュリティ ロール マッピングを指定する必要がなくなります。この場合、Administration Console を使って、いつでもロール割り当てを指定したり変更したりすることができます。
なお、この要素を使用するかどうかの選択は SIP サーブレットによって違ってくるはずなので、セキュリティ レルムに関して [デプロイメント記述子のロールとポリシーを無視] オプションを選択する必要はありません (このオプションの選択は、Administration Console の [セキュリティ|レルム|myrealm] コントロール パネルの [一般] タブの [今後の再デプロイの設定:] フィールドで行います)。したがって、同じセキュリティ レルム内で、セキュリティの指定や変更の手段としてデプロイメント記述子と Administration Console をアプリケーションに応じて使い分けることができます。
注意 : セキュリティ ロール名を指定するときは、次の規約と制限に従ってください。
|
例 6-4 は、例 6-1「sip.xml 内の宣言によるセキュリティ制約」で定義されている roleadmin
ロールでの externally-defined
要素の使用例を示しています。既存のプリンシパルとロールを roleadmin
ロールに割り当てるには、OWLCS の Administration Console を使用します。
Administration Console によるセキュリティ ロールの追加と変更については、「Users, Groups, and Security Roles」を参照してください。
「security-role-assignment を使用したロールの割り当て」で述べた security-role-assignment
は、sip.xml
内で定義された run-as
ロールをマップするのにも使用できます。ただし、weblogic.xml
内で使われる 2 つの要素は security-role-assignment
よりも優先されます。この 2 つの要素とは、run-as-principal-name
と run-as-role-assignment
です。
run-as-principal-name
では、すべての run-as
ロール割り当てに適用されるセキュリティ レルム内の既存のプリンシパルを指定します。weblogic.xml
の servlet-descriptor
要素内で定義する場合は、run-as-principal-name
がその他の run-as
ロールのロール割り当て要素より優先されます。
run-as-role-assignment
では、すべての run-as
ロール割り当てに適用されるセキュリティ レルム内の既存のロールまたはプリンシパルを指定します。この要素は weblogic-web-app
要素内で定義します。
weblogic.xml
の個々の要素の詳細については、「weblogic.xml デプロイメント記述子リファレンス」を参照してください。run-as
ロール マッピングならびに宣言およびプログラムによるセキュリティのロール マッピング優先順位については、「SIP サーブレット ロールのロール割り当て優先順位」も参照してください。
OWLCS では、デプロイメント時に sip.xml
のロールを SIP コンテナ内の実際のロールにマップする方法が何通りかあります。sip.xml
内で定義される宣言およびプログラムによるセキュリティに関しては、ロール割り当ての優先順位は次のようになります。
weblogic.xml
の security-role-assignment
要素内で sip.xml
のロールを割り当てた場合は、その security-role-assignment
が使われます。
使用できる security-role-assignment
がない場合は (または必要な web.xml
ロール割り当てが抜けている場合は)、暗黙的なロール割り当てが使われます。
run-as
ロール割り当てに関しては、ロール割り当ての優先順位は次のようになります。
weblogic.xml
の servlet-descriptor
内で定義した run-as-principal-name
要素内で sip.xml
の run-as
ロールを割り当てた場合は、その run-as-principal-name
割り当てが使われます。
weblogic.xml
の run-as-role-assignment
要素内で sip.xml
の run-as
ロールを割り当てた場合は、その run-as-role-assignment
要素が使われます。
weblogic.xml
が security-role-assignment
要素で sip.xml run-as
ロールを割り当てる場合は、security-role-assignment
を使用します。
使用できる security-role-assignment
がない場合は (または必要な web.xml
ロール割り当てが抜けている場合は)、暗黙的なロール割り当てが使われます。
開発した SIP サーブレットのセキュリティ機能をデバッグする場合は、OWLCS の起動時に -Dweblogic.Debug=wlss.Security startup
オプションを指定してください。このデバッグ オプションを使用すると、OWLCS でセキュリティ関連の追加のメッセージが標準出力に表示されるようになります。
weblogic.xml
DTD には、ここで説明したロール マッピング要素に関する詳細情報が記載されています。詳細については、「weblogic.xml Deployment Descriptor Elements」を参照してください。