59.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. 説明に従って、「必要な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サイトにログインして適切なロールを取得できることを確認します。
「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint ServerのためのAccess Managerのインストール」の説明に従って、すべてのタスクを実行します。

このタスクには、IIS対応10g WebGateのインストールと個別のSharePoint WebサイトのためのWebGate.dllの構成が含まれます。
「LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成」の説明に従って、この統合の認証スキームを追加します。
「SharePoint Webサイトを保護するアプリケーション・ドメインの更新」の説明に従って、SharePoint Webサイトを保護するアプリケーション・ドメインを更新します。
「ヘッダー変数SP_SSO_UIDのための認可レスポンスの作成」の説明に従って、新規アプリケーション・ドメインで、この統合の認可ルールを作成します。
「OAMAuthCookieのための認可レスポンスの作成」のすべてのステップを実行します。
「OAMCustomMembershipProviderの構成およびデプロイ」のすべてのステップを実行します。
「ディレクトリ・サーバーが同期化されていることの確認」の説明に従って、必要に応じてディレクトリ・サーバーを同期化します。
「Officeドキュメントのためのシングル・サインオンの構成」の説明に従って、Officeドキュメントのシングル・サインオンを構成します。
「Microsoft SharePoint Serverのためのシングル・サインオフの構成」の説明に従って、シングル・サインオフを構成します。
「統合のテスト」の説明に従って、統合をテストして問題なく機能することを確認して終了します。

59.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を持つことは許可されない

関連項目:

「統合の要件」

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

LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Serverと統合するためのインストールを準備できます。

前提条件

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

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

Oracle Identity ManagementおよびAccess Managerをインストールします。
ISAPI Webゲートをプロビジョニングしてインストールします。
保護の対象となる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. これらの変更を保存して適用します。
保護するWebサイト・レベルに移動し、新しくインストールしたWebGate_install_dirを指す/accessアプリケーションを作成します。次に例を示します。
1. 「Webサイト」で、保護するWebサイトの名前を右クリックします。
2. 該当のWebGate_install_dir\accessを指す別名「access」という名前を使用して「アプリケーションの追加」を選択します。
3. アクセス許可で、「読取り」、「起動スクリプト」および「実行」をチェックします。
4. これらの変更を保存して適用します。
「LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成」に進みます。

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

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

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

Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「起動パッド」タブで、「Access Manager」セクションの「作成」(+)ドロップダウン・メニューから「認証スキームの作成」を選択します。
「認証スキーム」ページで、次の項目を入力します。
「名前」: このスキームの一意の名前を入力します。例: SharePoint w/LDAP-MP

説明: オプション
「認証レベル」: スキームのセキュリティのレベルを選択します。
「チャレンジ・メソッド」を選択します。
SharePoint Webサイトのルート(/)に対する基本認証

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

SharePoint Webサイトのルート(/)に対するクライアント資格証明認証
「チャレンジ・リダイレクト」: 必要に応じて、チャレンジ・リダイレクト値を入力します。
リストの中から「認証モジュール」を選択します。
「チャレンジ・パラメータ」: 必要に応じて、チャレンジ・パラメータ値を入力します。
「チャレンジURL」: 資格証明コレクションのために資格証明コレクタがリダイレクトするURL。
「適用」をクリックして新しいスキームを送信し、確認ウィンドウで詳細を確認します。
オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。
ナビゲーション・ツリーで、新しいスキームがリストされていることを確認し、ページを閉じます。
「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を追加する必要がある場合があります。

59.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サイトを保護する代替認証スキームが含まれています。

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

Oracle Access Managementコンソールから、SharePoint w/LDAP-MPアプリケーション・ドメインを開きます。
「リソース」タブを開いて、「新規リソース」ボタンをクリックします。
「リソース」の「定義」ページで、1つのリソースの詳細を入力して、「適用」をクリックします。
- タイプ: http
- 説明(オプション): SharePoint Webサイトの保護
- ホスト識別子: 前に追加したホスト識別子を選択します。
- リソースURL: /ValidateCookieと入力します。
- 保護レベル: 保護
- 認証ポリシー(レベルが「保護」の場合)
- 認可ポリシー(レベルが「保護」で、「認証ポリシー」が選択されている場合)
「認証ポリシー」の「保護されたリソース・ポリシー」に、定義済リソースを追加します。
- 「認証ポリシー」ページで「リソース」タブをクリックします。
- 「リソース」タブの「追加」ボタンをクリックします。
- 目的のリソース定義を見つけて選択してから、「選択済の追加」をクリックします。
- 「適用」をクリックして、リソースを追加します。
- これを繰り返して、さらにリソースを追加します。
「レスポンス」タブをクリックし、「追加」ボタンをクリックした後、次の操作を実行します。
- 「名前」フィールドに、このレスポンスの一意の名前を入力します(SP_SSO_UID)。
- 「タイプ」リストから「ヘッダー」を選択します。
- 「値」フィールドに、このレスポンスの値を入力します。例: $user.userid。
- 「適用」をクリックします。
ポリシーの追加: 選択した場合、HTTP検証メソッドに使用するリソースのポリシーを追加します。
このアプリケーション・ドメインを有効にする前に、「ヘッダー変数SP_SSO_UIDのための認可レスポンスの作成」に進みます。

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

LDAPメンバーシップ・プロバイダを使用して構成された統合に関する認可レスポンスを追加できます。

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

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

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

戻り属性は、ログインに使用されるログイン属性です。
この認可ルールは、ルートのSharePoint Webサイト「/」を保護します。

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

Oracle Access Managementコンソールから、SharePoint w/LDAP-MP認可ポリシー(ProtectedResourcePolicy)を開きます。
「認可ポリシー」の「レスポンス」タブをクリックし、「追加」ボタンをクリックした後、次の操作を実行します。
- 「名前」フィールドに、このレスポンスの一意の名前を入力します(SharePoint w/LDAP-MP).。
- 「タイプ」リストから「ヘッダー」を選択します。
- 「値」フィールドに、このレスポンスの値を入力します。例: $user.userid。
- 「適用」をクリックします。
- 必要に応じて繰り返します。
「OAMAuthCookieのための認可レスポンスの作成」に進みます。

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

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

ヘッダー変数:

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

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

Oracle Access Managementコンソールから、SharePoint w/LDAP-MP (認可ポリシー: 保護されたリソース・ポリシー)を開きます。
「レスポンス」タブをクリックし、「追加」ボタンをクリックした後、次の操作を実行します。
「リダイレクションURL」: この統合では不要です。

戻り値
```
	Type = Cookie
	Name = OAMAuthCookie
	Return Attribute = $user.userid
```
- 「名前」フィールドに、このレスポンスの一意の名前を入力します(OAMAuthCookie)。
- 「タイプ」リストから「Cookie」を選択します。
- 「値」フィールドに、このレスポンスの値を入力します。例: $user.userid。
- 「適用」をクリックしてレスポンスを送信し、「確認」ウィンドウを閉じます。
- 必要に応じて繰り返します。
「OAMCustomMembershipProviderの構成およびデプロイ」に進みます。

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

Access Manager認証モジュールを使用してユーザーを認証および認可できます。

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

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

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

SharePoint Webサイト・ディレクトリの物理的な場所に移動します。次に例を示します。
```
C:\Inetpub\wwwroot\wss\VirtualDirectories\SharePoint website Name
```
folder_formsから、ファイルDefault.aspxをDefault.ORIG.aspxとしてコピーします。

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>

IISマネージャに移動し、サイトの前のプラス・アイコン(+)をクリックします。
SharePoint Webサービスの前のプラス・アイコン(+)をクリックします。
「SecurityTokenServiceApplication」を右クリックし、「エクスプローラ」をクリックします。
Web.configのバックアップ・コピーをWeb.config.ORIGとして作成し、Web.configを開きます。
メンバーシップ・プロバイダ・エントリで、LDAPメンバーシップ・プロバイダを有効にするには、<membership>、<providers>、タイプに移動し、タイプ値を次のように変更します。
```
type = "Oracle.CustomMembershipProvider, OAMCustomMembershipProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=52e6b93f6f0427a1
```

ステップ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の説明に従って、認可戻りアクションとして構成する必要があります。

ファイルを保存します。
コマンド・プロンプトを使用して、次のディレクトリに移動します。
```
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil.exe
```
次のように入力します。
```
gacutil -l OAMCustomMembershipProvider
```
結果が戻されないことを確認します。

次のように入力します。

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

次のように入力します。

gacutil -l OAMCustomMembershipProvider

1つの結果が戻されることを確認します。
SharePoint Webサイトを再起動します。
次に進みます。

59.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"

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

Access Managerに対して構成されているディレクトリ・サーバーのユーザーは、SharePointによって使用されるディレクトリ・サーバーと同期している必要があります(これらが異なる場合)。

これは、この章の他の統合シナリオで実行したタスクと同じです。ただし、SharePointの統合にLDAPメンバーシップ・プロバイダが含まれている場合、LDAPコマンドをサポートするディレクトリ・サーバーを使用できます。

関連項目:

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

59.8.10 統合のテスト

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

関連項目:

「SharePoint Serverの統合のテスト」