59.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によって保護されているリソースへのシングル・サインオンを提供します。詳細は、次を参照してください。

59.2.1 Windowsの偽装について

特に明記しないかぎり、この章で説明する統合は、Windowsの偽装に依存します。Windowsの偽装によって、Windowsサーバー・ドメインの信頼できるユーザーは、Microsoft SharePoint Serverのターゲット・リソースをリクエストする任意のユーザーのアイデンティティを持つことができます。

この信頼できるインパーソネータは、ユーザーのアイデンティティ・コンテキストを維持し、ユーザーのかわりにリソースにアクセスします。

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

ノート:

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

59.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検証メソッド(OAMsdk検証メソッド)は、フォーム・ベース認証にはサポートされていません。

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

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

ユーザー・リクエストはSharePoint Server RPサイトにアクセスします。
サイトを保護するWebGateは、リクエストを捕捉し、リソースが保護されているかどうかを判定し、ユーザーに要求します。
ユーザーはOAM資格証明を入力します。次にOAM WebGateサーバーはLDAPから資格証明を確認し、ユーザーを認証します。

WebGateは、OAMネイティブSSO Cookie (ObSSOCookie)を生成します。これは、シングル・サインオンを可能にし、HTTPリクエストの(ユーザー名に対する)ユーザーIDヘッダー変数を設定し、ユーザーをSharePoint RPサイトにリダイレクトします。
SharePoint RPのカスタム・ログイン・ページが呼び出され、これが、ユーザー名をヘッダー変数に渡されたユーザーIDに設定し、パスワードをObSSOCookie値に設定します。ログイン・ページもこれらの資格証明をSharePoint RPサイトに自動的に送信します。
SharePoint RPサイトは、資格証明をSharePoint STSに渡し、これは、ユーザー資格証明の検証のためにカスタム・メンバーシップ・プロバイダを呼び出します。
カスタム・メンバーシップ・プロバイダは、(パスワードとして渡された)ObSSOCookie値を取得し、HTTPリクエストの一部としてこれをWebGateによって保護されているリソースに送信し、ObSSOCookieを検証します。
ObSSOCookieが有効な場合、SharePoint STSは、SAMLトークンを生成し、これをSharePoint RPに渡します。
SharePoint RPは、SAMLトークンを検証し、FedAuth Cookieを生成します。ユーザーは、SharePoint RPサイトへのアクセスを許可されます。

59.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の偽装を使用した統合認証

ユーザー・リクエストはSharePoint Portal Serverリソースにアクセスします。
SharePoint Portal Serverを保護するWebGate ISAPIフィルタは、リクエストを捕捉し、ターゲット・リソースが保護されているかどうかを判定し、保護されている場合にはユーザーに認証資格証明を要求します。
ユーザーが資格証明を提供し、OAMサーバーがこれを検証すると、WebGateはユーザーのブラウザにObSSOCookieを設定し、シングル・サインオンを有効にします。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を介してターゲット・リソースにアクセスできます。

59.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 11gサーバーに送信します。OAM 11gサーバーは、KDC(キー配布センター)を使用してKerberosトークンをネゴシエーションします。
Access Managerは、認証成功情報をWebGateに送信します。
WebGateは、ObSSOCookieを作成し、それをブラウザに送信します。
Access Managerの認可およびその他のプロセスは通常どおりに進められます。

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