登録、ログイン、ユーザープロファイル

はじめに

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

• 登録
• ログイン
• ユーザープロファイルデータの保存
• グループメンバーシップ
• データ同期

登録

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

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

AEM 管理

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

1. 登録情報を収集するカスタム AEM コンポーネントを表示します。
2. 送信時に、適切にプロビジョニングされたサービスユーザーが次のことに使用されます。
   1. UserManager API の findAuthorizables() メソッドの 1 つを使用して、既存のユーザーが存在しないことを確認します。
   2. UserManager API の createUser() メソッドの 1 つを使用して、ユーザーレコードを作成します。
   3. Authorizable インターフェイスの setProperty() メソッドを使用して、キャプチャされたプロファイルデータを永続化します。
3. ユーザーにメールの検証を求めるなどの、オプションのフロー。

外部 web アプリケーション

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

ログイン

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

実装

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

AEM 管理

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

• Sling 認証フレームワーク
• あるいは、AEM コミュニティエキスパートセッションにログインについて質問してみてください。

ID プロバイダーとの統合

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

SAML ベース

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

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

OAuth/SSO

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

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

スティッキーセッションとカプセル化されたトークン

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

ユーザープロファイル

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

AEM リポジトリー

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

• サーバーサイドで com.adobe.granite.security.user インターフェイスを使用。UserPropertiesManager インターフェイスにより、/home/users のユーザーのノードの下にデータが配置されます。ユーザーごとに一意のページが、キャッシュされていないことを確認します。
• ドキュメントに説明されているように、クライアントサイドで ContextHub を使用。

サードパーティのデータストア

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

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

権限（クローズドユーザーグループ）

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

• ユーザーが SAML を使用して ID プロバイダー（IdP）の認証でログインすると、認証ハンドラーはユーザーのグループメンバーシップ（パブリッシュ層の CUG と一致する必要がある）を識別し、リポジトリーレコードを介してユーザーとグループの関連付けを保持します。
• IdP 統合を使用せずにログインを完了した場合、カスタムコードは同じリポジトリー構造の関係を適用できます。

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

データ同期

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

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

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

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

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

• AEM ディスパッチャー権限の機密性の高いキャッシュ
• Sling の動的インクルード
• AEM ContextHub

Business.Adobe.com リソース