SAML 2.0 認証
作成対象:
- 中級
- 開発者
任意の SAML 2.0 互換 IDP に対して(AEM オーサー以外の)エンドユーザーを設定し、認証する方法について説明します。
SAML for AEM as a Cloud Service とは
AEM パブリッシュ(またはプレビュー)との SAML 2.0 統合により、AEM ベースの Web エクスペリエンスのエンドユーザーは、アドビ以外の IDP(ID プロバイダー)に対して認証し、指定された承認済みユーザーとして AEM にアクセスできます。
AEM パブリッシュ SAML 統合の一般的なフローは次のとおりです。
-
ユーザーが、認証が必要であることを示すリクエストを AEM パブリッシュに行います。
- ユーザーが、CUG/ACL で保護されたリソースをリクエストします。
- ユーザーが、認証要件の対象となるリソースをリクエストします。
- ユーザーが、ログインアクションを明示的にリクエストする AEM のログインエンドポイント(つまり、
/system/sling/login
)へのリンクをたどります。
-
AEMが、IDP に認証プロセスの開始をリクエストして、IDP に AuthnRequest を送信します。
-
ユーザーが IDP に対して認証されます。
- ユーザーが、IDP に資格情報の入力を求められます。
- ユーザーが既に IDP で認証されていて、追加の資格情報を提供する必要はありません。
-
IDP が、ユーザーのデータを含む SAML アサーションを生成し、IDP の非公開証明書を使用して署名します。
-
IDP は、HTTP POST 経由で SAML アサーションを、ユーザーの web ブラウザー(RESPECTIVE_PROTECTED_PATH/saml_login)経由で、AEM パブリッシュに送信します。
-
AEM パブリッシュ SAML アサーションを受け取り、IDP 公開証明書を使用して SAML アサーションの整合性と信頼性を検証します。
-
AEM パブリッシュ、SAML 2.0 OSGi 設定と SAML アサーションの内容に基づいて AEM ユーザーレコードを管理します。
- ユーザーを作成する
- ユーザー属性を同期する
- AEM ユーザーグループのメンバーシップを更新する
-
AEM パブリッシュは HTTP 応答に AEM
login-token
Cookie を設定します。これは、AEM パブリッシュへの後続のリクエストを認証するために使用されます。 -
AEM パブリッシュは、
saml_request_path
Cookie で指定された AEM パブリッシュの URL にユーザーをリダイレクトします。
設定の手順
このビデオでは、AEM as a Cloud Service のパブリッシュサービスとの SAML 2.0 統合の設定、および Okta を IDP として使用する方法について説明します。
前提条件
SAML 2.0 認証を設定する場合は、次の操作が必要です。
- デプロイメントマネージャーによる Cloud Manager へのアクセス
- AEM as a Cloud Service 環境への AEM 管理者アクセス
- IDP への管理者アクセス
- SAML ペイロードの暗号化に使用する公開鍵/秘密鍵のペアへのアクセス(オプション)
SAML 2.0 は、AEM パブリッシュまたはプレビューに対するユーザーの認証にのみサポートされます。 IDP を使用して AEM オーサーの認証を管理するには、IDP を Adobe IMS と統合します。
AEM に IDP 公開証明書をインストールする
IDP の公開証明書が AEM グローバルトラストストアに追加され、IDP から送信される SAML アサーションが有効であることを検証するために使用されます。
- ユーザーが IDP に対して認証されます。
- IDP は、ユーザーのデータを含む SAML アサーションを生成します。
- IDP は IDP のプライベート証明書を使用して SAML アサーションに署名します。
- IDP は、署名された SAML アサーションを含む AEM パブリッシュの SAML エンドポイント(
.../saml_login
)へのクライアントサイドの HTTP POST を開始します。 - AEM パブリッシュは、署名済み SAML アサーションを含む HTTP POSTを受け取り、IDP 公開証明書を使用して署名を検証できます。
-
IDP から 公開証明書 ファイルを取得します。この証明書により、AEM は IDP によって AEM に提供される SAML アサーションを検証できます。
証明書は PEM 形式で、次のようになります。
-----BEGIN CERTIFICATE----- MIIC4jCBAcoCCQC33wnybT5QZDANBgkqhkiG9w0BAQsFADAyMQswCQYDVQQGEwJV ... m0eo2USlSRTVl7QHRTuiuSThHpLKQQ== -----END CERTIFICATE-----
-
AEM オーサーに AEM 管理者としてログインします。
-
ツール/セキュリティ/Trust Store に移動します。
-
Global Trust Store を作成するか、開きます。 Global Trust Store を作成する場合は、パスワードを安全な場所に保存します。
-
「証明書を CER ファイルから追加」を展開します。
-
「証明書ファイルを選択」を選択して、IDP から提供される証明書ファイルをアップロードします。
-
「証明書をユーザーにマッピング」を空白のままにします。
-
「送信」を選択します。
-
新しく追加された証明書は、CRT ファイルから証明書を追加 セクションの上に表示されます。
-
エイリアス をメモします。この値は SAML 2.0 認証ハンドラー OSGi 設定で使用されます。
-
「保存して閉じる」を選択します。
Global Trust Store は、AEM オーサー上で IDP の公開証明書を使用して設定されますが、SAML は AEM パブリッシュでのみ使用されるので、AEM パブリッシュで IDP 公開証明書にアクセスできるようにするには、グローバルトラストストアを AEM パブリッシュにレプリケートする必要があります。
-
ツール/デプロイメント/パッケージ に移動します。
-
パッケージを作成する
- パッケージ名:
Global Trust Store
- バージョン:
1.0.0
- グループ:
com.your.company
- パッケージ名:
-
新しい Global Trust Store パッケージを編集します。
-
「フィルター」タブを選択し、ルートパス
/etc/truststore
のフィルターを追加します。 -
「完了」を選択してから、「保存」を選択します。
-
Global Trust Store パッケージの「ビルド」ボタンを選択します。
-
ビルドが完了したら、その他/レプリケート を選択して、Global Trust Store ノード(
/etc/truststore
)を AEM パブリッシュに対してアクティベートします。
認証サービスキーストアの作成
認証サービスのキーストアの作成が必要なのは、SAML 2.0 認証ハンドラーの OSGi 設定プロパティ handleLogout
が true
に設定されている場合か、AuthnRequest 署名/SAML アサーション暗号化が必要な場合です。
-
AEM オーサーに AEM 管理者としてログインし、秘密鍵をアップロードします。
-
ツール/セキュリティ/ユーザー に移動し、authentication-service ユーザーを選択し、上部のアクションバーから「プロパティ」を選択します。
-
「キーストア」タブを選択します。
-
キーストアを作成するか、開きます。 キーストアを作成する場合は、パスワードを安全に保ちます。
- パブリック/プライベートキーストアがこのキーストアにインストールされるのは、AuthnRequest 署名/SAML アサーション暗号化が必要な場合のみです。
- この SAML 統合がログアウトをサポートし、AuthnRequest 署名/SAML アサーションをサポートしていない場合は、空のキーストアで十分です。
-
「保存して閉じる」を選択します。
-
更新された 認証サービス ユーザーを含むパッケージを作成します。
パッケージを使用して次の一時的な回避策を実行します。
-
ツール/デプロイメント/パッケージ に移動します。
-
パッケージを作成する
- パッケージ名:
Authentication Service
- バージョン:
1.0.0
- グループ:
com.your.company
- パッケージ名:
-
新しい 認証サービスキーストア パッケージを編集します。
-
「フィルター」タブを選択し、ルートパス
/home/users/system/cq:services/internal/security/<AUTHENTICATION SERVICE UUID>/keystore
のフィルターを追加します。<AUTHENTICATION SERVICE UUID>
を見つけるには、ツール/セキュリティ/ユーザー に移動し、認証サービス ユーザーを選択します。UUID は、URL の最後の部分です。
-
「完了」を選択してから、「保存」を選択します。
-
認証サービスキーストア パッケージの「ビルド」ボタンを選択します。
-
ビルドが完了したら、その他/レプリケート を選択して、認証サービスキーストアを AEM パブリッシュに対してアクティベートします。
-
AEM の 公開鍵と秘密鍵のペアをインストールする
AEM 公開鍵と秘密鍵のペアのインストールはオプションです
AEM パブリッシュは、(IDP に対して)AuthnRequest に署名し、(AEM に対して)SAML アサーションを暗号化するように設定できます。これは、AEM パブリッシュに秘密鍵を提供し、これが IDP への公開鍵と一致することで実現されます。
AuthnRequest(ログインプロセスを開始する AEM パブリッシュから IDP に対するリクエスト)は、AEM パブリッシュによって署名できます。 これを行うために、AEM パブリッシュは秘密鍵を使用して AuthnRequest に署名し、IDP は公開鍵を使用して署名を検証します。これにより、IDP に対して AuthnRequest が開始され、悪意のあるサードパーティではなく AEM パブリッシュからリクエストされたことが保証されます。
- ユーザーが AEM パブリッシュに HTTP リクエストを送信すると、IDP への SAML 認証リクエストが発生します。
- AEM パブリッシュは、IDP に送信する SAML リクエストを生成します。
- AEM パブリッシュが、AEM 秘密鍵を使用して SAML リクエストに署名します。
- AEM パブリッシュが AuthnRequest を開始します。これは、署名済み SAML リクエストを含む IDP への HTTP クライアントサイドリダイレクトです。
- IDP は AuthnRequest を受け取り、AEM 公開鍵を使用して署名を検証し、AuthnRequest を開始したのが AEM バブリッシュであることを保証します。
- 次に、AEM パブリッシュは、IDP 公開証明書を使用して、復号化された SAML アサーションの整合性と信頼性を検証します。
IDP と AEM パブリッシュ間のすべての HTTP 通信は HTTPS 経由で行うので、デフォルトでセキュリティで保護されています。 ただし、必要に応じて、HTTPS によって提供される機密性に加えてさらなる機密性が必要な場合は、SAML アサーションを暗号化できます。これを行うには、IDP が秘密鍵を使用して SAML アサーションデータを暗号化し、AEM が秘密鍵を使用して SAML アサーションを復号化します。
- ユーザーが IDP に対して認証されます。
- IDP が、ユーザーのデータを含む SAML アサーションを生成し、IDP の非公開証明書を使用して署名します。
- 次に、IDP は AEM の公開鍵で SAML アサーションを暗号化します。この場合、AEM 秘密鍵を復号化する必要があります。
- 暗号化された SAML アサーションは、ユーザーの web ブラウザーを通じて AEM パブリッシュに送信されます。
- AEM パブリッシュは SAML アサーションを受け取り、AEM の秘密鍵を使用して復号化します。
- IDP はユーザーに認証を求めます。
AuthnRequest 署名と SAML アサーション暗号化は両方ともオプションですが、SAML 2.0 認証ハンドラーの OSGi 設定プロパティuseEncryption
を使用して有効になっています。両方とも使用するか両方とも使用しないかを選択できます。
-
AuthnRequest への署名と SAML アサーションの暗号化に使用する公開鍵、秘密鍵(PKCS#8 形式)、および証明書チェーンファイル(公開鍵の場合もあります)を取得します。 キーは、通常、IT 組織のセキュリティチームが提供します。
- 自己署名キーペアは、openssl を使用して生成できます。
$ openssl req -x509 -sha256 -days 365 -newkey rsa:4096 -keyout aem-private.key -out aem-public.crt # Provide a password (keep in safe place), and other requested certificate information # Convert the keys to AEM's required format $ openssl rsa -in aem-private.key -outform der -out aem-private.der $ openssl pkcs8 -topk8 -inform der -nocrypt -in aem-private.der -outform der -out aem-private-pkcs8.der
-
公開鍵を IDP にアップロードします。
- 上記の
openssl
メソッドを使用すると、公開鍵はaem-public.crt
ファイルになります。
- 上記の
-
AEM オーサーに AEM 管理者としてログインし、秘密鍵をアップロードします。
-
ツール/セキュリティ/Trust Store に移動し、authentication-service ユーザーを選択し、上部のアクションバーから「プロパティ」を選択します。
-
ツール/セキュリティ/ユーザー に移動し、authentication-service ユーザーを選択し、上部のアクションバーから「プロパティ」を選択します。
-
「キーストア」タブを選択します。
-
キーストアを作成するか、開きます。 キーストアを作成する場合は、パスワードを安全に保ちます。
-
「秘密鍵を DER ファイルから追加」を選択し、秘密鍵とチェーンファイルを AEM に追加します。
- エイリアス:意味のある名前を指定します。通常は IDP の名前を指定します。
- 秘密鍵ファイル:秘密鍵ファイル(DER 形式の PKCS#8)をアップロードします。
- 上記の
openssl
メソッドを使用する場合、これはaem-private-pkcs8.der
ファイルです
- 上記の
- 証明書チェーンファイルを選択:付属のチェーンファイル(公開鍵の場合もあります)をアップロードします。
- 上記の
openssl
メソッドを使用する場合、これはaem-public.crt
ファイルです
- 上記の
- 「送信」を選択します。
-
新しく追加された証明書は、「CRT ファイルから証明書を追加」セクションの上に表示されます。
- エイリアス をメモしておいてください。このエイリアスは SAML 2.0 認証の OSGi 設定で使用します。
-
「保存して閉じる」を選択します。
-
更新された 認証サービス ユーザーを含むパッケージを作成します。
パッケージを使用して次の一時的な回避策を実行します。
-
ツール/デプロイメント/パッケージ に移動します。
-
パッケージを作成する
- パッケージ名:
Authentication Service
- バージョン:
1.0.0
- グループ:
com.your.company
- パッケージ名:
-
新しい 認証サービスキーストア パッケージを編集します。
-
「フィルター」タブを選択し、ルートパス
/home/users/system/cq:services/internal/security/<AUTHENTICATION SERVICE UUID>/keystore
のフィルターを追加します。<AUTHENTICATION SERVICE UUID>
を見つけるには、ツール/セキュリティ/ユーザー に移動し、認証サービス ユーザーを選択します。UUID は、URL の最後の部分です。
-
「完了」を選択してから、「保存」を選択します。
-
認証サービスキーストア パッケージの「ビルド」ボタンを選択します。
-
ビルドが完了したら、その他/レプリケート を選択して、認証サービスキーストアを AEM パブリッシュに対してアクティベートします。
-
SAML 2.0 認証ハンドラーの設定
AEM の SAML 設定は、Adobe Granite SAML 2.0 Authentication Handler の OSGi 設定により行われます。
設定は OSGi ファクトリ設定です。つまり、1 つの AEM as a Cloud Service パブリッシュサービスに、リポジトリの個別のリソースツリーをカバーする複数の SAML 設定がある場合があります。これは、マルチサイト AEM のデプロイメントに役立ちます。
Adobe Granite SAML 2.0 Authentication Handler の OSGi 設定
path
/
idpUrl
idpCertAlias
idpHttpRedirect
false
true
に設定されます。idpIdentifier
serviceProviderEntityId
が代わりに使用されます。assertionConsumerServiceURL
<Response>
メッセージの送信先を AEM に指定する、AuthnRequest の AssertionConsumerServiceURL
URL 属性。serviceProviderEntityId
useEncryption
true
spPrivateKeyAlias
と keyStorePassword
の設定が必要です。spPrivateKeyAlias
authentication-service
ユーザーのキーストアにある秘密鍵のエイリアス。useEncryption
が true
に設定されている場合は必須です。keyStorePassword
useEncryption
が true
に設定されている場合は必須です。defaultRedirectUrl
/
/content/wknd/us/en/html
)を指定することができます。userIDAttribute
uid
Subject:NameId
を空白のままにします。createUser
true
userIntermediatePath
/home/users/<userIntermediatePath>/jane@wknd.com
)。createUser
を true
に設定する必要があります。synchronizeAttributes
[ "saml-attribute-name=path/relative/to/user/node" ]
(例:[ "firstName=profile/givenName" ]
)。AEM ネイティブ属性の全リストをご覧ください。addGroupMemberships
true
groupMembershipAttribute
groupMembership
addGroupMemberships
に true
を設定する必要があります。defaultGroups
[ "wknd-user" ]
)。addGroupMemberships
に true
を設定する必要があります。nameIdFormat
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
storeSAMLResponse
false
cq:User
ノードに samlResponse
値が格納されているかどうかを示します。handleLogout
false
logoutUrl
が設定されている必要があります。logoutUrl
handleLogout
が true
に設定されている場合は必須です。clockTolerance
60
digestMethod
http://www.w3.org/2001/04/xmlenc#sha256
signatureMethod
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
identitySyncType
default
か idp
のどちらかにする必要があります。default
from
のデフォルトは変更しないでください。service.ranking
5002
path
でも、より上位の設定をお勧めします。AEM ユーザー属性
AEM は次のユーザー属性を使用し、Adobe Granite SAML 2.0 Authentication Handler OSGi 設定の synchronizeAttributes
プロパティで入力できます。任意の IDP 属性は任意の AEM ユーザープロパティに同期できますが、AEM の属性プロパティ(次に示す)を使用するようにマッピングすると、AEM で自然に使用できます。
rep:User
ノードからの相対的なプロパティパスMrs
)profile/title
profile/givenName
profile/familyName
profile/jobTitle
profile/email
profile/street
profile/city
profile/postalCode
profile/country
profile/phoneNumber
profile/aboutMe
-
プロジェクト内の
/ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~saml.cfg.json
に OSGi 設定ファイルを作成し、IDE で開いてください。/wknd-examples/
を/<project name>/
に変更します。- ファイル名の
~
の後の識別子は、この設定を一意に識別する必要があるため、...~okta.cfg.json
のような IDP の名前にできます。値は英数字でハイフンを使用する必要があります。
-
次の JSON を「
com.adobe.granite.auth.saml.SamlAuthenticationHandler~...cfg.json
」ファイルに貼り付け、必要に応じてwknd
の参照を更新してください。{ "path": [ "/content/wknd", "/content/dam/wknd" ], "idpCertAlias": "$[env:SAML_IDP_CERT_ALIAS;default=certalias___1652125559800]", "idpIdentifier": "$[env:SAML_IDP_ID;default=http://www.okta.com/exk4z55r44Jz9C6am5d7]", "idpUrl": "$[env:SAML_IDP_URL;default=https://dev-5511372.okta.com/app/dev-5511372_aemasacloudservice_1/exk4z55r44Jz9C6am5d7/sso/saml]", "serviceProviderEntityId": "$[env:SAML_AEM_ID;default=https://publish-p123-e456.adobeaemcloud.com]", "useEncryption": false, "createUser": true, "userIntermediatePath": "wknd/idp", "synchronizeAttributes":[ "firstName=profile/givenName" ], "addGroupMemberships": true, "defaultGroups": [ "wknd-users" ] }
-
プロジェクトに応じて、値を更新してください。設定プロパティの説明については、上記の SAML 2.0 Authentication Handler OSGi 設定用語集 を参照してください。
-
OSGi 環境変数とシークレットは、リリースサイクルと同期して値が変化する可能性がある場合や、類似の環境タイプやサービス層間で値が異なる場合に使用することが推奨されますが、必須ではありません。デフォルト値は、上記のように
$[env:..;default=the-default-value]"
構文で設定できます。
環境ごとの OSGi 設定(config.publish.dev
、config.publish.stage
および config.publish.prod
)は、SAML 設定が環境によって異なる場合に、特定の属性を使用して定義できます。
暗号化を使用
AuthnRequest と SAML アサーションを暗号化する場合、プロパティとして useEncryption
、spPrivateKeyAlias
、keyStorePassword
の 3 つが必要です。keyStorePassword
はパスワードを含むので、その値は OSGi 設定ファイルに保存してはならず、秘密の設定値を使って挿入する必要があります。
-
/ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~saml.cfg.json
を IDE で開きます。 -
次のように、
useEncryption
、spPrivateKeyAlias
、keyStorePassword
の 3 つのプロパティを追加します。{ "path": [ "/content/wknd", "/content/dam/wknd" ], "idpCertAlias": "$[env:SAML_IDP_CERT_ALIAS;default=certalias___1234567890]", "idpIdentifier": "$[env:SAML_IDP_ID;default=http://www.okta.com/abcdef1235678]", "idpUrl": "$[env:SAML_IDP_URL;default=https://dev-5511372.okta.com/app/dev-123567890_aemasacloudservice_1/abcdef1235678/sso/saml]", "serviceProviderEntityId": "$[env:SAML_AEM_ID;default=https://publish-p123-e456.adobeaemcloud.com]", "useEncryption": true, "spPrivateKeyAlias": "$[env:SAML_AEM_KEYSTORE_ALIAS;default=aem-saml-encryption]", "keyStorePassword": "$[secret:SAML_AEM_KEYSTORE_PASSWORD]", "createUser": true, "userIntermediatePath": "wknd/idp" "synchronizeAttributes":[ "firstName=profile/givenName" ], "addGroupMemberships": true, "defaultGroups": [ "wknd-users" ] }
-
暗号化に必要な 3 つの OSGi 設定プロパティは次のとおりです。
useEncryption
をtrue
に設定spPrivateKeyAlias
には、SAML 統合で使用される秘密鍵のキーストアエントリエイリアスが含まれます。keyStorePassword
には、authentication-service
ユーザーキーストアのパスワードを含んだ OSGi 秘密鍵設定変数が含まれます。
リファラーフィルターの設定
SAML 認証プロセスにおいて、IDP は AEM パブリッシュの .../saml_login
エンドポイントに対してクライアントサイドの HTTP POST を開始します。IDP と AEM パブリッシュが異なる接触チャネルに存在する場合、AEM パブリッシュの リファラーフィルター は、OSGi 設定を介して IDP の接触チャネルからの HTTP POST を許可するように設定されます。
-
プロジェクト内の
/ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/org.apache.sling.security.impl.ReferrerFilter.cfg.json
に OSGi 設定ファイルを作成(または編集)します。/wknd-examples/
を/<project name>/
に変更します
-
allow.empty
の値がtrue
に設定され、allow.hosts
(または必要に応じて、allow.hosts.regexp
)に IDP のオリジンが含まれ、filter.methods
にPOST
が含まれていることを確認してください。OSGi の設定は次のようになります。{ "allow.empty": true, "allow.hosts.regexp": [ ], "allow.hosts": [ "$[env:SAML_IDP_REFERRER;default=dev-123567890.okta.com]" ], "filter.methods": [ "POST", ], "exclude.agents.regexp": [ ] }
AEM パブリッシュは、1 つのリファラーフィルター設定をサポートしているので、SAML 設定要件と既存の設定を結合します。
環境ごとの OSGi 設定(config.publish.dev
、config.publish.stage
および config.publish.prod
)は、allow.hosts
(または allow.hosts.regex
)が環境間で異なる場合、特定の属性で定義できます。
クロスオリジンリソース共有(CORS)の設定
SAML 認証プロセスにおいて、IDP は AEM パブリッシュの .../saml_login
エンドポイントに対してクライアントサイドの HTTP POST を開始します。IDP と AEM パブリッシュが異なるホストやドメインに存在する場合、AEM パブリッシュの クロスオリジンリソース共有(CORS) は、IDP のホストまたはドメインからの HTTP POST を許可するように設定されている必要があります。
この HTTP POST リクエストの Origin
ヘッダーの値は通常、AEM パブリッシュホストとは異なるので、CORS 設定が必要です。
ローカル AEM SDK(localhost:4503
)で SAML 認証をテストする場合、IDP は Origin
ヘッダーを null
に設定する場合があります。その場合は、alloworigin
リストに "null"
を追加します。
-
プロジェクト内に OSGi 設定ファイル(
/ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.cors.impl.CORSPolicyImpl~saml.cfg.json
)を作成します。/wknd-examples/
をプロジェクト名に変更します。- ファイル名の
~
の後の識別子は、この設定を一意に識別するので、...CORSPolicyImpl~okta.cfg.json
のような IDP の名前にすることができます。値は英数字でハイフンを使用する必要があります。
-
次の JSON を
com.adobe.granite.cors.impl.CORSPolicyImpl~...cfg.json
ファイルにペーストします。
{
"alloworigin": [
"$[env:SAML_IDP_ORIGIN;default=https://dev-1234567890.okta.com]",
"null"
],
"allowedpaths": [
".*/saml_login"
],
"supportedmethods": [
"POST"
]
}
環境ごとの OSGi 設定(config.publish.dev
、config.publish.stage
および config.publish.prod
)は、alloworigin
と allowedpaths
が環境ごとに異なる場合、特定の属性で定義することができます。
AEM Dispatcher の設定による SAML HTTP POST の許可
IDP への認証に成功すると、IDP は HTTP POST を調整して AEM の登録済み /saml_login
エンドポイント(IDP に設定済み)に返します。この /saml_login
への HTTP POSTは、Dispatcher でデフォルトでブロックされるので、次の Dispatcher ルールを使用して明示的に許可する必要があります。
- IDE で
dispatcher/src/conf.dispatcher.d/filters/filters.any
を開きます。 - ファイルの一番下に、
/saml_login
で終わる URL への HTTP POST を許可するルールを追加します。
...
# Allow SAML HTTP POST to ../saml_login end points
/0190 { /type "allow" /method "POST" /url "*/saml_login" }
Apache web サーバーで URL の書き換えが設定されている場合(dispatcher/src/conf.d/rewrites/rewrite.rules
)、.../saml_login
エンドポイントへのリクエストが誤ってマングリングされないようにします。
動的グループメンバーシップ
動的グループメンバーシップは、グループの評価とプロビジョニングのパフォーマンスを向上させる Apache Jackrabbit Oak の機能です。この節では、この機能が有効な場合のユーザーとグループの保存方法、および SAML 認証ハンドラーの設定を変更して新しい環境または既存の環境に対して有効にする方法について説明します。
新しい環境で SAML ユーザーの動的グループメンバーシップを有効にする方法
新しい AEM as a Cloud Service 環境でのグループ評価パフォーマンスを大幅に向上させるには、新しい環境での動的グループメンバーシップ機能のアクティベーションをお勧めします。
また、これは、データ同期をアクティブ化する際にも必要な手順です。詳しくは、こちらを参照してください。
これを行うには、OSGI 設定ファイルに次のプロパティを追加します。
/apps/example/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~example.cfg.json
この設定では、ユーザーとグループは Oak 外部ユーザーとして作成されます。AEM では、外部ユーザーとグループには、[user name];[idp]
または [group name];[idp]
で構成されるデフォルトの rep:principalName
があります。
アクセス制御リスト(ACL)は、ユーザーまたはグループの PrincipalName に関連付けられます。
以前に identitySyncType
を指定していなかったか、default
に設定した既存のデプロイメントにこの設定をデプロイすると、新しいユーザーとグループが作成され、これらの新しいユーザーとグループに ACL を適用する必要があります。外部グループにローカルユーザーを含めることはできません。Repoinit は、ユーザーがログインを実行する際にのみ作成される場合でも、SAML 外部グループの ACL の作成に使用できます。
ACL でのこのリファクタリングを回避することを目的に、標準の移行機能が実装されました。
動的グループメンバーシップを使用してローカルグループと外部グループにメンバーシップを保存する方法
ローカルグループでは、グループメンバーは oak 属性 rep:members
に保存されます。属性には、グループのすべてのメンバーの UID のリストが含まれます。詳しくは、こちらを参照してください。
例:
{
"jcr:primaryType": "rep:Group",
"rep:principalName": "operators",
"rep:managedByIdp": "SAML",
"rep:members": [
"635afa1c-beeb-3262-83c4-38ea31e5549e",
"5e496093-feb6-37e9-a2a1-7c87b1cec4b0",
...
],
...
}
動的グループメンバーシップを持つ外部グループでは、グループエントリにメンバーが保存されません。
代わりに、グループメンバーシップがユーザーエントリに保存されます。追加のドキュメントについて詳しくは、こちらを参照してください。例えば、次はグループの OAK ノードです。
{
"jcr:primaryType": "rep:Group",
"jcr:mixinTypes": [
"rep:AccessControllable"
],
"jcr:createdBy": "",
"jcr:created": "Tue Jul 16 2024 08:58:47 GMT+0000",
"rep:principalName": "GROUP_1;aem-saml-idp-1",
"rep:lastSynced": "Tue Jul 16 2024 08:58:47 GMT+0000",
"jcr:uuid": "d9c6af8a-35c0-3064-899a-59af55455cd0",
"rep:externalId": "GROUP_1;aem-saml-idp-1",
"rep:authorizableId": "GROUP_1;aem-saml-idp-1"
}
そのグループのユーザーメンバーのノードは、次のとおりです。
{
"jcr:primaryType": "rep:User",
"jcr:mixinTypes": [
"rep:AccessControllable"
],
"surname": "Test",
"rep:principalName": "testUser",
"rep:externalId": "test;aem-saml-idp-1",
"rep:authorizableId": "test",
"rep:externalPrincipalNames": [
"projects-users;aem-saml-idp-1",
"GROUP_2;aem-saml-idp-1",
"GROUP_1;aem-saml-idp-1",
"operators;aem-saml-idp-1"
],
...
}
既存の環境で SAML ユーザーの動的グループメンバーシップを有効にする方法
前の節で説明したように、外部ユーザーとグループの形式は、ローカルユーザーとグループに使用される形式とは少し異なります。外部グループに新しい ACL を定義して新しい外部ユーザーをプロビジョニングすることも、以下に説明するように移行ツールを使用することもできます。
外部ユーザーを含む既存の環境の動的グループメンバーシップの有効化
SAML 認証ハンドラーは、次のプロパティが指定されている場合に外部ユーザーを作成します:"identitySyncType": "idp"
。この場合、このプロパティを "identitySyncType": "idp_dynamic"
に変更することで、動的グループメンバーシップを有効にすることができます。移行は必要ありません。
ローカルユーザーを含む既存の環境の動的グループメンバーシップへの自動移行
SAML 認証ハンドラーは、次のプロパティが指定されている場合にローカルユーザーを作成します:"identitySyncType": "default"
。これは、プロパティを指定しない場合のデフォルト値でもあります。この節では、自動移行手順で実行される手順について説明します。
この移行を有効にする場合、ユーザー認証中に実行され、次の手順で構成されます。
- ローカルユーザーは、元のユーザー名を保持しながら外部ユーザーに移行されます。つまり、移行されたローカルユーザーが外部ユーザーとして機能し、前の節で説明した命名構文に従わずに元のユーザー名を保持します。
[user name];[idp]
の値を持つrep:externalId
という 1 つの追加プロパティが追加されます。ユーザーのPrincipalName
は変更されません。 - SAML アサーションで受信した外部グループごとに、外部グループが作成されます。対応するローカルグループが存在する場合、外部グループはローカルグループにメンバーとして追加されます。
- ユーザーは、外部グループのメンバーとして追加されます。
- その後、ローカルユーザーは、メンバーであったすべての SAML ローカルグループから削除されます。SAML ローカルグループは、OAK プロパティ
rep:managedByIdp
によって識別されます。このプロパティは、属性syncType
を指定していないか、default
に設定した場合に、SAML 認証ハンドラーによって設定されます。
例えば、移行前に user1
がローカルユーザーで、ローカルグループ group1
のメンバーである場合、移行後に次の変更が行われます。user1
は、外部ユーザーになります。属性 rep:externalId
がプロファイルに追加されます。user1
は、外部グループ group1;idp
のメンバーになります。user1
は、ローカルグループ group1
の直接メンバーではなくなりました。group1;idp
は、ローカルグループ group1
のメンバーです。
その後、user1
は、継承を通じてローカルグループ group1
のメンバーになります。
外部グループのグループメンバーシップは、ユーザープロファイルのプロパティ rep:externalPrincipalNames
に保存されます。
動的グループメンバーシップへの自動移行の設定方法
- SAML OSGi 設定ファイル
com.adobe.granite.auth.saml.SamlAuthenticationHandler~...cfg.json
でプロパティ"identitySyncType": "idp_dynamic_simplified_id"
を有効にします。 - 新しい OSGi サービスを、
com.adobe.granite.auth.saml.migration.SamlDynamicGroupMembershipMigration~
で始まるファクトリ PID で設定します。例えば、PID はcom.adobe.granite.auth.saml.migration.SamlDynamicGroupMembershipMigration~myIdP
のようになります。次のプロパティを設定します。
{
"idpIdentifier": "<value of IDP Identifier (idpIdentifier)" property from the "com.adobe.granite.auth.saml.SamlAuthenticationHandler" configuration to be migrated>"
}
複数の SAML 設定を移行するには、com.adobe.granite.auth.saml.migration.SamlDynamicGroupMembershipMigration
の複数の OSGi ファクトリ設定を作成し、それぞれ移行する idpIdentifier
を指定する必要があります。
SAML 設定のデプロイ
OSGi 設定は、Git にコミットし、Cloud Manager を使用して AEM as a Cloud Service にデプロイする必要があります。
$ git remote -v
adobe https://git.cloudmanager.adobe.com/myOrg/myCloudManagerGit/ (fetch)
adobe https://git.cloudmanager.adobe.com/myOrg/myCloudManagerGit/ (push)
$ git add .
$ git commit -m "SAML 2.0 configurations"
$ git push adobe saml-auth:develop
フルスタックデプロイメントパイプラインを使用して、ターゲットの Cloud Manager Git ブランチ(この例では develop
)をデプロイします。
SAML 認証の呼び出し
SAML 認証フローは、特別に作成されたリンクまたはボタンを作成して、AEM サイトの web ページから呼び出すことができます。以下に説明するパラメーターは、必要に応じてプログラムで設定できます。例えば、ログインボタンでは、ボタンのコンテキストに基づいて、SAML 認証が成功した際にユーザーが移動する場所である saml_request_path
を様々な AEM ページに設定できます。
SAML 使用時のセキュリティ保護されたキャッシュ
AEM パブリッシュインスタンスでは、通常、ほとんどのページがキャッシュされます。ただし、SAML で保護されたパスの場合は、キャッシュを無効にするか、auth_checker 設定を使用してセキュリティ保護されたキャッシュを有効にする必要があります。詳しくは、こちらに記載されている詳細を参照してください。
auth_checker を有効にせずに保護されたパスをキャッシュすると、予期しない動作が発生する場合があります。
GET リクエスト
SAML 認証は、次の形式で HTTP GET リクエストを作成して呼び出すことができます。
HTTP GET /system/sling/login
次のクエリパラメーターを指定します。
resource
path
プロパティで定義されている、SAML 認証ハンドラーがリッスンする任意の JCR パスまたはサブパス。saml_request_path
例えば、この HTML リンクは SAML ログインフローをトリガーし、成功するとユーザーを /content/wknd/us/en/protected/page.html
に移動します。これらのクエリパラメーターは、必要に応じてプログラムで設定できます。
<a href="/system/sling/login?resource=/content/wknd&saml_request_path=/content/wknd/us/en/protected/page.html">
Log in using SAML
</a>
POST リクエスト
SAML 認証は、次の形式で HTTP POST リクエストを作成して呼び出すことができます。
HTTP POST /system/sling/login
次のフォームデータを指定します。
resource
path
プロパティで定義されている、SAML 認証ハンドラーがリッスンする任意の JCR パスまたはサブパス。saml_request_path
例えば、この HTML ボタンは HTTP POST を使用して SAML ログインフローをトリガーし、成功するとユーザーを /content/wknd/us/en/protected/page.html
に移動します。これらのフォームデータパラメーターは、必要に応じてプログラムで設定できます。
<form action="/system/sling/login" method="POST">
<input type="hidden" name="resource" value="/content/wknd">
<input type="hidden" name="saml_request_path" value="/content/wknd/us/en/protected/page.html">
<input type="submit" value="Log in using SAML">
</form>
Dispatcher 設定
HTTP GET メソッドと POST メソッドはどちらも AEM の /system/sling/login
エンドポイントへのクライアントアクセスを必要とするので、AEM Dispatcher 経由で許可する必要があります。
GET または POST が使用されているかどうかに基づいて、必要な URL パターンを許可します。
# Allow GET-based SAML authentication invocation
/0191 { /type "allow" /method "GET" /url "/system/sling/login" /query "*" }
# Allow POST-based SAML authentication invocation
/0192 { /type "allow" /method "POST" /url "/system/sling/login" }