登録、ログイン、ユーザープロファイル registration-login-and-userprofile

はじめに introduction

Web アプリケーションは、多くの場合、Web サイトへの登録用のアカウント管理機能を提供します。この機能は、ユーザーデータ情報を保持するので、ユーザーは登録後のログインで一貫した操作を楽しむことができます。この記事では、AEM as a Cloud Service の以下の概念について説明します。

登録 registration

エンドユーザーが AEM アプリケーションのアカウントに登録すると、AEM Publish サービスにユーザーアカウントが作成されて、JCR リポジトリーの /home/users 下のユーザーリソースに反映されます。

以下に示すように、登録を実装するには 2 つの方法があります。

AEM 管理 aem-managed-registration

少なくともユーザーの名前とパスワードを受け取り、AEM でユーザーレコードを作成して、ログイン時の認証に使用できるように、カスタム登録コードを記述できます。通常、この登録メカニズムの構築には次の手順を使用します。

外部 web アプリケーション external-managed-registration

場合によっては、AEM 以外のインフラストラクチャで登録やユーザーの作成が既に行われています。このシナリオでは、ログイン時に AEM にユーザーレコードが作成されます。

ログイン login

エンドユーザーが AEM Publish サービスに登録されると、これらのユーザーは、ログインして認証済みアクセス（AEM 認証メカニズムを使用）および持続的なユーザー固有のデータ（プロファイルデータなど）を取得できます。

実装 implementation

ログインは、次の 2 つの方法で実装できます。

AEM 管理 aem-managed-implementation

顧客は独自のカスタムコンポーネントを作成できます。詳しくは、以下を参照してください。

ID プロバイダーとの統合 integration-with-an-idp

顧客は、ユーザーを認証する IdP（ID プロバイダー）と統合できます。以下に示すように、統合テクノロジーには SAML および OAuth/SSO あどがあります。

SAML ベース

顧客は、好みの SAML IdP を使用して SAML ベースの認証を使用できます。AEM で IdP を使用する場合、SAML アサーションで説明されているように、IdP はエンドユーザーの資格情報の認証、ユーザー認証の AEM での転送、AEM でのユーザーレコードの作成（必要な場合）、および AEM でのユーザーグループのメンバーシップの管理を行います。

SAML 2.0 認証ハンドラーについて詳しくは、ドキュメントを参照してください。

OAuth/SSO

AEM SSO 認証ハンドラーサービスの使用について詳しくは、シングルサインオン（SSO）のドキュメントを参照してください。

com.adobe.granite.auth.oauth.provider インターフェイスは、任意の Oauth プロバイダーを使用して実装できます。

スティッキーセッションとカプセル化されたトークン sticky-sessions-and-encapsulated-tokens

AEM as a Cloud Service では cookie ベースのスティッキーセッションが有効になっており、エンドユーザーはリクエストのたびに同じ公開ノードにルーティングされます。パフォーマンスを向上させるために、カプセル化されたトークンの機能がデフォルトで有効になっているので、リポジトリ内のユーザーレコードを各リクエストで参照する必要はありません。エンドユーザーに親和性のある公開ノードが置き換えられた場合、以下のデータ同期のセクションで説明するように、ユーザー ID レコードは新しい公開ノードで使用できます。

ユーザープロファイル user-profile

データを保存する方法は、データの性質に応じて様々です。

AEM リポジトリー aem-repository

ユーザープロファイル情報の書き込みと読み取りは、次の 2 つの方法で行うことができます。

サードパーティのデータストア third-party-data-stores

エンドユーザーデータは、CRM などのサードパーティベンダーに送信し、ユーザーが AEM にログインする時に API を介して取得できます。また、AEM ユーザーのプロファイルノードで保持（または更新）され、必要に応じて AEM で使用できます。

サードパーティのサービスにリアルタイムでアクセスしてプロファイル属性を取得することはできますが、これが実質的に AEM のリクエスト処理に影響を与えないようにすることが重要です。

権限（クローズドユーザーグループ） permissions-closed-user-groups

パブリッシュ層アクセスポリシー（クローズドユーザーグループ（CUG）とも呼ばれる）は、AEM オーサーではここで説明されているとおりに定義されています。一部のユーザーから web サイトの特定のセクションまたはページを制限するには、ここで説明されているように AEM オーサーを使用して、必要に応じて CUG を適用し、パブリッシュ層に複製します。

ログインとは別に、カスタムコードは、組織の固有の要件に応じて、ユーザーのグループメンバーシップを保持および管理することもできます。

データ同期 data-synchronization

Web サイトのエンドユーザーは、別のブラウザーを使用してログインした場合、知らないうちに、パブリッシュ層インフラストラクチャの異なるサーバーノードに接続されたとしても,すべての web ページリクエストで一貫したエクスペリエンスを期待しています。AEM as a Cloud Service は、/home フォルダー階層（ユーザープロファイル情報、グループメンバーシップなど）をパブリッシュ層のすべてのノード間で迅速に同期することでこれを実現します。

他の AEM ソリューションとは異なり、AEM as a Cloud Service でのユーザーとグループメンバーシップの同期では、ポイントツーポイントメッセージングアプローチを使用せず、ユーザーの設定を必要としない公開サブスクライブアプローチを実装します。

キャッシュに関する考慮事項 cache-considerations

認証済みの HTTP リクエストは、CDN とディスパッチャーの両方でキャッシュするのが困難な場合があります。これは、リクエストの応答の一部としてユーザー固有のステートが転送される可能性があるからです。認証済みのリクエストを誤ってキャッシュして他のリクエスト元のブラウザーに提供すると、誤ったエクスペリエンスが発生したり、保護されたリクエストやユーザーデータが漏洩したりする場合があります。

ユーザー固有の応答をサポートしながら、リクエストの高いキャッシュ機能を維持する方法には次のようなものがあります。