Authentification SAML 2.0 saml-2-0-authentication

Découvrez comment configurer et authentifier les utilisateurs finaux (et non les auteurs et autrices AEM) sur le fournisseur d’identité compatible avec SAML 2.0 de votre choix.

Quel SAML pour AEM as a Cloud Service ?

L’intégration de SAML 2.0 au service de publication (ou de prévisualisation) AEM permet aux utilisateurs et utilisatrices finaux d’une expérience web basée sur AEM de s’authentifier auprès d’un fournisseur d’identité hors Adobe et d’accéder à AEM en tant qu’utilisateur autorisé et nommé.

Présentation de la configuration

Cette vidéo décrit comment configurer l’intégration SAML 2.0 au service de publication AEM as a Cloud Service et utiliser Okta comme fournisseur d’identité.

Conditions préalables

Les éléments suivants sont requis lors de la configuration de l’authentification SAML 2.0 :

SAML 2.0 est uniquement pris en charge pour authentifier les utilisateurs et utilisatrices dans le service de publication ou de prévisualisation AEM. Pour gérer l’authentification du service de création AEM à l’aide d’un fournisseur d’identité, intégrez le fournisseur d’identité à Adobe IMS.

Installer le certificat public du fournisseur d’identité sur AEM

Le certificat public du fournisseur d’identité est ajouté à AEM Global Trust Store et utilisé pour vérifier que l’assertion SAML envoyée par le fournisseur d’identité est valide.

.

Le Trust Store global est configuré avec le certificat public du fournisseur d’identité sur l’instance de création AEM, mais comme SAML est utilisé uniquement sur l’instance de publication AEM, le Trust Store global doit être répliqué dans l’instance de publication AEM pour que le certificat public du fournisseur d’identité y soit accessible.

.

Créer un KeyStore pour le service d’authentification authentication-service-keystore

La création d’un KeyStore pour le service d’authentification est requise lorsque la Propriété de configuration OSGi du gestionnaire d’authentification SAML 2.0 handleLogout est définie sur true ou lorsque la signature de la demande d’autorisation/le chiffrement de l’assertion SAML est requis(e).

Installer la paire de clés publique/privée AEM install-aem-public-private-key-pair

L’installation de la paire de clés publique/privée AEM est facultative.

Le service de publication AEM peut être configuré pour signer les requêtes AuthnRequests (pour le fournisseur d’identité) et chiffrer les assertions SAML (pour AEM). Pour ce faire, vous devez fournir une clé privée au service de publication AEM et faire correspondre la clé publique au fournisseur d’identité.

La signature de la requête AuthnRequest et le chiffrement de l’assertion SAML sont facultatifs. Toutefois, ils sont tous deux activés à l’aide de la propriété de configuration OSGi du gestionnaire d’authentification SAML 2.0useEncryption, ce qui signifie qu’il est possible d’utiliser les deux ou aucun des deux.

Configurer le gestionnaire d’authentification SAML 2.0. configure-saml-2-0-authentication-handler

La configuration SAML d’AEM est effectuée via la configuration OSGi du gestionnaire d’authentification SAML 2.0 Adobe Granite.
La configuration est une configuration d’usine OSGi, ce qui signifie qu’un service de publication AEM as a Cloud Service unique peut avoir plusieurs configurations SAML couvrant des arborescences de ressources discrètes du référentiel ; cela est utile pour les déploiements AEM de plusieurs sites.

Les configurations OSGi par environnement (config.publish.dev, config.publish.stage, et config.publish.prod) peuvent être définies avec des attributs spécifiques si la configuration SAML varie entre les environnements.

Utiliser le chiffrement

Lors du chiffrement de l’assertion SAML et de la requête AuthnRequest, les propriétés suivantes sont requises : useEncryption, spPrivateKeyAlias, et keyStorePassword. Le keyStorePassword contient un mot de passe. Par conséquent, la valeur ne doit pas être stockée dans le fichier de configuration OSGi, mais plutôt injectée à l’aide des valeurs de configuration secrètes.

Configurer le filtre de référent

Pendant le processus d’authentification SAML, le fournisseur d’identité lance une requête HTTP POST côté client vers le point d’entrée .../saml_login du service de publication AEM. Si le fournisseur d’identité et le service de publication AEM existent sur une origine différente, le Filtre de référent du service de publication AEM est configuré via la configuration OSGi pour autoriser les requêtes HTTP POST à partir de l’origine du fournisseur d’identité.

Le service de publication AEM prend en charge une configuration de filtre de référent unique. Par conséquent, fusionnez les exigences de configuration SAML avec toutes les configurations existantes.

Les configurations OSGi par environnement (config.publish.dev, config.publish.stage, et config.publish.prod) peuvent être définies avec des attributs spécifiques si allow.hosts (ou allow.hosts.regex) varie selon les environnements.

Configurer le partage des ressources entre origines multiples (CORS)

Pendant le processus d’authentification SAML, le fournisseur d’identité lance une requête HTTP POST côté client vers le point d’entrée .../saml_login du service de publication AEM. Si le fournisseur d’identité et le service de publication AEM existent sur différents hôtes/domaines, le partage de ressources entre origines multiples (CORS) du service de publication AEM doit être configuré pour autoriser les requêtes HTTP POST à partir de l’hôte/du domaine du fournisseur d’identité.

L’en-tête Origin de cette requête HTTP POST a généralement une valeur différente de celle de l’hôte du service de publication AEM, ce qui nécessite une configuration CORS.

Lors du test de l’authentification SAML sur le SDK AEM local (localhost:4503), le fournisseur d’identité peut définir l’en-tête Origin sur null. Si c’est le cas, ajoutez "null" à la liste alloworigin.

{
    "alloworigin": [
        "$[env:SAML_IDP_ORIGIN;default=https://dev-1234567890.okta.com]",
        "null"
    ],
    "allowedpaths": [
        ".*/saml_login"
    ],
    "supportedmethods": [
        "POST"
    ]
}

Les configurations OSGi par environnement (config.publish.dev, config.publish.stage et config.publish.prod) peuvent être définies avec des attributs spécifiques si alloworigin et allowedpaths varient entre les environnements.

Configurer le Dispatcher AEM pour autoriser les requêtes POST HTTP SAML

Une fois l’authentification au fournisseur d’identité réussie, le fournisseur d’identité orchestre une requête POST HTTP vers le point d’entrée /saml_login enregistré AEM (configuré dans le fournisseur d’identité). Cette requête POST HTTP vers /saml_login est bloqué par défaut sur Dispatcher. Elle doit donc être autorisée explicitement à l’aide de la règle Dispatcher suivante :

...

# Allow SAML HTTP POST to ../saml_login end points
/0190 { /type "allow" /method "POST" /url "*/saml_login" }

Si la réécriture de l’URL sur le serveur web Apache est configurée (dispatcher/src/conf.d/rewrites/rewrite.rules), assurez-vous que les requêtes vers les points d’entrée .../saml_login ne sont pas accidentellement tronquées.

Activation de l’appartenance à un groupe dynamique pour les utilisateurs et utilisatrices SAML dans de nouveaux environnements

Pour améliorer considérablement les performances d’évaluation de groupe dans de nouveaux environnements AEM as a Cloud Service, l’activation de la fonctionnalité d’appartenance à un groupe dynamique est recommandée dans de nouveaux environnements.
Cette étape est également nécessaire lorsque la synchronisation des données est activée. Plus de détails ici.
Pour ce faire, ajoutez la propriété suivante au fichier de configuration OSGI :

/apps/example/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~example.cfg.json

Avec cette configuration, les utilisateurs et utilisatrices et les groupes sont créés en tant qu’ utilisateurs et utilisatrices externes d’Oak. Dans AEM, les utilisateurs et utilisatrices et les groupes externes ont une valeur par défaut rep:principalName composée des éléments [user name];[idp] ou [group name];[idp].
Notez que les listes de contrôle d’accès (ACL) sont associées au PrincipalName des utilisateurs et utilisatrices ou des groupes.
Lors du déploiement de cette configuration dans un déploiement existant où identitySyncType n’a pas été auparavant spécifié ou défini sur default, de nouveaux utilisateurs, utilisatrices et groupes sont créés et des listes de contrôle d’accès doivent être appliquées à ces nouveaux utilisateurs, utilisatrices et groupes. Notez que les groupes externes ne peuvent pas contenir d’utilisateurs et d’utilisatrices locaux. Repoinit peut être utilisé pour créer des listes de contrôle d’accès pour les groupes externes SAML, même s’ils ne sont créés que lorsque l’utilisateur ou l’utilisatrice effectue une connexion.
Pour éviter cette refactorisation sur les listes de contrôle d’accès, une fonctionnalité de migration standard a été mise en œuvre.

Stockage des adhésions dans des groupes locaux et externes avec une appartenance à un groupe dynamique

Sur les groupes locaux, les personnes membres du groupe sont stockées dans l’attribut oak : rep:members. L’attribut contient la liste des uid de chaque personne membre du groupe. Vous trouverez des détails supplémentaires ici.
Exemple :

{
  "jcr:primaryType": "rep:Group",
  "rep:principalName": "operators",
  "rep:managedByIdp": "SAML",
  "rep:members": [
    "635afa1c-beeb-3262-83c4-38ea31e5549e",
    "5e496093-feb6-37e9-a2a1-7c87b1cec4b0",
    ...
  ],
   ...
}

Les groupes externes dotés d’une appartenance à un groupe dynamique ne stockent aucune personne membre dans l’entrée de groupe.
L’appartenance à un groupe est à la place stockée dans les entrées des utilisateurs et utilisatrices. Vous trouverez une documentation supplémentaire ici. Par exemple, il s’agit du nœud OAK du groupe :

{
  "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"
}

Il s’agit du nœud pour une personne membre de ce groupe :

{
  "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"
  ],
  ...
}

Migration automatique vers l’appartenance à un groupe dynamique pour les environnements existants

Lorsque cette migration est activée, elle est réalisée lors de l’authentification de l’utilisateur ou de l’utilisatrice et comprend les étapes suivantes :

Par exemple, si, avant la migration, user1 est une personne locale et membre du groupe local group1, les modifications suivantes se produisent après la migration :
user1 devient un utilisateur ou une utilisatrice externe. L’attribut rep:externalId est ajouté à son profil.
user1 devient membre du groupe externe : group1;idp.
user1 n’est plus un membre direct du groupe local : group1.
group1;idp est membre du groupe local : group1.
user1 est alors membre du groupe local : group1 par héritage.

L’appartenance à un groupe pour les groupes externes est stockée dans le profil d’utilisation dans l’attribut rep:authorizableId.

Configuration de la migration automatique vers l’appartenance à un groupe dynamique

{
  "idpIdentifier": "<vaule of identitySyncType of saml configuration to be migrated>"
}

Déployer la configuration SAML

Les configurations OSGi doivent être validées dans Git et déployées vers AEM as a Cloud Service à l’aide de Cloud Manager.

$ 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

Déployez la branche Git Cloud Manager cible (dans cet exemple, develop), à l’aide d’un pipeline de déploiement full stack.

Appel de l’authentification SAML

Le flux d’authentification SAML peut être appelé à partir d’une page web d’un site AEM, en créant un lien spécialement conçu ou un bouton. Les paramètres décrits ci-dessous peuvent être définis par programmation selon les besoins. Par exemple, un bouton de connexion peut définir le saml_request_path, où la personne est amenée à accéder à différentes pages d’AEM en fonction du contexte du bouton.

Requête GET

L’authentification SAML peut être appelée en créant une requête HTTP GET au format suivant :

HTTP GET /system/sling/login

et en fournissant les paramètres de requête :

Par exemple, ce lien HTML déclenche le flux de connexion SAML et, en cas de succès, la personne doit être dirigée vers /content/wknd/us/en/protected/page.html. Ces paramètres de requête peuvent être définis par programmation selon les besoins.

<a href="/system/sling/login?resource=/content/wknd&saml_request_path=/content/wknd/us/en/protected/page.html">
    Log in using SAML
</a>

Requête POST

L’authentification SAML peut être appelée en créant une requête HTTP POST au format suivant :

HTTP POST /system/sling/login

et en fournissant les données du formulaire :

Par exemple, ce bouton HTML utilisera un POST HTTP pour déclencher le flux de connexion SAML. Une fois l’opération terminée, la personne sera dirigée vers /content/wknd/us/en/protected/page.html. Ces paramètres de données de formulaire peuvent être définis par programmation selon les besoins.

<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>

Configuration de Dispatcher

Les méthodes HTTP GET et POST requièrent un accès client aux points d’entrée /system/sling/login d’AEM. Elles doivent donc être autorisées via AEM Dispatcher.

Autorisation des modèles d’URL nécessaires en fonction de l’utilisation de GET ou POST

# 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" }