これまで、AEM で管理セッションやリソースリゾルバーを取得する主な方法は、Sling に用意されている SlingRepository.loginAdministrative()
および ResourceResolverFactory.getAdministrativeResourceResolver()
メソッドを使用することでした。
ただし、これらのメソッドはいずれも最小権限の原則に基づいて設計されておらず、開発者がコンテンツの構造や対応するアクセス制御レベル(ACL)を早期に適切に計画しないことがよくあります。そのため、このようなサービスに脆弱性があると、コード自体を動作させるのに管理者権限が不要であっても、admin
ユーザーへの権限のエスカレーションが発生することがよくあります。
管理セッションが使用されていなかったり、機能が完全に無効化されている場合があります。現在の実装環境がこれに当てはまる場合は、機能を削除するか、NOP コードを埋め込んでください。
可能な限り機能をリファクタリングし、指定された認証済みのリクエストセッションを使用して、コンテンツの読み取りや書き込みをおこなうことができるようにします。 これができない場合は、多くの場合、次の優先度に従って適用することで達成できます。
問題の多くは、コンテンツの再構築によって解決できます。 再構築を行う際は、次のシンプルなルールに留意してください。
アクセス制御の変更
コンテンツ構造を調整
コードのリファクタリングを行って適切なサービスになるようにする
また、開発する新機能が、次の原則に従っていることを確認します。
コンテンツ構造はセキュリティ要件に基づいて進める必要があります
ノードタイプを使用する
プライバシー設定に配慮する
/profile
ノードにあるプロファイル画像、メールまたは氏名を公開しないようにします。コンテンツの再構築時にアクセス制御を適用したり、新しいサービスユーザーに対してアクセス制御を適用する場合には、可能な限り厳格な ACL を適用する必要があります。考えられるすべてのアクセス制御機能を使用してください。
例えば、jcr:read
を /apps
に適用するのではなく、/apps/*/components/*/analytics
にのみ適用します。
制限を使用します。
ノードタイプに ACL を適用
権限の制限
jcr:write
権限を付与するのではなく、代わりに jcr:modifyProperties
を使用してください。前述の方法がうまくいかない場合は、Sling 7 に用意されているサービスユーザーマッピングサービスを使用して、バンドルとユーザーのマッピングを設定したり、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
は、サービスを提供するバンドルの記号名です。
サービスユーザーは、パスワードが設定されていない JCR ユーザーで、特定のタスクの実行に必要な最小限の権限が設定されています。 パスワードが設定されていない場合、サービスユーザーとのログインはできなくなります。
管理セッションを廃止する方法の 1 つは、管理セッションをサービスユーザーセッションに置き換えることです。 必要に応じて、複数のサブサービスユーザーに置き換えることもできます。
admin セッションをサービスユーザーに置き換えるには、次の手順を実行する必要があります。
最小権限の原則を念頭に置いて、サービスに必要な権限を特定します。
必要な権限設定で既にユーザーが使用できるかどうかを確認します。 必要に応じた既存のユーザーがない場合は、新しいシステムサービスユーザーを作成します。 新しいサービスユーザを作成するには、RTC が必要です。 複数のサブサービスユーザー(例えば、書き込み用と読み取り用に 1 つ)を作成して、アクセスをさらに区分化すると効果的な場合があります。
ユーザーの ACE を設定およびテストします。
サービスおよび user/sub-users
に service-user
マッピングを追加します。
サービスユーザーの sling 機能をバンドルから使用できるようにします。つまり、org.apache.sling.api
を最新バージョンに更新します。
コード内の admin-session
を loginService
API または getServiceResourceResolver
API に置き換えます。
AEMサービスユーザーのリストに含まれるユーザーがユースケースに適用されないこと、および対応する RTC の問題が承認されたことを確認したら、先に進み、新しいユーザーをデフォルトコンテンツに追加できます。
推奨されるアプローチは、リポジトリエクスプローラー(https://<server>:<port>/crx/explorer/index.jsp)を使用するサービスユーザーを作成することです。
目的は、有効な jcr:uuid
プロパティを取得することです。このプロパティは、コンテンツパッケージのインストール環境を使用してユーザーを作成する場合に必須です。
サービスユーザーは次の方法で作成できます。
https://<server>:<port>/crx/explorer/index.jsp のリポジトリエクスプローラーにアクセスします。
管理者としてログインするには、 ログイン リンクをクリックします。
次に、システムユーザーを作成し、名前を付けます。 ユーザーをシステムユーザーとして作成するには、中間パスとして system
を設定し、ニーズに合わせてオプションのサブフォルダーを追加します。
システムユーザーノードが次のようになっていることを確認します。
サービスユーザーに 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](https://sling.apache.org/apidocs/sling7/org/apache/sling/serviceusermapping/ServiceUserMapper.html)
サービスのファクトリ設定を作成する必要があります。このモジュラーを維持するために、 Sling 修正メカニズム. このような設定をバンドルにインストールする場合は、 Sling の初期コンテンツの読み込み:
バンドルの src/main/resources フォルダーの下にサブフォルダー SLING-INF/content を作成します。
このフォルダーに、ファクトリ設定の内容(すべてのサブサービスユーザーマッピングを含む)を定義した org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<ファクトリ設定の一意の名前>.xml という名前のファイルを作成します。例:
バンドルの src/main/resources
フォルダーの下に SLING-INF/content
フォルダーを作成します。
このフォルダーに、ファクトリ設定の内容(すべてのサブサービスユーザーマッピングを含む)を定義した 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>
バンドルの pom.xml
内の maven-bundle-plugin
設定で Sling の初期コンテンツを参照します。例:
<Sling-Initial-Content>
SLING-INF/content;path:=/libs/system/config;overwrite:=true;
</Sling-Initial-Content>
バンドルをインストールし、ファクトリ設定がインストールされていることを確認します。 手順は次のとおりです。
loginAdministrative()
を呼び出すと、多くの場合、共有セッションも表示されます。これらのセッションはサービスのアクティベート時に取得され、サービスが停止された場合にのみログアウトされます。これは一般的な動作ですが、次の 2 つの問題を伴います。
このセキュリティリスクに対する最も明白な解決策は、loginAdministrative()
の呼び出しを loginService()
に置き換え、権限が制限されたユーザーを対象とすることです。ただし、これは、潜在的なパフォーマンス低下には影響しません。 この問題を軽減するには、セッションと関連付けられていないオブジェクト内で要求されたすべての情報をラップします。 次に、オンデマンドでセッションを作成(または破棄)します。
推奨されるアプローチは、呼び出し元がセッションの作成/破壊を制御できるように、サービスの API をリファクタリングすることです。
JSP では、関連するサービスがないので loginService()
を使用できません。ただし、JSP の管理セッションは、通常、MVC パラダイムの違反の兆候を示しています。
これは、次の 2 つの方法で修正できます。
推奨される方法は前者です。
イベントやジョブを処理する場合、場合によっては、イベントをトリガーした対応するセッションは通常失われます。 これにより、多くの場合、管理セッションを使用して作業を行うイベントハンドラーやジョブプロセッサが発生します。 この問題を解決する方法は、それぞれの利点と欠点があり、考えられる方法が異なります。
user-id
をイベントペイロードに渡し、代理実行を使用します。
メリット:容易に使用できます。
デメリット: loginAdministrative()
を使用する必要があります。認証済みのリクエストを再認証します。
データにアクセスできるサービスユーザーを作成または再利用します。
メリット:現在の設計と一貫しています。変更が最小限で済みます。
デメリット:非常に強力なサービスユーザーに柔軟性を持たせる必要があり、権限のエスカレーションが必要になる可能性が高くなります。セキュリティモデルに抜け道ができます。
Subject
のシリアル化をイベントペイロードに渡し、そのサブジェクトに基づいて ResourceResolver
を作成します。例えば、ResourceResolverFactory
で JAAS doAsPrivileged
を使用します。
メリット:セキュリティの観点からクリーンな実装が行えます。再認証を避け、元の権限で動作します。 セキュリティ関連のコードは、イベントの消費者に対して透過的です。
デメリット:リファクタリングが必要です。セキュリティ関連のコードがイベントの消費者に対して透過的であるという事実も、問題を引き起こす可能性があります。
現在、第 3 のアプローチが推奨される処理方法です。
ワークフロープロセスの実装内では、通常、ワークフローをトリガーした対応するユーザーセッションは失われます。 これにより、多くの場合、管理セッションを使用して作業を実行するワークフロープロセスが発生します。
これらの問題を修正するには、 イベント、レプリケーションプリプロセッサー、ジョブの処理 を使用します。
SlingPOST・プロセッサの実装で使用される管理セッションが 2 つあります。 通常、管理セッションは、処理中のPOST内で削除を保留しているノードにアクセスするために使用されます。 その結果、リクエストセッションからは使用できなくなります。 削除待ちのノードにアクセスして、アクセス不可のメタデータを開示することができます。