Authentification SAML 2.0

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

Quel SAML pour AEM as a Cloud Service ?

L’intégration de SAML 2.0 à AEM Publish (ou Preview) permet aux utilisateurs finaux d’une expérience web basée sur AEM de s’authentifier auprès d’un fournisseur d’identité (fournisseur d’identité) non-Adobe et d’accéder à AEM en tant qu’utilisateur autorisé et nommé.

Présentation de la configuration

Cette vidéo décrit la configuration de l’intégration SAML 2.0 avec AEM service de publication as a Cloud Service et l’utilisation d’Okta comme fournisseur d’identité.

Prérequis

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

• Accès de Deployment Manager à Cloud Manager
• Accès AEM administrateur à AEM environnement as a Cloud Service
• Accès de l’administrateur au fournisseur d’identité
• Éventuellement, l’accès à une paire de clés publique/privée utilisée pour le chiffrement des payloads SAML.

SAML 2.0 est uniquement pris en charge pour authentifier les utilisateurs dans AEM Publish ou Preview. Pour gérer l’authentification de l’auteur AEM à l’aide de et de IDP, Intégration du fournisseur d’identité avec Adobe IMS.

Installer le certificat public IDP sur AEM

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

1. Obtenez la variable certificat public à partir du IDP. Ce certificat permet à AEM de valider l’assertion SAML fournie à AEM par le fournisseur d’identité.

   Le certificat est au format PEM et doit ressembler à :

   -----BEGIN CERTIFICATE-----
   MIIC4jCBAcoCCQC33wnybT5QZDANBgkqhkiG9w0BAQsFADAyMQswCQYDVQQGEwJV
   ...
   m0eo2USlSRTVl7QHRTuiuSThHpLKQQ==
   -----END CERTIFICATE-----
   

2. Connectez-vous à AEM Author en tant qu’administrateur AEM.

3. Accédez à Outils > Sécurité > Trust Store.

4. Créez ou ouvrez le Trust Store global. Si vous créez un Trust Store global, stockez le mot de passe en lieu sûr.

5. Développer Ajout d’un certificat à partir du fichier CER.

6. Sélectionner Sélectionner le fichier de certificat et chargez le fichier de certificat fourni par le fournisseur d’identité.

7. Laissez tomber Mappage du certificat à l’utilisateur vide.

8. Sélectionnez Envoyer.

9. Le certificat nouvellement ajouté s’affiche au-dessus du Ajout d’un certificat à partir d’un fichier CRT .

10. Prenez note de la alias, car cette valeur est utilisée dans la variable Configuration OSGi du gestionnaire d’authentification SAML 2.0.

11. Sélectionnez Enregistrer et fermer.

Le Trust Store global est configuré avec le certificat public du fournisseur d’identité sur l’auteur AEM, mais comme SAML est utilisé uniquement sur AEM Publish, le Trust Store global doit être répliqué vers AEM Publish pour que le certificat public IDP y soit accessible.

1. Accédez à Outils > Déploiement > Modules.
2. Créer un package
   • Nom du module : Global Trust Store
   • Version: 1.0.0
   • Groupe : com.your.company
3. Modifiez la nouvelle Trust Store mondial module.
4. Sélectionnez la Filtres et ajouter un filtre pour le chemin d’accès racine. /etc/truststore.
5. Sélectionner Terminé puis Enregistrer.
6. Sélectionnez la Build pour le bouton Trust Store mondial module.
7. Une fois la création terminée, sélectionnez Plus > Répliquer pour activer le noeud Trust Store global (/etc/truststore) vers AEM Publish.

Installer AEM paire de clés publique/privée

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

La publication AEM peut être configurée pour signer les demandes d’auteur (IDP) et chiffrer les assertions SAML (pour AEM). Pour ce faire, vous devez fournir une clé privée à AEM Publish et faire correspondre la clé publique au fournisseur d’identité.

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

1. Procurez-vous la clé publique, la clé privée (PKCS#8 au format DER) et le fichier de chaîne de certificats (il peut s’agir de la clé publique) utilisés pour signer la demande d’auteur et chiffrer l’assertion SAML. Les clés sont généralement fournies par l’équipe de sécurité de l’entreprise informatique.

   • Une paire de clés auto-signée peut être générée à l’aide de 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
   

2. Téléchargez la clé publique vers le fournisseur d’identité.

   • En utilisant la variable openssl , la clé publique est la méthode aem-public.crt fichier .

3. Connectez-vous à l’auteur AEM en tant qu’administrateur AEM pour charger la clé privée.

4. Accédez à Outils > Sécurité > Trust Store, puis sélectionnez authentication-service et sélectionnez Propriétés dans la barre d’actions supérieure.

5. Accédez à Outils > Sécurité > Utilisateurs, puis sélectionnez authentication-service et sélectionnez Propriétés dans la barre d’actions supérieure.

6. Sélectionnez la Keystore .

7. Créez ou ouvrez le KeyStore. Si vous créez un fichier de stockage de clés, assurez-vous que le mot de passe est sécurisé.

8. Sélectionner Ajout d’une clé privée à partir du fichier DER, puis ajoutez la clé privée et le fichier de chaîne à AEM :

   • Alias: Attribuez un nom significatif, souvent le nom du fournisseur d’identité.
   • Fichier de clé privée: Téléchargez le fichier de clé privée (PKCS#8 au format DER).
     • En utilisant la variable openssl , il s’agit de la méthode aem-private-pkcs8.der fichier
   • Sélectionner le fichier de chaîne de certificat: Téléchargez le fichier de chaîne d’accompagnement (il peut s’agir de la clé publique).
     • En utilisant la variable openssl , il s’agit de la méthode aem-public.crt fichier
   • Sélectionnez Envoyer

9. Le certificat nouvellement ajouté s’affiche au-dessus du Ajout d’un certificat à partir d’un fichier CRT .

   • Prenez note de la alias car il est utilisé dans la variable Configuration OSGi du gestionnaire d’authentification SAML 2.0

10. Sélectionnez Enregistrer et fermer.

11. Sélectionner authentication-service et sélectionnez Activer dans la barre d’actions supérieure.

Configuration du gestionnaire d’authentification SAML 2.0

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

1. Créez un fichier de configuration OSGi dans votre projet à l’adresse /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~saml.cfg.json et ouvrez dans votre IDE.

   • Modifier /wknd-examples/ à /<project name>/
   • L’identifiant après la variable ~ dans le nom de fichier doit identifier de manière unique cette configuration. Il peut donc s’agir du nom du fournisseur d’identité, tel que ...~okta.cfg.json. La valeur doit être alphanumérique avec des tirets.

2. Collez le code JSON suivant dans le com.adobe.granite.auth.saml.SamlAuthenticationHandler~...cfg.json et mettez à jour le fichier wknd références selon les besoins.

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

3. Mettez à jour les valeurs comme requis par votre projet. Voir Glossaire de configuration OSGi du gestionnaire d’authentification SAML 2.0 ci-dessus pour les descriptions des propriétés de configuration

4. Il est recommandé, mais non obligatoire, d’utiliser des variables et des secrets d’environnement OSGi lorsque les valeurs peuvent ne pas être synchronisées avec le cycle de publication ou lorsque les valeurs diffèrent entre les types d’environnements/niveaux de service similaires. Les valeurs par défaut peuvent être définies à l’aide de la variable $[env:..;default=the-default-value]" comme illustré ci-dessus.

Configurations OSGi par environnement (config.publish.dev, config.publish.stage, et config.publish.prod) peut être défini avec des attributs spécifiques si la configuration SAML varie d’un environnement à l’autre.

Utiliser le chiffrement

When cryptage de l’assertion AuthnRequest et SAML, 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 de valeurs de configuration secrètes

Configuration du filtre de référent

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

1. Créez (ou modifiez) un fichier de configuration OSGi dans votre projet à l’adresse /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/org.apache.sling.security.impl.ReferrerFilter.cfg.json.

   • Modifier /wknd-examples/ à /<project name>/

2. Assurez-vous que la variable allow.empty est définie sur true, la variable allow.hosts (ou si vous préférez, allow.hosts.regexp) contient l’origine du fournisseur d’identité, et filter.methods inclut POST. La configuration OSGi doit être similaire à :

   {
       "allow.empty": true,
       "allow.hosts.regexp": [ ],
       "allow.hosts": [
           "$[env:SAML_IDP_REFERRER;default=dev-123567890.okta.com]"
       ],
       "filter.methods": [
           "POST",
       ],
       "exclude.agents.regexp": [ ]
   }
   

AEM Publish 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.

Configurations OSGi par environnement (config.publish.dev, config.publish.stage, et config.publish.prod) peut être défini avec des attributs spécifiques si la variable allow.hosts (ou allow.hosts.regex) varient selon les environnements.

Configurez le partage des ressources cross-origin (CORS)

Pendant le processus d’authentification SAML, le fournisseur d’identité lance un POST HTTP côté client vers le serveur de publication AEM .../saml_login point de terminaison. Si le fournisseur d’identité et la publication AEM existent sur différents hôtes/domaines, le Partage des ressources CRoss-Origin (CORS) doit être configuré pour autoriser les instructions POST HTTP à partir de l’hôte/du domaine du fournisseur d’identité.

Cette requête de POST HTTP Origin L’en-tête a généralement une valeur différente de celle de l’hôte 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 la variable Origin en-tête à null. Si tel est le cas, ajoutez "null" au alloworigin liste.

1. Créez un fichier de configuration OSGi dans votre projet à l’adresse /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.cors.impl.CORSPolicyImpl~saml.cfg.json
   • Modifier /wknd-examples/ dans le nom du projet
   • L’identifiant après la variable ~ dans le nom de fichier doit identifier de manière unique cette configuration. Il peut donc s’agir du nom du fournisseur d’identité, tel que ...CORSPolicyImpl~okta.cfg.json. La valeur doit être alphanumérique avec des tirets.
2. Collez le code JSON suivant dans le com.adobe.granite.cors.impl.CORSPolicyImpl~...cfg.json fichier .

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

Configurations OSGi par environnement (config.publish.dev, config.publish.stage, et config.publish.prod) peut être défini avec des attributs spécifiques si la variable alloworigin et allowedpaths varie d’un environnement à l’autre.

Configuration d’AEM Dispatcher pour autoriser les POST HTTP SAML

Une fois l’authentification au fournisseur d’identité réussie, le fournisseur d’identité orchestrera un POST HTTP vers AEM enregistré. /saml_login point de terminaison (configuré dans le fournisseur d’identité). Ce POST HTTP vers /saml_login est bloqué par défaut sur Dispatcher. Il doit donc être autorisé explicitement à l’aide de la règle Dispatcher suivante :

1. Ouvrir dispatcher/src/conf.dispatcher.d/filters/filters.any dans votre IDE.
2. Ajoutez au bas du fichier une règle permettant d’autoriser les publications HTTP aux URL se terminant par /saml_login.

...

# 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 de la variable .../saml_login les points de fin ne sont pas gérés accidentellement.

Activation de la synchronisation des données et encapsulation des jetons

Une fois que le flux d’authentification SAML crée un utilisateur dans AEM Publish, le noeud utilisateur AEM authentifiable au niveau du service de publication AEM.
Cela nécessite synchronisation des données et jetons encapsulés pour être activé par l’assistance Adobe sur le service de publication AEM.

Envoyez une demande au service clientèle d’Adobe (via Admin Console > Assistance) demandant :

La synchronisation des données et les jetons encapsulés sont activés sur le service AEM Publish pour le programme X et l’environnement Y.

Déploiement de 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éployer la branche Git Cloud Manager cible (dans cet exemple, develop), à l’aide d’un pipeline de déploiement Stack complet.

Ressources Business.Adobe.com