アイデンティティーベースの通信の例

この例では、約 1,000 〜 5,000 人の従業員を持つ中規模企業用のアイデンティティーベースの通信を示します。通常、論理アーキテクチャーの設計を行なうためには、徹底的なビジネス分析の後に詳細な技術要件分析を行なう必要があります。ただし、これは理論上の例であるので、次のビジネス要件が決定されたものと仮定します。

• 企業の従業員は、内部の Web サイト、通信サービス、カレンダサービス、およびその他のリソースに対する個人用カスタマイズされたアクセスを必要としている。

• 企業全体の認証と承認により、内部の Web サイトなどのサービスに対するアクセスが許可される。

• 1 つのアイデンティティーは、すべてのエンタープライズサービスにおいて追跡され、内部の Web サイトなどのサービスへのアクセスを許可するシングルサインオンが有効になる。

この例のユースケースでは、ログイン手順、電子メールの参照、電子メールの送信、ポータルの個人用カスタマイズ、カレンダの同期、およびその他の類似のユーザーアクティビティーについて詳細化されています。

次の図は、このタイプのアイデンティティーベースの通信ソリューションに対する論理アーキテクチャーを示します。

アイデンティティーベースの通信シナリオ例のユースケース

通常、この種の配備ソリューションの場合、ソリューションが提供するサービスに対するユーザーのインタラクションを説明する多数の詳細なユースケースがあります。この例では、ユーザーが Web ブラウザクライアントからポータルにログインするときの、コンポーネント間のインタラクションを取り上げます。例では、ログインシナリオが次の 2 つのユースケースに分割されています。

• ユーザーがログインし、認証されると、Portal Server はユーザーのポータル設定を検索する。

• Portal Server は、電子メールおよびカレンダ情報を検索して、Web クライアントに表示する。

2 つのユースケースは、1 つの拡張されたユースケースと考えることができます。しかし、この例では、単純化のためにユースケースは分割されています。

ユースケース 1: ユーザーが正常にログインし、ポータルがユーザーの設定を検索する

手順

1. Web ブラウザクライアントが、ユーザー ID とパスワードを Portal Server に送信する。

2. Portal Server は、Access Manager に認証を要求する。

3. Access Manager は、ユーザー ID とパスワードの検証を Directory Server に要求する。

4. Directory Server は、ユーザー ID とパスワードを検証する。

5. Access Manager は、Directory Server にユーザープロファイルを要求する。

6. Directory Server は、ユーザープロファイルを返す。

7. Portal Server は、Access Manager にユーザー表示プロファイルを要求する。

8. Access Manager は、ポータル設定を返す。

9. ポータル設定が Web ブラウザクライアントに表示される。

   

ユースケース 2: Portal Server が電子メール情報とカレンダ情報を表示する

手順

1. ログイン、認証、およびポータル設定の検索が正常に完了したあと、Portal Server は、Messaging Server MMP に電子メールメッセージを要求する。

2. MMP は、Messaging Server STR にメッセージリストを要求する。

3. STR は、MMP にメッセージリストを返す。

4. MMP は、Portal Server にメッセージヘッダーを転送する。

5. Portal Server は、Communications Express にカレンダ情報を要求する。

6. Communications Express は、Calendar Server バックエンドにカレンダ情報を要求する。

7. Calendar Server バックエンドは、Communications Express にカレンダ情報を返す。

8. Communications Express は、Portal Server にカレンダ情報を転送する。

9. Portal Server は、すべてのチャネル情報を Web ブラウザクライアントに送信する。