フェデレーション認証を構成する

Version: 10.4
日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

フェデレーション認証を使用して、ユーザーが外部プロバイダーを通じてSitecoreにログインできるようにします。フェデレーション認証では、使用する外部プロバイダーに応じて、特定の方法でSitecoreを設定する必要があります。フェデレーション認証の設定には、いくつかのタスクが含まれます。

IDプロバイダーを構成する

使用するIDプロバイダーを構成する必要があります。これを行う方法は、使用するプロバイダーによって異なります。主なユース ケースは、Azure Active Directory (Azure AD) を使用することです。 OpenID ConnectとAzure Active Directoryを使用してWebアプリケーションへのアクセスを承認 する では、Azure ADのしくみについて説明します。

IDプロバイダーを構成するには、次のようにします。

  1. configuration/sitecore/federatedAuthentication/identityProvidersノードにパッチを適用するには、identityProviderという名前の新しいノードを作成します。

  2. id属性とtype属性の値を入力します。typeは、抽象クラスSitecore.Owin.Authentication.Configuration.IdentityProvider.Sitecoreにはデフォルトの実装であるSitecore.Owin.Authentication.Configuration.DefaultIdentityProviderがあります。

  3. 作成したノードの下に、paramcaptiondomainclearroleswhensignin 、およびtransformations子ノードの値を入力します。

    メモ

    clearroleswhensignin設定は、ユーザーに割り当てられたロールをSitecoreで管理するか、外部IDプロバイダーで管理するかを決定します。

    デフォルト値はfalseです。つまり、Sitecoreでユーザーにすでに割り当てられているロールは保持されます。設定をtrueに変更すると、ユーザーがログインすると、ユーザーが既にSitecoreに持っているロールはすべて削除され、外部プロバイダーでユーザーに割り当てられたロールに置き換えられます。

  4. configuration/sitecore/federatedAuthentication/identityProvidersPerSitesノードの下に、mapEntryという名前の新しいノードを作成します。

  5. name属性とtype属性の値を入力します。name属性の値は、エントリごとに一意である必要があります。typeは、Sitecore.Owin.Authentication.Collections.IdentityProvidersPerSitesMapEntrySitecore.Owin.Authentication、またはこれから継承する必要があります。

  6. resolve 属性の値としてtrueを入力します。

  7. 作成したノードの下に、sites (プロバイダーが動作するサイトの一覧)、identityProviders (プロバイダーの一覧)、およびexternalUserBuilder子ノードの値を入力します。各externalUserBuilderノードのresolve属性の値としてtrueを入力します。

    手記

    これはSXAサイトにも当てはまります。

プロバイダーのコードを追加する

owin.identityProvidersパイプライン用に新しいプロセッサを作成する必要があります。

新しいプロセッサを作成するには、次のようにします。

  1. Sitecore.Owin.Authentication.Pipelines.IdentityProviders.IdentityProvidersProcessorクラスを継承します。

  2. IdentityProviderNameプロパティを、設定のidentityProviderに指定した名前で上書きします。

  3. ProcessCoreメソッドをオーバーライドします。

owin.identityProvidersパイプラインと統合する

次に、コードをowin.identityProvidersパイプラインに統合する必要があります。

たとえば、このサンプルでは、IDプロバイダーとしてAzure ADを使用しています。

RequestResponse
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
  <sitecore role:require="Standalone or ContentDelivery or ContentManagement">
    <pipelines>
      <owin.identityProviders>
        <processor type="Sitecore.Owin.Authentication.YourIdentityProviders.AzureAd, YourAssembly" resolve="true" />
      </owin.identityProviders>
    </pipelines>
  </sitecore>
</configuration>  

Sitecoreユーザー名の生成

ユーザー名は、Sitecoreインスタンス全体で一意である必要があります。異なる外部プロバイダーのユーザー名をSitecoreユーザー名として使用することはできません。これは、ユーザー名が一意であることを保証するものではないためです。

DefaultExternalUserBuilderクラスは、特定の外部ユーザー名に対してユーザー名のシーケンスを作成します。次に、Sitecoreにまだ存在しないこれらの名前の最初の名前を使用します。シーケンスの値は、外部ユーザー名と、特定のIDプロバイダーに設定されたSitecoreドメインにのみ依存します。

要求とロールのマッピング

プロバイダーはクレームを発行し、各クレームに1つ以上の値を付与します。Sitecoreは、外部認証プロセス中に認証されたユーザーに対して発行されたクレームを読み取ります。一部のリソースへのアクセスを、特定の要求のみを持つID (クライアントまたはユーザー) に制限できます。

外部ユーザーとは、要求を持つユーザーです。クレームをロールにマッピングすると、Sitecoreのロールベースの認証システムで外部ユーザーを認証できます。

要求をロールにマップするには:

  1. <identityProvider>ノードをconfiguration/sitecore/federatedAuthentication/identityProviders.

  2. <identityProvider>ノードに<transformations hint="list:AddTransformation">ノードを追加します。

  3. 変換ノードを子ノードとして追加します。

    たとえば、変換ノードは次のようになります。

    RequestResponse
    <transformation type="Sitecore.Owin.Authentication.Services.DefaultTransformation, Sitecore.Owin.Authentication">
      <sources hint="raw:AddSource">
        <claim name="groups" value="f04b11c5-323f-41e7-ab2b-d70cefb4e8d0" />
        <claim name="groups" value="40901f21-29d0-47ae-abf5-184c5b318471" />
      </sources>
      <targets hint="raw:AddTarget">
        <claim name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" value="Sitecore\Developer" />
      </targets>
      <keepSource>true</keepSource>
    </transformation>
    • typeは、Sitecore.Owin.Authentication.Services.Transformationクラスから継承する必要があります。

    • この例では、変換によって、名前がhttp://schemas.microsoft.com/ws/2008/06/identity/claims/roleで、値がSitecore\Developerという要求が、名前がgroupで、値がf04b11c5-323f-41e7-ab2b-d70cefb4e8d040901f21-29d0-47ae-abf5-184c5b318471の2つの要求を持つIDに、変換によって追加されます。

    • keepSource==true元の要求 (この例では2つのgroup要求) を削除しないことを指定します。既定値はfalseで、変換がIDに正常に適用された場合、元の要求は <targets> ノードに記述されている要求に置き換えられます。

    • keepSource==true元の要求 (この例では2つのgroup要求) を削除しないことを指定します。Sitecoreでは、Sitecore.Owin.Authentication.Services.DefaultTransformationkeepSourceのデフォルト値はfalseで、変換がIDに正常に適用された場合、元の要求は <targets> ノードに記述されているものに置き換えられます。

      手記

      Identity Serverでは、Sitecore.Plugin.IdentityProviders.DefaultClaimsTransformationのデフォルト値keepSource trueです。

手記

sitecore/federatedAuthentication/sharedTransformationsノードで要求変換を指定した場合、これらの変換はすべてのIDプロバイダーに対して行われます。

マップのプロパティ

IDクレームは、ユーザー プロファイルに保存されているSitecoreユーザー プロパティにマッピングする必要があります。

sitecore\federatedAuthenticationノードの下にあるpropertyInitializerノードには、マップの一覧が格納されます。各マップには、内部ソースノードとターゲットノードがあります。これらのノードには、namevalueの2つの属性があります。プロパティをマップするには、これらのプロパティの値を設定します。

要求がソース ノードのname属性と一致する場合 (指定されている場合はvalue)、ターゲット ノードのname属性で指定されたユーザー プロパティのvalue属性は、一致した要求の値に設定されます (value属性がtargetノードで指定されていない場合)。

例えば:

RequestResponse
<propertyInitializer type="Sitecore.Owin.Authentication.Services.PropertyInitializer, Sitecore.Owin.Authentication">
  <maps hint="list">
    <map name="status to UserStatus"
      type="Sitecore.Owin.Authentication.Services.DefaultClaimToPropertyMapper, Sitecore.Owin.Authentication">
      <data hint="raw:AddData">
        <source name="status" value="first" />
        <target name="UserStatus" value="1" />
      </data>
    </map>
  </maps>
</propertyInitializer>

この例では、ソースname属性とvalue属性は、UserStatusターゲットの名前と値1にマップされます。

大事な

設定ファイルを分割する場合は、name属性をマップ ノードに追加して、ノードがすべてのファイルで一意であることを確認する必要があります。これは、Sitecore設定のパッチ適用の仕組みによるものです。

カスタム・ユーザー・プロパティーのマッピング

カスタムユーザープロパティは、Sitecore.Owin.Authentication.Services.DefaultClaimToPropertyMapperが保存できる2つの場所にマップできます。

  • ユーザーが仮想ユーザーの場合、プロパティがカスタムであるかどうかに関係なく、Sitecore.Security.Accounts.Userクラスに.RuntimeSettings.Propertiesプロパティとして格納されます。

  • ユーザーが永続的である場合、そのユーザーはSitecore.Security.Accounts.Userクラスに.Profile.CustomPropertiesプロパティとして格納されます。

デバッグや開発の目的で、これらのプロパティを確認することは可能ですが、これらはプライベート プロパティであり、直接アクセスされることは想定されていません。

カスタム機能の場合、これらのプロパティにアクセスする必要がある場合は、Sitecore.Security.Accounts.UserクラスProfileプロパティのインデクサーを使用してアクセスできます。 これにより、ユーザーが仮想か永続かに関係なく、ユーザー プロパティが正しい場所から解決されます。

ユーザーアカウントのConnect

アカウント接続を使用すると、一方の複数の外部アカウントともう一方の永続的なアカウント間でプロファイルデータを共有できます。永続化されたユーザーにロールが割り当てられている場合、フェデレーション認証はこれらを外部アカウントと共有します。

次の状況では、アカウントへの接続は自動的に行われます。Sitecoreは認証されたユーザーをサインアウトし、新しい永続アカウントまたは仮想アカウントを作成してから、認証します。

  • ユーザーはすでにサイトで認証されています。

  • ユーザーは、外部プロバイダーを使用して同じサイトにサインインします。

  • 外部IDと既存の永続アカウントとの間には、まだ接続がありません。ASP.NET Identityでは、signInManager.ExternalSignIn(...)SignInStatus.Failureを返します。

外部IDを既に認証済みのアカウントにバインドするには、依存関係の挿入を使用してSitecore.Owin.Authentication.Services.UserAttachResolverクラスをオーバーライドする必要があります。次の手順は、これを行う例を示しています。

  1. Sitecore.Owin.Authentication.Services.UserAttachResolverクラスを拡張します。

    RequestResponse
    using System;
    
    using System.Threading.Tasks;
    
    using Microsoft.Owin;
    
    using Sitecore.Owin.Authentication.Services;
    
    using Sitecore.Text;
    
    namespace Sitecore.Owin.Authentication.Samples.Services
    
    {
    
        public class SampleUserAttachResolver : UserAttachResolver
    
        {
    
            public override UserAttachResolverResult Resolve(UserAttachContext context)
    
            {
    
                IFormCollection formData = Task.Run(async () => await context.OwinContext.Request.ReadFormAsync()).Result;
    
                string consentResult = formData["uar_action"];
    
                UserAttachResolverResultStatus resultStatus;
    
                if (Enum.TryParse(consentResult, true, out resultStatus))
    
                {
    
                    return new UserAttachResolverResult(resultStatus);
    
                }
    
                string redirectUrl = new UrlBuilder("/dialogs/consent") { ["returnUrl"] = context.ReturnUrl }.ToString();
    
                context.OwinContext.Response.Redirect(redirectUrl);
    
                return new UserAttachResolverResult(UserAttachResolverResultStatus.DelayedResolve);
    
            }
    
        }
    
    }

    Resolveメソッドは、UserAttachContextを値引数として受け取り、コントローラーに要求を送信し、呼び出したコントローラーからの応答を処理します。

  2. MVCコントローラーとレイアウトを作成して、エンドポイントを作成します。

    MVCコントローラー:

    RequestResponse
    using System.Web.Mvc;
    
    namespace Sitecore.Owin.Authentication.Samples.Controllers
    
    {
    
        public class ConsentController : Controller
    
        {
    
            public ActionResult Index()
    
            {
    
                this.ViewBag.User = this.HttpContext.User.Identity.Name;
    
                this.ViewBag.ReturnUrl = this.Request.Params["ReturnUrl"];
    
                return this.View();
    
            }
    
        }
    
    }

    レイアウト:

    RequestResponse
    <html xmlns="http://www.w3.org/1999/xhtml">
      <head>
        <title>Consent window</title>
      </head>
    
      <body>
        <p>
          The @ViewBag.User user is already logged in. Would you like to attach to
          the user or create new record?
        </p>
    
        <br />
    
        <form method="POST" action="@ViewBag.ReturnUrl">
          <button type="submit" name="uar_action" value="attach">Attach</button>
    
          <button type="submit" name="uar_action" value="new">New</button>
        </form>
      </body>
    </html>
  3. 新しいサービス コンフィギュレーター クラスを作成して、拡張クラスをSitecoreに登録します。

    RequestResponse
    using Microsoft.Extensions.DependencyInjection;
    
    using Sitecore.DependencyInjection;
    
    using Sitecore.Owin.Authentication.Samples.Services;
    
    using Sitecore.Owin.Authentication.Services;
    
    namespace Sitecore.Owin.Authentication.Samples.Infrastructure
    
    {
    
        public class ServicesConfigurator : IServicesConfigurator
    
        {
    
            public void Configure(IServiceCollection serviceCollection)
    
            {
    
                serviceCollection.AddSingleton<UserAttachResolver, SampleUserAttachResolver>();
    
            }
    
        }
    
    }
  4. 作成したクラスをカスタム設定ファイルで定義するには、<sitecore> ノードの下に次のノードを追加します。

    RequestResponse
    <services>
    
      <configurator
        type="Sitecore.Owin.Authentication.Samples.Infrastructure.ServicesConfigurator, Sitecore.Owin.Authentication.Samples" />
    
    </services>

プログラマティックアカウント接続管理

Sitecoreはアカウント接続にASP.NET Identityを使用するため、アカウント接続はASP.NET Identity APIと同じ方法で処理されます。

  1. OwinコンテキストからUserManagerオブジェクトを取得します。

    RequestResponse
    using Sitecore.Owin.Authentication.Extensions;
    
    // [...]
    
    IOwinContext context = HttpContext.Current.GetOwinContext();
    
    UserManager<ApplicationUser> userManager = context.GetUserManager();
  2. CRUD操作には、次の方法を使用します。

    RequestResponse
    Task<IdentityResult> AddLoginAsync(ApplicationUser user, UserLoginInfo login);
    
    Task<IdentityResult> RemoveLoginAsync(ApplicationUser user, UserLoginInfo login);
    
    Task<IList<UserLoginInfo>> GetLoginsAsync(ApplicationUser user);
    
    Task<ApplicationUser> FindAsync(UserLoginInfo login);

仮想ユーザーと永続ユーザーの設定

Sitecoreは仮想ユーザーをサポートしています。外部プロバイダーを通じてユーザーを認証すると、Sitecoreは適切なアクセス権を持つ仮想ユーザーを作成して認証します。

ただし、仮想ユーザーを使用することにはいくつかの欠点があります。仮想ユーザープロファイルは、ユーザーセッションが継続する間のみ存在するため、ユーザープロファイルデータをセッション間で保持することはできません。したがって、外部ユーザーごとに実際の永続的なユーザーを作成する必要があります。ユーザーが初めて外部認証を使用すると、Sitecoreは新しいユーザーを作成して保持し、このユーザーを外部IDプロバイダーとそのプロバイダーのユーザー IDにバインドします。次回、ユーザーが同じ外部プロバイダーと同じ資格情報で認証を行うと、Sitecoreは既に作成され永続化されたユーザーを見つけて認証します。

ユーザービルダー

identityProvidersPerSites/mapEntryノードには、externalUserBuilderノードが含まれています。次のようなユーザービルダーを追加します。

  • Sitecore.Owin.Authentication.Services.ExternalUserBuilderを継承するクラスを指定します。ユーザー ビルダーは、外部ユーザー情報に基づいてSitecoreユーザーを作成する責任があります。

    永続ユーザーまたは仮想ユーザーを作成するために設定するデフォルトの実装は、isPersistentUserコンストラクタパラメータに基づいています。

    RequestResponse
    <externalUserBuilder type="Sitecore.Owin.Authentication.Services.DefaultExternalUserBuilder, Sitecore.Owin.Authentication">
        <IsPersistentUser>true</IsPersistentUser>
    </externalUserBuilder>
手記

ユーザー・ビルダーを実装するときは、データベースにユーザーを作成するためにユーザー・ビルダーを使用しないでください。 ApplicationUserクラスのインスタンスのみを作成する必要があります。

ビルダーをサイトに適用する

ユーザー ビルダーを定義するサイトのidentityProvidersPerSitesノード内のmapEntryを検索し、externalUserBuilderノードを指定します。例えば:

RequestResponse
<mapEntry type="Sitecore.FederatedAuthentication.Collections.IdentityProvidersPerSitesMapEntry, Sitecore.FederatedAuthentication">
    <sites hint="list">
        <site>shell</site>
        <site>admin</site>
        <site>website</site>
    </sites>
    <identityProviders hint="list:AddIdentityProvider">mapEntry
        <identityProvider ref="federatedAuthentication/identityProviders/identityProvider[@id='AzureAd']" />
        <identityProvider ref="federatedAuthentication/identityProviders/identityProvider[@id='IdentityServer']" />
    </identityProviders>
    <externalUserBuilder type="Sitecore.Owin.Authentication.Services.DefaultExternalUserBuilder, Sitecore.Owin.Authentication">
         <IsPersistentUser>true</IsPersistentUser>
    </externalUserBuilder>
</mapEntry>

上記の例では、Sitecoreはビルダーをshelladmin、およびwebsitesサイトに適用します。

適用されたビルダーは、関連するサイトのビルダーをオーバーライドします。

何かフィードバックはありますか?

この記事を改善するための提案がある場合は、