次の方法で共有


Enterprise Single Sign-On の概要

複数の異なるアプリケーションに依存するビジネス プロセスでは、複数の異なるセキュリティ ドメインを超える必要がある場合があります。 Microsoft Windows システムでアプリケーションにアクセスするには、1 セットのセキュリティ資格情報が必要になる場合があります。一方、IBM メインフレーム上のアプリケーションにアクセスするには、RACF ユーザー名やパスワードなど、異なる資格情報が必要になる場合があります。 この資格情報の豊富な処理はユーザーにとって困難であり、自動化されたプロセスではさらに困難になる可能性があります。 この問題に対処するために、BizTalk Server には Enterprise シングル サインオンが含まれています。

混乱しないでください。これは、すべてのアプリケーションに対して 1 つのログインをユーザーに許可するメカニズムではありません。 代わりに、Enterprise Single Sign-On では、Windows ユーザー ID を Windows 以外のユーザー資格情報にマップする方法が提供されます。 組織のすべてのエンタープライズ サインオンの問題を解決するわけではありませんが、このサービスを使用すると、さまざまなシステムでアプリケーションを使用するビジネス プロセスの作業が簡単になります。

Windows 以外のシステムの関連アプリケーションを作成する

エンタープライズ シングル サインオンを使用するには、管理者が関連アプリケーションを定義します。各アプリケーションは Windows 以外のシステムまたはアプリケーションを表します。 たとえば、関連アプリケーションは、IBM メインフレームで実行されている CICS アプリケーション、Unix 上で実行されている SAP ERP システム、またはその他の種類のソフトウェアなどです。 これらのアプリケーションにはそれぞれ独自の認証メカニズムがあるため、それぞれに固有の資格情報が必要です。

Enterprise Single Sign-On は、ユーザーの Windows ユーザー ID と、SSO データベース内の 1 つ以上の関連アプリケーションの資格情報との間の暗号化されたマッピングを格納します。 このユーザーが関連アプリケーションにアクセスする必要がある場合、そのアプリケーションの資格情報は、シングル Sign-On (SSO) サーバーによって SSO データベースで検索できます。 次の図は、このしくみを示しています。

シングル Sign-On (SSO) サーバーによって SSO データベースでアプリケーションの資格情報を検索する方法を示す図。

この例では、一部のアプリケーションから BizTalk Server に送信されたメッセージはオーケストレーションによって処理され、IBM メインフレームで実行されている関連アプリケーションに送信されます。 Enterprise Single Sign-On のジョブは、関連アプリケーションに渡されるときに、正しい資格情報 (つまり、適切なユーザー名とパスワード) がメッセージと共に送信されるようにすることです。

SSO チケットを使用したメッセージ処理

図に示すように、受信アダプターがメッセージを取得すると、アダプターは SSO サーバー A に SSO チケットを要求できます (手順 1)。 この暗号化されたチケットには、要求を行ったユーザーの Windows ID とタイムアウト期間が含まれます。 (Kerberos チケットと混同しないでください。これは同じことではありません)。チケットが取得されると、受信メッセージにプロパティとして追加されます。 その後、メッセージは BizTalk Server エンジンを介して通常のパスを受け取ります。この例では、メッセージはオーケストレーションによって処理されていることを意味します。 このオーケストレーションで送信メッセージが生成されると、そのメッセージには、前に取得した SSO チケットも含まれます。

この新しいメッセージは、IBM メインフレームで実行されているアプリケーション宛てであるため、このユーザーがそのアプリケーションにアクセスするための適切な資格情報を含める必要があります。 これらの資格情報を取得するために、送信アダプターは SSO サーバー B (手順 2) に接続し、受信したメッセージ (SSO チケットを含む) と資格情報を取得しようとしている関連アプリケーションの名前を指定します。 この操作は引き換えと呼ばれ、SSO サーバー B が SSO チケットを検証し、そのアプリケーションに対するこのユーザーの資格情報を検索します (手順 3)。 SSO サーバー B は、これらの資格情報を送信アダプター (手順 4) に返します。この資格情報を使用して、適切に認証されたメッセージを関連アプリケーションに送信します (手順 5)。

SSO の管理

Enterprise Single Sign-On には、さまざまな操作を実行するための管理ツールも含まれています。 たとえば、SSO データベースで実行されるすべての操作が監査されるため、管理者がこれらの操作を監視し、さまざまな監査レベルを設定できるツールが提供されます。 その他のツールを使用すると、管理者は特定の関連アプリケーションを無効にしたり、ユーザーの個々のマッピングをオンまたはオフにしたり、他の機能を実行したりできます。 エンド ユーザーが独自の資格情報とマッピングを構成できるようにするクライアント ユーティリティもあります。 また、BizTalk Server の他の部分と同様に、エンタープライズ シングル Sign-On は、プログラミング可能な API を介してそのサービスを公開します。 サードパーティの BizTalk Server アダプターの作成者は、この API を使用してシングル サインオン サービスにアクセスし、管理者はこれを使用して一般的なタスクを自動化するためのスクリプトを作成できます。

上で説明した例は、Enterprise シングル サインオンの一般的な使用方法を示していますが、SSO は他の方法で構成できます。 たとえば、小規模な BizTalk Server のインストールでは、SSO サーバーが 1 つだけの場合があり、BizTalk Server エンジンとは別に Enterprise Single Sign-On を使用できます。 (このテクノロジは、Microsoft Host Integration Server にも付属しています)。

こちらもご覧ください

BizTalk Server メッセージング エンジン
Enterprise シングル サインオンの実装