第 1 部では、勇敢な秘密諜報員 Jim Bland を例にとり、シングル・サインオンの基礎から複数ディレクトリー、複数 ID 環境までを説明しました。この記事では、SSO のシナリオをいくつか紹介し、Notes/Domino 7 での SSO 環境について簡単に説明します。第 1 部と同様に、この記事も Notes/Domino に習熟したユーザーまたはシステム管理者を対象として書かれています。

シングル・サインオンのシナリオ

SSO のソリューションにはいくつかの種類がありますが、この記事では、典型的な 4 つのデプロイメント・シナリオを取り上げます。各ソリューション間で優劣の差はありません。どの方法を選択するのかは、常に、組織のインフラストラクチャーとシステム管理者が守らなければならない規則に強く依存します。組織内のいくつかの部署では、LDAP が社内ディレクトリーになっていて、すべての変更はこのディレクトリーで行う必要があります。また、他の支店では、LDAP スキーマの変更が禁止されていて、すべての変更は Domino ディレクトリで行わなければなりません (LDAP スキーマと Domino スキーマの詳細については、この資料を参照してください)。

SSO 以外の理由で、組織内で LDAP ディレクトリーと Domino ディレクトリの両方にアクセスしなければならない特殊なケースも存在します。たとえば、TSGA には、諜報活動用の機密装置を管理する専用の在庫システムがあります。この在庫システムは、"Special Equipment" ディレクトリー・オブジェクトが存在する ITDS LDAP ディレクトリーにアクセスする必要があります。このため、ITDS LDAP ディレクトリーを指すようディレクトリアシスタントが環境内で設定されています。このケースでは、設定済みのさまざまなディレクトリー間の関係を管理することが SSO デプロイメントのポイントとなります。

これから説明する SSO シナリオでは、SSO 情報を Domino ディレクトリで管理するシナリオと LDAP ディレクトリーで管理するシナリオがあります。また、ディレクトリアシスタントを使用するケースもあります。さまざまなシナリオの中で、自社のインフラストラクチャーや組織のニーズに最も近いものが見つかるでしょう。どの SSO 構成にするのかは、常に組織の現在のニーズに応じて選択します。

採用する SSO の手法はシナリオによって異なりますが、いずれの場合も、Bland は最初に WebSphere Portal Server にログインし、ITDS の ID「uid=jb013」を含む LtpaToken が作成される点に注意してください。

シナリオ 1:Domino ユーザー文書を使用した名前のマッピング

それでは、最も一般的で基本的なシナリオから始めましょう。このシナリオでは、SSO 情報を Domino ディレクトリで管理する方法を説明します。

Bland が DWA ポートレットに切り替えると、jb013 を含む LtpaToken が HTTP を介して送信されます。しかし、Domino Server はどのような方法で Bland に DWA メール・ファイルへのアクセスを許可するのでしょうか。特に、メール・ファイルの ACL エントリーでは、「cn=Jim Bland/ou=secret/o=spies」にアクセスが許可されています。答えは簡単で、システム管理者が Bland のユーザー文書を変更し、fullname フィールド の 2 次値として「uid=jb013/ou=secret/dc=spies/dc=com」を追加します (図 1 参照)。

Domino Web Access サーバーは、LtpaToken に含まれている値を Domino ディレクトリで検索します。この値はユーザー文書に格納されているので、検索によって見つけられます。Domino はこの名前を解決して Domino の識別名「Jim Bland/Secret/Spies」を得ます。これはメール・ファイルの ACL に含まれているので、Bland はメール・ポートレットへのアクセスを認められます。

TSGA のシステム管理者は、名前のマッピングに関する次のルールを守る必要があります。

• Domino ユーザー文書の FullName フィールドを変更するときは、ユーザーの LDAP 識別名を「Domino 形式」で入力します。
  LDAP 形式:uid=jb013,ou=secret,dc=spies,dc=com
  Domino 形式:uid=jb013/ou=secret/dc=spies/dc=com
• LDAP DN は、2 次値として FullName フィールドに追加します。LDAP DN を最初の値または 2 番目の値としては追加しないでください。Domino は、最初の値を Domino DN とみなし、2 番目の値を Domino の「共通名」とみなします。
• アプリケーションによっては大文字と小文字が区別されるので、注意が必要です。Domino では大文字と小文字は区別されませんが、区別されるアプリケーションもあります。トラブルを避けるために、正しく入力してください。
• ディレクトリーの変更を容易にするために、IBM Tivoli Directory Integrator を使用し、マッピング・ポリシーの実装を自動化することもできます。

シナリオ 2:ディレクトリアシスタントを使用した名前のマッピング:複数の一致を解決する

前述のように、シングル・サインオン以外の理由で、両方のディレクトリーに同時にアクセスしなければならない組織もあります。TSGA 調査部門のインフラストラクチャーでは、前述の機密装置の在庫システム用に、Domino Server が IBM Tivoli Directory Server (ITDS) にアクセスする必要があります。TSGA の在庫管理 Notes アプリケーションが ITDS に存在する "Special Equipment" ディレクトリー・オブジェクトにアクセスできるようにするために、システム管理者は Domino Server (Domino Web Access も実行しているサーバー) のディレクトリアシスタント・データベースで ITDS ディレクトリー用の LDAP エントリーを作成します。

この環境で SSO を実現するために、前のシナリオと同様に、TSGA は LtpaToken 値「uid=jb013,ou=secret,dc=spies,dc=com」を Domino のユーザー文書に追加します。これによって新たなジレンマが生じます。名前「uid=jb013,ou=secret,dc=spies,dc=com」が、ユーザーの ITDS エントリーと、Jim Bland/Secret/Spies の Domino ユーザー文書の 2 か所に存在することになります。DN (識別名) が異なるとき、Domino Server は、Domino ディレクトリと ITDS サーバーの両方に存在する Bland をどのような方法で一致させるのでしょうか。また、Domino はどのような方法で、この 2 つが同じユーザーであると判断するのでしょうか。

最新の 6.x および 7.0 リリースは、ディレクトリアシスタントが使用されているとき、ユーザー・エントリーが複数の場所にあるときの名前のマッピングに対応しています。Domino では、Domino ユーザー文書と LDAP レコード間に整合性があることが必要です。このため、両方のディレクトリーにある "Internet address" フィールドで値が一致するかどうかを判断する追加作業が Domino で実行されます。これを行うために、ディレクトリアシスタントは Notes フィールドの InternetAddress と等価の LDAP 属性に対し、ID「uid=jb013」を検索するクエリーを発行します。LDAP では、等価の属性は mail です。

TSGA の環境にディレクトリアシスタントがあり、これが SSO の ID を含む LDAP ディレクトリーを指す場合、システム管理者は Domino 属性 "Internet address" の値と LDAP 属性 "mail" の値を一致させる必要があります。

Domino およびディレクトリアシスタントが、名前のマッピングと複数の一致を処理する方法の詳細については、『Notes/Domino 6.0.4 リリース情報』の「Domino HTTP サーバーが処理する WebSphere と Domino ユーザー名」を参照してください。

ディレクトリアシスタントが、ユーザー文書に追加された uid と同じ uid を含む LDAP ディレクトリーを指すときに、Jim Bland の操作にともなう SSO での処理手順を次の図 2 〜 5で示します。図 2 について説明します。
A．Bland は DWA ポートレットにアクセスします。ポートレットは LtpaToken を Domino Web Access サーバーに渡します。このサーバーは、Domino ディレクトリで「uid=jb013,ou=secret,dc=spies,dc=com」を検索します。
B．Domino は、1 次ディレクトリーにある「Jim Bland/Secret/Spies」という Domino 識別名のユーザー文書で、3 番目の FullName 値「uid=jb013,ou=secret,dc=spies,dc=com」が一致することを見つけます。

図 3 について説明します。
C．ディレクトリアシスタントは、指定された LDAP ディレクトリーに検索クエリーを発行するよう設定されています。LDAP 検索:
BaseDN: ou=secret,dc=spies,dc=com
Filter: uid=jb013
attrs to return: "mail"
D．IBM Directory Server は一致を検出し、要求された mail 属性値「mail=JBland@secret.spies.com」を返します。

図 4 について説明します。
E．"mail" の内容が "InternetAddress" の内容に一致しているか判断します。言い換えると、Domino ユーザー文書の InternetAddress 属性の値が ITDS の mail 属性の値に一致するかどうかを調べます。

最後に、図 5 について説明します。
F．2 つのレコードのメール・アドレスが一致することに基づき、同じユーザーが ITDS レコードと Domino ユーザー文書の両方で表されていることが検証されます。LDAP 名から Domino 名へのユーザー名のマッピングが成功し、Bland は自分自身の Domino Web Access メール・ファイルへのアクセスが許可されます。

シナリオ 3:外部 LDAP スキーマとディレクトリアシスタントの変更によるユーザー名のマッピング

TSGA のさまざまな組織では、LDAP が社内ディレクトリーとして選択されています。LDAP では、ディレクトリー・スキーマの追加、削除、および変更を管理するポリシーと手続きが定められています。この例では、変更と更新は主に IBM Tivoli Directory Server を通して管理され、Domino ディレクトリでの変更は許可されていません。Domino 6.0 のディレクトリアシスタントに組み込まれた新しい機能は柔軟性が高いので、これは問題とはなりません。TSGA のシステム管理者は、Notes 識別名 (DN) をユーザーの LDAP ID の属性として追加することにより、社内 LDAP ディレクトリーの変更という方法を選択できます。Bland のケースでは、IBM Tivoli Directory Server で Bland の「uid=jb013,ou=secret,dc=spies,dc=com」エントリーの属性として Notes 識別名を追加します。また、社内 LDAP ディレクトリー・サーバーを指すディレクトリアシスタントに LDAP ドメインを追加します。TSGA がこの方法を使用して LDAP に情報を追加すると、Domino ユーザー文書に変更を加える必要はありません (つまり、FullName フィールドの 2 次値は変更しません)。

次に、システム管理者は、IBM Tivoli Directory Server でどの LDAP 属性に Notes 識別名を生成するのかを選択しなければなりません。システム管理者は、この属性として、LDAP スキーマにある既存の属性を選択できます。また、新しい属性を作成して LDAP スキーマを拡張することもできます。どちらの方法でも、属性は DN 構文タイプにすることが必要です。属性の構文の詳細については、RFC 2252 を参照してください。

属性を選択した後、TSGA のシステム管理者は SSO が必要な各 ID ごとに LDAP 形式の構文で Notes DN を追加できます。システム管理者が NotesDN という新しい属性の作成を選択した場合を考えます。この属性は、IBM Tivoli Directory Server LDAP ディレクトリーのユーザー・スキーマの一部です。システム管理者は、Notes 識別名「cn=Jim Bland, ou=secret, o=spies」を NotesDN 属性の値として追加します。SSO を設定するために、システム管理者はディレクトリアシスタントのドメインのエントリーの [LDAP] タブ (図 6 参照) を選択し、[Notes の識別名で使う属性] フィールドに LDAP 属性の名前「NotesDN」を追加します。次に、[名前付けのコンテキスト (ルール)] タブで、[証明書を信用] がオンになっていることを確認します。また、TSGA のシステム管理者は LDAP 階層での名前付けコンテキスト・ルールが正しいことを確認します。言い換えると、IBM Tivoli Directory Server のディレクトリー階層 (ou=secret,dc=spies,dc=com) は Domino のディレクトリー階層 (ou=secret/o=spies) と異なります。ディレクトリアシスタントでルールが正しく定義されているか検証してください。ディレクトリアシスタントの命名規則の詳細については、『Domino Administrator ヘルプ』の「ディレクトリアシスタントと命名規則」を参照してください。

この新しい機能を使用した SSO 環境で、Jim Bland の要求がどのように処理されるかを図 7 〜 10 に示します。図 7 について説明します。
A．Jim は自分自身の Domino Web Access ポートレットにアクセスします。Portal は DWA サーバーに LtpaToken を渡します。サーバーは、Domino ディレクトリで「uid=jb013,ou=secret,dc=spies,dc=com」を検索します。前のセクションで説明したシナリオとは異なり、「uid=jb013,ou=secret,dc=spies,dc=com」は Domino ディレクトリのどこにも存在しません。
B．Domino ディレクトリではディレクトリアシスタントが設定されています。ディレクトリアシスタントでは、[Notes の識別名で使う属性] 機能が設定されています。

図 8 について説明します。
C．「uid=jb013」を検索し、その NotesDn 属性を返すことを求める LDAP 検索クエリーを発行します。LDAP 検索:
BaseDN: ou=secret,dc=spies,dc=com
Filter: uid=jb013
attrs to return: "NotesDN"
D．IBM Directory Server は一致するエントリーを見つけ、「cn=Jim Bland,ou=secret,o=spies」という値を含む NotesDN 属性を返します。

図 9 について説明します。
E．NotesDN が返されたので、「uid=jb013/ou=secret/dc=spies/dc=com」形式のユーザー名が、メール・ファイルの ACL に存在するユーザーの Notes 識別名にマッピングされます。

図 10 について説明します。
F．Jim Bland は、自分自身の Domino Web Access メール・ファイルへのアクセスを許可されます。

シナリオ 4:ユーザー名のマッピングに LDAP プロトコルを使用する IBM コラボレーティブ・コンポーネント

ここまでは、比較的理解しやすく、デプロイも簡単なシナリオについて見てきました。このセクションでは、少し複雑なシナリオについて説明します。このシナリオでは、Domino 関連製品群に必要な SSO に注目します。

Jim は Dubuque で起きている面倒な事態について、Agent 009 とインスタント・メッセージングで連絡を取ることにしました。この後、Jim は WebSphere Portal Server のポータル・ページから TSGA Agent Team Workspace にアクセスする計画を立案します。現在、Jim は IBM の SSO 用の統合環境で Sametime と QuickPlace の 2 つのコラボレーティブ・コンポーネントを使用しています。Sametime と QuickPlace は SSO 用に設定されています (どちらも、ログイン済みユーザー「uid=jb013...」のユーザー名を含む同じ LtpaToken を受け取ります)。前の例の DWA とは異なり、Sametime と QuickPlace は、LDAP プロトコルを介して Domino ディレクトリでユーザーを検索するように設定されています。つまり、ネイティブ Domino NRPC プロトコルに基づく Dominoディレクトリのインターフェースは使用しません。Sametime サーバーまたは QuickPlace サーバーが LtpaToken に含まれる ID を Domino で検索するとき、検索は LDAP プロトコルを使用して実行されるので、Domino LDAP サーバーが要求を受け取り、検索を開始します。

Domino Server がディレクトリーで一致するエントリーを見つけると、その Domino DN を LDAP 形式の構文「cn=Jim Bland,ou=secret,o=spies」で要求側に返します。この後、「cn=Jim Bland,ou=secret,o=spies」が LtpaToken 値「uid=jb013,ou=secret,dc=spies,dc=com」と本当に同じ ID かどうかを判断することは、Sametime または QuickPlace での作業となります。つまり、Sametime サーバーと QuickPlace サーバーは、ユーザー名のマッピングを行う必要があります。この点が前のシナリオと異なっています。アプリケーションが HTTP を介して Domino にアクセスするケースでは (TSGA の例では、このアプリケーションは DWA ポートレット)、Domino Web Server が要求を受け取り、ディレクトリアシスタントによって LDAP クエリーがネイティブに作成されます。この結果、Domino ディレクトリがユーザー名のマッピングをすべて行うことになります。これに対し、いま説明しているシナリオでは、Domino とディレクトリアシスタントはユーザー名のマッピングを処理する責任はありません。代わりに、Sametime と QuickPlace がユーザー名のマッピングを処理しなければなりません。前述のように、Sametime と QuickPlace は、LDAP プロトコルを介したディレクトリー検索という方法でユーザー名のマッピングを実現します。

これを行うために、TSGA のシステム管理者は次の設定を実行する必要があります。

まず、ユーザー名のマッピングを実装するために、Domino ユーザー文書の FullName フィールドの 2 次値として LDAP DN を追加します。次に、各 LDAP クライアントに LDAP エイリアスの非参照を設定します。この場合、設定するクライアントは、Sametime Links クライアントと QuickPlace クライアントです。LDAP サーバーが Domino ユーザー文書の FullName フィールドの 2 次値として登録されている LDAP 名を検出するために、LDAP クライアントは、名前の検索時にエイリアスの非参照を行うよう LDAP サーバーに要求する必要があります。LDAP エイリアスと Notes 別名は異なる概念です。基本的に、LDAP エイリアスは LDAP ディレクトリーまたは X.500 ディレクトリー内のエントリーで、ディレクトリー階層の別のエントリーを指します。Notes の場合、別名は FullName フィールドまたは ShortName フィールドの任意の 2 次値です。Domino Server がエイリアス (たとえば、「uid=jb013...」のような LDAP ユーザー名) を Domino 識別名として解決するために、LDAP サーバーは LDAP クライアントから、エイリアスの非参照がオンになっている要求を受け取る必要があります。

LDAP エイリアスの非参照は、LDAP サーバーでも有効にしてください。デフォルトでは、Domino LDAP Server はエイリアスの非参照は行いません。TSGA のシステム管理者がこの機能を有効にするには、1 次 Domino ディレクトリの [設定] オプションでサーバー設定文書の *-[すべてのサーバー] を開き、[LDAP] タブで [検索リクエスト時にエイリアス非参照を許可しますか？] を [はい] に設定します (図 11 参照)。

Sametime サーバーと QuickPlace サーバーを最新のリリースにアップグレードします (複数ディレクトリ構成では Hotfix が必要な場合もあります)。

これ以外にも、重要なことがあります。Sametime の管理については、この資料を参照してください。また、QuickPlace に関する情報については、この資料を参照してください。

上に戻る

即時停止のシナリオ

Jim Bland は陰謀と危険にあふれた任務を夢見ています。しかし、現在取り組んでいる駐車料金のおとり捜査では、生死を賭けるような局面にはならないでしょう。SSO には同じことはあてはまりません。複数ディレクトリー、複数 ID という用語の氾濫で、少し疲れてきたのではないでしょうか。しかし、特殊文字を含むユーザー名に関する重要な問題を考慮しなければなりません。特殊文字を含むユーザー名は、SSO シナリオを即時停止に追い込む原因となります。

Domino 識別名は、LDAP 識別名と異なる形式を持ちます。前述のように、Domino は区切り記号としてスラッシュを使用し、LDAP はコンマを使用します。ある形式のユーザー名を別の形式のユーザー名に変換するロジックは、さまざまな IBM 製品に実装されています。しかし、Domino 形式のユーザー名と LDAP 形式のユーザー名の間には、特殊文字のほかにも、正しい処理が必要な構文的な違いも存在します。特に、LDAP ユーザー名に次の特殊文字があるときは、特別な処理をしなければなりません。

• より小さい <
• より大きい >
• セミコロン ;
• コンマ , (区切り記号ではなく名前の中で使用されているもの)
• プラス記号 +
• 二重引用符 "
• バックスラッシュ \
• 文字列の先頭のスペースまたは #
• 文字列の末尾のスペース

ユーザー名に特殊文字が含まれていると、LTPA Cookie に含まれる名前が LDAP 形式から Domino 形式に、またはその逆に変換されるときに、SSO シナリオにトラブルを与える可能性があります。SSO ではユーザー名が重要なので、認識不可能な名前になるなど、ユーザー名の変換に不具合があると、SSO 自体に明らかな影響を及ぼします。バックグラウンドのソフトウェアは、適切な変換を行うよう実装しなければなりません。最新のリリースを使用することで、環境内で SSO が即時停止する事態を避けられます。SSO シナリオでユーザー名に含まれる特殊文字を適切に処理するには、Domino 6.5.4 またはそれ以降にアップグレードする必要があります。

特殊文字が含まれるユーザー名は、Collaborative Portlet および Domino 関連製品群でも問題の原因となることがあります。5.1 より前のバージョンの WebSphere Portal が導入されている場合は、特殊文字を含むユーザー名の処理に修正が必要なこともあります。同様に、QuickPlace サーバーおよび Sametime サーバーにも、特殊文字をサポートするための修正が必要です。

上に戻る

魅力的な新機能

現在、複数ディレクトリーのシナリオでは、ユーザーは常に WebSphere (または、ポータルなどの WebSphere コンポーネント) に最初にログインする必要があります。WebSphere は LTPA Cookie を作成し、WebSphere が認識できる LDAP ユーザー名をこの Cookie 内に格納します。Domino は柔軟性が高く、WebSphere が認識可能な LDAP ユーザー名を使用して作成された LTPA Cookie を受け入れるように設定できるので、SSO は正しく機能します。しかし、逆の状況、つまり、複数 ID のシナリオで WebSphere が Domino 形式のユーザー名を受け取ると問題が生じます。なぜ、ユーザー名が Domino 形式になるのでしょうか。ユーザーが最初に Domino にログインすると、Domino は LTPA Cookie を作成し、Domino 形式のユーザー名をこの Cookie 内に格納します。WebSphere が Cookie を受け取り、Cookie に含まれる名前を検索すると、SSO は機能しなくなります。WebSphere のユーザー・ディレクトリーで Domino ユーザー名が見つからないからです。Domino ユーザー名を受け入れるよう WebSphere の柔軟性を高めるには、WebSphere 用のカスタム・コードを書く必要があります。このようなカスタム・ソリューションには多くの導入作業とサポートが必要なので、通常はあまり適切な戦略ではありません。それよりも、ユーザーに最初に WebSphere にログインしてもらう方がはるかに簡単です。現在、この対策も進行中です。ユーザーの利便性を向上するために、Domino 7 では、ユーザーが最初に WebSphere にログインしなければならい制限が取り除かれています。Domino 7 では、ユーザーが最初に Domino へログインできる設定オプションが追加されています。これは、Domino がユーザー用に作成する LTPA Cookie に含めるユーザー名の形式をシステム管理者が選択できるというアイデアです。Domino 7 では、LTPA Cookie に Domino 形式のユーザー名を格納する代わりに、LDAP ユーザー名を格納するよう設定できます。SSO の相互運用性を最大限に高めるために、システム管理者は、Domino、WebSphere、および Domino 関連製品群のいずれにも受け入れられるユーザー名の形式を選択する必要があります。

現在、Domino 7 のユーザーはこの機能を試すことができます。最初に、LTPA ユーザー名を設定するかどうかを切り替えるオプションを変更します。このオプションは、SSO 設定文書内の新しいフィールドにあります (図 12 参照)。このオプションが [無効] のままの場合、Domino はこれまでどおり、ユーザー用に作成する LTPA Cookie に Domino ユーザー名を格納します。このオプションを [有効] にすると、Domino は LTPA Cookie に格納する LDAP 設定済みユーザー名を検索します。

Domino 7 のユーザー文書には、LTPA ユーザー名を指定する新しいフィールドが追加されました。このフィールドは、SSO 設定で LTPA トークンでの名前のマッピングが有効な場合に参照されます。システム管理者は、ユーザー文書の [LTPA ユーザー名] フィールドで、WebSphere と Domino の両方に受け取られる Jim Bland の LDAP ユーザー名を設定できます。この名前が、Domino 7 によって作成される LTPA Cookie に格納されます。設定済みの LTPA ユーザー名は、Domino 形式でユーザー文書に入力してください。つまり、コンマの代わりにスラッシュを使用します。心配する必要はありません。Domino が LTPA Cookie を作成するとき、必要に応じて Cookie 内に格納する名前を Notes 形式から LDAP 形式に変更します。名前に含まれる特殊文字も適切に処理されます。

もちろん、Domino ユーザー文書を持たないユーザーもいます。これらのユーザーは、外部 LDAP ディレクトリーにユーザー・レコードを持っています。この場合は、Domino ディレクトリアシスタントを使用して LDAP ディレクトリーでユーザーを見つけます。これらのユーザーは Domino ユーザー文書を持たないので、SSO の設定で LTPA トークン内のユーザー名のマッピングが有効になっている場合、ユーザー文書の新しい LTPA ユーザー名フィールドは使用されません。システム管理者は LDAP ディレクトリー内の Domino ユーザーに対して、代わりの方法として、ディレクトリアシスタント文書で LTPA ユーザー名を設定できます。Domino 7 のディレクトリアシスタントの設定には、[SSO トークン内の名前で使う属性 (Notes LTPA_UsrNm にマップ)] という新しいフィールドがあります。通常、システム管理者は特殊なキーワード $DN を使用してこのフィールドを指定します。$DN キーワードは、ユーザーの LDAP 識別名を LTPA Cookie に格納することを指示するための簡便な方法です。SSO トークン内の名前として使用される属性として $DN が設定されていると、Domino は外部 LDAP ディレクトリーのユーザー用に LTPA Cookie を作成するたびに、そのユーザーの LDAP 識別名を Cookie に格納します。

上に戻る

SSO の (少しだけ) 不思議な世界: まとめ

記事も終わりに近づき、SSO の基本を理解して SSO のヒーローになるときがきました。もし、あなたが任務を引き受けるのであれば、それは社内で Jim Bland のすべての役割を補助し、作業が効率よくはかどるようにすることです。これ以上やりがいのあることはありません。

この連続記事では、特に複数ディレクトリー、複数 ID が含まれる環境で、SSO のデプロイメントを推進する際に必要となる情報を提供してきました。SSO の動作や、複数の名前でユーザーが認識される環境でのインフラストラクチャーの選択方法について、理解を深められたと思います。どのような選択を行うのかは、管理方針によって決まります。IBM は、Domino ディレクトリおよび外部 LDAP ディレクトリーで SSO 情報を管理するソリューションを提供しています。SSO ディレクトリーのデプロイメントには、Sametime および QuickPlace の設定も必要です。この記事で述べた複数 ID 環境で成功するためのヒントが参考になります。ユーザーが複雑な SSO 環境を信頼して正しく使用するためには、システム管理者はあらゆる機能に精通する必要があります。

この記事では、私たちのヒーロー Jim Bland は、スパイの世界での活躍と同様、SSO に対応した Web ポータルを簡単に使いこなしています。一方、Bland のボスである VM は、Bland に求められている大幅な生産性の向上が、SSO によって達成されたことに満足しています。今後、Bland は任務をこなす上で、ID の確認を何度も求められることはないでしょう。完全に統合された SSO 環境での唯一のマイナス面は、Bland の名前が各段階で呼ばれなくなることです。正しく設定された SSO 環境であれば、エレベータのドアが開くときは常に足を踏み出すフロアが広がっていることを確信できます。SSO に感謝しましょう。

参考文献

• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
  
  
• この連続記事の第 1 部では、シングルサインオンと複数ディレクトリー、複数 ID 環境の基礎について解説しました。
  
  
• Lotus Notes/Domino 7.0 の新しい暗号化/復号 API の詳細については、developerWorks: Lotus 記事『Notes/Domino 7.0 でのセキュリティ API』を参照してください。
  
  
• Lotus Domino 7.0 の新機能については、記事『Lotus Domino 7.0 の新機能』を参照してください。
  
  
• Lotus Notes/Domino 製品の詳細については、Lotus Notes/Domino 製品のページを参照してください。
  
  
• developerWorks ブログを通して developerWorks コミュニティに参加できます。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• シングル・サインオンのシナリオ
• 即時停止のシナリオ
• 魅力的な新機能
• SSO の (少しだけ) 不思議な世界: まとめ
• 参考文献
• 著者について
• コメント