| Oracle® Spatial開発者ガイド 11gリリース2 (11.2) B72087-03 |
|
 前 |
 次 |
SpatialのWebサービスを使用する場合は、できるだけセキュアな方法でデータベースに接続します。このような状況におけるセキュリティには、次のような考慮事項があります。
機密保護: 第三者がユーザーとサーバー間のメッセージを傍受および復号化することはできないという保証
認証性: 第三者が別のユーザーになりすましてサーバーに接続することはできないという保証
整合性: メッセージの変更を検出されずに、第三者がユーザーとサーバー間のメッセージを変更することはできないという保証
信頼性の高い方法で各ユーザーIDが認証された後に、ユーザーIDおよびIDに関連付けられた権限に基づいてデータおよび機能へのアクセスを制限する、柔軟かつファイングレインな認可が行われることもユーザーは期待します。しかし、現行の多くのXMLインタフェースおよびSOAPインタフェースは、このようなセキュリティ方式には十分に対応していません。
この章の内容は次のとおりです。
SpatialのWebサービスのセキュリティに関連する説明およびサンプルは、wsclient.jarデモ・ファイル(10.4項を参照)も参照してください。
SpatialのWebサービスでは複数のユーザー管理方法が使用でき、管理者が外部ユーザー(SOAP/XMLリクエストを作成するユーザー)およびデータベース・ユーザーを管理する方法に加え、ユーザーの資格証明を制御する方法(これらのユーザーがアクセスできるデータおよびWebサービスの機能を制御する方法)に影響を与えます。
データベースの場合、ユーザーはデータベース/エンタープライズ・ユーザー(システムによる管理)またはアプリケーション・ユーザー(表で管理)のいずれかです。また、エンタープライズ・ユーザーのユーザー定義がOC4Jで共有されている場合があります。あるいは、OC4Jではデータベース・ユーザーとは別にLDAP管理のユーザー(既存のデータベース・ユーザーと同じ名前を使用しても、必ずしもそのデータベース・ユーザーと同じ認証は使用しないユーザーなど)が定義されている場合があります。
通常、ユーザーはSOAPリクエストの作成時に、ユーザー名Johnおよび認証secretなどを入力します。この例では、JohnはOC4Jユーザーであることが必要です。(管理者は、LDAP、LDAP/XMLおよび他の方法を使用して、OC4Jユーザーを管理できます。)
データベース内でのユーザー管理はアイデンティティ伝播(17.1.1項を参照)とリンクします。
OC4Jに含まれるSpatialWSサービスでは、いくつかのオプションのうち1つを使用してデータベースにユーザーIDが伝播されます。いずれのオプションもデータベースでのユーザー管理とリンクされているため、管理者はユーザーの認可および監査を柔軟に制御できます。使用可能なアイデンティティ伝播のオプションは、次のとおりです。
プロキシ認証: JDBCを使用し、プロキシ・ユーザー経由でデータベース・ユーザーに接続します。たとえば、データベース・ユーザーJohnとOC4JユーザーJohnの設定が別でパスワードも異なる場合、ユーザーJohnがエンタープライズ・ユーザーとして設定され、OC4Jとデータベースで共有されている場合、またはデータベース・ユーザーJohnが、直接SQLで接続するのではなく、プロキシ認証を介して使用するように設定されている場合があります。
アプリケーション・ユーザー管理: データベース・ユーザーを介するのではなく、データベース表でユーザーを管理することで、管理者はより柔軟な管理が可能になります。この方法では、仮想プライベート・データベース(17.2.1項を参照)を使用する場合に、SELECT USER FROM DUALと入力してユーザーIDを特定することができないため、かわりに次のようにシステム・コンテキストを問い合せる必要があります。
SELECT SYS_CONTEXT('APP_CTX', 'APP_USER_ID') FROM DUAL;
たとえば、データベース・ユーザーJohnとOC4JユーザーJohnの設定が別でパスワードも異なる場合、またはデータベース表でアプリケーション・ユーザーを共有するようにOC4Jが構成されている場合があります。
単一アプリケーション・ユーザー: データベースへの接続には単一アプリケーション・ユーザーを使用します。アプリケーションで特定のユーザーを識別する必要がなく、そのユーザーによるSpatialのWebサービスの使用が認可されているかぎり、この方法を使用できます。その場合、特定のユーザーは単一アプリケーション・ユーザーと同じ資格証明を使用し、そのユーザーの個別監査は行われません。
アイデンティティ伝播のオプションを指定するには、次のいずれかのサブ要素をWSConfig.xmlファイル(10.3項を参照)内の<Proxy_management>要素に挿入します。
<Proxy_authentication/>: プロキシ認証を指定する場合
<Application_user_management/>: アプリケーション・ユーザー管理を指定する場合
<Fixed_app_user/>: 単一アプリケーション・ユーザーを使用する場合
SpatialのWebサービス・フレームワーク内のハンドラでは、OC4Jでのキャッシュの使用を選択できます。たとえば、WFSではフィーチャ表がキャッシュされます。OC4Jのキャッシュは、仮想プライベート・データベース(VPD)の使用など、データベースに設定された認可制約に従う必要があります。データベースの認可フレームワーク全体をローカルに複製することは実用的ではないため、各問合せでは適用可能なデータベースの認可制約を確認する必要があります。
WFSの場合は、ID列以外に含まれる実際のデータ値を使用するのではなく、ID値のみを使用して問い合せる必要があることを意味します。たとえば、問合せにはSELECT col1, col2 FROM...のかわりにSELECT id FROM...を指定します。このような場合、実際のデータはすでにキャッシュされており、問合せでは行レベルの認可のみ確認されます。この方法には、通常、パフォーマンス上のメリットもあり、特に大きなデータ・レコードの場合に有効です(一般的に、空間データのデータ・レコードは大きいものです)。
ただし、この方法は列レベルのVPDを使用する一部の方式では機能しません。たとえば、ユーザーJohnは総合的なジオメトリのみ参照でき、ユーザーJaneは元の詳細なジオメトリを参照できるように、列レベルのVPDが構成されているとします。ユーザーは2人とも同じデータ・レコードにアクセスしますが、Johnに対してはジオメトリ列レベルが不明瞭に表示されます。この例は、ジオメトリの汎化を意味します。別の例では、不明瞭化によって許可されたユーザーのみに社会保険番号が表示され、それ以外のユーザーには不明瞭化された********* という値が表示される例があります。
Spatialのネットワーク・データ・モデルの場合、キャッシュ機能では認可制約の確認は行われません(これは、ネットワーク問合せパターンに関連するパフォーマンスが考慮されるためです)。したがって、ネットワーク・データ・モデルの場合は、アイデンティティ伝播の単一アプリケーション・ユーザー・オプション(17.1.1項を参照)を使用します。このオプションでは、ユーザーの認可を制御するための管理者の選択は制限されます。
管理者が一部の認可制約をOC4Jで実行するように構成できる場合でも、認可およびバージョニングはOC4Jではなくデータベースで基本的に実行されます。Oracle Databaseでは、仮想プライベート・データベース(VPD)の場合も同様に、選択、挿入および更新の各操作に対する一般的な権限を構成することができます。Workspace Managerの操作もサポートされます。
17.1.2項で説明されているとおり、OC4Jのキャッシュはデータベースの構成と一致している必要があります。ただし、キャッシュが一致していない場合は、単一アプリケーション・ユーザー・オプション(17.1.1項を参照)を使用する必要があります。これは、アプリケーションのすべての使用者が同一データを参照できても問題にならないためです。
|
注意: OpenLSマッピング・サービスおよびルーティング・サービスは、仮想プライベート・データベース(VPD)または別の方式によるユーザー固有の認可(表に対するSELECT権限を特定のユーザーに付与するなど)を使用する場合は動作しません。 |
管理者は仮想プライベート・データベース(VPD)を実装してユーザーのアクセスを制限することができます。アイデンティティ伝播(17.1.1項を参照)にプロキシ認証またはアプリケーション・ユーザー管理が使用されている場合、SOAPリクエストは、各SOAPリクエストのWSSセクションでの指定どおりに、現行ユーザーに対するVPDポリシーのコンテキスト内で実行されます。
アイデンティティ伝播に単一アプリケーション・ユーザーが使用されている場合、SOAPリクエストは、汎用の単一ユーザーに対するコンテキスト内で実行され、すべてのSOAPリクエストはデータベースに対して基本的に匿名になります。(OC4JではSOAPメッセージのWSSセクションに含まれるユーザー名によって引き続きユーザーが認識されるため、監査用に構成することはできますが、データベースではユーザー名は認識されません。)
次の例のように<SdoRequest>要素に作業領域IDを指定することにより、任意のSOAPリクエストを作業領域のコンテキスト内で実行できます。
<mdsys:SdoRequest xmlns:mdsys="http://www.oracle.com/2006/mdsys"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<mdsys:SdoRequestHeader workspace_id="OlsWorkspace"/>
<mdsys:SdoRequestBody>
<XLS …>
</XLS>
</mdsys:SdoRequestBody>
</mdsys:SdoRequest>
wsclient.jarデモ・ファイル(10.4項を参照)内のsrc/oracle/spatial/ws/svrproxy/の下にあるoracle.spatial.ws.svrproxy.TestYPWithWorkspace.javaも参照してください。
.earファイルをデプロイした後は、これを構成する必要があります。一般的な構成には次のファイルが含まれています。ただし、WSConfig.xmlファイルのWFS固有の部分など、サービス固有の設定は含まれません。
data-sources.xml: Catalog、OpenLS、WFSなどの各サービスのデータベース接続が含まれます。次に例を示します。
<?xml version = '1.0' encoding = 'windows-1252'?>
. . .
<native-data-source
name="jdev-connection-NdmProxyConnection"
jndi-name="jdbc/NdmProxyConnectionCoreDS"
url="jdbc:oracle:thin:@server.com:port:sid"
user="usr"
password="password"
data-source-class="oracle.jdbc.pool.OracleDataSource"/>
. . .
</data-sources>
WSConfig.xml: WFS固有のパラメータの他に、名前、実装およびユーザー管理の各ハンドラ定義が含まれます。次に例を示します。
<Handlers>
<OpenLS>
<JavaClass>oracle.spatial.ws.openls.OpenLsHandler</JavaClass>
<Anonymous_xml_user>SpatialWsXmlUser</Anonymous_xml_user>
<Proxy_management>
<Proxy_authentication/>
</Proxy_management>
</OpenLS>
. . .
<Network>
<JavaClass>oracle.spatial.network.xml.NetworkWSHandler</JavaClass>
<Proxy_management>
<Fixed_app_user/>
</Proxy_management>
</Network>
. . .
</Handlers>
data-sources.xmlファイルには、WFSなどの各サービス・ハンドラのデータベース接続が含まれます。次の3つの例は、ユーザー・アイデンティティ伝播の方法(17.1.1項を参照)に基づいています。
プロキシ認証: 指定された接続ではプロキシ・ユーザーが参照されます(プロキシ・ユーザーは実際のSOAPユーザーとは異なります)。
アプリケーション・ユーザー管理: 指定された接続では、システム・コンテキストが設定されたユーザーとして接続されているプロキシ・ユーザーが参照されます。
単一アプリケーション・ユーザー: 指定された接続では最終ユーザー(APP_USER)が参照されます。代理ユーザーの使用、システム・コンテキストの変更、異なるユーザーとしての再接続は行われません。
WSConfig.xmlファイルには、ハンドラの宣言部が含まれます。
<JavaClass>: 最初のパラメータです。サービス・ハンドラの実装を指定します。このJavaクラスによってインタフェースoracle.spatial.ws.SpatialWSHandlerが実装されます。この実装クラスは、server.xmlファイルに指定された共有ライブラリ内でOC4Jに対して使用できます。次に例を示します。
<shared-library name="sdows" version="1.0">
<code-source path="*"/>
<import-shared-library name="oracle.xml"/>
<import-shared-library name="oracle.jdbc"/>
</shared-library>
. . .
</application-server>
管理者は、その共有ライブラリに対してSpatialWSの.earファイルへのアクセス権限を付与する必要があります。これは、次の例のようにapplication.xmlでグローバルに行うことができます。
<imported-shared-libraries>
. . .
<import-shared-library name="sdows"/>
</imported-shared-libraries>
</orion-application>
<Anonymous_xml_user>: 2つ目のパラメータです。SOAPインタフェースとは反対に、データベースに単純な非SOAP XMLインタフェースを介したユーザーの接続IDを指定します。(詳細は、17.4.2項を参照。)
<Proxy_management>: 3つ目のパラメータです。ユーザーIDをデータベースに伝播する方法を指定します。指定可能な値は<Proxy_authentication>、<Application_user_management>および<Fixed_app_user>です。ほとんどの場合<Proxy_authentication>を選択します。
また、.earファイルをデプロイおよび構成する場合は、『Oracle Containers for J2EE構成および管理ガイド』に記載されているJ2EEアプリケーション(EAR)のデプロイに関する記述に含まれるセキュリティに関連する情報と、OC4JのセキュアなWebサイトの構成に関する情報を必ず確認してください。
SpatialのWebサービスにはCSW、OpenLSおよびWFSのサポートがデフォルトで含まれています。ただし、必要な各ハンドラのインタフェースを実装およびデプロイすることにより、追加のサービス・ハンドラのサポートを追加することができます。
サービス・ハンドラのサポートを含めるには、インタフェースoracle.spatial.ws.SpatialWSHandlerを実装し、このインタフェースを.jarファイルにデプロイします。実装には、現行のリクエストがこのサービスを示しているかどうかを判断する次のファンクションが含まれます。
public boolean canHandle(Element request)
インタフェースをデプロイするには、次の操作を実行します。(手順は任意の順番で実行できます。)
OC4Jから.jarファイルにアクセスできるようにします。アクセスできるようにするには、管理者は新しい共有ライブラリを作成するか(server.xmlおよびapplication.xmlの更新方法は17.3項を参照)、または既存の共有ライブラリsdowsに.jarファイルを追加(短時間でできる方法)します。
WSConfig.xmlファイル内の<Handlers>要素でサービスを宣言します。このとき、実装クラス名も指定します。(OpenLSおよびネットワークでのハンドラの例は、17.3項を参照。)
data-sources.xmlファイル内の<native-data-source>要素でデータソースを宣言します。このとき、接続JNDI名も指定します。(jdbc/NdmProxyConnectionCoreDSの例は、17.3項を参照。)実装には、接続JNDI名を特定する次のファンクションが含まれます。
public String getConnectionJndiName()
この名前は、data-sources.xmlファイルで指定したJNDI名と一致する必要があります。
空間Webサービスには異なるインタフェースを介してアクセスできます。インタフェースにはそれぞれセキュリティ上の影響があります。すべてのサービスで、単純なXML (非SOAP)インタフェースと同様にSOAP/WSSインタフェースを使用できます。OpenLSの場合は、OpenLS実装自体がPL/SQLで記述されるため、PL/SQLインタフェースもあります。
SpatialのWebサービスへのアクセスでは、ほとんどの場合にSOAP/WSSインタフェースを選択することをお薦めします。このインタフェースは、WSSのエンドツーエンドのセキュリティを提供しており、他のWebサービスと統合できます。ただし、単純なXMLインタフェースも代替手段として使用できます(17.4.2項を参照)。
SOAP/WSSインタフェースのデフォルトURLの書式は、次のとおりです。
http://hostname:port/SpatialWS-SpatialWS-context-root/SpatialWSSoapHttpPort
SpatialのWebサービスに、単純な非SOAP XMLインタフェースを使用することが適している場合があります。具体的に、このXMLインタフェースには次の利点があります。
既存のソフトウェアとの統合が容易です。たとえば、JMeter接続はSOAPよりもXMLサーブレットに対して容易に作成できます(特にWSSを使用している場合)。
オーバーヘッドが少ないため、高いパフォーマンスが提供されます。SOAPの場合、WSSによる解析のオーバーヘッドと暗号化および署名のオーバーヘッドが追加されます。(ただし、SSL経由でXMLサービスにアクセスする場合はオーバーヘッドが減少します。)
非SOAP XMLインタフェースのデフォルトURLの書式は、次のとおりです。
http://hostname:port/SpatialWS-SpatialWS-context-root/SpatialWSXmlServlet
このXMLインタフェースは、ユーザーIDまたは認証を要求しないように設定されます。したがって、XMLリクエストの場合、SpatialWSサービスは、すべてのXMLユーザーに共通の汎用IDに基づいてデータベースに接続します。このIDはWSConfig.xmlファイルに<Anonymous_xml_user>として定義されています。
この方法は、WSConfig.xmlファイルで<fixed_app_user>オプションを使用する場合と同様、データベースが関係するかぎり、ユーザーはOC4Jによって匿名の状態で保持されます。つまり、OC4Jでは監査またはJAASベースの認可制約が引き続き実行できますが、データベース側でのユーザーの認可および監査は制限されます。ただし、非SOAP XMLインタフェースの場合、ユーザーはOC4Jに対しても匿名です。
OpenLSには、SOAPインタフェースおよび非SOAP XMLインタフェースの他に、PL/SQLインタフェースがあります。SQLを介して接続し、PL/SQL APIを直接使用する場合は、セキュリティに関する考慮事項が、SOAPおよび非SOAP XML APIに適用される場合と次のように異なります。
ユーザーとデータベース間で接続が直接行われるため、プロキシ認証およびアプリケーション・ユーザー管理は不要です。
OC4Jが関係しないため、OC4Jの認証、認可およびキャッシュは不要です。
PL/SQLインタフェースでは、環境が異なる場合でも、SOAPインタフェースと同じレベルのセキュリティが提供されます。ただし、非SOAP XMLインタフェースでは低いレベルの(安全性が低い)セキュリティが提供されます。これは、データベースに対してユーザーが匿名のまま(汎用APP_USER以外)保持されることが主な理由です。非SOAP XMLインタフェースでは、SSL、ユーザー認証およびユーザー認可を併用できるため、データベースへのアイデンティティ伝播が可能です。ただし、この方法は、単純なXMLインタフェース・オプションの選択という既知のメリットを上回る可能性があります。
非SOAP XMLインタフェースが不要なために使用不能にする場合は、次の書式のURLでサーブレットを非アクティブ化することができます。
http://hostname:port/SpatialWS-SpatialWS-context-root/SpatialWSXmlServlet
