認証

認証機能とは、通信するプロセスどうしがお互いの ID を証明し合うことです。BEA Tuxedo 製品の ATMI 環境での認証プラグイン・インターフェイスは、共有シークレット・パスワード、ワンタイム・パスワード、CHALLENGE 応答、Kerberos などの認証技術を使用して、セキュリティ・プロバイダによるさまざまな認証プラグインに対応できます。インターフェイスは、必要に応じて GSSAPI (Generic Security Service Application Programming Interface) の仕様に厳密に従います。GSSAPI は、公開されている IETF (Internet Engineering Task Force) の標準です。認証プラグイン・インターフェイスは、サードパーティ・ベンダのセキュリティ製品をできるだけ簡単に BEA Tuxedo システムに統合できるように設計されています。ただし、セキュリティ製品は GSSAPI を使用して記述しておく必要があります。

認証プラグインのアーキテクチャ

認証機能を使用するためのプラグイン・インターフェイスは、1 つのプラグインとしてインプリメントされ、デフォルトの認証プラグインを使用することも、カスタマイズした認証プラグインを使用することもできます。

委任された信用認証について

BEA Tuxedo システムなどの分散型のエンタープライズ・ミドルウェア環境で、エンド・ツー・エンドの相互認証を直接行う場合、特に、長時間の接続用に最適化されたセキュリティ・メカニズムでは、大幅にコストがかかります。クライアントから各サーバ・プロセスに対して直接ネットワーク接続を確立したり、サービス要求の処理時に複数の認証メッセージを交換および検証するのは、非効率的です。代わりに、ATMI アプリケーションは、次の図のような、高信頼性委託型認証モデルを使用しています。

ATMI の高信頼性委託型認証モデル

信頼性のあるゲートウェイは、通過するクライアント要求にセキュリティ・トークンを添付します。添付されたセキュリティ・トークンは、クライアント要求のメッセージと共に送信され、送信先のサーバ・プロセスでの認可と監査で使用されます。

このモデルのゲートウェイでは、認証ソフトウェアがクライアントの ID を検証し、適切なトークンを生成することが期待されています。一方、サーバ側では、ゲートウェイ・プロセスで適切なセキュリティ・トークンが添付され、そのセキュリティ・トークンが、クライアント要求を処理するその他のサーバに安全に格納されることが期待されています。

セッションの確立

次の図は、ワークステーション・クライアントと WSH との間でセッションが確立されているときの、BEA Tuxedo システムの ATMI 環境内での制御フローを示しています。ここでは、ワークステーション・クライアントと WSH が、メッセージを交換して相互に認証し合い、長期間にわたる接続を確立する様子を示しています。

クライアントと WSH 間の認証

セキュリティ・プロバイダの認証プラグインでは、セキュリティ・インプリメンテーション用のセッション・トークンおよびセッション・コンテキストの内容が定義されています。したがって、ATMI の認証では、セッション・トークンとセッション・コンテキストをオペークなオブジェクトとして扱う必要があります。交換されるトークンの数は定義されておらず、認証システムのアーキテクチャに応じて異なります。

ネイティブ・クライアントでセッションを開始する場合、イニシエータ・プロセスとターゲット・プロセスは同じです。このプロセスは、ミドルウェア・クライアント・プロセスと見なすことができます。ミドルウェア・クライアント・プロセスは、セキュリティ・プロバイダの認証プラグインを呼び出してネイティブ・クライアントを認証します。

認可トークンおよび監査トークンの取得

認証に成功すると、信頼性のあるゲートウェイは、BEA Tuxedo の内部関数を 2 つ呼び出し、クライアント用の認可トークンおよび監査トークンを取得します。これらのトークンは、ゲートウェイによって格納されます。 これらのトークンの組み合わせは、セキュリティ・コンテキストのユーザ ID を表します。セキュリティ・トークンという用語は、集合的に認可トークンと監査トークンを表します。

デフォルトの認証の認可トークンには、次の 2 つの情報が設定されています。

また、デフォルトの認証を使用する場合、監査トークンにもプリンシパル名とアプリケーション・キーが設定されます。

セッション・トークンと同様に、認可トークンと監査トークンもオペークであり、内容は、セキュリティ・プロバイダごとに異なります。認可トークンを使用すると、認可 (パーミッション) をチェックすることができます。監査トークンを使用すると、監査情報を記録することができます。ATMI アプリケーションによっては、認可用と監査用のユーザ ID を別々に設定すると便利です。

クライアント・トークンとサーバ・トークンの交換

クライアントのサービス要求がサーバ側で転送されるとき、サーバの ID が付く場合があります。次の図はその様子を示しています。サーバは、サービス要求に添付されたクライアント・トークンを自らのトークンに置き換えてから、そのサービス要求を適切なサービスに転送します。

サーバ・パーミッションのアップグレード例

カスタマイズされた認証のインプリメント

ATMI アプリケーションで認証機能を実行するには、デフォルトのプラグインまたはカスタマイズしたプラグインを使用します。どちらのプラグインを使用するかは、BEA Tuxedo のレジストリを設定して決めます。これは、すべてのセキュリティ・プラグインを制御するツールです。

関連項目