41 Microsoft SharePoint ServerとAccess Managerの統合
この章では、Access Managerを11g WebGateおよびMicrosoft SharePoint Serverと統合する方法を説明します。内容は次のとおりです。
ノート:
11g WebGateを使用するAccess Managerは、Microsoft SharePoint Server 2010とMicrosoft SharePoint Server 2013のどちらもサポートしています。その他のバージョンのMicrosoft SharePoint Serverは、このリリースではサポートされていません。
特に明記しないかぎり、この章のすべての詳細は、OAM偽装プラグインを使用したMicrosoft SharePoint ServerおよびLDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint ServerとのAccess Managerの統合に同様に適用されます。
41.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ドキュメントのためのシングル・サインオンの構成」を参照してください。
41.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によって保護されているリソースへのシングル・サインオンを提供します。詳細は、次を参照してください。
41.2.1 Windowsの偽装について
この信頼できるインパーソネータは、ユーザーのアイデンティティ・コンテキストを維持し、ユーザーのかわりにリソースにアクセスします。
偽装は、ユーザーに対して透過的に行われます。アクセスは、SharePointリソースがアクセス・システム・ドメイン内のリソースであるかのように実行されます。
ノート:
Windowsの偽装は、LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合時には使用されません。
41.2.2 この統合でのフォーム・ベースの認証
フォーム・ベースの認証では、WebGateはISAPIフィルタとして構成されます。SharePoint RPのフォーム・ログイン・ページは、ユーザーがSharePoint RPによって資格証明の入力を求められないようにカスタマイズされます。また、メンバーシップ・プロバイダは、WebGateによって設定されたOAMAuthnCookieのみを検証してユーザーを認証するようにもカスタマイズされます。
次の概要では、フォーム・ベースの認証を使用してこの統合の認証フローを説明します。
プロセス概要: フォーム・ベースの認証を使用したリクエスト処理
-
ユーザー・リクエストはSharePoint Server RPサイトにアクセスします。
-
サイトを保護するWebGateは、リクエストを捕捉し、リソースが保護されているかどうかを判定し、ユーザーに要求します。
-
ユーザーはOAM資格証明を入力します。次にOAM WebGateサーバーはLDAPから資格証明を確認し、ユーザーを認証します。
WebGateは、OAMネイティブSSO Cookie (OAMAuthnCookie)を生成します。これは、シングル・サインオンを可能にし、HTTPリクエストの(ユーザー名に対する)ユーザーIDヘッダー変数を設定し、ユーザーをSharePoint RPサイトにリダイレクトします。
-
SharePoint RPのカスタム・ログイン・ページが呼び出され、これが、ユーザー名をヘッダー変数に渡されたユーザーIDに設定し、パスワードをOAMAuthnCookie値に設定します。ログイン・ページもこれらの資格証明をSharePoint RPサイトに自動的に送信します。
-
SharePoint RPサイトは、資格証明をSharePoint STSに渡し、これは、ユーザー資格証明の検証のためにカスタム・メンバーシップ・プロバイダを呼び出します。
-
カスタム・メンバーシップ・プロバイダは、OAMAuthnCookie値(パスワードとして渡された値)を取得し、HTTPリクエストの一部としてこれをWebGateによって保護されているリソースに送信してOAMAuthnCookieを検証します。
-
OAMAuthnCookieが有効な場合、SharePoint STSは、SAMLトークンを生成し、これをSharePoint RPに渡します。
-
SharePoint RPは、SAMLトークンを検証し、FedAuth Cookieを生成します。ユーザーは、SharePoint RPサイトへのアクセスを許可されます。
41.2.3 Windowsの偽装およびSharePoint Serverの統合を使用した認証
次の概要では、SharePoint ServerおよびWindowsの偽装を有効にした場合に認証処理フローを特定します。
プロセス概要: Windowsの偽装を使用した統合認証
-
ユーザー・リクエストはSharePoint Portal Serverリソースにアクセスします。
-
SharePoint Portal Serverを保護するWebGate ISAPIフィルタは、リクエストを捕捉し、ターゲット・リソースが保護されているかどうかを判定し、保護されている場合にはユーザーに認証資格証明を要求します。
-
ユーザーが資格証明を提供し、OAMサーバーがこれを検証すると、WebGateはユーザーのブラウザにOAMAuthnCookieを設定し、シングル・サインオンを有効にします。WebGateは、impersonateというHTTPヘッダー変数も設定します。この値は次のいずれかに設定されます。
-
認証されるユーザーのLDAP
uid
-
ユーザー・アカウントがActive Directoryに存在する場合、
samaccountname
-
-
Access Manager HTTPモジュール
IISImpersonationModule.dll
は、impersonate
という認可成功アクション・ヘッダー変数があるかどうかを確認します。 -
このヘッダー変数が存在する場合、Oracle ISAPIモジュールは、このユーザーに対するKerberosチケットを取得します。
このService for User to Self (S4U2Self)偽装トークンを使用すると、指定された信頼できるユーザーは、リクエストしているユーザーのアイデンティティを持ち、IISおよびSharePoint Portal Serverを介してターゲット・リソースにアクセスできます。
41.2.4 Windowsネイティブ認証に対するAccess Managerサポート
Access Managerは、Windowsネイティブ認証(WNA)のサポートを提供します。
環境には次のものが含まれます。
-
Windows 2008/R2または2012/R2サーバー
-
Internet Information Services (IIS) 7.xまたは8.x
-
Active Directory
たとえばユーザーのディレクトリ・サーバーにNTログオンIDがある場合、またはユーザー名がすべての場所で同じ場合、ユーザーは任意のディレクトリ・サーバーに対して認証できます。Windows Server 2008で最も一般的な認証メカニズムはKerberosです。
Access ManagerによるWNAの使用はシームレスです。ユーザーは、デスクトップにログインし、Internet Explorer (IE)ブラウザを開き、保護されているWebリソースをリクエストしてシングル・サインオンを完了するときに、通常の認証とWNAの違いに気付きません。
プロセスの概要: WNA認証の使用方法
-
ユーザーがデスクトップ・コンピュータにログインすると、Windows Domain Administrator認証スキームを使用してローカル認証が完了します。
-
ユーザーは、Internet Explorer (IE)ブラウザを開き、アクセス・システムで保護されたWebリソースをリクエストします。
-
ブラウザは、ローカル認証をノートにとって、KerberosトークンをIIS Webサーバーに送信します。
ノート:
Internet Explorerのインターネットおよび(または)イントラネットのセキュリティ・ゾーンが自動ログオンを許可するように適切に調整されていることを確認してください。
-
IIS WebサーバーにインストールされているWebGateは、KerberosトークンをOAMサーバーに送信します。OAMサーバーは、KDC (キー配布センター)を使用してKerberosトークンをネゴシエーションします。
-
Access Managerは、認証成功情報をWebGateに送信します。
-
WebGateは、OAMAuthnCookieを作成し、それをブラウザに送信します。
-
Access Managerの認可およびその他のプロセスは通常どおりに進められます。
WebGateに対して構成されている最大セッション・タイムアウト期間が、生成されたOAMAuthnCookieに適用されます。
41.3 統合の要件
特に明記しないかぎり、この項では、この章で説明する統合に必要なコンポーネントを紹介します。次のトピックが含まれています:
41.3.1 要件の確認
特定のバージョンおよびプラットフォームについて言及している場合、それらは例示のみの目的で記載されています。最新のAccess Manager動作保証の情報は、Oracle Technology Networkにある動作保証マトリックスを参照してください:
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
41.3.2 必要なAccess Managerのコンポーネント
Access Managerは、アクセス機能およびセキュリティ機能(Webベースのシングル・サインオン、ポリシー管理、レポートと監査など)を提供します。
Microsoft SharePoint Serverと統合すると、Access Managerは、ISAPIフィルタおよびISAPIモジュールを介してユーザー認証を処理し、2つの製品間のシングル・サインオンが可能になります。表41-1のコンポーネントは、Microsoft SharePoint Server (またはLDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server)との統合に必要です。
表41-1 コンポーネントの要件
コンポーネント | 説明 |
---|---|
11g WebGate |
ISAPIバージョン11g WebGateは、SharePoint Serverと同じコンピュータに存在する必要があります。 この統合のコンテキスト内では、このWebGateは、WebリソースのHTTPリクエストを捕捉し、これらをOAMサーバーに転送してリクエストをしたユーザーを認証するISAPIフィルタです。認証が成功すると、WebGateは、OAMAuthnCookieを作成し、これをユーザーのブラウザに送信するため、シングル・サインオンが容易になります。WebGateは、このユーザー・セッションのHeaderVarアクションとして偽装の設定も行います。 LDAPメンバーシップ・プロバイダのシナリオの場合: 「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合」を参照してください。 |
|
このIISネイティブ・モジュールは、WebGateとともにインストールされます。 WebGateのインストール後、 LDAPメンバーシップ・プロバイダのシナリオの場合: |
ディレクトリ・サーバー |
Access Managerは、任意のサポートされているディレクトリ・サーバー(LDAPおよびActive Directoryを含むがこれらに限定されない)に接続できます。Access Managerは、SharePoint Serverによって使用されるActive Directoryの同じインスタンスにさえ接続できます。 いずれのケースでも、ディレクトリはSharePoint Serverおよび保護しているWebGateと同じマシン上である必要はありません。 |
OAMサーバー |
この統合では、SharePoint Serverのインストールを保護しているWebGateが相互運用に構成されている相互運用相手のOAMサーバーのインストールも必要です。 SharePoint Serverを保護しているWebGate以外のコンポーネントをSharePoint Serverをホストしているマシンに配置する必要はありません。 |
41.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
表41-2に、この統合に必要なその他のコンポーネントを示します。
関連項目:
Microsoft SharePoint Serverの次のライブラリの場所および適用可能なソフトウェアへのアクセス。
http://technet.microsoft.com/en-us/library/cc262485.aspx
表41-2 この統合のためのMicrosoftの要件
コンポーネント | 説明 |
---|---|
SharePointサイトのカスタム・ログイン・ページ |
フォーム・ベースの認証を使用するように構成されたSharePointサイトにユーザーがアクセスしようとすると、ユーザーはログイン・ページにリダイレクトされ、そこで資格証明(ユーザー名およびパスワード)を入力します。カスタム・ログイン・ページは資格証明をSharePointサイトに渡します。 |
SharePointサイト |
SharePointサーバーの全体管理アプリケーションを使用してSharePointサイトを作成します。このサイトは、 SharePointサイトは、カスタム・メンバーシップ・プロバイダによるOAMAuthnCookieの検証成功時にSAMLトークンを生成するSharePoint STSにユーザー資格証明を渡します。SharePointサイトは、SAMLトークンをSharePoint STSから受信したときにFedAuth Cookieも生成します。SharePointサイトは、FedAuth Cookieをユーザーに渡し、ユーザーがSharePointサイトにアクセスできるようにします。 |
SharePointセキュリティ・トークン・サービス(STS) |
SharePointサイトは、ユーザー資格証明(ユーザー名とパスワード)をSharePoint STSに渡し、これは、カスタム・メンバーシップ・プロバイダを呼び出して、これに資格証明を渡します。カスタム・メンバーシップ・プロバイダがこれに渡されたOAMAuthnCookieを検証すると、SharePoint STSは、SharePoint Relying Party (RP)に渡されるユーザーのためのSAMLトークンを生成します。 |
SharePoint STSのためのカスタム・メンバーシップ・プロバイダ |
SharePoint STSは、(フォーム・ベースの認証によって構成された)メンバーシップ・プロバイダを呼び出します。STSは、ユーザー資格証明および(SharePointサイト上の メンバーシップ・プロバイダは、これに渡されたOAMAuthnCookie値が有効な場合に成功を返すようにカスタマイズされます。 カスタム・メンバーシップ・プロバイダ・ライブラリ(
|
Cookie検証のIISリソース |
SharePointサイトの HTTP検証メソッドの場合、WebGateは、カスタム・メンバーシップ・プロバイダによって送信されたリクエストを捕捉し、リクエストからOAMAuthnCookieを抽出してこれを検証します。Cookieが有効な場合、リクエストはIISリソースにリダイレクトされ、これが200 (OK)のステータス・コードを含むレスポンスをカスタム・メンバーシップ・プロバイダに返します。そうでない場合は、403(禁止)エラー・コードがカスタム・メンバーシップ・プロバイダに返されます。 |
41.4 SharePoint Serverとの統合の準備
IIS 11g WebGateは、SharePoint Serverと同じコンピュータにインストールする必要があります。この統合の他のコンポーネントは、WebGateと同じホストまたはデプロイメント(Solaris、LinuxまたはWindowsプラットフォーム)の他のコンピュータに配置できます。
次の手順のタスクは、この章で説明するすべての統合シナリオで必要です。
Microsoftコンポーネントをインストールしてテストした後、ここに示すステップを実行して、統合のためにAccess Managerをインストールします。このタスクは、この章の両方の統合シナリオに適用されます。重複を避けるために、ここで示す情報は、他の場所では繰り返しません。
異なるホストをActive Directoryまたは他のディレクトリ・サービスに設定できます。Access ManagerとSharePoint Serverの両方がActive Directoryの異なるインスタンスに設定される場合、両方のインスタンスは、同じActive Directoryドメインに属する必要があります。
前提条件
「必要なMicrosoftのコンポーネント」に記載されているMicrosoftのコンポーネントをインストールしてテストします。
SharePoint Serverとの統合の準備を行います。
-
Oracle Identity ManagementとAccess Managerをインストールします。手順については、『Oracle Identity Managementのインストールと構成』を参照してください。
-
IIS Webサーバーの11g WebGateをAccess Managerに登録します。
-
Oracle Access Managementコンソールにログインします。たとえば:
http://
host:port/oamconsole
。 -
ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
-
「起動パッド」タブで、「クイック・スタート・ウィザード」セクションの「SSOエージェント登録」をクリックします。
-
エージェント・タイプとして「Webゲート」を選択し、「次」をクリックします。
-
エージェント・バージョンを11gに設定し、必要な詳細(*が付いているもの)を入力します。
- 名前
- SharePointのユーザー名およびパスワード
- セキュリティ・モード(エージェント・ホストはOAMサーバーと一致する必要があります)
- ポリシーの自動作成(選択済)
ノート:
ベースURLを指定しないでください。
-
保護されているリソース・リスト: この表では、このOAMエージェントで保護する個々のリソースのURLを入力します。
-
パブリック・リソース・リスト: この表では、公開する(保護しない)個々のリソースのURLを入力します。
-
「適用」をクリックして登録を送信し、確認ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。
-
-
次の手順を実行します。
-
新しいWebGateのインストール: ステップ6、7および8に進みます。
-
SharePointホスト上の既存のWebゲート: 「Microsoft SharePoint Serverとの統合」にスキップします。
ノート:
「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合」で説明しているように、64ビットISAPI Webゲートのみがサポートされます。
-
-
次のように、64ビットIIS WebGateのインストーラを探してダウンロードします。
-
次のOracle Fusion Middleware 11gR1ソフトウェア・ダウンロードに移動します。
https://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html
-
ページの一番上のライセンス契約に同意をクリックします。
-
Access Manager Webgates (10.1.4.3.0)の行から、該当するプラットフォームのダウンロード・リンクをクリックし、画面の指示に従います。
-
インストールする11g (10.1.4.3)アクセス・システムの言語パックと同じディレクトリにWebGateインストーラを格納します。
-
-
使用プラットフォーム、インストール・モードおよびWebサーバー用のWebGateインストーラを起動します。
次のステップを実行します。
-
画面に表示されるプロンプトに従います。
-
Webサーバーの管理者資格証明を指定します。
-
言語パック - デフォルトのロケールとインストールするその他のロケールを選択して、「次へ」をクリックします。
-
WebGateのインストールが始まります(
IISImpersonationModule.dll
はWebGate_install_dir\webgate\iis\lib
にインストールされます)。
-
-
Webサーバー構成を更新する前に、WebGateアーティファクトをAdmin ServerからWebGateをホストしているコンピュータにコピーします。
-
Oracle Access Managementコンソール(AdminServer)をホストしているコンピュータでObAccessClient.xml (およびすべての証明書アーティファクト)を探してコピーします。
$DOMAIN_HOME
/output/
$Agent_Name/
-
ObAccessClient.xml
-
password.xml
(必要な場合) -
aaa_key.pem
(openSSLによって生成される秘密キー) -
aaa_cert.pem
(PEM形式の署名済証明書)
-
-
OAMエージェントのホストで、アーティファクトをWebGateパスに追加します。たとえば:
- WebGate_instance_dir
/webgate/config/ObAccessClient.xml
- WebGate_instance_dir
/webgate/config/
- WebGate_instance_dir
-
WebGate Webサーバーを再起動します。
-
(オプション。)このエージェントをホストするOAMサーバーを再起動します。このステップは推奨されますが、必須ではありません。
-
-
必要に応じて次に進み、使用中の環境内でこの統合を完了します。
41.5 Microsoft SharePoint Serverとの統合
Webアプリケーションまたはサイト・アプリケーションを新規作成することで、Microsoft SharePoint Serverと統合できます。
次の概要では、この統合のために実行する必要があるタスクと、ステップおよび詳細に関する項目について説明します。
カスタム・メンバーシップ・プロバイダ・ライブラリ(OAMCustomMembershipProvider.dll
)は、パッケージ化されIIS Web Serverの10g WebGateを使用してインストールされます。次に説明するように、SharePoint Serverをホストするコンピュータのグローバル・アセンブリ・キャッシュにライブラリをデプロイする必要があります。
タスクの概要: Microsoft SharePoint Serverとの統合には次の項目が含まれます
-
前提条件となるタスクの実行
-
SharePoint Serverでの新規Webアプリケーション(またはサイト・アプリケーション)の作成は、次のトピックで説明します。
-
「Microsoft Windowsの偽装の設定」(LDAPメンバーシップ・プロバイダでは使用しません)。
41.5.1 Microsoft SharePoint Serverでの新規Webアプリケーションの作成
LDAPメンバーシップ・プロバイダを使用してまたは使用せずにMicrosoft SharePoint Serverで新しいWebアプリケーションを作成できます。
Microsoft SharePoint Serverとの統合時に、LDAPメンバーシップ・プロバイダを使用してまたは使用せずにこのタスクを実行します。
Prerequisites
Microsoftのコンポーネントのインストール。「必要なMicrosoftのコンポーネント」を参照してください。
Microsoft SharePoint Serverで新規Webアプリケーションを作成する手順
41.6 Microsoft Windowsの偽装の設定
Active Directory以外のディレクトリ・サーバーを使用する場合、LDAPメンバーシップ・プロバイダを使用してください。OAMCustomMembershipプロバイダは、LDAPメンバーシップ・プロバイダの機能を利用します。
この項では、SharePoint Serverの統合または他のアプリケーションによる使用のための偽装の設定について説明します。
ノート:
LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverと統合している場合、この項をスキップしてください。Windowsの偽装はLDAPメンバーシップ・プロバイダでは使用されません。
タスクの概要: 偽装の設定
- 「信頼できるユーザー・アカウントの作成」の説明に従って、SharePoint Serverに接続されたActive Directoryでの偽装に対してのみ信頼できるユーザー・アカウントを作成します。
- 「信頼できるユーザーへの権限の割当て」の説明に従って、オペレーティング・システムの一部として機能する特別な権限を信頼できるユーザーに付与します。
- 「信頼できるユーザーのWebGateへのバインド」の説明に従って、信頼できるユーザーの認証資格証明を提供して、信頼できるユーザーをWebゲートにバインドします。
- 「偽装レスポンスの認可ポリシーへの追加」の説明に従って、アプリケーション・ドメインで偽装のための認可成功アクションにIMPERSONATEという名前のヘッダー変数を追加します。
- 「偽装DLLのIISへの追加」の説明に従って、
IISImpersonationModule.dll
をIIS構成に追加して、IISを構成します。 - 「偽装のテスト」の説明に従って、偽装をテストします。
41.6.1 信頼できるユーザー・アカウントの作成
信頼できるユーザー・アカウントを作成できます。この特別なユーザーは、偽装以外には使用しないでください。
次の手順例では、Impersonatorを新規オブジェクト - ユーザーとして使用します。環境はユーザーによって異なります。
信頼できるユーザー・アカウントを作成するには::
ノート:
信頼できるユーザーには、非常に強力な権限が付与されるため、非常に複雑なパスワードを選択することをお薦めします。また、「パスワードの有効期限なし」ボックスがマークされていることも確認してください。偽装モジュールは、信頼できるユーザー・アカウントを表示できる唯一のエンティティであるため、外部のエージェンシがパスワードの期限切れを発見することは非常に困難です。
41.6.3 信頼できるユーザーのWebGateへのバインド
信頼できるユーザーの認証資格証明を指定して、Access Managerと通信する11g Webゲートに信頼できるユーザーをバインドする必要があります。
次の手順では、11g WebGateをAccess Managerにまだ登録していないことを前提としています。次の手順の値は、例としてのみ提供されます。環境はユーザーによって異なります。
信頼できるユーザーをWebGateにバインドする手順
-
Oracle Access Managementコンソールに移動します。
たとえば:
http://hostname:port/oamconsole
ここで、hostnameはOracle Access Managementコンソールをホストしているコンピュータの完全修飾DNS名、portはOAMサーバー用に構成されたリスニング・ポート、oamconsoleはOracle Access Managementコンソールです。
-
ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
-
「起動パッド」タブで、「クイック・スタート・ウィザード」セクションの「SSOエージェント登録」をクリックします。
-
エージェント・タイプとして「Webゲート」を選択し、「次」をクリックします。
-
バージョンを11gに設定し、必要な詳細(*が付いているもの)を入力して、このWebゲートを登録します。
-
保護されているリソース・リスト: この表では、表14-9にあるように、このOAMエージェントで保護する個々のリソースのURLを入力します。
-
パブリック・リソース・リスト: この表では、表14-9にあるように、公開する(保護しない)個々のリソースのURLを入力します。
-
「ポリシーの自動作成」: 新規ポリシーの作成をチェックします(または、クリアして別のWebGateと同じホスト識別子を使用してポリシーを共有します(表14-9))。
-
「適用」をクリックして、登録を送信します。
-
「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。
-
ナビゲーション・ツリーで、「エージェント」ページを開きます。
-
SharePointの要件: Sharepointインパーソネータ・フィールドに信頼できるユーザー資格証明を入力し、「適用」をクリックします。
-
次のようにアーティファクトをコピーします(またはWebGateをインストールしてからこれらのアーティファクトをコピーします)。
-
Oracle Access Managementコンソールのホストで、更新されたOAMエージェントの構成ファイルObAccessClient.xml (およびすべての証明書アーティファクト)を検索します。たとえば:
$DOMAIN_HOME/output/$Agent_Name/ObAccessClient.xml
-
エージェントをホストしているコンピュータで、アーティファクトをコピーします。たとえば
- 11g WebGate/AccessClient: $WebGate_instance_dir/webgate/config/ObAccessClient.xml
- ObAccessClient.xml
-
「偽装レスポンスの認可ポリシーへの追加」に進みます。
-
41.6.4 偽装レスポンスの認可ポリシーへの追加
IMPERSONATE
に設定し、レスポンス値を$user.userid (シングルドメインのActive Directoryインストールの場合は"samaccountname"、マルチドメインのActive Directoryフォレストの場合は"userPrincipalName")とする必要があります。偽装レスポンスを認可ポリシーに追加するには::
41.6.5 偽装DLLのIISへの追加
偽装DLLをIISに追加できます。
この統合のためにIIS Webサーバーを構成するには、すべてのサイト(中央管理およびWebサービスを含む)でIISImpersonationModule.dllを登録して構成します。
または、複数のWebサイトがあり、その一部がAccess Managerに統合されていて、残りが統合されていない場合、Access Managerに統合されてしるWebサイトに対してのみ偽装を有効にする必要があります。そのためには、統合が必要なサイトのみでネイティブ・モジュールを構成する必要があります。参照:
41.6.6 偽装のテスト
統合を完了する前に、テストして偽装が正しく機能していることを確認できます。
偽装をテストする方法は次のとおりです。
-
SharePoint Serverの外部でのシングル・サインオンのテスト(「SharePoint Serverによって保護されていないIIS仮想サイトの作成」を参照)
-
イベント・ビューアの使用(「イベント・ビューアを使用した偽装のテスト」を参照)
-
Webページの使用(「Webページを使用した偽装のテスト」を参照)
-
ネガティブ・テストの使用(「偽装のネガティブ・テスト」を参照)
関連項目:
偽装の構成が正しく機能することを確認した後に、「SharePoint Serverの統合の完了」を参照してください。
41.6.6.1 SharePoint Serverによって保護されていないIIS仮想サイトの作成
SharePoint Server外の偽装機能をテストするまたはシングル・サインオンをテストするには、SharePoint Serverによって保護されていないIIS仮想Webサイト上にターゲットWebページが必要です。
このような仮想Webサイトは、次のタスクを実行して作成します。
SharePoint Serverによって保護されていないIIS仮想サイトを作成するには:
- 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順に選択します。
- 左ペインにあるツリー上のローカル・コンピュータのアイコンの左側のプラス・アイコン(+)をクリックします。
- 左ペインにあるツリー上のWebサイトを右クリックして、メニューの「新規作成」、「Webサイト」に移動します。
- 「Webサイト作成」ウィザードでプロンプトに応答します。
- 仮想サイトを作成した後、これをアプリケーション・ドメインのポリシーで保護する必要があります。
41.6.6.2 イベント・ビューアを使用した偽装のテスト
Windows 2003イベント・ビューアを使用して偽装のテストを実行する場合、実際のテストを実行する前にイベント・ビューアを構成する必要があります。
イベント・ビューアを使用して偽装をテストするには::
偽装が正しく機能している場合、イベント・ビューアがアクセス試行の成功を報告します。
41.6.6.3 Webページを使用した偽装のテスト
リクエストに関する情報を返し、表示できる.aspページやPerlスクリプトなどの動的テスト・ページを使用して偽装をテストすることも可能です。
サーバー変数を表示するWebページを使用して偽装をテストするには:
41.6.6.4 偽装のネガティブ・テスト
偽装のネガティブ・テストを実行するには、信頼できるユーザーをWebゲートからアンバインドする必要があります。
信頼できるユーザーをWebGateからアンバインドするには::
- Oracle Access Managementコンソールで、Webゲートを探します。
- 必要なWebGate登録ページを開いて、信頼できるユーザーの資格証明を削除します。
- 「適用」をクリックして変更を保存します。
- ブラウザ・ウィンドウでIISサーバーを再起動し、保護されているコード・ページ(信頼できるユーザーが以前アクセスできたページ)に移動します。
- ページが表示されるというメッセージを受信することを確認します。AUTH_USERとIMPERSONATEの値は、偽装資格証明をWebGateにバインドするために必要です。
- 信頼できるユーザーをWebGate登録ページにリストアします。
41.7 SharePoint Serverの統合の完了
Access ManagerとSharePoint Serverとの統合を設定するためには、複数の手順を実行する必要があります。
LDAPメンバーシップ・プロバイダを使用して構成されたSharePoint Serverと統合している場合、この項をスキップしてください。
タスクの概要: SharePoint Serverの統合の完了
- 「IISセキュリティの構成」の説明に従って、IISセキュリティを設定します。
- 「SharePoint Serverの統合のテスト」の説明に従って、統合をテストします。
41.7.1 IISセキュリティの構成
続行する前にIISセキュリティを構成します。
SharePoint Serverの統合のためにIISセキュリティを構成するには:
- 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順に選択します。
- 左ペインにあるツリー上のローカル・コンピュータのアイコンの左側のプラス・アイコン(+)をクリックします。
- 左ペインのツリーで「Webサイト」をクリックします。
- 中央のペインで、「IIS」の下の「認証」をダブルクリックします。
- 「匿名アクセス」が有効になっていて、「Windows認証」が無効になっていることを確認します。
41.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との統合」
-
この統合の準備
-
説明に従って、「必要なMicrosoftのコンポーネント」をインストールします。
-
「Microsoft SharePoint Serverでの新規Webアプリケーションの作成」の説明に従って、SharePoint Webサイトを作成します。
-
「Microsoft SharePoint Serverのための新規サイト・コレクションの作成」の説明に従って、SharePointサイト・コレクションを構成します。
-
SharePointのドキュメントの説明に従って、要求ベースの認証タイプ(LDAPメンバーシップ・プロバイダを使用)を使用して、作成したWebサイトをLDAPディレクトリに対して構成します。
-
LDAPディレクトリに存在するユーザーがSharePoint Webサイトにログインして適切なロールを取得できることを確認します。
-
SharePointのドキュメントの説明に従って、構成をテストして、LDAPディレクトリに存在するユーザーがSharePoint Webサイトにログインして適切なロールを取得できることを確認します。
-
-
「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint ServerのためのAccess Managerのインストール」の説明に従って、すべてのタスクを実行します。
このタスクには、IIS対応11g WebGateのインストールと個別のSharePoint Webサイトのための
WebGate.dll
の構成が含まれます。 -
「LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成」の説明に従って、この統合の認証スキームを追加します。
-
「ディレクトリ・サーバーが同期化されていることの確認」の説明に従って、必要に応じてディレクトリ・サーバーを同期化します。
-
「Officeドキュメントのためのシングル・サインオンの構成」の説明に従って、Officeドキュメントのシングル・サインオンを構成します。
-
「Microsoft SharePoint Serverのためのシングル・サインオフの構成」の説明に従って、シングル・サインオフを構成します。
-
「統合のテスト」の説明に従って、統合をテストして問題なく機能することを確認して終了します。
41.8.1 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合について
前のシナリオ「Microsoft SharePoint Serverとの統合」では、Windows認証の使用方法を説明しています。そのシナリオでは、認証および認可は、Active Directoryに存在するユーザーに対して実行されます。Access Managerは、統合のためにWindowsの偽装を使用しました。
この項で説明する統合の場合、LDAPメンバーシップ・プロバイダのサポートは、HeaderVarベースの統合によって実現されます。ISAPI WebGateフィルタは、WebリソースのHTTPリクエストを捕捉し、OAMサーバーと連動して、リクエストをしたユーザーを認証します。認証が成功すると、WebGateは、OAMAuthnCookieを作成し、これをユーザーのブラウザに送信して、シングル・サインオン(SSO)を容易にします。WebGateは、このユーザー・セッションのHeaderVar
アクションとしてOAM_REMOTE_USER
の設定も行います。SharePointのOracleカスタム・メンバーシップ・プロバイダは、HTTP検証メソッドを使用してObSSOCookieを検証します。これにより、Access Managerのカスタム・メンバーシップ・プロバイダは、HTTP/HTTPSリクエストを保護されたリソースに対して実行します。その後で、Access Managerは認可の成功時にOAM_REMOTE_USER
で返されたユーザー・ログインを検証して比較します。
関連項目:
この章で説明するこの統合と他の統合の処理の違いについては、「SharePoint Serverとの統合の概要」を参照してください。
要件: この統合では、Microsoft SharePoint Serverに次の要件があります。
-
LDAPメンバーシップ・プロバイダと統合されている必要があり、Windows認証を使用することは許可されない
-
要求ベースの認証を使用してWebサイトで構成した
IISImpersonationModule.dll
を持つことは許可されない
関連項目:
41.8.2 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint ServerのためのAccess Managerのインストール
LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverと統合するためのインストールを準備できます。
Prerequisites
前の「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverとの統合について」のステップ1を実行します。
LDAPメンバーシップ・プロバイダを含む統合のデプロイメントを準備するには:
-
Oracle Identity ManagementおよびAccess Managerをインストールします。
-
IIS WebGateゲートをプロビジョニングしてインストールします。
-
保護の対象となるSharePoint Webサイトで
Webgate.dll
を構成します。たとえば:-
インターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。
-
「Webサイト」で、保護するSharePoint Webサイトの名前をダブルクリックします。
-
中央ペインで、「IISフィルタ」をダブルクリックし、右ペインで「追加」をクリックします。
-
フィルタ名を
Oracle WebGate
と入力します。 -
Webgate.dll
ファイルに次のパスを入力します。WebGate_install_dir\webgate\iis\lib
-
これらの変更を保存して適用します。
-
中央ペインで、「認証」をダブルクリックします。
-
Internet Information Services設定が正しいことを確認します。匿名認証とフォーム認証が有効になっており、Windows認証が無効になっている必要があります。
ノート:
要求ベースの認証をAccess Managerで使用する場合、SharePointサイトのWindows認証を無効にする必要があります。
-
これらの変更を保存して適用します。
-
-
IIS Webサイトで
ConfigureIISWebGate.bat
ツールを実行します。例:
configureIISwebgate -oh C:\Oracle_WebGateHome -w C:\Oracle_WebGateInstance -site "Default WebSite"
41.8.3 LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成
統合にLDAPメンバーシップ・プロバイダが含まれる場合、3つのAccess Manager認証メソッドのみがサポートされます。
LDAPメンバーシップ・プロバイダを使用したSharePointのための認証スキームを構成するには::
41.8.4 FBAを使用したSharePoint ServerとOAM 11gの統合
Access Managerは、FBA (OAMCustomMembershipProvider)を使用してSharePoint 2013 OAM 11gと統合されます。この統合の場合は、次のステップを実行する必要があります。
41.8.5 ディレクトリ・サーバーが同期化されていることの確認
Access Managerに対して構成されているディレクトリ・サーバーのユーザーは、SharePointによって使用されるディレクトリ・サーバーと同期している必要があります(これらが異なる場合)。
これは、この章の他の統合シナリオで実行したタスクと同じです。ただし、SharePointの統合にLDAPメンバーシップ・プロバイダが含まれている場合、LDAPコマンドをサポートするディレクトリ・サーバーを使用できます。
41.9 Officeドキュメントのためのシングル・サインオンの構成
Officeドキュメントのためのシングル・サインオンは、認証スキームで永続Cookieを設定することによって実現できます。
OAM 11gを使用してこれを行うには、認証スキームにssoCookie=max-age
を設定する必要があります。こうすることによって、複数セッション継続する永続Cookieが作成されます。
ノート:
Windowsネイティブ認証に基づく統合の場合には、永続Cookieパラメータを設定する必要はありません。
41.10 Microsoft SharePoint Serverのためのシングル・サインオフの構成
安全にために、常に、サインオフした後にブラウザ・ウィンドウを閉じることをお薦めします。ユーザー・セッション全体がOAMAuthnCookieによって制御されていると、Cookieタイムアウトが発生します。次のユースケースについて考えてみます。
-
FedAuth Cookieがタイムアウトになり、OAMAuthnCookieが依然として有効: OAMAuthnCookieが存在するため、ユーザーは再チャレンジされません。新規FedAuth Cookieが生成されます(以前説明した同じフローを使用)。
-
OAMAuthnCookieがタイムアウトになり、FedAuth Cookieが依然として有効: 各リクエストがWebGateによって捕捉されるため、ユーザーは再び資格証明を求められます。
Access Managerは、ユーザー・セッションに単一のログアウト(グローバル・ログアウトまたは集中管理ログアウトとも呼ばれる)を提供します。Access Managerでは、単一のログアウトはアクティブなユーザー・セッションを終了するプロセスを意味します。
このトピックは、SharePointとの統合に関してシングル・サインオフを構成する方法を説明します。シングル・サインオフは、ユーザー・セッションを削除します。
41.10.1 SharePoint Serverでのカスタム・ログアウトURLの構成
SharePoint Serverでカスタム・ログアウトURLを構成できます。
構成するには、次のようにします。
41.11 Access ManagerとWindowsネイティブ認証の設定
この項では次のトピックを記載しています:
41.11.2 SharePoint Serverを使用したWNAの設定
次の概要では、Access ManagerおよびSharePoint Serverを使用してWNAを設定するために実行する必要があるタスクを説明します。
タスクの概要: SharePoint Serverを使用したWNAの設定
-
次の前提条件となるタスクを実行します。
-
「必要なMicrosoftのコンポーネント」のタスクを実行します。
-
「Microsoft SharePoint Serverでの新規Webアプリケーションの作成」の説明に従って、SharePoint Webサイトを作成します。
-
「Microsoft SharePoint Serverのための新規サイト・コレクションの作成」の説明に従って、SharePointサイト・コレクションを構成します。
-
SharePointのドキュメントの説明に従って、構成をテストして、ディレクトリ・サーバーに存在するユーザーがSharePoint Webサイトにログインして適切なロールを取得できることを確認します。
-
-
「WNAおよびSharePoint ServerのためのAccess Managerのインストール」の説明に従って、Access Managerをインストールします。
このステップには、IIS対応WebGateのインストールと個別のSharePoint Webサイトのための
Webgate.dll
の構成が含まれます。 -
次のようにActive Directory認証プロバイダを構成します。
-
WebLogicコンソールにログインします。
-
「セキュリティ・レルム」に移動し、使用する「レルム」をクリックします。
-
「プロバイダ」タブに移動し、「新規」をクリックします。
-
プロバイダ名を入力し、タイプActiveDirectoryAuthenticatorを選択して「OK」をクリックします。
-
新しく作成したプロバイダを選択し、「制御フラグ」を「十分」に変更して、保存します。
-
「プロバイダ固有」タブに移動し、Active Directoryの詳細を入力して、これらを保存します。
-
-
「WNA実装のテスト」を実行します。
41.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をインストールするには:
-
『Oracle Identity and Access Managementのインストールおよび構成』の説明に従って、Access Managerをインストールします。
-
次のようにしてISAPI Webゲートをインストールします。
-
Webゲートのインストール
-
IIS WebサーバーのためのWebコンポーネントのインストール
次に、保護の対象となるSharePoint Webサイトで
Webgate.dll
を構成します。Webgate.dll
を「Webサイト・レベル」で構成すると、IIS Webサーバー上のすべてのWebサイトが保護されます。しかし、Webgate.dll
を「SharePoint Webサイト」で構成すると想定されるWebサイトのみが保護されます。
-
-
保護の対象となるSharePoint Webサイトで
Webgate.dll
を構成します。たとえば:-
インターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「プログラム」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。
-
「Connections」ペインでhostnameを選択します。
-
host nameの「Home」ペインで「ISAPI Filters」をダブルクリックし、
Webgate.dll
を検索します。存在する場合は選択して、「Action」ペインの「Remove」をクリックします。 -
「Connection」ペインの「Sites」の下で、WebGateフィルタを構成するWebサイト名をクリックします。
-
「Home」ペインで「ISAPI Filters」をダブルクリックします。
-
「Actions」ペインで「Add…」をクリックします。
-
「Add ISAPI Filter」ダイアログ・ボックスの「Filter name」テキスト・ボックスに、ISAPIフィルタの名前としてWebGateと入力します。
-
「Executable」ボックスにWebGate ISAPIフィルタ・ファイルのファイル・システム・パスを入力するか、省略記号ボタン(...)をクリックして
WebGate.dll
ISAPIフィルタ・ファイルを含むフォルダに移動し、「OK」をクリックします。WebGate_install_dir\access\oblix\apps\Webgate\bin\Webgate.dll
-
-
仮想ディレクトリの作成
-
「Sites」ペインを開き、ISAPIフィルタ(
Webgate.dll
)を構成したばかりのWebサイトを選択します。 -
「Action」ペインで「View Virtual Directories」をクリックし、「Add Virtual Directory」を選択します。
-
「Alias」フィールドにaccessを指定し、WebGateの\accessフォルダの物理パスを指定します(または、省略ボタン(...)をクリックして\accessフォルダに移動して、「OK」をクリックします)。
WebGate_install_dir\access\
-
-
仮想ディレクトリの権限の設定:
-
ステップ3で作成したaccess仮想ディレクトリを選択します。
-
accessの「Home」ペインで「Handler Mappings」をダブルクリックします。「Action」ペインで「Edit Feature Permissions…」を選択します。
-
「読取り」、「スクリプト」、「実行」を選択し、「OK」をクリックします。
-
-
Windowsネイティブ認証を使用するようにAccess Managerを構成します。
-
Microsoft SharePointで新規Webアプリケーションを作成するときに、Microsoft SharePoint Server認証をクラシック・モード認証に構成します。「認証プロバイダ」セクションで、ネゴシエート(Kerberos)を選択します。
-
IISで新しく作成したSharePointサイトに移動します。
-
「認証」、Windows認証、詳細設定の順に開きます。
-
「Kernelモード認証を有効にする」を選択します。
-
プロバイダを選択して、NTLMプロバイダを削除します。
-
Negotiate:Kerberosを追加し、これを最上位レベルに移動します。
-
IISを再起動します。
-
-
「WNA実装のテスト」に進みます。
41.12 ディレクトリ間のユーザー・プロファイルの同期化
SharePoint ServerのディレクトリとAccess Managerのディレクトリの間でユーザー・プロファイルを同期化する必要があります。
特に明記しないかぎり、このタスクは、この章のすべての統合シナリオで実行する必要があります。
ノート:
統合にLDAPメンバーシップ・プロバイダが含まれている場合、LDAPコマンドをサポートする任意のディレクトリ・サーバーを使用できます。
同期するには、次のようにします。
-
ユーザー・データのアップロード—Access ManagerのインストールがSharePoint Active Directory以外の任意のディレクトリ・サーバーに対して構成されている場合、他のディレクトリ・サーバーにあるユーザー・プロファイルをSharePoint Active Directoryにロードする必要があります。
「統合のテスト」に進みます。
41.13 統合のテスト
タスクを完了して統合を有効にした後、テストして統合が動作していることを確認する必要があります。
この項では、次の項目について説明します。
41.13.1 SharePoint Serverの統合のテスト
Access Managerの認証とSharePoint Serverの認可を使用してSharePoint Serverのリソースにユーザーがアクセスできることを確認できます。
SharePoint Serverの統合をテストするには::
41.13.2 SharePoint Serverの統合のためのシングル・サインオンのテスト
資格証明を提供し、SharePoint Serverリソースにアクセスしたユーザーが(OAMAuthnCookieが期限切れになる前に)再び資格証明を提供せずに非SharePoint Serverリソースにアクセスできることを示してシングル・サインオンをテストすることもできます。
たとえば、Policy Managerで定義したリソースを使用します。シングル・サインオンが動作している場合、再び資格証明を提供する必要なく、ページへのアクセスが付与されます。
SharePoint Serverの統合のためにシングル・サインオンをテストするには::
41.14 トラブルシューティング
41.14.1 Internet ExplorerがSSL経由によるファイルのダウンロードを実行できない
この問題は、サーバーがCache-control:no-store
ヘッダーまたはCache-control:no-cache
ヘッダーを送信している場合に発生します。WebGateは、構成パラメータを提供して、これらのヘッダーの設定を制御します。
次に、パラメータとそのデフォルト値を示します。
CachePragmaHeader
no-cache
CacheControlHeader
no-cache
WebGate構成を変更して、これらのヘッダーをまったく設定しないようにできます(これらのパラメータの値は空白のままになります)。こうすることによって、Access Managerはキャッシング動作を制御しなくなります。