認証構成  目次

この項では、Oracle Service Registryの構成を変更して次の認証オプションを使用可能にする方法について説明します。

HTTP Basic  目次

HTTP Basicを使用可能にするには、次の手順を実行します。

  1. REGISTRY_HOME/app/uddi/services/Wasp-inf/package.xmlを次のように変更して、HTTP Basic認証を有効にします。

    1. <processing name="UDDIv1v2v3PublishingProcessing"/>の下の<use ref="tns:HttpBasicInterceptor"/>のコメントを解除します。これによって、UDDI Publishing API v1、v2、v3のHTTP Basic認証が有効になります。

    2. <processing name="UDDIv1v2v3InquiryProcessing"/>の下に<use ref="tns:HttpBasicInterceptor"/>を追加します。これによって、3つすべてのバージョンのUDDI Inquiry APIに対してHTTP Basic認証が有効になります。

    3. <processing name="wsdl2uddiProcessing">の下に<use ref="tns:HttpBasicInterceptor"/>を追加します。これによって、バージョン2および3のWSDL2UDDI APIに対してHTTP Basic認証が有効になります。

    4. HTTP Basic認証を介してアクセスする(UDDI公開とInquiryエンドポイントを除く)サービスエンドポイントに、属性accepting-security-providers="HttpBasic"を追加します。

    例2に、package.xmlの一部を示します。

  2. Oracle Service Registryを停止し、REGISTRY_HOME/workディレクトリを削除して、レジストリを再起動します。

例2 package.xml: HTTP Basicが有効

.....
    <service-endpoint path="/inquiry" version="3.0" name="UDDIInquiryV3Endpoint"
        service-instance="tns:UDDIInquiryV3" processing="tns:UDDIv1v2v3InquiryProcessing"
          accepting-security-providers="HttpBasic">
        <wsdl uri="uddi_api_v3.wsdl" service="uddi_api_v3:UDDI_Inquiry_SoapService"/>
        <envelopePrefix xmlns="arbitraryNamespace" value=""/>
        <namespaceOptimization xmlns="arbitraryNamespace">false</namespaceOptimization>
    </service-endpoint>
    <service-instance
        implementation-class="com.systinet.uddi.publishing.v3.PublishingApiImpl"
        name="UDDIPublishingV3"/>
    <service-endpoint path="/publishing" version="3.0" name="UDDIPublishingV3Endpoint"
        service-instance="tns:UDDIPublishingV3"
        processing="tns:UDDIv1v2v3PublishingProcessing"
        accepting-security-providers="HttpBasic">
        <wsdl uri="uddi_api_v3.wsdl" service="uddi_api_v3:UDDI_Publication_SoapService"/>
        <envelopePrefix xmlns="arbitraryNamespace" value=""/>
        <namespaceOptimization xmlns="arbitraryNamespace">false</namespaceOptimization>
    </service-endpoint>

    <processing name="UDDIv3Processing">
      <use ref="uddiclient_v3:UDDIClientProcessing"/>
      <fault-serialization name="MessageTooLargeFaultSerializer"
      serializer-class="com.systinet.uddi.publishing.v3.serialization.MessageTooLargeFaultSerializer"
      serialized-exception-class="com.systinet.uddi.interceptor.wasp.MessageTooLargeException"/>
    </processing>

    <processing name="UDDIv1v2v3PublishingProcessing">
     <use ref="uddiclient_v3:UDDIClientProcessing"/>
     <use ref="uddiclient_v2:UDDIClientProcessing"/>
     <use ref="uddiclient_v1:UDDIClientProcessing"/>
     <!-- HttpBasic (without authtoken)         -->
     <use ref="tns:HttpBasicInterceptor"/>

    <interceptor name="MessageSizeCheckerInterceptor"
       implementation-class="com.systinet.uddi.interceptor.wasp.MessageSizeCheckerInterceptor"
       direction="in">
        <config:maxMessageSize>2097152</config:maxMessageSize>
        </interceptor>
    </processing>

    <processing name="UDDIv1v2v3InquiryProcessing">
        <use ref="tns:UDDIv3Processing"/>
        <use ref="tns:UDDIv2Processing"/>
        <use ref="tns:UDDIv1Processing"/>
        <use ref="tns:HttpBasicInterceptor"/>
    </processing>
.....

Netegrity SiteMinder  目次

Netegrity SiteMinder認証を使用可能にするには、次の手順を実行します。

  1. REGISTRY_HOME/app/uddi/services/Wasp-inf/package.xmlを次のように変更します。

    1. <processing name="UDDIv1v2v3PublishingProcessing"/>の下に<use ref="tns:SiteMinderInterceptor"/>を追加します。これによって、3つすべてのバージョンのUDDI Publishing APIに対してSiteMinder認証が有効になります。

    2. <processing name="UDDIv1v2v3InquiryProcessing">の下に<use ref="tns:SiteMinderInterceptor"/>を追加します。これによって、バージョン1、2および3のInquiry APIに対してSiteMinder認証が有効になります。

    3. <processing name="wsdl2uddiProcessing">の下に<use ref="tns:SiteMinderInterceptor"/>を追加します。これによって、バージョン2および3のWSDL2UDDI APIに対してSiteMinder認証が有効になります。

    4. Netegrity SiteMinder認証を介してアクセスする(UDDI公開とInquiryエンドポイントを除く)サービスエンドポイントに、属性accepting-security-providers="Siteminder"を追加します。

    5. 要素<securityProviderPreferences>および<interceptor name="SiteMinderInterceptor"の下に次のように入力します。

      • <loginNameHeader>: ログイン名ヘッダー

      • <groupHeader>: グループ・ヘッダー

      • <delimiter>: グループ名デリミタ

      重要重要

      <securityProviderPreferences>および<interceptor name="SiteMinderInterceptor"要素には、同じ要素値を設定する必要があります。

    例3に、package.xmlの一部を示します。

  2. Oracle Service Registryを停止し、REGISTRY_HOME/workディレクトリを削除して、レジストリを再起動します。

例3 package.xml: Netegrity SiteMinderが有効

.....
  <!-- Netegrity SiteMinded security provider preferences for the server side -->
    <securityProviderPreferences xmlns="http://systinet.com/wasp/package/extension"
       name="Siteminder">
        <loginNameHeader>sm-userdn</loginNameHeader>
        <groupHeader>sm-role</groupHeader>
        <delimiter>^</delimiter>
    </securityProviderPreferences>

    <!-- Netegrity SiteMinded interceptor-->
    <interceptor name="SiteMinderInterceptor"
         implementation-class="com.systinet.uddi.security.siteminder.SmInterceptor" >
        <config:loginNameHeader>sm-userdn</config:loginNameHeader>
        <config:groupHeader>sm-role</config:groupHeader>
        <config:delimiter>^</config:delimiter>
    </interceptor>
.....

埋込みHTTP/HTTPSサーバーを使用したSSLクライアント認証  目次

埋込みHTTP/HTTPSサーバーを使用するOracle Service Registryは、双方向SSLを介して取得されるクライアント証明書を使用して認証を実行するように構成できます。双方向SSLでは、クライアントがサーバーに対してクライアント自身も認証する必要があります。 埋込みHTTP/HTTPSサーバーと、アプリケーション・サーバーにデプロイされるレジストリでは、設定の手順が異なります。 この項では、埋込みHTTP/HTTPSサーバーについてのみ説明します。デプロイされたレジストリにSSLクライアント認証を構成する方法の詳細は、「J2EEサーバー認証」を参照してください。

スタンドアロン・レジストリでSSLクライアント認証を使用可能にするには、次の手順を実行します。

  1. レジストリが実行されていないことを確認します。

  2. REGISTRY_HOME/conf/serverconf.xmlを次のように変更します。

    • <httpsPreferences name="https">の下で、<needsClientAuth>trueに変更します。 これによって、クライアント証明書を要求するHTTPS転送が構成されます。

    • <securityPreferences name="main">の下に<acceptingSecurityProvider>SSL</acceptingSecurityProvider>を追加します。 これによって、クライアント証明書がユーザー名に確実にマッピングされます。

    例4に、変更されたREGISTRY_HOME/conf/serverconf.xmlの一部を示します。

  3. クライアント証明書の発行に使用される、認証局の証明書を信頼します。 レジストリで使用されるトラスト・ストアにこの証明書をインポートするには、REGISTRY_HOME/binディレクトリからPStoreToolツールを実行します。

                      PStoreTool add --certFile <client certificates authority certificate file>
                    
  4. ユーザー名にクライアント証明書をマッピングする方法を構成します。 レジストリは、クライアント証明書の必須部分のサブジェクトからユーザー名を抽出するJAASログイン・モジュールに付属しています。 このマッピングを実行するログイン・モジュールは、REGISTRY_HOME/conf/jaas.confファイルのCertsMappingエントリの下に構成されます。 例5に、CertsMappingエントリの例を示します。

    構成できるオプションは、次のとおりです。

    • debug: trueに設定すると、エラー・ストリームにログイン・モジュールのデバッグ・アクションが出力されます。 デフォルトは、falseです。

    • issuer: 発行者の名前。 設定すると、認証局によって、マッピングされた証明書がこのサブジェクト名で発行されます(推奨)。

    • pattern: ユーザー名の取得に使用する(java.util.regexpの)正規表現。 指定したパターンで最初に取得されたグループが、ユーザー名として使用されます。 パターンに一致するグループが取得されない場合は、サブジェクト全体がユーザー名となります。 正規表現は、大/小文字が区別されて使用されます。 次に例を示します。

      • デフォルトは、(?<!\\,\s?)EMAILADDRESS=(.+)@です。 これは、EMAILADDRESSに表示される名前に一致します。 この正規表現は、サブジェクトの他の部分にEMAILADDRESSが含まれる場合に、その大/小文字の区別を無視します。

      • CN=([^,]+)は、共通名に一致します。

      • .*はすべてのサブジェクトに一致します。 グループが取得されないため、サブジェクト全体のDNが使用されます。

    証明書のマッピングを行うために、複数のログイン・モジュールを構成できます。 これは、異なる発行者を受け入れる必要がある場合または最初に構成したログイン・モジュールで失敗した証明書のマッピングにフォールバックを提供する必要がある場合、あるいはその両方が必要な場合に有効です。 例6に、2人の発行者によって発行された証明書のマッピングを許可するCertsMappingエントリの例を、それぞれのマッピングとともに示します。

  5. レジストリは、SSLクライアント認証用に構成されました。 SSLセキュリティ・プロバイダの構成を変更して、SSLクライアント認証の適用性を変更することもできます。 この構成は、REGISTRY_HOME/conf/serverconf.xmlファイルの<securityProviderPreferences name="SSL">要素で行います。 例4に例を示します。

例4 双方向SSLが有効なserverconf.xmlの一部

<?xml version="1.0" encoding="UTF-8"?>
<config name="main">
   ...
  <securityPreferences name="main">
     <!-- Added acceptingSecurityProvider -->
    <acceptingSecurityProvider>SSL</acceptingSecurityProvider>
    <pstoreInitParams/>
    ...
  </securityPreferences>
  ...
  <httpsPreferences name="https">
    ...
    <!-- Client authentication required -->
    <needsClientAuth>true</needsClientAuth>
    ...
  </httpsPreferences>
  ...
  <!-- security provider preferences intended mainly for SSL client authentication -->
  <securityProviderPreferences name="SSL">
      <!-- What to do when SSL is not used to access the resource? Avalaible options:
      redirect
        - perform HTTP redirect to associated HTTPS URL (302 Moved Temporarily)
      fail
        - return a message that informs to use HTTPS URL (400 Bad Request)
      skip
        - do not perform certififate mapping at all
      perform
        - try to perform certificate mapping with no client certificates
      -->
      <whenNotSsl>skip</whenNotSsl>
      <!-- Can certificate mapping fail? If set to true and it fails, no received subject will be constructed. -->
      <certMappingMayFail>false</certMappingMayFail>
      <!-- Can a default account be created when no account for a mapped user exists? -->
      <createDefaultAccount>false</createDefaultAccount>
  </securityProviderPreferences>
</config>

例5 CertsMapping JAASの構成

CertsMapping{
 com.systinet.uddi.security.jaas.CertMappingLoginModule sufficient pattern="(?<!\\,\s?)EMAILADDRESS=(.+)@" debug=false issuer="CN=Company CA, OU=mycomp";
};

例6 2人の発行者が許可されたCertsMapping JAASの構成

CertsMapping{
 com.systinet.uddi.security.jaas.CertMappingLoginModule sufficient pattern="(?<!\\,\s?)EMAILADDRESS=(.+)@" debug=false issuer="CN=Company CA, OU=mycomp";
 com.systinet.uddi.security.jaas.CertMappingLoginModule sufficient pattern="CN=([^,]*)" issuer="CN=Company CA2, OU=mycomp" debug=false;
};

Oracle HTTP/HTTPS Serverを使用したOracle Application ServerでのSSLクライアント認証  目次

この項では、Oracle HTTP/HTTPS Serverを使用するOracle Application ServerにデプロイされたOracle Service Registryで、SSLおよびSSLクライアント認証を有効にする方法について説明します。

  1. Oracle Wallet Managerを起動します。

  2. 新しい(空の)ウォレットを作成し、パスワードを記憶して、デフォルトの「standard」タイプを選択します。

  3. メニュー・オプションで、「File」「Auto Login」ボックスを選択します。

  4. ウォレットをORACLE_HOME\Apache\Apache\conf\ssl.wlt\newに保存し(作成されたことを確認し)ます。

  5. 証明書要求を発行し、フィールドに入力します。「CN」フィールドには、ドメイン名を含むホスト名を含める必要があります。

  6. 証明書要求をファイルにエクスポートします(ファイル名のデフォルトの拡張子は.csrです)。

  7. ウォレットを保存し、Wallet Managerを終了します。

  8. 認証局を使用して、エクスポートした証明書要求の証明書を取得します。 この要求では、認証局の証明書と署名証明書が必要となります。 認証局は、次のいずれかになります。

    • 公共の認証局(VeriSignなど)。

    • 企業の認証局。 企業のITセキュリティ・ガイドラインを選択します。

    • ユーザー自身(OpenSSLツールを使用する場合など)。

  9. (CAおよび証明書を取得したら)Oracle Wallet Managerを起動し、作成したウォレットを開きます。

  10. 「Operations」「Import Trusted Certificate」メニューで、CA証明書を選択します。

  11. 「Operations」「Import User Certificate」メニューで、CA署名証明書を選択します。

  12. ウォレットを保存し、Wallet Managerを終了します。

  13. 作成したウォレットを使用するためにOracle HTTP Serverを設定します。

  14. ORACLE_HOME\Apache\Apache\conf\ssl.confを次のように編集します。

    • ORACLE_HOME\Apache\Apache\conf\ssl.wlt\newにある新しく生成したウォレット・ファイルを指すようにSSLWalletディレクティブを変更します。

    • クライアント証明書を必須にするか任意にするかを指定して、SSLVerifyClientディレクティブをコメント解除または追加します。

    • 「SSLOptions +ExportCertData」を追加します。

  15. ORACLE_HOME\Apache\Apache\conf\mod_oc4j.confを次のように編集します。

    • <IfModule mod_oc4j.c>内にOc4jExtractSSL Onを追加します。

  16. 双方向SSLによる接続にデモ、Signerツールまたは他のクライアント・ツールが必要な場合は、PStoreToolを使用してREGISTRY_HOME/conf/clientconf.xmlにクライアント証明書をインポートします。

  17. (再デプロイ時にも変更が有効になるように)ORACLE_HOME\j2ee\home\applications\REGISTRY_PORTING_CONTEXT\REGISTRY_PORTING_CONTEXT\WEB-INF\web.xmlにあるweb.xmlまたはEARにある同名のファイルを設定するには、J2EEでの内部SSLクライアント認証マッピングの説明に進みます。

  18. OASを再起動します。

OC4Jコンテナを使用したOracle Application ServerでのSSLクライアント認証  目次

この項では、Oracle HTTP/HTTPS ServerではなくOC4J SSLを使用するOracle Application ServerにデプロイされたOracle Service Registryで、SSLおよびSSLクライアント認証を有効にする方法について説明します。

  1. ORACLE_HOME/opmn/bin/opmnctl shutdownを使用してサーバーを停止します。

  2. ファイルORACLE_HOME/j2ee/home/keystoreが存在する場合は、削除します。

  3. (自己署名IDを使用するか認証局のIDを使用するかによって)次のいずれかを実行します。

    • Java keytoolを使用して、サーバーIDをORACLE_HOME/j2ee/home/keystoreに生成します。たとえば、keytool -genkey -keyalg RSA -alias oracle -keystore ORACLE_HOME/j2ee/home/keystore -storepass PASSWORDのように指定します。

    • サーバーIDをORACLE_HOME/j2ee/home/keystoreにインポートします。

  4. アプリケーションの<web-app>エントリを、ORACLE_HOME/j2ee/home/config/ディレクトリにあるhttp-web-site.xmlまたはdefault-web-site.xmlserver.xml内のweb-site要素のpath属性で使用可能かつ参照される方)に指定して、属性shared="true"を追加します。

  5. ORACLE_HOME/j2ee/home/config/ディレクトリにあるORACLE_HOME/j2ee/home/config/http-web-site.xmlまたはdefault-web-site.xmlserver.xml内のweb-site要素のpath属性で使用可能かつ参照される方)を、ORACLE_HOME/j2ee/home/config/secure-web-site.xmlにコピーします。

  6. ORACLE_HOME/j2ee/home/config/secure-web-site.xmlを編集します。ポートを変更し、属性secure="true"を<web-site>要素に追加します(<web-site port="4443" ... secure="true">など)。

  7. タグ<process-type id="home" module-id="OC4J" ...>内のORACLE_HOME/opmn/conf/opmn.xmlで、port要素を他のport要素の横に追加します。 port要素は<port id="secure-web-site" range="4443" protocol="https"/>のようになります。

  8. トラスト・ストアを準備します。 トラスト・ストアには、HTTPSサーバーに信頼させるすべての証明書が含まれます。 たとえば、トラスト・ストアにインポートされたCAは、クライアント証明書に署名できます。 トラスト・ストアには、Javaキーストアの標準的なファイル形式が必要です。

  9. キーストア・ファイルへの絶対パスを使用して、ORACLE_HOME/j2ee/home/config/secure-web-site.xmlの<web-site>要素に次のような要素を追加します。たとえば、<ssl-config keystore="ORACLE_HOME\j2ee\home\keystore" keystore-password="changeit" truststore="ORACLE_HOME\j2ee\home\truststore" truststore-password="changeit" needs-client-auth="true"/>のように指定します。

  10. ファイルserver.xml: <web-site path="./secure-web-site.xml" />にsecure-web-site.xmlのパス参照を追加します。

  11. (再デプロイ時にも変更が有効になるように)ORACLE_HOME\j2ee\home\applications\REGISTRY_PORTING_CONTEXT\REGISTRY_PORTING_CONTEXT\WEB-INF\web.xmlにあるweb.xmlまたはEARにある同名のファイルを設定するには、「J2EEでの内部SSLクライアント認証マッピング」に進みます。

  12. ORACLE_HOME/opmn/bin/opmnctl startallを使用してサーバーを起動します。

  13. 双方向SSLによる接続にデモ、Signerツールまたは他のクライアント・ツールが必要な場合は、PStoreToolを使用してREGISTRY_HOME/conf/clientconf.xmlにクライアント証明書をインポートします。 デモの実行時に、使用する証明書を指定するために追加のプロパティを指定する必要があります。詳細は、「開発者ガイド」の「クライアント認証」を参照してください。

Oracle WebLogicでのSSLクライアント認証  目次

この項では、Oracle WebLogic Server 10.3にデプロイされたOracle Service Registryで、SSLおよびSSLクライアント認証を有効にする方法について説明します。 次の手順では、WebLogicにレジストリをデプロイ済であることが前提となります。

  1. WARファイルに使用するWEB-INF/web.xmlを検索します。 アーカイブを直接編集できるファイル・コマンダでWARファイル編集して後で再デプロイするか、WARファイルを解凍する場所でファイルを特定することができます。

    1. <web-app>内に次のようにタグを追加します。

                                 <context-param>
                                      <param-name>use.request.user</param-name>
                                      <param-value>true</param-value>
                                  </context-param>
      
                                  <login-config>
                                    <auth-method>CLIENT-CERT</auth-method>
                                  </login-config>
      
                                  <security-constraint>
                                    <display-name>HTTPS required to access registry</display-name>
                                    <web-resource-collection>
                                      <web-resource-name>Protected Area</web-resource-name>
                                      <url-pattern>/*</url-pattern>
                                      <http-method>DELETE</http-method>
                                      <http-method>GET</http-method>
                                      <http-method>POST</http-method>
                                      <http-method>PUT</http-method>
                                    </web-resource-collection>
                                    <user-data-constraint>
                                      <description>Require confidentiality</description>
                                      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
                                    </user-data-constraint>
                                  </security-constraint>
                                       

    2. <servlet-class>com.systinet.transport.servlet.server.registry.RegistryServlet</servlet-class>のように、サーブレットのクラスを変更します。

  2. WebLogicでレジストリを起動します。 レジストリは、まだ通常のユーザー/パスワード認証で動作します。

  3. Environment/Servers/_your_server_/Configuration/を選択します。

    1. 「Keystores」タブを選択します。 「Custom Identity and Custom Trust」を選択します。 IDおよびトラスト・ストアに値を指定します。 「Save」をクリックします。

    2. 「SSL」タブを選択します。 「Advanced」オプションを選択します。 「Identity Alias」および「Password」に入力します。 「Two Way Client Cert Behavior」「Client Certs Requested and enforced」を選択します。 「Save」をクリックします。

  4. 「Domain Structure」「Security Realms」をクリックします。 「myrealm」を選択します。

    1. 「Users and groups」をクリックします。 adminという新しいユーザーを作成します。 ここで、他のユーザーを作成することもできます。 他のユーザーの名前は、証明書にある電子メールの名前部分に対応します。

    2. 「Providers」タブをクリックします。 新しい認証プロバイダを作成します。 mysslauthproviderという名前を付けて「DefaultIdentityAsserter」を選択します。 プロバイダのプロパティをクリックします。 「X.509」タイプを追加します。 「Save」をクリックします。 「Provider specific」タブをクリックします。 「Use Default User Name Mapper」を選択します。 「Default User Name Mapper Attribute Delimiter」をデフォルト値「@」のままにします。 「Save」をクリックします。

    注意注意

    「DefaultIdentityAsserter」を使用する他のプロバイダが存在すると、最後の手順が有効になりません。 古いプロバイダを変更するか、または古いプロバイダを削除して新しいmysslauthproviderを構成します。

J2EEサーバー認証  目次

J2EEアプリケーション・サーバーで認証を実行できるようにレジストリを構成できます。 Netegrity SiteMinderおよびHTTP Basicとは異なり、レジストリ・アプリケーション全体に対して認証が行われます。 J2EEサーバー認証を許可するには、次の手順を実行します。

  1. インストーラによって生成されるEARファイルまたはWARファイルを特定します。 ファイルは、デプロイ後、REGISTRY_HOME/conf/portingまたはアプリケーション・サーバーで使用できます。 EARファイルには、実際のWARファイルが含まれることに注意してください。 いずれのファイルも、ZIPアーカイブとして開くことができます。

  2. WARファイルでWEB-INF/web.xmlファイルを次のように変更します。

    1. コンテキスト・パラメータuse.request.userの値をtrueに変更します。

    2. 選択したJ2EE認証のタイプでlogin-config要素を追加します。 例7に、SSLクライアント認証に使用されるCLIENT-CERT認証メソッドを有効にするログイン構成を示します。

      機密性または整合性、あるいはその両方が必要な場合は、リソースのセットを指定する際にsecurity-constraint要素を追加することもできます。 例7には、すべてのレジストリ・リソースに対してクライアントとサーバー間の機密性のある通信を要求するsecurity-constraintが含まれています。これは通常、レジストリとの通信にHTTPSのみが許可されることを意味します。

    3. 希望する認証メソッド用にJ2EEアプリケーション・サーバーを構成します。 SSLクライアント認証の場合、これは通常、クライアント証明書の要求およびユーザー名へのクライアント証明書のマッピングにHTTPS転送を設定することを意味します。 詳細は、J2EEアプリケーション・サーバーのドキュメントを参照してください。

  3. 変更したWARファイルのデプロイを続行します。

例7 web.xmlの一部

<?xml version="1.0" encoding="UTF-8"?>
<web-app>
    <display-name>Registry</display-name>
...
    <context-param>
        <param-name>use.request.user</param-name>
        <param-value>true</param-value>
    </context-param>
....
<!-- Added CLIENT-CERT authentication method -->
    <login-config>
      <auth-method>CLIENT-CERT</auth-method>
    </login-config>

<!-- Added security contraint that allow to access registry only via HTTPS -->
    <security-constraint>
      <display-name>HTTPS required to access registry</display-name>
      <web-resource-collection>
        <web-resource-name>Protected Area</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method>DELETE</http-method>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
        <http-method>PUT</http-method>
      </web-resource-collection>
      <user-data-constraint>
        <description>Require confidentiality</description>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
    </security-constraint>
</web-app>

J2EEでの内部SSLクライアント認証マッピング  目次

J2EEアプリケーションの認証は様々な方法で構成できますが、一部のアプリケーション・サーバーでは構成が複雑になる可能性があります。 単純なデプロイメントの場合は、内部SSLクライアント認証マッピングを使用すると、簡単に構成できるようになります。

内部クライアント認証マッピングでは、「埋込みHTTP/HTTPSサーバーを使用したSSLクライアント認証」で説明したCertMapperと同じ構成オプションが提供されます。 インストールの手順は次のとおりです。

  1. 証明書がJ2EEサーバーによって信頼されていることを確認します。 一部のサーバーには専用のトラスト・ストアがありますが、Javaランタイム内のcacerts Javaキーストア・ファイルを使用するサーバーもあります。 サーバーのトラスト・ストアに、信頼できる証明書として、使用している認証局の証明書を追加します。

  2. J2EEサーバーSSLを設定します。 通常は、Javaトラスト・ストア・ファイルにサーバーIDを指定する必要があります。 ファイル、エイリアスおよびストア・パスワードを指定して、トラスト・ストアを使用するようにサーバーSSLを構成します。

  3. クライアント認証を要求するようにJ2EEサーバーを設定します。

  4. デプロイ済のレジストリでweb.xmlを編集します。

    • com.systinet.transport.servlet.server.registry.RegistryServletTwoWaySSLを含むようにタグservlet-classを変更します。

    • CLIENT-CERT認証メソッドを追加します(例8を参照)。

    • コンテキスト・パラメータを追加します。 コンテキスト・パラメータtwowayssl.use_userを値trueに設定します。

    • コンテキスト・パラメータtwowayssl.issuerを、許可する証明書のX.509発行者のDNに設定します。

    • コンテキスト・パラメータtwowayssl.mappingをサブジェクトDNの一致部分の正規表現(デフォルトでは、「email」フィールドの電子メール・アドレスの名前の部分)に設定します。

    • 一致についてのランタイム情報に対して、コンテキスト・パラメータtwowayssl.debugにtrueを設定できます。

    設定するコンテキスト・パラメータはすべて、「埋込みHTTP/HTTPSサーバーを使用したSSLクライアント認証」のパラメータに対応しています。 これらのパラメータの例は、例8を参照してください。

例8 web.xmlの一部

    <login-config>
      <auth-method>CLIENT-CERT</auth-method>
    </login-config>

    <context-param>
      <param-name>twowayssl.use_user</param-name>
      <param-value>true</param-value>
    </context-param>
    <context-param>
      <param-name>twowayssl.issuer</param-name>
      <param-value>C=CZ, ST=Czech, L=Prague, O=Example company, OU=Security Team, CN=CA</param-value>
    </context-param>

通常の認証の無効化  目次

クライアントSSL証明書などのカスタム認証メカニズムを実装した後、通常の認証を無効にすることもできます。 通常の認証を無効にするには、system#everyoneグループからget_authToken UDDI APIのパーミッションを削除します。 (get_authToken APIには、デフォルトでこのパーミッションがあります。)

system#everyoneグループからget_authToken UDDI APIのパーミッションを削除するには、次の手順を実行します。

  1. 管理アカウントを使用してWEB UIにログインし、「Management」タブを開きます。

  2. 「Permissions」ページを開きます。

  3. 「Group」ラジオ・ボタンを選択します。

  4. グループsystem#everyoneを編集し、次のパーミッション(「Permission type」、「Api name」、「Actions」)を削除します。

    • org.systinet.uddi.security.permission.ApiUserPermission / org.systinet.uddi.client.v3.UDDI_Security_PortType / get_authToken,

    • org.systinet.uddi.security.permission.ApiUserPermission / org.systinet.uddi.client.v2.Publish / get_authToken,

    • org.systinet.uddi.security.permission.ApiUserPermission / org.systinet.uddi.client.v1.PublishSoap / get_authToken.

注意注意

通常の認証を無効にした後は、通常のログイン・ダイアログ・ボックスを使用してWebユーザー・インタフェースにログインできなくなることに注意してください。

コンソール構成  目次

この項では、レジストリ・コントロールおよびビジネス・サービス・コントロールの認証を構成する方法について説明します。コンソールの構成は、他のエンドポイントの構成と類似しています。

注意jarパッケージの参照

ファイル・パスREGISTRY_HOME/app/uddi/web.jar/WASP-INF/package.xmlは、jarパッケージREGISTRY_HOME/app/uddi/web.jar内の/WASP-INF/package.xmlを意味します。

レジストリ・コントロールの場合は、ファイルREGISTRY_HOME/app/uddi/web.jar/WASP-INF/package.xmlを次のように変更します。

<service-endpoint path="/web" name="WebUIEndpoint1"
     service-instance="tns:WebUI" type="raw" other-methods="get"
     accepting-security-providers="HttpBasic"/>
<service-endpoint path="/web/*" name="WebUIEndpoint2"
     service-instance="tns:WebUI" type="raw" other-methods="get"
     accepting-security-providers="HttpBasic"/>
            

Netegrity SiteMinderプロバイダを設定する場合は、accepting-security-providers="Siteminder"を使用します。

ビジネス・サービス・コントロールの場合は、ファイルREGISTRY_HOME/app/uddi/bsc.jar/WASP-INF/package.xmlで同じ変更を実行します。

これで、HTTPおよびHTTPSプロトコルの認証プロバイダが設定されました。次に、ユーザー認証に使用するプロトコル・コンソールを指定する必要があります。デフォルトのレジストリ構成では、参照および検索にHTTPが使用されます。HTTPSは公開に使用されます。ログイン・ダイアログ・ボックスが2回(1回目はHTTPを介してアクセスする際、2回目はHTTPSを介してアクセスする際)表示されないようにするには、1つのプロトコルのみが使用されるように構成を変更します。

レジストリ・コントロールの場合は、ファイルREGISTRY_HOME/app/uddi/conf/web.xmlのurlおよびsecureUrl要素が同じ値になるように変更します。

<url>https://servername:8443/registry</url>
<secureUrl>https://servername:8443/registry</secureUrl>
 

ビジネス・サービス・コントロールの場合は、REGISTRY_HOME/app/uddi/bsc.jar/conf/web.xmlファイルで同じ変更を実行します。

SSLクライアント認証で保護された送信接続  目次

Oracle Service Registryは、SSLクライアント認証でクライアントとして使用できます。 これによって、次のシナリオが可能になります。

  • SOAPクライアント: 通常、次のシナリオで使用します。

    • 承認プロセス

    • レプリケーション

    • クラスタ

    承認プロセス、レプリケーションおよびクラスタの機能には、SOAPエンドポイントを経由して接続します。 すべてのレジストリが専用の内部ネットワークに存在するため、前述のシナリオにおけるデプロイメントでは通常、SSL保護は必要ありません。ただし、Oracle Service Registryは、これらのシナリオでクライアントSSL証明書を使用するように構成できます。 他方のレジストリがクライアントSSL認証で保護され、プレーンHTTP接続が許可されない場合、レジストリはSSL証明書に接続する必要があります。 これは、security.xml内でdestinationConfigを構成することで実現できます。SSL関連タスク用のツールおよびdestinationConfigについては、「管理者ガイド」のsslToolに関するドキュメントを参照してください。 宛先の構成では、SOAPスタブまたはURL接頭辞のいずれかを指定することによって、各エンドポイントに異なる証明書を指定できます。

  • HTTPS保護リソース

    • WSDL

    • XML

    • XSD

    • XSLT

    Oracle Service Registryによって処理用にダウンロードされたリソースは、SSLクライアント認証によって保護されたHTTPSの背後に置くことができます。 接続に特定の証明書を使用するようにOracle Service Registryを設定できます。 証明書は、pstore.xml内のキー・エントリとして存在している必要があります。 このキー・エントリは、エイリアスによって識別されます。 例に示すように、エイリアスおよびパスワードは、configに含まれるsecurityREGISTRY_HOME/app/uddi/conf/security.xmlで指定する必要があります。

            <sslConnectionAlias>myAliasName</sslConnectionAlias>
            <sslConnectionPassword_coded>9vTJ9GKyjIURFY0qrWvADA==</sslConnectionPassword_coded>
               

    クリアテキスト・パスワードからエンコードされたパスワードを取得するには、encryptオプションを指定してREGISTRY_HOME/bin/sslTool(.bat or .sh)を使用します。