TCP/IP接続での認証の有効化

概要

OAuthトークン方式の認証メカニズムでは、OAuth 2.0/OpenID Connect準拠のサーバーから取得した署名付きJSON Webトークンが必要です。このトークンは、ユーザーがパブリッシュ/サブスクライブAPIまたはアダプターに提供します。次に、トークンは、クライアントからサーバーへコンパクトなシリアル化形式(base64url暗号化)で渡されます。これは、サーバーによって解析され、検証されます。

OAuthローカル認証の場合、SAS Event Stream Processingでは、Cloud Foundry (CF) User Account and Authentication (UAA)サーバーからトークンを取得する必要があります。CF UAAサーバーにトークンを要求し、そのトークンをクライアントに提供する必要があります。

curlを使用してローカルにインストールされたCF UAAサーバーへのREST要求を呼び出すことによって、トークンを手動で要求できます。REST要求は、認証情報フローで暗黙の許可を呼び出します。詳細については、CF UAAのマニュアルを参照してください。例については、CF UAAサーバー情報を参照してください。

次のリソースで詳細情報を確認できます。

• JSON Webトークン: https://self-issued.info/docs/draft-ietf-oauth-json-web-token.html
• OAuth 2.0: https://tools.ietf.org/html/rfc6749
• OpenID Connect: http://openid.net/specs/openid-connect-core-1_0.html
• CF UAA: https://github.com/cloudfoundry/uaa

OAuthトークン方式のサーバー要件

エンジンを初期化するときにクライアントID文字列を渡すかセキュリティプロパティファイルを使用することで、イベントストリーム処理サーバー上で認証が有効になります。C++モデリングAPIでは、これはdfESPengine::initialize()呼び出しのパラメーターです。認証を有効にするには、現在のpubsub_ENABLE(portNum)パラメーターをpubsub_ENABLE_OAUTH(portNum, clientId) に置き換えます。

サーバー上でOAuthローカル認証を有効にするには、セキュリティ構成プロパティを設定します。

security:
   ...     
   server:         
      auth: oauth_local
      ...
   oauth_local:         
      server:             
         client_id:client_id 1
         key_file: pubkey.pem 2

トークンの検証でエラーが発生すると、サーバーはエラーコードをクライアントに返します。クライアントはサーバーから切断されます。

OAuthトークン方式のクライアント要件

クライアント上でOAuthローカル認証を有効にするには、セキュリティ構成プロパティを設定します。

security:
   ...
   client:         
      auth: oauth_local
   ...     
   oauth_local:         
      client:             
         token: null             
         token_file: token.txt

クライアントは、トークンをサーバーに渡すことによって、認証された接続を要求します。トークンは、次のいずれかの方法で渡すことができます。

• 次のオプションエレメントを使用して、パブリッシュ/サブスクライブまたはアダプタURLに渡します。

  ?oauth_token

  このエレメントは、次のようにURLのhost:port部分に続く必要があります。

  dfESP://host:port?oauth_token=token… になります。URLの残りの部分は同じです。

• トークンを含むローカルファイルシステム上のファイルの完全なパスとファイル名を指定します。パブリッシュ/サブスクライブAPIを使用する場合は、対応するC、Java、またはPythonのパブリッシュ/サブスクライブAPIメソッドを呼び出します。Cのメソッドは C_dfESPpubsubSetTokenLocation() で、JavaとPythonのメソッドはsetTokenLocation()です。アダプターを実行するときは、対応するオプションのアダプター構成スイッチを使用してください。
• ESPクライアントの-auth oauth-tokenまたは-auth oauth-token-urlコマンドラインパラメーターを使用します。

複数のメソッドを同時に使用することはできません。パブリッシュ/サブスクライブAPIエラーが生成されます。

クライアントはトークンを隠ぺいされた状態でサーバーに渡し、トークンの検証結果を待ちます。正常に終了すると、接続が確立され、さらにクライアントサーバーの操作が正常に進行します。失敗した場合、クライアントはサーバーと接続を断ちます。

OAuthトークン検証

サーバーは、受信したトークン内の複数の項目を検証します。

CF UAAサーバー情報

CF UAAサーバーは、GitHubから入手可能なオープンソースのパッケージです。インストール後、次の追加の管理手順を強​​くお勧めします。

• OpenSSL (たとえばopenssl genrsa -out privkey.pem 1024)を使用して新しい秘密鍵を生成し、その秘密鍵に基づいて公開鍵を生成します(openssl rsa -pubout -in privkey.pem -out pubkey.pem)。これらのキーをセキュアな状態に保ちます。
• CF UAAトークン検証鍵を公開鍵で、CF UAAトークン署名鍵を秘密鍵で設定します。次に、このCF UAAサーバーによって生成されたトークンを使用してクライアントを認証するすべてのイベントストリーム処理サーバーに公開鍵をコピーします。
• イベントストリーム処理サーバーまたはクライアントを実行しているユーザーのみが使用できるように制限された1つまたは複数のCF UAAクライアントIDを設定します。
• イベントストリーム処理クライアントが使用するトークンを必要とするユーザについて、CF UAAユーザ名とパスワードの認証情報を登録します。

設定が終わったら、認証済み接続のトークンを取得して使用するために必要な手順は、次のとおりです。

• クライアントを特定のサーバーに接続するには、イベントストリーム処理サーバーで使用されているのと同じ公開鍵で設定されたCF UAAサーバーからトークンを取得します。トークン要求には、サーバーで認証を有効にするために使用したのと同じCF UAAクライアントIDが含まれている必要があります。CF UAAからトークンを要求する方法を選択できます。
• 応答からトークンを抽出し、OAuthトークン方式のクライアント要件で説明されている方法でクライアントに提供します。
• トークンが有効期限切れでない限り、同じサーバーに接続するときは、単一のトークンを無制限に再利用できます。

次に、認証情報を用いた暗黙的な付与により、CF UAAサーバーからトークンを取得するためにcurlを使用して呼び出したREST要求の例を示します。

curl -v -H "Accept: application/json" -H "Content-Type: application/x-www-form-urlencoded" "http://myhost:8080/uaa/oauth/authorize?client_id=myclientid&response_type=token&scope=openid&redirect_uri=http://localhost/hello" -d "credentials=%7B%22username%22%3A%22myusername%22%2C%22password%22%3A%22mypassword%22%7D"

REST応答に成功した "302 Found"応答が含まれている場合、REST応答のLocationフィールドの&access_token部分にトークンを見つけることができます。

概要

この認証メカニズムでは、ユーザーが簡単なユーザー名とパスワードの認証情報を提供する必要があります。これらの認証情報は、イベントストリーム処理サーバーからSASLogonサービスに渡されるときに有効である必要があります。

処理の順序は次のとおりです。

1. ユーザーは、パブリッシュ/サブスクライブAPI、アダプター、またはHTTPクライアントに認証情報を提供します。
2. 認証情報は、変更されずにイベントストリーム処理サーバーに渡されます。
3. サーバーは、REST要求における変更を加えていない認証情報を、構成済みのSASLogonサービスに渡します。
4. サーバーは、認証要求の結果をクライアントに返します。

SAS Event Stream Processingでは、ユーザーが、少なくともパブリッシュ/サブスクライブURLにユーザー名を含める必要があります。あるいは、パブリッシュ/サブスクライブURLにパスワードを直接含めることもできます。それ以外の場合、イベントストリーム処理クライアントAPIは、クライアントのローカルファイルシステム内の.authinfoまたは.netrcファイルを検索し、 指定されたユーザー名と一致するパスワードを探します。どちらの方法でも、パスワードはクリアテキストまたはSASでエンコードされたものを使用できます。

SASLogonサービスを使用した認証のサーバー要件

この認証方法は、エンジンを初期化するときにSASLogonサービスのURLを渡すことによって、ESPサーバーで有効になります。

構成ファイルを使用して認証メカニズムを設定するには、ESPサーバー上で次のセキュリティ構成プロパティを指定します。

security:     
   server:         
      auth: saslogon 1
   ...     
   saslogon:         
      server:             
         server_url: URL              
         ca_cert: ca.pem

コマンドラインでESPサーバーを起動するときは、-auth saslogon://sasLogonURLコマンドラインパラメーターを含めます。

SASLogonサーバーはHTTPSもサポートしています。

デフォルトでは、ESPサーバはSASLogonサーバーにサーバー証明書を要求します。有効な証明書が指定されていない場合、セッションは終了します。security.trust_selfsigned=trueを設定すると、証明書が提供されていない場合や無効な証明書が提供されている場合でも、セッションは正常に進行します。

SASLogonサービスを使用した認証のクライアント要件

クライアントは、ユーザー名とパスワードをサーバーに渡すことによって、認証された接続を要求します。クライアントのセキュリティ構成プロパティを指定します。

security:
   ...     
   client:         
      auth: saslogon
   ... 
   saslogon:
   ...         
      client:             
         username: username 

これらの値は、コマンドラインでクライアントを起動するときにオーバーライドできます。

• パブリッシュ/サブスクライブURLまたはアダプタURLでオプションエレメント:?usernameおよび?passwordを使用して指定します。これらのエレメントは、URLのhost:port部分に続けて、dfESP://host:port?username=username?password=passwordのように記述する必要があります。URLの残りの部分は同じです。

  パスワードはエンコードできますが、必ずしもそうである必要はありません。必要に応じて、PWENCODEプロシージャーを使用してパスワードをエンコードします。PWENCODEの結果のプレフィクス{SAS00x} を、イベントストリーム処理クライアントに渡されるパスワード文字列に含めるか、.authinfoファイルまたは .netrc ファイルに含めるようにしてください。クライアントは、認証情報を隠ぺいされた状態でサーバーに渡し、SASLogon認証の結果を待ちます。成功すると、接続が確立され、それ以降のクライアント/サーバーの操作は正常に進みます。失敗した場合、クライアントはサーバーから切断されます。

• ユーザー名は上で説明した方法で渡しますが、APIにローカルの.authinfoまたは.netrcファイルから一致するパスワードを抽出させます。この場合、環境変数AUTHINFOまたはNETRCはフルパスとファイル名に設定する必要があります。環境変数が設定されていない場合、クライアントAPIはユーザーのホームディレクトリ内でファイルを検索します。
• ESPクライアントを起動するときは、-auth saslogon://usernameコマンドラインパラメーターを使用してユーザー名を渡します。

概要

Kerberos認証を有効にするには、ESPサーバーとクライアントがKerberosサーバーにアクセスする必要があります。Kerberosサーバーは、サーバーとクライアントが使用するサービス名をサポートする必要があります。

これらの条件が満たされると、ユーザーは同じKerberosサービス名をESPサーバーおよびクライアントに渡すことができます。クライアントが接続するとき、クライアントとサーバーの間で適切なKerberos交換が実行されます。クライアントは、ユーザーが渡したパブリッシュ/サブスクライブURLに含まれているホストに、ユーザーが渡したサービス名を組み合わせて、サービスプリンシパルのフルネームを作成します。

Kerberos認証のサーバー要件

イベントストリーム処理サーバーでKerberos認証を有効にするには、エンジンを初期化するときにKerberosサービス名を渡す必要があります。C++モデリングAPIでは、dfESPengine::initialize()呼び出しのパラメーターを使用してエンジンを初期化します。認証を有効にするには、現在のpubsub_ENABLE(portNum) パラメーターをpubsub_ENABLE_KERBEROS(portNum, serviceName)に置き換えます。

Kerberosサーバー環境には、読み取り可能なKeyTabファイルが含まれている必要があります。このファイルは通常/etc/krb5.keytabにあります。

ESPサーバーの次のセキュリティ構成プロパティを設定します。

security
   server:
      auth: kerberos
   ...
   kerberos:         
      service_name: serviceName 

これらの値は、-auth kerberos://serviceNameコマンドラインパラメーターでオーバーライドできます。

Kerberos認証のクライアント要件

クライアントは、サービス名をサーバーに渡すことによって、認証された接続を要求します。

JavaおよびC++クライアントを含め、クライアントの次のセキュリティ構成プロパティを設定します。

security:
   client:
      auth: kerberos     
   kerberos:         
      service_name: serviceName

これらの値は、-auth kerberos://serviceNameコマンドラインパラメーターを使用してオーバーライドできます。サーバーは、Kerberosプロトコル交換を開始する前に、同じサービス名で構成されていることを検証します。

コマンドラインでクライアントを起動するときに、?kerberos_servicenameエレメントを使用してサービス名を指定できます。このエレメントは、URLのhost:port部分に続く必要があります。たとえば、

dfESP://host:port?kerberos_servicename=servicename.

URLの残りの部分は同じです。

クライアントを実行してローカルトークンキャッシュを更新する前に、kinitを実行する必要があります。

クライアントがJavaクライアントの場合は、jaas.confファイルがSAS Event Stream Processing構成ディレクトリに存在する必要があります。これは、すでにクライアントマシン上の他のJavaクライアントによって使用されているjaas.confファイルのコピーである必要があります。ファイルには次の行が含まれている必要があります。

com.sun.security.jgss.krb5.initiate {

com.sun.security.auth.module.Krb5LoginModule required
   useTicketCache=true 
   renewTGT=true
   doNotPrompt=true;
};  

Javaクライアントが認証に失敗した場合は、Javaコマンドラインで次のデバッグプロパティを使用できます。

—Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true

デバッグ結果に “サポートされていないキータイプがデフォルトのTGTを見つけました: 18”のメッセージが表示された場合、Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Fileをインストールする必要があります。