AEM のサービスユーザー

概要

AEMで管理セッションやリソースリゾルバーを取得する主な方法は、 SlingRepository.loginAdministrative() および ResourceResolverFactory.getAdministrativeResourceResolver() Sling が提供するメソッド。

ただし、これらのメソッドはいずれも最小権限の原則に基づいて設計されておらず、開発者がコンテンツの構造や対応するアクセス制御レベル（ACL）を早期に適切に計画しないことがよくあります。そのため、このようなサービスに脆弱性があると、コード自体を動作させるのに管理者権限が不要であっても、admin ユーザーへの権限のエスカレーションが発生することがよくあります。

管理セッションの廃止方法

優先度 0：機能がアクティブであるか、必要であるか、放置されているかの確認

管理セッションが使用されていなかったり、機能が完全に無効化されている場合があります。現在の実装環境がこれに当てはまる場合は、機能を削除するか、NOP コードを埋め込んでください。

優先度 1：要求セッションの使用

可能な限り、機能のリファクタリングをおこなって、コンテンツの読み取りや書き込みに特定の認証済み要求セッションを使用できるようにしてください。それが可能でなくても、ほとんどの場合は、以降で説明する方法に従って優先度を適用することによって対応できます。

優先度 2：コンテンツの再構築

問題の多くは、コンテンツを再構築することによって解決できます。再構築する際には、次の単純なルールに留意してください。

• アクセス制御を変更する

  • 本当にアクセスを必要とするユーザーまたはグループに実際にアクセス権を付与するようにします。

• コンテンツ構造を調整する

  • コンテンツを他の場所（使用可能な要求セッションとアクセス制御が一致する場所など）に移動します。
  • コンテンツの精度を変更します。

• コードのリファクタリングをおこなって適切なサービスになるようにする

  • JSP コードからサービスにビジネスロジックを移動します。こうすると、様々なコンテンツモデリングが可能になります。

また、新機能を開発する場合は、次の原則に従ってください。

• セキュリティ要件に従ってコンテンツ構造を決定する

  • アクセス制御の管理は自然な形でおこなう必要があります。
  • アクセス制御はアプリケーションではなくリポジトリによって適用する必要があります。

• ノードタイプを使用する

  • 設定可能なプロパティセットを制限します。

• プライバシー設定に配慮する

  • プライベートプロファイルの場合、例えば、プライベートで見つかったプロファイル画像、E メールまたはフルネームを公開しないようにします /profile ノード。

厳格なアクセス制御

コンテンツの再構築時にアクセス制御を適用するか、新しいサービスユーザーに対してアクセス制御を適用するかは、可能な限り厳密な ACL を適用する必要があります。 考えられるすべてのアクセス制御機能を使用してください。

• 例えば、 jcr:read オン /apps、にのみ適用 /apps/*/components/*/analytics

• 制限を使用します。

• ノードタイプに ACL を適用します。

• 権限を制限します。

  • 例えば、プロパティの書き込みのみが必要な場合は、 jcr:write 許可use jcr:modifyProperties 代わりに

サービスユーザーとマッピング

上記の処理が失敗した場合、Sling 7 では、Service User Mapping サービスが提供されます。このサービスでは、バンドルとユーザーのマッピングおよび次の 2 つの対応する API メソッドを設定できます。 [SlingRepository.loginService()](https://sling.apache.org/apidocs/sling7/org/apache/sling/jcr/api/SlingRepository.html#loginService-java.lang.String-java.lang.String-) および [ResourceResolverFactory.getServiceResourceResolver()](https://sling.apache.org/apidocs/sling7/org/apache/sling/api/resource/ResourceResolverFactory.html#getServiceResourceResolver-java.util.Map-) 設定されたユーザーの権限のみを持つセッション/リソースリゾルバーを返す これらのメソッドの特徴は次のとおりです。

• サービスをユーザーにマッピングできます。

• サブサービスユーザーを定義できます。

• 中央設定ポイントは org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl です。

• service-id = service-name [ ":" subservice-name ]

• service-id は、認証用にリソースリゾルバーまたは JCR リポジトリユーザー ID（あるいはその両方）にマッピングされます。

• service-name は、サービスを提供するバンドルの記号名です。

その他の推奨事項

admin-session を service-user に置き換える

サービスユーザーとは、パスワードを設定しておらず、特定のタスクを実行するために必要な最小限の権限を持つ JCR ユーザーのことです。パスワードを設定していないということは、サービスユーザーとしてはログインできないことを意味します。

管理セッションを廃止するには、管理セッションをサービスユーザーセッションに置き換えます。必要に応じて、複数のサブサービスユーザーに置き換えることもできます。

管理セッションをサービスユーザーに置き換えるには、次の手順を実行します。

1. 最小権限の原則を念頭に置いて、サービスに必要な権限を特定します。

2. 必要な権限が正確に設定されたユーザーが既に存在するかどうかをチェックします。既存のユーザーがニーズを満たさない場合は、新しいシステムサービスユーザーを作成します。新しいサービスユーザーを作成するには、RTC が必要です。場合によっては、複数のサブサービスユーザー（例えば、書き込み用と読み取り用にそれぞれ 1 つ）を作成して、アクセスをさらに区分化します。

3. ユーザーに対する ACE を設定してテストします。

4. を追加します。 service-user サービスとのマッピング user/sub-users

5. サービスユーザーの sling 機能をバンドルから使用できるようにします。つまり、org.apache.sling.api を最新バージョンに更新します。

6. を admin-session を loginService または getServiceResourceResolver API

新しいサービスユーザーの作成

ユースケースに適したユーザーが AEM サービスユーザーのリストに存在せず、対応する RTC の発行が承認されていることを確認したら、デフォルトコンテンツに新しいユーザーを追加できます。

推奨されるアプローチは、リポジトリエクスプローラー ( ) を使用するサービスユーザーを作成することです https://<server>:<port>/crx/explorer/index.jsp

目的は、有効な jcr:uuid プロパティを取得することです。このプロパティは、コンテンツパッケージのインストール環境を使用してユーザーを作成する場合に必須です。

サービスユーザーは次の方法で作成できます。

1. リポジトリエクスプローラー ( ) に移動します。 https://<server>:<port>/crx/explorer/index.jsp

2. 画面の左上隅にある「ログイン」リンクをクリックして、admin としてログインします。

3. 次に、システムユーザーを作成して名前を付けます。ユーザーをシステムユーザーとして作成するには、中間パスとして system を設定し、ニーズに合わせてオプションのサブフォルダーを追加します。

   

4. システムユーザーノードが次のようになっていることを確認します。

   

   メモ

   サービスユーザーに mixin タイプが関連付けられていないことに注意してください。これは、システムユーザーに対するアクセス制御ポリシーが存在しないことを意味します。

対応する .content.xml をバンドルのコンテンツに追加する際には、rep:authorizableId を設定し、プライマリタイプを rep:SystemUser にしてください。次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:rep="internal"
    jcr:primaryType="rep:SystemUser"
    jcr:uuid="4917dd68-a0c1-3021-b5b7-435d0044b0dd"
    rep:principalName="authentication-service"
    rep:authorizableId="authentication-service"/>

ServiceUserMapper 設定への修正の追加

サービスから対応するシステムユーザーへのマッピングを追加するには、 [ServiceUserMapper](https://sling.apache.org/apidocs/sling7/org/apache/sling/serviceusermapping/ServiceUserMapper.html) サービスのファクトリ設定を作成する必要があります。この操作をモジュール化するには、Sling 修正メカニズムを使用してこのような設定をおこなうことができます。このような設定をバンドルと共にインストールする場合は、Sling の初期コンテンツ読み込み機能を使用することをお勧めします。

1. バンドルの src/main/resources フォルダーの下にサブフォルダー SLING-INF/content を作成します。

2. このフォルダーに、org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended — という名前のファイルを作成します。<some unique="" name="" for="" your="" factory="" configuration="">.xml を作成し、ファクトリ設定の内容（すべてのサブサービスユーザーマッピングを含む）を保存します。 例：

3. の作成 SLING-INF/content の下のフォルダー src/main/resources バンドルのフォルダー

4. このフォルダーにファイルを作成します named org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<a unique name for your factory configuration>.xml すべてのサブサービスユーザーマッピングを含む、ファクトリ設定のコンテンツを含む

   例示のために、org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-com.adobe.granite.auth.saml.xml というファイルを取り上げています。

   <?xml version="1.0" encoding="UTF-8"?>
   <node>
       <primaryNodeType>sling:OsgiConfig</primaryNodeType>
       <property>
           <name>user.default</name>
           <value></value>
       </property>
       <property>
           <name>user.mapping</name>
           <values>
               <value>com.adobe.granite.auth.saml=authentication-service</value>
           </values>
       </property>
   </node>
   

5. Sling の初期コンテンツを maven-bundle-plugin 内 pom.xml バンドルの 例：

   <Sling-Initial-Content>
      SLING-INF/content;path:=/libs/system/config;overwrite:=true;
   </Sling-Initial-Content>
   

6. バンドルをインストールし、ファクトリ設定がインストールされていることを確認します。手順は次のとおりです。

   • Web コンソール ( ) に移動します。 https://serverhost:serveraddress/system/console/configMgr
   • Apache Sling Service User Mapper Service Amendment を探します。
   • リンクをクリックして、設定が適切におこなわれていることを確認します。

サービスでの共有セッションの処理

への呼び出し loginAdministrative() 多くの場合、共有セッションと一緒に表示されます。 これらのセッションはサービスのアクティベート時に取得され、サービスが停止された場合にのみログアウトされます。これは一般的な方法ですが、次の 2 つの問題が発生します。

• セキュリティ：​このような管理セッションは、共有セッションにバインドされているリソースやその他のオブジェクトをキャッシュしたり、返したりする目的で使用されます。その後、呼び出しスタックではこれらのオブジェクトが昇格された権限でセッションまたはリソースリゾルバーに適応される可能性があり、それが操作中の管理セッションであるかどうかを呼び出し元が判別できなくなることがよくあります。
• パフォーマンス： Oak では、共有セッションはパフォーマンス問題の原因となることがあるので、現在使用は推奨されていません。

セキュリティリスクに対する最も明白な解決策は、 loginAdministrative() 電話で loginService() 1 つは、権限が制限されたユーザーに対するものです。 ただし、この方法は潜在的なパフォーマンスの低下には効果がありません。代わりに、セッションに関連しないオブジェクトに要求されたすべての情報をラップすることによって、パフォーマンスの低下を軽減できる可能性があります。その後、要求に応じてセッションを作成（または破棄）します。

推奨されるアプローチは、サービスの API のリファクタリングをおこなって、呼び出し元がセッションの作成と破棄を制御できるようにすることです。

JSP の管理セッション

JSP は loginService()関連付けられたサービスがないので、個別に読み込むことができます。 しかし、JSP の管理セッションは、通常、MVC パラダイムの違反の兆候です。

これは次の 2 つの方法で解決できます。

1. ユーザーセッションで操作できるようにコンテンツを再構築します。
2. JSP で使用できる API を備えたサービスにロジックを抽出します。

推奨される方法は前者です。

イベント、レプリケーション、プリプロセッサーおよびジョブの処理

イベントやジョブ、場合によってはワークフローを処理する際には、そのイベントのトリガーとなった該当セッションは通常失われます。その結果、イベントハンドラーやジョブプロセッサーでは、多くの場合、管理セッションを使用して処理がおこなわれます。様々なアプローチによってこの問題を解決できますが、それぞれ利点と欠点があります。

1. user-id をイベントペイロードに渡し、代理実行を使用します。

   メリット： 使いやすい。

   デメリット： 使用中 loginAdministrative(). 認証済みの要求が再認証されます。

2. データへのアクセス権限を持つサービスユーザーを作成または再利用します。

   利点：​現在の設計と一貫している。変更が最小限で済みます。

   デメリット： 非常に強力なサービスユーザーが柔軟である必要があり、権限のエスカレーションを容易に引き起こすことができます。 セキュリティモデルに抜け道ができます。

3. Subject のシリアル化をイベントペイロードに渡し、そのサブジェクトに基づいて ResourceResolver を作成します。例えば、doAsPrivileged で JAAS ResourceResolverFactory を使用します。

   利点：​セキュリティの観点からクリーンな実装。再認証は回避し、元の権限で動作します。セキュリティ関連のコードはイベントの消費者に対して透過的です。

   デメリット： リファクタリングが必要です。 セキュリティ関連のコードがイベントの消費者に対して透過的であることから、問題に発展する可能性があります。

3 番目のアプローチが現在推奨されている処理手法です。

ワークフロープロセス

ワークフロープロセス実装では、ワークフローのトリガーとなった該当ユーザーセッションは通常失われます。その結果、ワークフロープロセスでは、多くの場合、管理セッションを使用して処理がおこなわれます。

このような問題を修正するには、イベント、レプリケーション、プリプロセッサーおよびジョブの処理で説明したものと同じアプローチを使用することをお勧めします。

Sling POST プロセッサーと削除されたページ

Sling POST プロセッサーの実装では、いくつかの管理セッションが使用されます。通常、管理セッションは、処理中の POST 内で削除待ちになっているノードにアクセスするために使用されます。そのため、要求セッションからは使用できません。削除待ちのノードにアクセスすると、本来アクセスできないメタデータを取得できます。