ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11gリリース2 (11.1.2.2) for All Platforms
B69533-09
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

52 Microsoft SharePoint ServerとAccess Managerの統合

この章では、Access Managerを10g WebGateおよびMicrosoft SharePoint Serverと統合する方法を説明します。次のトピックを取り扱います:


注意:

10g WebGateを使用するAccess Managerは、Microsoft SharePoint Server 2010とMicrosoft SharePoint Server 2013のどちらもサポートしています。それ以外のバージョンのMicrosoft SharePoint Serverは、このリリースではサポートされていません。

特に明記しないかぎり、この章のすべての詳細は、OAM偽装プラグインを使用したMicrosoft SharePoint ServerおよびLDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint ServerとのAccess Managerの統合に同様に適用されます。

52.1 このリリースのサポート内容

Access ManagerとSharePointとの統合のサポートによって、次の機能が可能になります。

  • Access Managerを使用したSSOログインの前にユーザーがSharePointにアクセスするとき、ユーザーにはAccess Manager SSOログイン資格証明を求めるプロンプトが表示されます。

  • 有効なAccess Managerログイン・セッションを持つユーザーがSharePointドキュメントにアクセスするとき、SharePointによって確立される必要があります(ログインしてSharePointで認証される)。Access Managerセッションが確立されると、SharePointによってLDAPメンバーシップ・プロバイダ、OAM WNAおよび偽装を使用したAccess ManagerとSharePointの統合も実行されます。認証ステータスに基づいて、SharePointは、SharePointに格納されているドキュメントへのアクセスを許可または拒否します。

  • ユーザーがブラウザを使用してOfficeドキュメントをSharePointから開くとき、SSOセッションはMS Officeプログラムに永続化し、MS Officeプログラムを介したドキュメントへのアクセスが維持されるようにする必要があります。「Officeドキュメントのためのシングル・サインオンの構成」を参照してください。

  • Access Manager 10gとのSharePointの統合によってすべての機能を備えたパリティが提供され、Access Managerへのアップグレードが容易になります。


注意:

11g WebGatesは、IIS Webサーバーではサポートされません。この統合では、WebGate 10g WebGate for IISのみが使用可能です。

52.2 SharePoint Serverとの統合の概要

SharePoint Serverは、Windows Server Microsoft Internet Information Services (IIS)およびWindows SharePoint Services (WSS)上に構築されたMicrosoft所有の安全でスケーラブルなエンタープライズ・ポータル・サーバーです。SharePoint Serverは、通常、Webコンテンツおよびドキュメント管理システムと関連付けられています。SharePoint Serverは、Microsoft IIS Webサーバーと連動して、コラボレーション、ファイル共有、Webデータベース、ソーシャル・ネットワークおよびWeb公開のためのサイトを生成します。WSS機能に加えて、SharePoint Serverは、追加の機能(ニュースとトピック、MySiteの個人ビューと公開ビューなど)を組み込んでいます。

Microsoft SharePoint Serverは、コンテンツ、ビジネス・プロセスおよび情報共有の制御を拡張します。Microsoft SharePoint Serverによって、ドキュメント、ファイル、Webコンテンツおよび電子メールの一元化されたアクセスおよび制御が提供され、コラボレーション作業のためのユーザーによるポータルへのファイルの送信が可能になります。

SharePointサーバー・ファームは、Webサイト、ポータル、イントラネット、エクストラネット、インターネット・サイト、Webコンテンツ管理システム、検索エンジン、Wiki、ブログ、ソーシャル・ネットワーク、ビジネス・インテリジェンス、ワークフローをホストでき、またWebアプリケーション開発用のフレームワークを提供します。

Microsoft SharePoint Serverと統合すると、Access Managerは、ISAPIフィルタおよびISAPIモジュールを介してユーザー認証を処理します。このことによって、Access ManagerとSharePoint Serverの間のシングル・サインオンが可能になります。

SharePoint Serverは、次の認証メソッドをサポートします。

  • フォーム・ベースの認証

  • 偽装ベースの認証

  • Windows認証: ユーザーに関する情報がActive Directoryサーバーに格納されている構成に対してのみ使用

この章の統合では、Microsoft SharePoint Serverリソースおよびその他すべてのAccess Managerによって保護されているリソースへのシングル・サインオンを提供します。詳細な情報は、次を参照してください:

52.2.1 Windowsの偽装について

特に明記しないかぎり、この章で説明する統合は、Windowsの偽装に依存します。

Windowsの偽装によって、Windowsサーバー・ドメインの信頼できるユーザーは、Microsoft SharePoint Serverのターゲット・リソースをリクエストする任意のユーザーのアイデンティティを持つことができます。この信頼できるインパーソネータは、ユーザーのアイデンティティ・コンテキストを維持し、ユーザーのかわりにリソースにアクセスします。

偽装は、ユーザーに対して透過的に行われます。アクセスは、SharePointリソースがアクセス・システム・ドメイン内のリソースであるかのように実行されます。


注意:

Windowsの偽装は、LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合時には使用されません。

52.2.2 この統合でのフォーム・ベースの認証について

3つの認証メソッドのいずれかを使用してAccess ManagerとSharePoint Serverを統合できます。LDAPサーバー(Sun Directory Serverとインスタンス用Active Directory)の一般的な使用の場合、統合に任意のLDAPサーバーを組み込めます。

SharePoint Serverのフォーム・ベースの認証は要求対応型です。ユーザーがSharePointのRelying Party (RP)の「Formsログイン」ページに資格証明を入力するとき、これらはSharePointのSecurity Token Service (STS)に渡されます。SharePoint STSは、そのメンバーシップ・プロバイダに対してユーザーを認証し、SharePoint RPに渡すSAMLトークンを生成します。SharePoint RPは、SAMLトークンを検証し、FedAuth Cookieを生成します。ユーザーは、SharePoint RPサイトへのアクセスを許可されます。

フォーム・ベースの認証では、WebGateはISAPIフィルタとして構成されます。SharePoint RPのフォーム・ログイン・ページは、ユーザーがSharePoint RPによって資格証明の入力を求められないようにカスタマイズされます。また、メンバーシップ・プロバイダは、WebGateによって設定されたObSSOCookieのみを検証してユーザーを認証するようにカスタマイズされます。


注意:

HTTP検証メソッド(OAMHttp検証メソッド)を使用するフォーム・ベース認証をサポートしているのは、WebGateのみです。ASDK検証メソッド(OAMAsdk検証メソッド)は、フォーム・ベース認証にはサポートされていません。

次の概要では、フォーム・ベースの認証を使用してこの統合の認証フローを説明します。

プロセス概要: フォーム・ベースの認証を使用したリクエスト処理

  1. ユーザー・リクエストはSharePoint Server RPサイトにアクセスします。

  2. サイトを保護するWebGateは、リクエストを捕捉し、リソースが保護されているかどうかを判定し、ユーザーに要求します。

  3. ユーザーはOAM資格証明を入力します。次にOAM WebGateサーバーはLDAPから資格証明を確認し、ユーザーを認証します。

    WebGateは、OAMネイティブSSO Cookie (ObSSOCookie)を生成します。これは、シングル・サインオンを可能にし、HTTPリクエストの(ユーザー名に対する)ユーザーIDヘッダー変数を設定し、ユーザーをSharePoint RPサイトにリダイレクトします。

  4. SharePoint RPのカスタム・ログイン・ページが呼び出され、これが、ユーザー名をヘッダー変数に渡されたユーザーIDに設定し、パスワードをObSSOCookie値に設定します。ログイン・ページもこれらの資格証明をSharePoint RPサイトに自動的に送信します。

  5. SharePoint RPサイトは、資格証明をSharePoint STSに渡し、これは、ユーザー資格証明の検証のためにカスタム・メンバーシップ・プロバイダを呼び出します。

  6. カスタム・メンバーシップ・プロバイダは、(パスワードとして渡された)ObSSOCookie値を取得し、HTTPリクエストの一部としてこれをWebGateによって保護されているリソースに送信し、ObSSOCookieを検証します。

  7. ObSSOCookieが有効な場合、SharePoint STSは、SAMLトークンを生成し、これをSharePoint RPに渡します。

  8. SharePoint RPは、SAMLトークンを検証し、FedAuth Cookieを生成します。ユーザーは、SharePoint RPサイトへのアクセスを許可されます。

52.2.3 Windowsの偽装およびSharePoint Serverの統合を使用した認証について

前記のとおり、Windowsの偽装によって、Windowsサーバー・ドメインの信頼できるユーザーは、SharePoint Portal Serverのターゲット・リソースをリクエストする任意のユーザーのアイデンティティを持つことができます。この信頼できるインパーソネータは、ユーザーのアイデンティティ・コンテキストを維持し、ユーザーのかわりにリソースにアクセスします。偽装は、ユーザーに対して透過的に行われます。アクセスは、SharePointリソースがOAMサーバー・ドメイン内のリソースであるかのように実行されます。WindowsベースのSharePoint 2010および2013との統合は、SharePoint 2007とのサポートされている統合と同じです。


注意:

SharePoint 2007の統合では、Access Manager ISAPIの拡張子(IISImpersonationExtension.dll)が使用されていました。SharePoint 2010においてイベント処理の内部アーキテクチャが変更されたため、Access ManagerのISAPI拡張子はHTTPモジュールに変更されました。

次の概要では、SharePoint ServerおよびWindowsの偽装を有効にした場合に認証処理フローを特定します。

プロセス概要: Windowsの偽装を使用した統合認証

  1. ユーザー・リクエストはSharePoint Portal Serverリソースにアクセスします。

  2. SharePoint Portal Serverを保護するWebGate ISAPIフィルタは、リクエストを捕捉し、ターゲット・リソースが保護されているかどうかを判定し、保護されている場合にはユーザーに認証資格証明を要求します。

  3. ユーザーが資格証明を提供し、OAMサーバーがこれを検証すると、WebGateはユーザーのブラウザにObSSOCookieを設定し、シングル・サインオンを有効にします。WebGateは、impersonateというHTTPヘッダー変数も設定します。この値は次のいずれかに設定されます。

    • 認証されるユーザーのLDAP uid

    • ユーザー・アカウントがActive Directoryに存在する場合、samaccountname

  4. Access Manager HTTPモジュールIISImpersonationModule.dllは、impersonateという認可成功アクション・ヘッダー変数があるかどうかを確認します。

  5. このヘッダー変数が存在する場合、Oracle ISAPIモジュールは、このユーザーに対するKerberosチケットを取得します。

    このService for User to Self (S4U2Self)偽装トークンを使用すると、指定された信頼できるユーザーは、リクエストしているユーザーのアイデンティティを持ち、IISおよびSharePoint Portal Serverを介してターゲット・リソースにアクセスできます。

52.2.4 Access ManagerとWindowsネイティブ認証について

Access Managerは、Windowsネイティブ認証(WNA)のサポートを提供します。環境には次のものが含まれます。

  • Windows 2008または2008 R2サーバー

  • Internet Information Services (IIS) 7または7.5

  • Active Directory

    たとえばユーザーのディレクトリ・サーバーにNTログオンIDがある場合、またはユーザー名がすべての場所で同じ場合、ユーザーは任意のディレクトリ・サーバーに対して認証できます。Windows Server 2008で最も一般的な認証メカニズムはKerberosです。

Access ManagerによるWNAの使用はシームレスです。ユーザーは、デスクトップにログインし、Internet Explorer (IE)ブラウザを開き、保護されているWebリソースをリクエストしてシングル・サインオンを完了するときに、通常の認証とWNAの違いに気付きません。

プロセスの概要: WNA認証の使用方法

  1. ユーザーがデスクトップ・コンピュータにログインすると、Windows Domain Administrator認証スキームを使用してローカル認証が完了します。

  2. ユーザーは、Internet Explorer (IE)ブラウザを開き、アクセス・システムで保護されたWebリソースをリクエストします。

  3. ブラウザは、ローカル認証をメモし、KerberosトークンをIIS Webサーバーに送信します。


    注意:

    Internet Explorerのインターネットおよび(または)イントラネットのセキュリティ・ゾーンが自動ログオンを許可するように適切に調整されていることを確認してください。

  4. IIS WebサーバーにインストールされているWebGateは、KerberosトークンをOAM 11gサーバーに送信します。OAM 11gサーバーは、KDC(キー配布センター)を使用してKerberosトークンをネゴシエーションします。

  5. Access Managerは、認証成功情報をWebGateに送信します。

  6. WebGateは、ObSSOCookieを作成し、それをブラウザに送信します。

  7. Access Managerの認可およびその他のプロセスは通常どおりに進められます。

    WebGateに対して構成されている最大セッション・タイムアウト期間が、生成されたObSSOCookieに適用されます。

52.3 統合の要件

特に明記しないかぎり、この項では、この章で説明する統合に必要なコンポーネントを紹介します。次のトピックが含まれます:

52.3.1 要件の確認

特定のバージョンおよびプラットフォームについて言及している場合、それらは例示のみの目的で記載されています。最新のAccess Manager証明書の情報は、Oracle Technology Networkにある動作保証マトリックスを参照してください:

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

52.3.2 必要なAccess Managerのコンポーネント

Access Managerは、アクセス機能およびセキュリティ機能(Webベースのシングル・サインオン、ポリシー管理、レポートと監査など)を提供します。Microsoft SharePoint Serverと統合すると、Access Managerは、ISAPIフィルタおよびISAPIモジュールを介してユーザー認証を処理し、2つの製品間のシングル・サインオンが可能になります。

表52-1のコンポーネントは、Microsoft SharePoint Server(またはLDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server)との統合に必要です。

表52-1 Access Managerのコンポーネントの要件

コンポーネント 説明

10g WebGate

ISAPIバージョン10g WebGateは、SharePoint Serverと同じコンピュータに存在する必要があります。

この統合のコンテキスト内では、このWebGateは、WebリソースのHTTPリクエストを捕捉し、これらをOAMサーバーに転送してリクエストをしたユーザーを認証するISAPIフィルタです。認証が成功すると、WebGateは、ObSSOCookieを作成し、これをユーザーのブラウザに送信するため、シングル・サインオンが容易になります。WebGateは、このユーザー・セッションのHeaderVarアクションとして偽装の設定も行います。

LDAPメンバーシップ・プロバイダのシナリオの場合: 「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合」を参照してください。

IISImpersonationModule.dll

このIISネイティブ・モジュールは、WebGateとともにインストールされます。IISImpersonationModule.dllモジュールは、認可成功アクションHeaderVarが偽装に設定されたかどうかを判定し、その場合には、このDLLファイルは、SharePoint Server Active Directoryの特別な信頼できるユーザーが元々リクエストをしたユーザーに偽装できるようにするKerberos S4U2Selfチケットを作成します。

WebGateのインストール後、IISImpersonationModule.dllを手動で構成し、偽装およびこの統合を有効にする必要があります。

LDAPメンバーシップ・プロバイダのシナリオの場合: IISImpersonationModule.dllを構成しないでください。

ディレクトリ・サーバー

Access Managerは、任意のサポートされているディレクトリ・サーバー(LDAPおよびActive Directoryを含むがこれらに限定されない)に接続できます。Access Managerは、SharePoint Serverによって使用されるActive Directoryの同じインスタンスにさえ接続できます。

いずれのケースでも、ディレクトリはSharePoint Serverおよび保護しているWebGateと同じマシン上である必要はありません。

OAMサーバー

この統合では、SharePoint Serverのインストールを保護しているWebGateが相互運用に構成されている相互運用相手のOAMサーバーのインストールも必要です。

SharePoint Serverを保護しているWebGate以外のコンポーネントをSharePoint Serverをホストしているマシンに配置する必要はありません。

「SharePoint Serverとの統合の準備」も参照してください。

52.3.3 必要なMicrosoftのコンポーネント

最小要件では、64ビット、4コアのプロセッサを指定しています。ただし、特定のバージョンおよびプラットフォームについて言及している場合、それらは例示のみの目的で記載されています。Access Managerの最新の動作確認情報は、Microsoft SharePoint Serverの次のMicrosoftライブラリの場所を参照してください。

https://technet.microsoft.com/en-us/library/cc262485.aspx

SharePointの多目的プラットフォームでは、イントラネット・ポータル、エクストラネットおよびWebサイトの管理およびプロビジョニング、ドキュメント管理とファイル管理、コラボレーション・スペース、ソーシャル・ネットワーク・ツール、エンタープライズ検索とインテリジェンス・ツール、プロセスと情報の統合、サードパーティが開発したソリューションが可能です。


注意:

最小要件では、64ビット、4コアのプロセッサを指定しています。ただし、特定のバージョンおよびプラットフォームについて言及している場合、それらは例示のみの目的で記載されています。Access Managerの最新の動作確認情報は、次のOracle Technology Networkを参照してください。 
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

表52-2に、この統合に必要なその他のコンポーネントを示します。


関連項目:

Microsoft SharePoint Serverの次のライブラリの場所および適用可能なソフトウェアへのアクセス。 
http://technet.microsoft.com/en-us/library/cc262485.aspx

表52-2 この統合のためのMicrosoftの要件

コンポーネント 説明

SharePointサイトのカスタム・ログイン・ページ

フォーム・ベースの認証を使用するように構成されたSharePointサイトにユーザーがアクセスしようとすると、ユーザーはログイン・ページにリダイレクトされ、そこで資格証明(ユーザー名およびパスワード)を入力します。カスタム・ログイン・ページは資格証明をSharePointサイトに渡します。

SharePointサイト

SharePointサーバーの全体管理アプリケーションを使用してSharePointサイトを作成します。このサイトは、http://technet.microsoft.com/en-us/library/ee806890.aspxで説明されている次のステップに従って、認証メソッドとしてフォーム・ベースの認証を使用するように構成されます。

SharePointサイトは、カスタム・メンバーシップ・プロバイダによるObSSOCookieの検証成功時にSAMLトークンを生成するSharePoint STSにユーザー資格証明を渡します。SharePointサイトは、SAMLトークンをSharePoint STSから受信したときにFedAuth Cookieも生成します。SharePointサイトは、FedAuth Cookieをユーザーに渡し、ユーザーがSharePointサイトにアクセスできるようにします。

SharePointセキュリティ・トークン・サービス(STS)

SharePointサイトは、ユーザー資格証明(ユーザー名とパスワード)をSharePoint STSに渡し、これは、カスタム・メンバーシップ・プロバイダを呼び出して、これに資格証明を渡します。カスタム・メンバーシップ・プロバイダがこれに渡されたObSSOCookieを検証すると、SharePoint STSは、SharePoint Relying Party (RP)に渡されたユーザーのためにSAMLトークンを生成します。

SharePoint STSのためのカスタム・メンバーシップ・プロバイダ

SharePoint STSは、(フォーム・ベースの認証によって構成された)メンバーシップ・プロバイダを呼び出します。STSは、ユーザー資格証明および(SharePointサイト上のweb.configで構成された)IISリソースのURLをCookie検証のためにカスタム・メンバーシップ・プロバイダに渡します。

メンバーシップ・プロバイダは、これに渡されたObSSOCookie値が有効な場合に成功を返すようにカスタマイズされます。

カスタム・メンバーシップ・プロバイダ・ライブラリ(OAMCustomMembershipProvider.dll)は、パッケージ化されIIS Webサーバーの10g WebGateを使用してインストールされます。SharePoint Serverホストのグローバル・アセンブリ・キャッシュにライブラリをデプロイする必要があります。

CustomMembershipProviderクラスは、Microsoft.Office.Server.SecurityネームスペースにあるLdapMembershipProviderクラスから派生します。

Cookie検証のIISリソース

SharePointサイトのweb.configファイルでIISリソースのURLを構成します。

HTTP検証メソッドの場合、WebGateは、カスタム・メンバーシップ・プロバイダによって送信されたリクエストを捕捉し、リクエストからObSSOCookieを抽出してこれを検証します。Cookieが有効な場合、リクエストはIISリソースにリダイレクトされ、これが200 (OK)のステータス・コードを含むレスポンスをカスタム・メンバーシップ・プロバイダに返します。そうでない場合は、403(禁止)エラー・コードがカスタム・メンバーシップ・プロバイダに返されます。

52.4 SharePoint Serverとの統合の準備

次の手順のタスクは、この章で説明するすべての統合シナリオで必要です。

Microsoftコンポーネントをインストールしてテストした後、ここに示すステップを実行して統合のためにAccess Managerをインストールします。このタスクは、この章の両方の統合シナリオに適用されます。重複を避けるために、ここで示す情報は、他の場所では繰り返しません。

ISAPI 10g WebGateは、SharePoint Serverと同じコンピュータにインストールする必要があります。この統合の他のコンポーネントは、WebGateと同じホストまたはデプロイメント(Solaris、LinuxまたはWindowsプラットフォーム)の他のコンピュータに配置できます。異なるホストをActive Directoryまたは他のディレクトリ・サービスに設定できます。Access ManagerとSharePoint Serverの両方がActive Directoryの異なるインスタンスに設定される場合、両方のインスタンスは、同じActive Directoryドメインに属する必要があります。


関連項目:

10g WebGateのインストールの詳細は、第25章を参照してください。

前提条件

「必要なMicrosoftのコンポーネント」に記載されているMicrosoftのコンポーネントをインストールしてテストします。

SharePoint Serverとの統合の準備を行います。

  1. 『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の説明に従って、Oracle Identity ManagementおよびAccess Managerをインストールします。

  2. IIS Webサーバーの10g WebGateをAccess Managerに登録します。

    1. Oracle Access Managementコンソールにログインします。例: http://host:port/oamconsole。

    2. 「ようこそ」ページのSSOエージェント・パネルから、「新規OAM 10gエージェント」をクリックして新規ページを開きます。

    3. 「OAMエージェントの作成」ページで、必要な詳細(*が付いている項目)を入力します。


      「名前」
      SharePoint user name and password
      「セキュリティ・モード」(エージェント・ホストはOAMサーバーと一致する必要があります)
      「ポリシーの自動作成」(チェック)

      注意:

      ベースURLを指定しないでください。

    4. 保護されているリソース・リスト: この表では、このOAMエージェントで保護する個々のリソースのURLを入力します。

    5. パブリック・リソース・リスト: この表では、公開する(保護しない)個々のリソースのURLを入力します。

    6. 「適用」をクリックして登録を送信し、「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。

  3. 次のように進めます:

  4. 次のように、64ビットISAPI WebGateのインストーラを探してダウンロードします。

    1. 次のOracle Fusion Middleware 11gR1ソフトウェア・ダウンロードに移動します。

      https://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html

    2. ページの一番上のライセンス契約に同意をクリックします。

    3. Access Manager Webgates (10.1.4.3.0)の行から、該当するプラットフォームのダウンロード・リンクをクリックし、画面の指示に従います。

    4. インストールする10g (10.1.4.3)アクセス・システムの言語パックと同じディレクトリにWebGateインストーラを格納します。

  5. 使用プラットフォーム、インストール・モードおよびWebサーバー用のWebGateインストーラを起動します。10g WebGateのインストールの詳細は、第25章を参照してください。

    次の手順に従います。

    1. 画面に表示されるプロンプトに従います。

    2. Webサーバーの管理者資格証明を指定します。

    3. 言語パック - デフォルトのロケールとインストールするその他のロケールを選択して、「次へ」をクリックします。

    4. WebGateのインストールが始まります(IISImpersonationModule.dllはWebgate_install_dir\access\Oblix\apps\Webgate\bin\にインストールされます)。

  6. Webサーバー構成を更新する前に、WebGateアーティファクトをAdmin ServerからWebGateをホストしているコンピュータにコピーします。

    1. Oracle Access Managementコンソール(AdminServer)をホストしているコンピュータでObAccessClient.xml(およびすべての証明書アーティファクト)を探してコピーします。

      $DOMAIN_HOME/output/$Agent_Name/


      ObAccessClient.xml
      password.xml(必要に応じて)
      aaa_key.pem (openSSLによって生成される秘密鍵)
      aaa_cert.pem (PEMフォーマットの署名済証明書)

    2. OAMエージェントのホストで、アーティファクトをWebGateパスに追加します。例:


      WebGate_install_dir/access/oblix/lib/ObAccessClient.xml
      WebGate_install_dir/access/oblix/config

    3. WebGate Webサーバーを再起動します。

    4. (オプション。)このエージェントをホストするOAMサーバーを再起動します。この手順は推奨されますが、必須ではありません。

  7. 必要に応じて次に進み、使用中の環境内でこの統合を完了します。

52.5 Microsoft SharePoint Serverとの統合

次の概要では、この統合のために実行する必要があるタスクと、手順および詳細に関する項目について説明します。

カスタム・メンバーシップ・プロバイダ・ライブラリ(OAMCustomMembershipProvider.dll)は、パッケージ化されIIS Web Serverの10g WebGateを使用してインストールされます。次に説明するように、SharePoint Serverをホストするコンピュータのグローバル・アセンブリ・キャッシュにライブラリをデプロイする必要があります。

タスクの概要: Microsoft SharePoint Serverとの統合には次の項目が含まれます

  1. 前提条件となるタスクの実行

  2. SharePoint Serverでの新規Webアプリケーション(またはサイト・アプリケーション)の作成は、次のトピックで説明します。

  3. 「Microsoft Windowsの偽装の設定」(LDAPメンバーシップ・プロバイダには使用しません)。

  4. 「SharePoint Serverの統合の完了」。

  5. 「Microsoft SharePoint Serverのためのシングル・サインオフの構成」

  6. 「ディレクトリ間のユーザー・プロファイルの同期化」

  7. 「統合のテスト」

52.5.1 Microsoft SharePoint Serverでの新規Webアプリケーションの作成

Microsoft SharePoint Serverとの統合時に、LDAPメンバーシップ・プロバイダを使用してまたは使用せずにこのタスクを実行します。

前提条件

Microsoftのコンポーネントのインストール。「必要なMicrosoftのコンポーネント」を参照してください。

Microsoft SharePoint Serverで新規Webアプリケーションを作成する手順

  1. SharePoint Serverがインストールされているホストで、「集中管理」ホーム・ページを開きます: 「起動」、「すべてのプログラム」、SharePoint製品、SharePoint、「集中管理」。

  2. 「集中管理」ホーム・ページから、アプリケーション管理をクリックします。

  3. アプリケーション管理ページの「Webアプリケーション」から、「Webアプリケーションの管理」をクリックします。

  4. 左上隅で、「新規作成」ボタンをクリックして新規Webアプリケーションを作成します。

  5. 「新規Webアプリケーションの作成」ページで表52-3の項目を構成します。

    表52-3 Microsoft SharePoint Serverの「Webアプリケーションの作成: {0}」オプション

    セクション この項で構成するもの

    認証

    この項では、要求ベースの認証またはクラシック・モード認証のどちらか該当する方を選択します。

    IIS Webサイト

    この項では、次のように、新規Webアプリケーションに対して次の設定を構成します。

    • 既存のWebサイトを選択するには、「既存のWebサイトを使用する」をクリックします。

    • 新規のサイトを作成するには、「作成」をクリックします。

    • ポート・フィールドで、Webアプリケーションへのアクセスに使用するポート番号を入力します。

      新規Webサイトの場合、このフィールドにはデフォルトのポート番号が入っています。既存のサイトの場合、このフィールドには現在構成されているポート番号が入っています。

    • オプションのホスト・ヘッダー・フィールドに、WebアプリケーションにアクセスするためのURLを入力します。

    • 「パス」フィールドに、サーバー上のサイトを含むディレクトリへのパスを入力します。

      新規Webサイトの場合、このフィールドにはデフォルトのパスが入っています。既存のサイトの場合、このフィールドには現在のパスが入っています。

    セキュリティ構成

    この項では、次のように、使用中のWebアプリケーションに対して認証と暗号化を構成します。

    • 「認証プロバイダ」セクションで、適宜、「ネゴシエート(Kerberos)」または「NTLM」を選択します。

    • 「匿名を許可」セクションで、「はい」または「いいえ」を選択します。

      値が「はい」の場合、コンピュータ固有の匿名アクセス・アカウントを使用して、Webサイトへの匿名アクセスが許可されます。アカウント名はIUSR_コンピュータ名です。

    • 「Secure Sockets Layer」(SSL)セクションで、「はい」または「いいえ」を選択します。

      Webサイトに対してSSLを有効にすることを選択すると、証明書をリクエストしてインストールすることによってSSLを構成する必要があります。

    パブリックURL

    このWebアプリケーションでユーザーがアクセスするすべてのサイトのドメイン名のURLを入力します。このURLドメインは、Webアプリケーションのページに表示されるすべてのリンクで使用されます。デフォルトでは、このボックスには現在のサーバー名およびポートが移入されます。「ゾーン」フィールドは、新規Webアプリケーションのデフォルトに自動的に設定され、このページからは変更できません。

    アプリケーション・プール

    「アプリケーション・プール」セクションでは、次のように、このWebアプリケーションに対して既存のアプリケーション・プールを使用するか新規アプリケーション・プールを作成するかを選択します。

    • 既存のアプリケーション・プールを使用するには、「既存のアプリケーション・プールを使用」を選択し、ドロップダウン・メニューから使用するアプリケーション・プールを選択します。

    • 新規アプリケーション・プールを作成するには、「新規アプリケーション・プールの作成」を選択し、アプリケーション・プール名フィールドに、新規アプリケーション・プールの名前を入力するか、デフォルト名のままにします。

      「このアプリケーション・プール用のセキュリティ・アカウントを選択する」セクションで、「事前定義」を選択して既存のアプリケーション・プールのセキュリティ・アカウントを使用し、ドロップダウン・メニューからセキュリティ・アカウントを選択します。既存のアプリケーション・プールに現在使用されていないセキュリティ・アカウントを使用するには、構成可能を選択し、使用するアカウントのユーザー名を「ユーザー名」フィールドに入力し、そのアカウントのパスワードを「パスワード」フィールドに入力します。

    データベース名および認証

    この項では、新規Webアプリケーションに対してデータベース・サーバー、データベース名および認証メソッドを選択します。

    「データベース名」フィールドに、データベースの名前を入力するか、デフォルト・エントリを使用します。データベース認証フィールドで、次のように、Windows認証(推奨)を使用するかSQL認証を使用するかを選択します。

    • Windows認証を使用する場合、このオプションを選択したままにします。

    • SQL認証を使用する場合、SQL認証を選択します。「アカウント」フィールドに、SQL Serverデータベースに対して認証するためにWebアプリケーションが使用するアカウント名を入力し、「パスワード」フィールドにパスワードを入力します。

    フェイルオーバー・サーバー

    オプションで、フェイルオーバー・データベース・サーバーを指定してフェイルオーバー・サーバーを構成することを選択できます。

    サービス・アプリケーション接続

    デフォルト値を使用するか、カスタム値を選択できます。また、オプションで、Webアプリケーションが接続するサービスを選択できます。

  6. 「OK」をクリックして新規Webアプリケーションを作成するか、「取消」をクリックしてプロセスを取り消し、アプリケーション管理ページに戻ります。

  7. 「Microsoft SharePoint Serverのための新規サイト・コレクションの作成」に進みます。

52.5.2 Microsoft SharePoint Serverのための新規サイト・コレクションの作成

Microsoft SharePoint Serverとの統合時に、LDAPメンバーシップ・プロバイダを使用してまたは使用せずにこのタスクを実行します。

Microsoft SharePoint Serverのために新規サイト・コレクションを作成するには:

  1. アプリケーション管理ページのサイト・コレクション・セクションから、「サイト・コレクションの作成」をクリックします。

  2. 「サイト・コレクションの作成」ページの「Webアプリケーション」セクションで、次のように、サイト・コレクションをホストするWebアプリケーションを(「Webアプリケーション」ドロップダウン・リストから)選択するか、新規Webアプリケーションを作成してサイト・コレクションをホストします。

    表52-4 SharePoint Serverのサイト・コレクションをホストするWebアプリケーションの作成

    セクション この項で構成するもの

    割当て制限テンプレート

    適宜、事前定義済の割当てテンプレートを使用してこのサイト・コレクション用に使用するリソースを制限するか、「割当てなし」を使用できます。

    タイトルと説明

    サイト・コレクションのタイトルと説明の入力

    Webサイト・アドレス

    URLタイプを選択し、サイト・コレクションのURLを指定します。

    テンプレート

    タブ付きテンプレート制御からテンプレートを選択します。

    プライマリ・サイト・コレクション管理者

    サイト・コレクションのプライマリ管理者にするユーザーのユーザー・アカウント名を入力します。

    テキスト・ボックスの右にある「ブック」アイコンをクリックしてユーザー・アカウントを参照することも可能です。テキスト・ボックスの右にある「名前の確認」アイコンをクリックしてユーザー・アカウントを確認できます。

    セカンダリ・サイト・コレクション管理者(オプション)

    サイト・コレクションのセカンダリ管理者にするユーザーのユーザー・アカウントを入力します。

    テキスト・ボックスの右にある「ブック」アイコンをクリックしてユーザー・アカウントを参照することも可能です。テキスト・ボックスの右にある「名前の確認」アイコンをクリックしてユーザー・アカウントを確認できます。

  3. この統合を終了したら次のトピックを参照してください。

52.6 Microsoft Windowsの偽装の設定

Active Directory以外のディレクトリ・サーバーを使用する場合、LDAPメンバーシップ・プロバイダを使用してください。OAMCustomMembershipプロバイダは、LDAPメンバーシップ・プロバイダの機能を利用します。

この項では、SharePoint Serverの統合または他のアプリケーションによる使用のための偽装の設定について説明します。


注意:

LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverと統合している場合、この項をスキップしてください。Windowsの偽装はLDAPメンバーシップ・プロバイダでは使用されません。

タスクの概要: 偽装の設定

  1. 「信頼できるユーザー・アカウントの作成」の説明に従って、SharePoint Serverに接続されたActive Directoryでの偽装に対してのみ信頼できるユーザー・アカウントを作成します。

  2. 「信頼できるユーザーへの権限の割当て」の説明に従って、オペレーティング・システムの一部として機能する特別な権限を信頼できるユーザーに与えます。

  3. 「信頼できるユーザーのWebGateへのバインド」の説明に従って、信頼できるユーザーの認証資格証明を提供して、信頼できるユーザーをWebGateにバインドします。

  4. 「偽装レスポンスの認可ポリシーへの追加」の説明に従って、アプリケーション・ドメインで偽装のための認可成功アクションにIMPERSONATEという名前のヘッダー変数を追加します。

  5. 「偽装dllのIISへの追加」の説明に従って、IISImpersonationModule.dllをIIS構成に追加して、IISを構成します。

  6. 「偽装のテスト」の説明に従って、偽装をテストします。

52.6.1 信頼できるユーザー・アカウントの作成

この特別なユーザーは、偽装以外には使用しないでください。

次の手順例では、Impersonatorを新規オブジェクト - ユーザーとして使用します。環境はユーザーによって異なります。

信頼できるユーザー・アカウントを作成するには:

  1. SharePoint Serverインストールをホストしているコンピュータで次のステップを実行します。

    • Windows 2008: 「スタート」→「プログラム」→「管理ツール」→「Active Directoryユーザーとコンピュータ」の順に選択します。

  2. 「Active Directoryユーザーとコンピュータ」ウィンドウで、左ペインのツリーで「ユーザー」を右クリックし、「新規作成」→「ユーザー」の順に選択します。

  3. 「新規オブジェクト - ユーザー」というペインの1つ目の「名前」フィールドに、覚えやすい名前(Impersonatorなど)を入力します。

  4. この同じ文字列を「ユーザー ログオン名」フィールドにコピーし、「次へ」をクリックします。

  5. 次のパネルで、パスワードの選択と確認用の再入力を求められます。


注意:

信頼できるユーザーには、非常に強力な権限が付与されるため、非常に複雑なパスワードを選択することをお薦めします。また、「パスワードの有効期限なし」ボックスがマークされていることも確認してください。偽装モジュールは、信頼できるユーザー・アカウントを表示できる唯一のエンティティであるため、外部のエージェンシがパスワードの期限切れを発見することは非常に困難です。

図52-1 Windowsの偽装のための信頼できるユーザー・アカウントの設定

信頼できるユーザー・アカウントの設定

52.6.2 信頼できるユーザーへの権限の割当て

オペレーティング・システムの一部として機能する権限を信頼できるユーザーに与える必要があります。

信頼できるユーザーに適切な権限を与えるには:

  1. 使用中の環境で次のステップを実行します。

    • Windows 2008: 「スタート」→「プログラム」→「管理ツール」→「ローカル セキュリティ ポリシー」の順に選択します。

  2. 左ペインのツリーで、「ローカル ポリシー」の横のプラス・アイコン(+)をクリックします。

  3. 左ペインのツリーで「ユーザー権利の割り当て」をクリックします。

  4. 右ペインで「オペレーティング システムの一部として機能」をダブルクリックします。

  5. 「ユーザーまたはグループの追加」をクリックします。

  6. 「ユーザーまたはグループの追加」パネルで、信頼できるユーザーのユーザー・ログオン名(この例ではSPPSImpersonator)をユーザー名とグループ名のテキスト入力ボックスに入力し、「OK」をクリックして変更を登録します。

図52-2 Windowsの偽装での信頼できるユーザーの権限の構成

信頼できるユーザーの権限の構成

52.6.3 信頼できるユーザーのWebGateへのバインド

次のように、信頼できるユーザーの認証資格証明を提供することによって、Access Managerと通信する10g WebGateに信頼できるユーザーをバインドする必要があります。

次の手順では、10g WebGateをAccess Managerにまだ登録していないことを前提としています。次の手順の値は、例としてのみ提供されます。環境はユーザーによって異なります。


関連項目:

10g WebGateの管理の詳細は、第25章を参照してください。

信頼できるユーザーをWebGateにバインドする手順

  1. Oracle Access Managementコンソールに移動します。

    例:

    http://hostname:port/oamconsole

    ここで、hostnameはOracle Access Managementコンソールをホストしているコンピュータの完全修飾DNS名、portはOAMサーバー用に構成されたリスニング・ポート、oamconsoleはOracle Access Managementコンソールです。

  2. 「ようこそ」ページのSSOエージェント・パネルから、「新規OAM 10gエージェント」をクリックして新規ページを開きます。

  3. 「OAMエージェントの作成」ページで、必要な詳細(*の付いたもの)を入力して、このWebGateを登録します

  4. 保護されているリソース・リスト: この表では、表14-9にあるように、このOAMエージェントで保護する個々のリソースのURLを入力します。

  5. パブリック・リソース・リスト: この表では、表14-9にあるように、公開する(保護しない)個々のリソースのURLを入力します。

  6. 「ポリシーの自動作成」: 新規ポリシーの作成をチェックします(または、クリアして別のWebGateと同じホスト識別子を使用してポリシーを共有します(表14-9))。

  7. 「適用」をクリックして、登録を送信します。

  8. 「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。

  9. ナビゲーション・ツリーで、「エージェント」ページを開きます。

  10. SharePoint要件: ここに表示されるフィールドに信頼できるユーザーの資格証明を追加し、「適用」をクリックします。

    Webgate登録でのSharePointユーザー資格証明

  11. 次のようにアーティファクトをコピーします(またはWebGateをインストールしてからこれらのアーティファクトをコピーします)。

    1. Oracle Access Managementコンソールのホストで、更新されたOAMエージェントの構成ファイルObAccessClient.xml(およびすべての証明書アーティファクト)を検索します。例:

      $DOMAIN_HOME/output/$Agent_Name/ObAccessClient.xml

    2. エージェントをホストしているコンピュータで、アーティファクトをコピーします。次に例を示します。


      10g WebGate/AccessClient: $WebGate_install_dir/oblix/lib/
      ObAccessClient.xml

    3. 「偽装レスポンスの認可ポリシーへの追加」に進みます。

52.6.4 偽装レスポンスの認可ポリシーへの追加

SharePointリソースを保護するアプリケーション・ドメインおよび基本ポリシーは、WebGateをAccess Managerに登録したときに作成されました。ここで、ヘッダーの戻りタイプを含む認可成功アクション(レスポンス)を追加し、この名前をIMPERSONATEに設定し、レスポンス値を$user.useridにします。


関連項目:

第20章: アプリケーション・ドメインおよびポリシーの詳細

偽装レスポンスを認可ポリシーに追加するには:

  1. Oracle Access Managementコンソールの「ポリシー構成」タブで、「アプリケーション・ドメイン」を開き、DesiredDomainを見つけて開いてから、DesiredPolicyを開きます。

    「既存のアプリケーション・ドメインの検索」を参照してください。

    ここで、DesiredDomainは、偽装専用に作成されたアプリケーション・ドメイン(Impersonationなど)を表します。DesiredPolicyは、エージェント登録中に作成されたデフォルトのポリシーです。デフォルトでは、ユーザーが作成するまでポリシー・レスポンスは存在しません。

  2. レスポンス: 「ポリシーを開く」ページで、「レスポンス」タブをクリックし、「追加」(+)ボタンをクリックします。

    • 「タイプ」リストから「ヘッダー」を選択します。

    • 「名前」フィールドに、このレスポンスの一意の名前を入力します: IMPERSONATE

    • 「値」フィールドに、このレスポンスの値を入力します。例: $user.userid。

    • 関連項目: 「SSOのポリシー・レスポンスの追加および管理」。

  3. 「追加」をクリックして、レスポンスを保存します。これは、2つ目のWebGateリクエスト(認可用)に使用されます。次に例を示します。

    認可成功ルールのサンプル。

52.6.5 偽装DLLのIISへの追加

この統合のためにIIS Webサーバーを構成する準備ができました。そのためには、すべてのサイト(中央管理およびWebサービスを含む)でIISImpersonationModule.dllを登録して構成します。

または、複数のWebサイトがあり、その一部がAccess Managerに統合されていて、残りが統合されていない場合、Access Managerに統合されてしるWebサイトに対してのみ偽装を有効にする必要があります。そのためには、統合が必要なサイトのみでネイティブ・モジュールを構成する必要があります。関連項目:

IISに対してImpersonationModuleを構成して登録するには:

  1. 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順に選択します。

  2. IIS 7の左ペインで、ホスト名をクリックします。

  3. 中央ペインのIISヘッダーで、「モジュール」をダブルクリックします。

  4. 右ペインで「ネイティブ モジュールを構成」をクリックして「登録」をクリックします。

  5. ウィンドウに、モジュール名(たとえば、Oracle偽装モジュール)を入力します。

  6. 「パス」フィールドに、IISImpersonationModule.dllへのフルパスを入力します。

    デフォルトでは、パスは次のとおりです。

    WebGate_install_dir\access\oblix\apps\Webgate\bin\IISImpersonation

    ここで、WebGate_install_dirはWebGateインストールのディレクトリです。


    注意:

    パスにスペースが存在する場合(たとえば、
    C:\Program Files\Oracle\...)文字列全体を二重引用符(" ")で囲みます。

  7. 「OK」をクリックして、モジュールを登録します。

  8. 新しく作成したモジュールの名前を確認し、「OK」をクリックして、各Webサイトにモジュールを適用します。

図52-3 偽装モジュールの登録

IISセキュリティ設定のグラフィック

Webサイトに対してサイト・レベルのネイティブ・モジュールを構成するには:

  1. サイトの左にあるプラス・アイコン(+)をクリックします。

  2. 偽装を有効にするサイトをクリックします。

  3. 中央ペインのIISで、「モジュール」をダブルクリックします。

  4. 右ペインで「ネイティブ モジュールを構成」をクリックして、前に登録した偽装モジュールを選択します。

  5. 「OK」をクリックします。

    site_level_imprsn.pngについては周囲のテキストで説明しています。

  6. 次に進みます。

52.6.6 偽装のテスト

統合を完了する前に、次の方法で偽装が正しく機能していることをテストできます。


関連項目:

偽装の構成が正しく機能することを確認した場合、「SharePoint Server統合の完了」

52.6.6.1 SharePoint Serverによって保護されていないIIS仮想サイトの作成

SharePoint Server外の偽装機能をテストするまたはシングル・サインオンをテストするには、SharePoint Serverによって保護されていないIIS仮想Webサイト上にターゲットWebページが必要です。このような仮想Webサイトは、次のタスクを実行して作成します。

SharePoint Serverによって保護されていないIIS仮想サイトを作成するには:

  1. 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順に選択します。

  2. 左側のペインにあるツリー上のローカル・コンピュータのアイコンの左のプラス・アイコン(+)をクリックします。

  3. 左ペインにあるツリー上のWebサイトを右クリックして、メニューの「新規作成」、「Webサイト」に移動します。

  4. 「Webサイト作成」ウィザードでプロンプトに応答します。

  5. 仮想サイトを作成した後、これをアプリケーション・ドメインのポリシーで保護する必要があります。アプリケーション・ドメインおよびポリシーの詳細は、第20章を参照してください。

52.6.6.2 イベント・ビューアを使用した偽装のテスト

Windows 2003イベント・ビューアを使用して偽装のテストを実行する場合、実際のテストを実行する前にイベント・ビューアを構成する必要があります。

イベント・ビューアを使用して偽装をテストするには:

  1. 「スタート」メニュー→「イベント ビューア」に順に選択します。

  2. 左ペインで、「セキュリティ」を右クリックし、「プロパティ」をクリックします。

  3. 「セキュリティのプロパティ」シートで「フィルタ」タブをクリックします。

  4. すべての「イベントの種類」にチェックが付いていることおよび「イベント ソース」と「分類」の各リストが「すべて」に設定されていることを確認し、「OK」をクリックして「プロパティ」シートを閉じます。

    イベント・ビューアは、リソース・リクエストに関連付けられたHeaderVarに関する情報が表示されるように構成されました。

    図52-4 イベント・ビューアの設定の確認

    イベント・ビューアの設定の確認のグラフィック

  5. 新規IIS仮想サーバー(仮想サイト)を作成します。

  6. 仮想サイト上のツリーのどこかにターゲットWebページを配置します。

  7. Webページでブラウザを指します。

偽装が正しく機能している場合、イベント・ビューアがアクセス試行の成功を報告します。

52.6.6.3 Webページを使用した偽装のテスト

リクエストに関する情報を返し、表示できる.aspページやPerlスクリプトなどの動的テスト・ページを使用して偽装をテストすることも可能です。

サーバー変数を表示するWebページを使用して偽装をテストするには:

  1. パラメータAUTH_USERおよびIMPERSONATEを表示する.aspページまたはPerlスクリプトを作成します。これは、次のリストに示すサンプル・ページに似せることができます。

    例52-1 サンプルの.ASPページ・コード

    <TABLE border=1>
       <TR>
             <TD>Variable</TD>
             <TD>&nbsp&nbsp</TD>
             <TD>Value</TD></TR>
       <%for each servervar in request.servervariables%>
       <TR>
             <TD><%=servervar%></TD>   
             <TD>&nbsp&nbsp</TD>
             <TD><%=request.servervariables(servervar)%>&nbsp</TD>
       </TR>

  2. IIS仮想サイトを作成するかまたは前のタスクで作成したものを使用します。

  3. 新規仮想サイトのツリーのどこかに.aspページまたはPerlスクリプト(前のリストのサンプルなど)を配置します。

  4. ブラウザで表示するページを指定し、要求を発行するユーザーの名前にAUTH_USERとIMPERSONATEの両方を設定します。

52.6.6.4 偽装のネガティブ・テスト

偽装のネガティブ・テストを実行するには、次の手順で説明するように、信頼できるユーザーをWebGateからバインド解除します。

信頼できるユーザーをWebGateからアンバインドするには:

  1. Oracle Access Managementコンソールで、WebGateを探します。

    「OAMエージェント登録の検索」を参照してください。

  2. 必要なWebGate登録ページを開いて、信頼できるユーザーの資格証明を削除します。

  3. 「適用」をクリックして変更を保存します。

  4. ブラウザ・ウィンドウでIISサーバーを再起動し、保護されているコード・ページ(信頼できるユーザーが以前アクセスできたページ)に移動します。

  5. ページが表示されるというメッセージを受信することを確認します。AUTH_USERとIMPERSONATEの値は、偽装資格証明をWebGateにバインドするために必要です。

  6. 信頼できるユーザーをWebGate登録ページにリストアします。

52.7 SharePoint Serverの統合の完了

Access ManagerとSharePoint Serverとの統合を設定するためには、複数の手順を実行する必要があります。


注意:

LDAPメンバーシップ・プロバイダを使用して構成されたSharePoint Serverと統合している場合、この項をスキップしてください。

タスクの概要: SharePoint Serverの統合の完了

  1. 「IISセキュリティの構成」の説明に従って、IISセキュリティを設定します。

  2. 「SharePoint Serverの統合のテスト」の説明に従って、統合をテストします。

52.7.1 IISセキュリティの構成

続行する前にIISセキュリティを構成します。

SharePoint Serverの統合のためにIISセキュリティを構成するには:

  1. 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順に選択します。

  2. 左側のペインにあるツリー上のローカル・コンピュータのアイコンの左のプラス・アイコン(+)をクリックします。

  3. 左ペインのツリーで「Webサイト」をクリックします。

  4. 中央ペインで、IISの下の「認証」をダブルクリックします。

  5. 「匿名アクセス」が有効になっていて、「Windows認証」が無効になっていることを確認します。

図52-5 偽装認証

IISセキュリティ構成のグラフィック

52.8 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合

このシナリオでは、Access Managerは、SharePoint Security Token Service (STS)を使用してSharePoint Serverと統合されます。これには、IISへのISAPI WebGateインストール、Access Managerの構成およびHeaderVarの統合を実現するために必要な手順が含まれます。


注意:

この統合には、64ビットISAPI WebGateのみがサポートされます。

次の概要では、この統合のために実行する必要があるタスク(前提条件を含む)と、各タスクに必要な情報がある場所について説明します。

「タスクの概要: LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合」

  1. この統合の準備

    1. 説明に従って、「必要なMicrosoftのコンポーネント」をインストールします。

    2. 「Microsoft SharePoint Serverでの新規Webアプリケーションの作成」の説明に従って、SharePoint Webサイトを作成します。

    3. 「Microsoft SharePoint Serverのための新規サイト・コレクションの作成」の説明に従って、SharePointサイト・コレクションを構成します。

    4. SharePointのドキュメントの説明に従って、要求ベースの認証タイプ(LDAPメンバーシップ・プロバイダを使用)を使用して、作成したWebサイトをLDAPディレクトリに対して構成します。

    5. LDAPディレクトリに存在するユーザーがSharePoint Webサイトにログインして適切なロールを取得できることを確認します。

    6. SharePointのドキュメントの説明に従って、構成をテストして、LDAPディレクトリに存在するユーザーがSharePoint Webサイトにログインして適切なロールを取得できることを確認します。

  2. 「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint ServerのためのAccess Managerのインストール」の説明に従って、すべてのタスクを実行します。

    このタスクには、IIS対応10g WebGateのインストールと個別のSharePoint WebサイトのためのWebGate.dllの構成が含まれます。

  3. 「LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成」の説明に従って、この統合の認証スキームを追加します。

  4. 「SharePoint Webサイトを保護するアプリケーション・ドメインの更新」の説明に従って、SharePoint Webサイトを保護するアプリケーション・ドメインを更新します。

  5. 「ヘッダー変数SP_SSO_UIDのための認可レスポンスの作成」の説明に従って、新規アプリケーション・ドメインで、この統合の認可ルールを作成します。

  6. 「OAMAuthCookieのための認可レスポンスの作成」のすべてのステップを実行します。

  7. 「OAMCustomMembershipProviderの構成およびデプロイ」のすべての手順を実行します。

  8. 「ディレクトリ・サーバーが同期化されていることの確認」の説明に従って、必要に応じてディレクトリ・サーバーを同期化します。

  9. 「Officeドキュメントのためのシングル・サインオンの構成」の説明に従って、Officeドキュメントのシングル・サインオンを構成します。

  10. 「Microsoft SharePoint Serverのためのシングル・サインオフの構成」の説明に従って、シングル・サインオフを構成します。

  11. 「統合のテスト」の説明に従って、統合をテストしてこれが問題なく機能することを確認して終了します。

52.8.1 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合について

前のシナリオ「Microsoft SharePoint Serverとの統合」では、Windows認証の使用方法を説明しています。そのシナリオでは、認証および認可は、Active Directoryに存在するユーザーに対して実行されます。Access Managerは、統合のためにWindowsの偽装を使用しました。

この項で説明する統合の場合、LDAPメンバーシップ・プロバイダのサポートは、HeaderVarベースの統合によって実現されます。ISAPI WebGateフィルタは、WebリソースのHTTPリクエストを捕捉し、OAMサーバーと連動して、リクエストをしたユーザーを認証します。認証が成功すると、WebGateは、ObSSOCookieを作成し、これをユーザーのブラウザに送信して、シングル・サインオン(SSO)を容易にします。WebGateは、このユーザー・セッションのHeaderVarアクションとしてSP_SSO_UIDの設定も行います。SharePointのOracleカスタム・メンバーシップ・プロバイダは、HTTP検証メソッドを使用してObSSOCookieを検証します。これにより、Access Managerのカスタム・メンバーシップ・プロバイダは、HTTP/HTTPSリクエストを保護されたリソースに対して実行します。次にAccess Managerは、SP_SSO_UIDを設定した認可の成功で返されたユーザー・ログインを検証し比較します。


関連項目:

この章で説明する、この統合と他の統合の処理の違いについては、「SharePoint Serverとの統合の概要」を参照してください。

要件: この統合では、Microsoft SharePoint Serverに次の要件があります。

  • LDAPメンバーシップ・プロバイダと統合されている必要があり、Windows認証を使用することは許可されない

  • 要求ベースの認証を使用してWebサイトで構成したIISImpersonationModule.dllを持つことは許可されない


関連項目:

「統合の要件」

52.8.2 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint ServerのためのAccess Managerのインストール

この手順は、LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverと統合するためのインストールの準備方法を説明します。

前提条件

前の「タスクの概要: LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合」のステップ1を実行します。

LDAPメンバーシップ・プロバイダを含む統合のデプロイメントを準備するには:

  1. 『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の説明に従って、Oracle Identity ManagementおよびAccess Managerをインストールします。

  2. 第25章および第28章の手順を使用してISAPI WebGateをプロビジョニングおよびインストールします。

  3. 保護の対象となるSharePoint WebサイトでWebgate.dllを構成します。例:

    1. インターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

    2. 「Webサイト」で、保護するSharePoint Webサイトの名前をダブルクリックします。

    3. 中央ペインで、「ISAPIフィルタ」をダブルクリックし、右ペインで「追加」をクリックします。

    4. フィルタ名をOracle WebGateと入力します。

    5. Webgate.dllファイルに次のパスを入力します。

      WebGate_install_dir/access/oblix/apps/Webgate/bin/Webgate.dll

    6. これらの変更を保存して適用します。

    7. 中央ペインで、「認証」をダブルクリックします。

    8. Internet Information Services設定が正しいことを確認します。匿名認証とフォーム認証が有効になっており、Windows認証が無効になっている必要があります。


      注意:

      要求ベースの認証をAccess Managerで使用する場合、SharePointサイトのWindows認証を無効にする必要があります。

    9. これらの変更を保存して適用します。

  4. 保護するWebサイト・レベルに移動し、新しくインストールしたWebGate_install_dirを指す/accessアプリケーションを作成します。次に例を示します。

    1. 「Webサイト」で、保護するWebサイトの名前を右クリックします。

    2. 該当のWebGate_install_dir\accessを指す別名「access」という名前を使用して「アプリケーションの追加」を選択します。

    3. アクセス許可で、「読取り」、「起動スクリプト」および「実行」をチェックします。

    4. これらの変更を保存して適用します。

  5. 「LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成」に進みます。

52.8.3 LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成

統合にLDAPメンバーシップ・プロバイダが含まれる場合、この手順で説明するように、3つのAccess Manager認証メソッドのみがサポートされます。


関連項目:

第19章: 認証スキームの管理の詳細

LDAPメンバーシップ・プロバイダを使用したSharePointのための認証スキームを構成するには:

  1. Oracle Access Managementコンソールの「ポリシー構成」タブから、「共有コンポーネント」ノードを開きます。

  2. 「認証スキーム」ノードをクリックし、ツール・バーの「作成」ボタンをクリックします。

  3. 「認証スキーム」ページで、次の項目を入力します。

    「名前」: このスキームの一意の名前を入力します。例: SharePoint w/LDAP-MP

    「説明」: オプション

  4. 「認証レベル」: スキームのセキュリティのレベルを選択します。

  5. 「チャレンジ・メソッド」を選択します。

    SharePoint Webサイトのルート(/)に対する基本認証

    SharePoint Webサイトのルート(/)に対する「チャレンジ・リダイレクト」を使用したフォーム認証

    SharePoint Webサイトのルート(/)に対するクライアント資格証明認証

  6. 「チャレンジ・リダイレクト」: 必要に応じて、チャレンジ・リダイレクト値を入力します。

  7. リストの中から「認証モジュール」を選択します。

  8. 「チャレンジ・パラメータ」: 必要に応じて、チャレンジ・パラメータ値を入力します。

  9. 「チャレンジURL」: 資格証明コレクションのために資格証明コレクタがリダイレクトするURL。

  10. 「適用」をクリックして新しいスキームを送信し、「確認」ウィンドウで詳細を確認します。

  11. オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、「確認」ウィンドウを閉じます。

  12. ナビゲーション・ツリーで、新しいスキームがリストされていることを確認し、ページを閉じます。

  13. 「SharePoint Webサイトを保護するアプリケーション・ドメインの更新」に進みます。


    注意:

    SharePointリソースがAccess Managerのクライアント資格証明認証スキームで保護されている場合、PATH環境変数にC:\Program Files\Microsoft Office Servers\14.0\Bin;C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BINを追加する必要がある場合があります。

52.8.4 SharePoint Webサイトを保護するアプリケーション・ドメインの更新

このアプリケーション・ドメインは、IIS WebGateをプロビジョニングして、LDAPメンバーシップ・プロバイダを使用した統合シナリオでMicrosoft SharePoint Server Webサイトを保護するときに作成されました。

アプリケーション・ドメイン内で、リソース定義はオブジェクトのフラットな集合として存在します。各リソースは、特定のタイプおよびサーバーに格納されて多くのユーザーがアクセスできるドキュメントまたはエンティティを識別するURL接頭辞として定義されます。既存の共有ホスト識別子を使用して、場所を指定します。


注意:

この統合では、URL接頭辞を空のままにします。URL接頭辞に追加するリージョンを入力しないでください。

以前に作成した認証スキームを使用する必要があります。ObSSOCookieを検証するには、WebGateによって保護されているリソースに別のポリシーを作成する必要があります。例: /ValidateCookie。このリソースをWebGateによって保護されているWebサーバーにデプロイし、正しいAccess Manager資格証明を提供した後にアクセスできる必要があります(http(s)://host:port/ValidateCookie)

この例では、アプリケーション・ドメイン名としてSharePoint w/LDAP-MPを使用しています。環境はユーザーによって異なります。


注意:

手順4には、フォーム認証スキームを使用してSharePoint Webサイトを保護する代替認証スキームが含まれています。


関連項目:

第20章: リソースを保護するポリシーの管理の詳細

ルートのSharePoint Webサイトを保護するアプリケーション・ドメインを更新するには

  1. Oracle Access Managementコンソールから、SharePoint w/LDAP-MPアプリケーション・ドメインを開きます。

    「既存のアプリケーション・ドメインの検索」を参照してください。

  2. 「リソース」タブを開いて、「新規リソース」ボタンをクリックします。

  3. 「リソース」の「定義」ページで、1つのリソースの詳細を入力して、「適用」をクリックします。


    タイプ: http
    説明(オプション): SharePoint Webサイトの保護
    ホスト識別子: 前に追加したホスト識別子を選択します。
    リソースURL: /ValidateCookieと入力します。
    保護レベル: 保護
    認証ポリシー(レベルが「保護」の場合)
    認可ポリシー(レベルが「保護」で、「認証ポリシー」が選択されている場合)

  4. 「認証ポリシー」の「保護されたリソース・ポリシー」に、定義済リソースを追加します。

    「認証ポリシーの表示または編集」を参照してください。

    • 認証ポリシー・ページの「リソース」タブをクリックします。

    • 「リソース」タブの「追加」ボタンをクリックします。

    • 目的のリソース定義を見つけて選択してから、「選択済の追加」をクリックします。

    • 「適用」をクリックして、リソースを追加します。

    • これを繰り返して、さらにリソースを追加します。

  5. 「レスポンス」タブをクリックして、「追加」ボタンをクリックします。

    • 「名前」フィールドに、このレスポンスの一意の名前を入力します(SP_SSO_UID)。

    • 「タイプ」リストから「ヘッダー」を選択します。

    • 「値」フィールドに、このレスポンスの値を入力します。例: $user.userid。

    • 「適用」をクリックします。

    • 関連項目: 「SSOのポリシー・レスポンスの追加および管理」。

    ユーザー偽装の認可レスポンス

  6. ポリシーの追加: 選択した場合、HTTP検証メソッドに使用するリソースのポリシーを追加します。

  7. このアプリケーション・ドメインを有効にする前に、「ヘッダー変数SP_SSO_UIDのための認可レスポンスの作成」に進みます。

52.8.5 ヘッダー変数SP_SSO_UIDのための認可レスポンスの作成

このトピックは、LDAPメンバーシップ・プロバイダを使用して構成された統合に関する認可レスポンスを追加する方法を説明します。この統合では、次のヘッダー変数を認可成功のレスポンスとしてアプリケーション・ドメインに追加します。

  Type = Header
        Name = SP_SSO_UID
        Return Attribute = $user.userid

この場合、次のようになります。

  • 戻り属性は、ログインに使用されるログイン属性です。

  • この認可ルールは、ルートのSharePoint Webサイト「/」を保護します。


関連項目:

第20章: 認可ルールの詳細

LDAPメンバーシップ・プロバイダを使用したSharePointに対して認可レスポンスを作成するには:

  1. Oracle Access Managementコンソールから、SharePoint w/LDAP-MP認可ポリシー(ProtectedResourcePolicy)を開きます。

    「認可ポリシーの検索」を参照してください。

  2. 「認可ポリシー」の「レスポンス」タブをクリックしてアクティブ化し、「追加」ボタンをクリックします。

    • 「名前」フィールドに、このレスポンスの一意の名前を入力します(SharePoint w/LDAP-MP).。

    • 「タイプ」リストから「ヘッダー」を選択します。

    • 「値」フィールドに、このレスポンスの値を入力します。例: $user.userid。

    • 「適用」をクリックします。

    • 必要に応じて繰り返します。

    • 関連項目: 「SSOのポリシー・レスポンスの追加および管理」。

  3. 「OAMAuthCookieのための認可レスポンスの作成」に進みます。

52.8.6 OAMAuthCookieのための認可レスポンスの作成

ここでは、次のOAMAuthCookieという名前のヘッダー変数を認可成功のレスポンスとしてアプリケーション・ドメインに追加します。

  Type = Cookie
        Name = OAMAuthCookie
        Return Attribute = $user.userid

関連項目:

第20章: ポリシー・レスポンスの詳細

検証URLを保護するためのアプリケーション・ドメインを作成するには

  1. Oracle Access Managementコンソールから、SharePoint w/LDAP-MPアプリケーション・ドメインを開きます。「認可ポリシー」: 保護されたリソース・ポリシー:

    「認可ポリシーの検索」を参照してください。

  2. 「レスポンス」タブをクリックして、「追加」ボタンをクリックします。

    「リダイレクションURL」: この統合では不要です。

    戻り値

      Type = Cookie
        Name = OAMAuthCookie
        Return Attribute = $user.userid

    • 「名前」フィールドに、このレスポンスの一意の名前を入力します(OAMAuthCookie)。

    • 「タイプ」リストから「Cookie」を選択します。

    • 「値」フィールドに、このレスポンスの値を入力します。例: $user.userid。

    • 「適用」をクリックしてレスポンスを送信し、「確認」ウィンドウを閉じます。

    • 必要に応じて繰り返します。

  3. 「OAMCustomMembershipProviderの構成およびデプロイ」に進みます。

52.8.7 OAMCustomMembershipProviderの構成およびデプロイ

SharePointで次の構成ステップを実行し、Access Manager認証モジュールを使用してユーザーを認証して認可します。


注意:

次のファイルにバンドルされているデフォルト・ログイン・ページを指定することもできます。

WebGate_install_dir\access\oblix\apps\Webgate\ OAMCustomMembershipProvider\samples\Sample.Default.aspx

SharePointを構成してOAM認証モジュールを使用するには:

  1. SharePoint Webサイト・ディレクトリの物理的な場所に移動します。例:

    C:\Inetpub\wwwroot\wss\VirtualDirectories\SharePoint website Name

  2. folder_formsから、ファイルDefault.aspxをDefault.ORIG.aspxとしてコピーします。

  3. Default.aspxを開き、</asp:login>を探し、その行の後に次のコードを追加して、ファイルを保存します。

    <asp:HiddenField EnableViewState="false" ID="loginTracker" runat="server" Value="autoLogin" />

 <%bool autoLogin = loginTracker.Value == "autoLogin";%>

 <script runat="server">
    void Page_Load() 
    {

        signInControl.LoginError += new EventHandler(OnLoginError);
        NameValueCollection headers = Request.ServerVariables;
        NameValueCollection queryString = Request.QueryString;
        string loginasanotheruser = queryString.Get("loginasanotheruser");
        string username = Request.ServerVariables.Get("HTTP_SP_SSO_UID");
        HttpCookie ObSSOCookie = Request.Cookies["ObSSOCookie"];
        bool isOAMCredsPresent = username != null && username.Length > 0  && ObSSOCookie != null && ObSSOCookie.Value != null;
        bool signInAsDifferentUser = loginasanotheruser != null && loginasanotheruser.Contains("true");

        if (isOAMCredsPresent)
        {

            //Handling For UTF-8 Encoding in HeaderName
            if (username.StartsWith("=?UTF-8?B?") && username.EndsWith("?="))
            {
                username = username.Substring("=?UTF-8?B?".Length, username.Length - 12);
                byte[] decodedBytes = Convert.FromBase64String(username);
                username = Encoding.UTF8.GetString(decodedBytes);
            }
        }
       if (isOAMCredsPresent  && loginTracker.Value == "autoLogin" && !signInAsDifferentUser)
        {
           bool status=Microsoft.SharePoint.IdentityModel.SPClaimsUtility.AuthenticateFormsUser(new Uri(SPContext.Current.Site.Url),username,"ObSSOCookie:"+ObSSOCookie.Value);
        if(status){
                if (Context.Request.QueryString.Keys.Count > 1)
                {
                    Response.Redirect(Context.Request.QueryString["Source"].ToString());
                }
                else
                    Response.Redirect(Context.Request.QueryString["ReturnUrl"].ToString());
      }
         else{
                  loginTracker.Value = 
          }

        }
        else
        {

            // DO NOTHING
        }
    }
        void OnLoginError(object sender, EventArgs e)
    {
                  loginTracker.Value = "";
    }
 </script>

  4. IISマネージャに移動し、サイトの前のプラス・アイコン(+)をクリックします。

  5. SharePoint Webサービスの前のプラス・アイコン(+)をクリックします。

  6. 「SecurityTokenServiceApplication」を右クリックし、「エクスプローラ」をクリックします。

  7. Web.configのバックアップ・コピーをWeb.config.ORIGとして作成し、Web.configを開きます。

  8. メンバーシップ・プロバイダ・エントリで、LDAPメンバーシップ・プロバイダを有効にするには、<membership>、<providers>、タイプに移動し、タイプ値を次のように変更します。

    type = "Oracle.CustomMembershipProvider, OAMCustomMembershipProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=52e6b93f6f0427a1

  9. 手順8のエントリの最後に、次の属性(ObSSOCookie検証メソッドを示すValidationMode="OAMHttp")を追加します。

    <add name="membership" 
             type = "Oracle.CustomMembershipProvider, OAMCustomMembershipProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=52e6b93f6f0427a1"                                       
                     server="HOST1.COM"
             port="389" 
             useSSL="false" 
             userDNAttribute="distinguishedName"
             userNameAttribute="sAMAccountName"
             userContainer="cn=users,dc=bored,dc=com"
             userObjectClass="person" 
             userFilter="(&amp;(ObjectClass=person))" 
             scope="Subtree" 
             otherRequiredUserAttributes="sn,givenname,cn" 
                         ValidationURL="http(s)://host:port/ValidateCookie.html"
             OAMAuthUser="OAMAuthCookie
             ValidationMode="OAMHttp"
                         />

    注意:

    ValidationURLのために構成するリソースは、Webサーバー上に存在する必要があります。また、OAMAuthUserパラメータの値は、ステップ6の説明に従って、認可戻りアクションとして構成する必要があります。

  10. ファイルを保存します。

  11. コマンド・プロンプトを使用して、次のディレクトリに移動します。

    C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil.exe

  12. 次のように入力します。

    gacutil -l OAMCustomMembershipProvider

  13. 結果が戻されないことを確認します。

  14. 次のように入力します。

    gacutil -i <Webgate_install_dir>\access\oblix\apps\Webgate\OAMCustomMembershipProvider\OAMCustomMembershipProvider.dll

  15. 次のように入力します。

    gacutil -l OAMCustomMembershipProvider

  16. 1つの結果が戻されることを確認します。

  17. SharePoint Webサイトを再起動します。

  18. 次のように進めます:

52.8.8 CustomMemberShipProviderのロギングの有効化

Oracleカスタム・メンバーシップ・プロバイダのログを有効にする場合、Oracleカスタム・メンバーシップ・プロバイダの構成ファイルのDebugFileパラメータを構成する必要があります。たとえば、DebugFile=Location_of_logs_file"のサンプル・エントリは次のようになります。

type = "Oracle.CustomMembershipProvider, OAMCustomMembershipProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=52e6b93f6f0427a1" DebugFile="c:\Debug.txt"

52.8.9 ディレクトリ・サーバーが同期化されていることの確認

Access Managerに対して構成されているディレクトリ・サーバーのユーザーは、SharePointによって使用されるディレクトリ・サーバーと同期している必要があります(これらが異なる場合)。これは、この章の他の統合シナリオで実行したタスクと同じです。ただし、SharePointの統合にLDAPメンバーシップ・プロバイダが含まれている場合、LDAPコマンドをサポートするディレクトリ・サーバーを使用できます。


関連項目:

「ディレクトリ間のユーザー・プロファイルの同期化」

52.8.10 統合のテスト

これは、この章の他の統合シナリオで実行したタスクと似ています。LDAPメンバーシップ・プロバイダを使用して構成した場合、違いはありません。


関連項目:

「SharePoint Serverの統合のテスト」

52.9 Officeドキュメントのためのシングル・サインオンの構成

Officeドキュメントのためのシングル・サインオンは、認証スキームで永続Cookieを設定することによって実現できます。このためには、認証スキームでssoCookie:max-ageを設定する必要があります。こうすることによって、複数セッション継続する永続Cookieが作成されます。


注意:

Windowsネイティブ認証に基づく統合の場合には、永続Cookieパラメータを設定する必要はありません。

Officeドキュメントのためのシングル・サインオンに永続Cookieを定義するには:

  1. Oracle Access Managementコンソールにログインします。

  2. 使用する「認証スキーム」を探し、ページを開きます。

  3. 「チャレンジ・パラメータ」で、次を追加します。

      ssoCookie:max-age=1000000   (Table 19-30)

    ここで、time-in-secondsは、Cookieが期限切れになるまでの時間間隔を表します。たとえば、ssoCookie:max-age=3600の設定では、Cookieは1時間(3600秒)で期限切れになります。

  4. 変更内容を保存します。

  5. 第25章の説明に従って、10g WebGateの集中管理ログアウトを構成します。

52.10 Microsoft SharePoint Serverのためのシングル・サインオフの構成

ユーザーがSharePoint Serverから「ログアウト」ボタンをクリックすると、手動ログアウトされます。ユーザーがSharePoint Serverサイトから「ログアウト」ボタンをクリックしたときにAccess Managerのログアウトもトリガーされるように、Access ManagerでSharePoint ServerのログアウトURLを構成することも可能です。


注意:

安全にために、常に、サインオフした後にブラウザ・ウィンドウを閉じることをお薦めします。

ユーザー・セッション全体がObSSOCookieによって制御されると、Cookieタイムアウトが発生します。次のユースケースについて考えてみます。

  • FedAuth Cookieがタイムアウトになり、ObSSOCookieが依然として有効: ObSSOCookieが存在するため、ユーザーはチャレンジされません。新規FedAuth Cookieが生成されます(以前説明した同じフローを使用)。

  • ObSSOCookieがタイムアウトになり、FedAuth Cookieが依然として有効: 各リクエストがWebGateによって捕捉されるため、ユーザーは再び資格証明を求められます。

Access Managerは、ユーザー・セッションに単一のログアウト(グローバル・ログアウトまたは集中管理ログアウトとも呼ばれる)を提供します。Access Managerでは、単一のログアウトはアクティブなユーザー・セッションを終了するプロセスを意味します。

このトピックは、SharePointとの統合に関してシングル・サインオフを構成する方法を説明します。シングル・サインオフは、ユーザー・セッションを削除します。


関連項目:

第22章: OAM 11gサーバーを使用した10g WebGateの集中管理ログアウトの構成の詳細

52.10.1 SharePoint Serverでのカスタム・ログアウトURLの構成

SharePoint Serverでカスタム・ログアウトURLを構成するには:

  1. WebGateのために生成されたアーティファクトから、logout.htmlをSharePoint Serverサイトに追加します。

  2. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATESを探します。

  3. \CONTROLTEMPLATESで、次のタグを追加してwelcome.ascxを変更します。例:

    <SharePoint:MenuItemTemplate runat="server" id="ID_OverrideLogout" Text="Custom Logout"       
          ClientOnClickNavigateUrl="/logout.html?end_url=_layouts/SignOut.aspx"
     Description="My Custom Logout"
   MenuGroupId="200"
   Sequence="100"
   UseShortId="true" />

  4. 「保存」をクリックします。

  5. 匿名認証を使用して、アプリケーション・ドメインの2つのURL(/_layouts/SignOut.aspxと/_layouts/closeConnection.aspx)を保護します。

  6. 「偽装を使用したSharePoint Serverでのログアウトの構成」に進みます。

52.10.2 偽装を使用したSharePoint Serverでのログアウトの構成

偽装を構成していない場合、この手順をスキップできます。

偽装を使用してSharePoint Serverでログアウトを構成するには:

  1. signout.aspxをC:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTSから同じパスのMySignout.aspxにコピーします。

  2. MySignout.aspxの(<asp:content contentplaceholderid="PlaceHolderAdditionalPageHead" runat="server">)の下に、次のスクリプト詳細を追加します。

    <script runat="server">       
private void Page_Load(object sender, System.EventArgs e){
 Response.Status = "302 Moved Temporarily";
 Response.AddHeader("Location", "/logout.html?end_url=/_layouts/SignOut.aspx");}
</script>

  3. 保存します。

  4. 偽装の場合、このURL _layouts/Mysignout.aspxをSharePoint Serverのカスタム・ログアウトURLとして使用します。

  5. 「統合のテスト」に進みます。

52.11 Access ManagerとWindowsネイティブ認証の設定

この項では次のトピックを記載しています:

52.11.1 Access Manager WNAの設定

第50章の説明に従って、Windowsネイティブ認証を使用するようにAccess Managerを構成します。

52.11.2 SharePoint Serverを使用したWNAの設定

次の概要では、Access ManagerおよびSharePoint Serverを使用してWNAを設定するために実行する必要があるタスクを説明します。

タスクの概要: SharePoint Serverを使用したWNAの設定

  1. 次の前提条件となるタスクを実行します。

  2. 「WNAおよびSharePoint ServerのためのAccess Managerのインストール」の説明に従って、Access Managerをインストールします。

    この手順には、IIS対応WebGateのインストールと個別のSharePoint WebサイトのためのWebgate.dllの構成が含まれます。

  3. 次のようにActive Directory認証プロバイダを構成します。

    1. WebLogicコンソールにログインします。

    2. 「セキュリティ・レルム」に移動し、使用する「レルム」をクリックします。

    3. 「プロバイダ」タブに移動し、「新規」をクリックします。

    4. プロバイダ名を入力し、タイプActiveDirectoryAuthenticatorを選択して「OK」をクリックします。

    5. 新しく作成したプロバイダを選択し、「制御フラグ」を「十分」に変更して、保存します。

    6. 「プロバイダ固有」タブに移動し、Active Directoryの詳細を入力して、これらを保存します。

  4. 「WNA実装のテスト」を実行します。

52.11.3 WNAおよびSharePoint ServerのためのAccess Managerのインストール

「タスクの概要: SharePoint Serverを使用したWNAの設定」のステップ1で説明しているすべての前提条件を実行した後、このタスクを実行します。この統合シナリオでほとんどのAccess Managerコンポーネントをインストールすることは、他のシチュエーションの場合と同じです。

IIS WebGateのインストールは、他の任意のWebGateのインストールと似ています。WebGateは、IIS v7 Webサーバーを使用してインストールする必要があります。後で、これを特定のSharePoint Webサイト・レベルで構成して保護できます。IISの場合、WebGateを「Webサイト」レベルで構成する必要があります。Microsoft SharePoint Serverの場合、WebGateを特定のSharePoint Webサイト・レベルで構成して保護する必要があります。

WNAおよびSharePoint ServerのためにAccess Managerをインストールするには:

  1. 『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の説明に従って、Oracle Access Management Access Managerをインストールします。

  2. 次のために、第25章の手順に従ってISAPI WebGateをインストールします。

    • WebGateのインストール

    • IIS WebサーバーのためのWebコンポーネントのインストール

      次に、保護の対象となるSharePoint WebサイトでWebgate.dllを構成します。Webgate.dllを「Webサイト・レベル」で構成すると、IIS Webサーバー上のすべてのWebサイトが保護されます。しかし、Webgate.dllを「SharePoint Webサイト」で構成すると想定されるWebサイトのみが保護されます。

  3. 保護の対象となるSharePoint WebサイトでWebgate.dllを構成します。例:

    1. インターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「プログラム」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

    2. 「Connections」ペインでhostnameを選択します。

    3. host nameの「Home」ペインで「ISAPI Filters」をダブルクリックし、Webgate.dllを検索します。存在する場合は選択して、「Action」ペインの「Remove」をクリックします。

    4. 「Connection」ペインの「Sites」の下で、WebGateフィルタを構成するWebサイト名をクリックします。

    5. 「Home」ペインで「ISAPI Filters」をダブルクリックします。

    6. 「Actions」ペインで「Add…」をクリックします。

    7. 「Add ISAPI Filter」ダイアログ・ボックスの「Filter name」テキスト・ボックスに、ISAPIフィルタの名前としてWebGateと入力します。

    8. 「Executable」ボックスにWebGate ISAPIフィルタ・ファイルのファイル・システム・パスを入力するか、省略記号ボタン(...)をクリックしてWebGate.dll ISAPIフィルタ・ファイルを含むフォルダに移動し、「OK」をクリックします。

      WebGate_install_dir\access\oblix\apps\Webgate\bin\Webgate.dll

  4. 仮想ディレクトリの作成

    1. 「Sites」ペインを開き、ISAPIフィルタ(Webgate.dll)を構成したばかりのWebサイトを選択します。

    2. 「Action」ペインで「View Virtual Directories」をクリックし、「Add Virtual Directory」を選択します。

    3. 「Alias」フィールドにaccessを指定し、WebGateの\accessフォルダの物理パスを指定します(または、省略ボタン(...)をクリックして\accessフォルダに移動して、「OK」をクリックします)。

      WebGate_install_dir\access\

  5. 仮想ディレクトリの権限の設定:

    1. 手順3で作成したaccess仮想ディレクトリを選択します。

    2. accessの「Home」ペインで「Handler Mappings」をダブルクリックします。「Action」ペインで「Edit Feature Permissions…」を選択します。

    3. 「読取り」、「スクリプト」、「実行」を選択し、「OK」をクリックします。

  6. 第50章の説明に従って、Windowsネイティブ認証を使用するようにAccess Managerを構成します。

  7. Microsoft SharePointで新規Webアプリケーションを作成するときに、Microsoft SharePoint Server認証をクラシック・モード認証に構成します。「認証プロバイダ」セクションで、ネゴシエート(Kerberos)を選択します。

  8. IISで新しく作成したSharePointサイトに移動します。

    1. 「認証」、Windows認証、詳細設定の順に開きます。

    2. 「Kernelモード認証を有効にする」を選択します。

    3. プロバイダを選択して、NTLMプロバイダを削除します。

    4. ネゴシエート:Kerberosを追加し、これを上位レベルに移動します。

    5. IISを再起動します。

  9. 「WNA実装のテスト」に進みます。

52.11.4 WNA実装のテスト

次のステップを使用して、WNA実装が正しく動作していることを確認します。

WNA実装をテストするには:

  1. Access ManagerとWindowsオペレーティング・システムの両方のユーザーである人物としてマシンにログインします。

  2. 保護されたリソースのURLを入力します。

52.12 ディレクトリ間のユーザー・プロファイルの同期化

特に明記しないかぎり、このタスクは、この章のすべての統合シナリオで実行する必要があります。


注意:

統合にLDAPメンバーシップ・プロバイダが含まれている場合、LDAPコマンドをサポートする任意のディレクトリ・サーバーを使用できます。

SharePoint ServerのディレクトリとAccess Managerのディレクトリの間でユーザー・プロファイルを同期化する必要があります。

  • ユーザー・データのアップロード: Access ManagerのインストールがSharePoint Active Directory以外の任意のディレクトリ・サーバーに対して構成されている場合、他のディレクトリ・サーバーにあるユーザー・プロファイルをSharePoint Active Directoryにロードする必要があります。

    「統合のテスト」に進みます。

52.13 統合のテスト

タスクを完了して統合を有効にした後、テストして統合が動作していることを確認する必要があります。

この項には次のトピックが含まれます:

52.13.1 SharePoint Serverの統合のテスト

Access Managerの認証とSharePoint Serverの認可を使用してSharePoint Serverのリソースにユーザーがアクセスできることを確認できます。

SharePoint Serverの統合をテストするには:

  1. ブラウザを使用して、任意のSharePoint Server Webページに移動します。

    資格証明を求められます。

  2. 必要な資格証明を提供してログインします。

  3. リクエストしたページを表示できることを確認します。

  4. オプション: イベント・ビューアを確認して、アクセス・リクエストが成功したことを確認します。

52.13.2 SharePoint Serverの統合のためのシングル・サインオンのテスト

資格証明を提供し、SharePoint Serverリソースにアクセスしたユーザーが(ObSSOCookieが期限切れになる前に)再び資格証明を提供せずに非SharePoint Serverリソースにアクセスできることを示してシングル・サインオンをテストすることもできます。たとえば、Policy Managerで定義したリソースを使用します。

シングル・サインオンが動作している場合、再び資格証明を提供する必要なく、ページへのアクセスが付与されます。

SharePoint Serverの統合のためにシングル・サインオンをテストするには:

  1. アプリケーション・ドメインを使用して新規仮想サイトを作成して保護します(または、すでに作成したものを使用します)。

  2. この仮想サイトのツリーのどこかにWebページを配置します。

  3. ブラウザを使用して、新規仮想サイトのページに移動します。

    すでに認証をパスしている場合、再び資格証明を提供する必要なく、ページへのアクセスが付与されます。

52.14 トラブルシューティング

52.14.1 Internet ExplorerがSSL経由によるファイルのダウンロードを実行できない

この問題は、サーバーがCache-control:no-storeヘッダーまたはCache-control:no-cacheヘッダーを送信している場合に発生します。WebGateは、構成パラメータを提供して、これらのヘッダーの設定を制御します。次に、パラメータとそのデフォルト値を示します。

CachePragmaHeader no-cache

CacheControlHeader no-cache

WebGate構成を変更して、これらのヘッダーをまったく設定しないようにできます(これらのパラメータの値は空白のままになります)。こうすることによって、Access Managerはキャッシング動作を制御しなくなります。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引