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

Prérequis

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.

Appartenance à un groupe dynamique

L’appartenance à un groupe dynamique est une fonctionnalité d’Apache Jackrabbit Oak qui améliore les performances de l’évaluation et de la mise en service des groupes. Cette section décrit comment les utilisateurs et utilisatrices et les groupes sont stockés lorsque cette fonctionnalité est activée et comment modifier la configuration du gestionnaire d’authentification SAML pour l’activer pour les environnements nouveaux ou existants.

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

Activer l’appartenance à un groupe dynamique pour les utilisateurs et utilisatrices SAML dans des environnements existants

Comme expliqué dans la section précédente, le format des utilisateurs et utilisatrices et des groupes externes est légèrement différent de celui utilisé pour les utilisateurs et utilisatrices et groupes locaux. Il est possible de définir une nouvelle liste de contrôle d’accès pour des groupes externes et de configurer de nouveaux utilisateurs et utilisatrices externes, ou d’utiliser l’outil de migration comme décrit ci-dessous.

Activer l’appartenance à un groupe dynamique pour les environnements existants comportant des utilisateurs et utilisatrices externes

Le gestionnaire d’authentification SAML crée des utilisateurs et utilisatrices externes lorsque la propriété suivante est spécifiée : "identitySyncType": "idp". Dans ce cas, l’appartenance à un groupe dynamique peut être activée en modifiant cette propriété sur : "identitySyncType": "idp_dynamic". Aucune migration n’est requise.

Migration automatique vers l’appartenance à un groupe dynamique pour les environnements existants avec des utilisateurs et utilisatrices locaux

Le gestionnaire d’authentification SAML crée des utilisateurs et utilisatrices locaux lorsque la propriété suivante est spécifiée : "identitySyncType": "default". Il s’agit également de la valeur par défaut lorsque la propriété n’est pas spécifiée. Cette section décrit les étapes de la procédure de migration automatique.

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 la propriété rep:externalPrincipalNames.

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

{
  "idpIdentifier": "<value of IDP Identifier (idpIdentifier)" property from the "com.adobe.granite.auth.saml.SamlAuthenticationHandler" configuration to be migrated>"
}

Pour migrer plusieurs configurations SAML, plusieurs configurations d’usine OSGi pour com.adobe.granite.auth.saml.migration.SamlDynamicGroupMembershipMigration doivent être créées, chacune spécifiant un idpIdentifier à migrer.

Hooks SAML personnalisés pour les cas d’utilisation avancés

Si le fournisseur d’identité ne peut pas envoyer les données de profil utilisateur et l’appartenance du groupe d’utilisateurs à l’assertion SAML, ou si les données doivent être transformées avant la synchronisation vers AEM, des hooks SAML personnalisés peuvent être implémentés pour étendre le processus d’authentification SAML. Les hooks SAML permettent de personnaliser l’affectation d’appartenance à un groupe, de modifier les attributs de profil utilisateur et d’ajouter une logique commerciale personnalisée pendant le flux d’authentification.

Quand utiliser des hooks SAML personnalisés ?

Les hooks SAML personnalisés sont utiles lorsqu’il est nécessaire de :

Présentation de l’interface SamlHook

L’interface com.adobe.granite.auth.saml.spi.SamlHook fournit deux méthodes de hook appelées à différentes étapes du processus d’authentification SAML :

1. postSamlValidationProcess

Cette méthode est appelée après la validation de la réponse SAML, mais avant le lancement du processus de synchronisation des utilisateurs. Il s’agit de l’emplacement idéal pour modifier les données d’assertion SAML, telles que l’ajout ou la transformation d’attributs.

public void postSamlValidationProcess(
    HttpServletRequest request,
    Assertion assertion,
    Message samlResponse)

Cas d’utilisation :

2. postSyncUserProcess

Cette méthode est appelée une fois le processus de synchronisation des utilisateurs terminé. Ce hook peut être utilisé pour effectuer des opérations supplémentaires après la création ou la mise à jour de l’utilisateur AEM.

public void postSyncUserProcess(
    HttpServletRequest request,
    HttpServletResponse response,
    Assertion assertion,
    AuthenticationInfo authenticationInfo,
    String samlResponse)

Cas d’utilisation :

Important : pour modifier les propriétés de l’utilisateur dans le référentiel, l’implémentation du hook requiert les éléments suivants :

Mise en œuvre d’un hook SAML personnalisé

Les étapes suivantes décrivent comment créer et déployer un hook SAML personnalisé :

Étape 1 : créer l’implémentation du hook SAML

Créez une classe Java dans le projet AEM qui implémente l’interface com.adobe.granite.auth.saml.spi.SamlHook :

package com.mycompany.aem.saml;

import com.adobe.granite.auth.saml.spi.Assertion;
import com.adobe.granite.auth.saml.spi.Attribute;
import com.adobe.granite.auth.saml.spi.Message;
import com.adobe.granite.auth.saml.spi.SamlHook;
import org.apache.jackrabbit.api.JackrabbitSession;
import org.apache.jackrabbit.api.security.user.Authorizable;
import org.apache.jackrabbit.api.security.user.UserManager;
import org.apache.sling.auth.core.spi.AuthenticationInfo;
import org.apache.sling.jcr.api.SlingRepository;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;
import org.osgi.service.component.annotations.ReferenceCardinality;
import org.osgi.service.metatype.annotations.AttributeDefinition;
import org.osgi.service.metatype.annotations.Designate;
import org.osgi.service.metatype.annotations.ObjectClassDefinition;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.annotation.Nonnull;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
import javax.jcr.ValueFactory;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@Component
@Designate(ocd = SampleImpl.Configuration.class, factory = true)
public class SampleImpl implements SamlHook {
    @ObjectClassDefinition(name = "Saml Sample Authentication Handler Hook Configuration")
    @interface Configuration {
        @AttributeDefinition(
                name = "idpIdentifier",
                description = "Identifier of SAML Idp. Match the idpIdentifier property's value configured in the SAML Authentication Handler OSGi factory configuration (com.adobe.granite.auth.saml.SamlAuthenticationHandler~<unique-id>) this SAML hook will hook into"
        )
        String idpIdentifier();

    }

    private static final String SAMPLE_SERVICE_NAME = "sample-saml-service";
    private static final String CUSTOM_LOGIN_COUNT = "customLoginCount";

    private final Logger log = LoggerFactory.getLogger(getClass());

    private SlingRepository repository;

    @SuppressWarnings("UnusedDeclaration")
    @Reference(name = "repository", cardinality = ReferenceCardinality.MANDATORY)
    public void bindRepository(SlingRepository repository) {
        this.repository = repository;
    }

    /**
     * This method is called after the user sync process is completed.
     * At this point, the user has already been synchronized in OAK (created or updated).
     * Example: Track login count by adding custom attributes to the user in the repository
     *
     * @param request
     * @param response
     * @param assertion
     * @param authenticationInfo
     * @param samlResponse
     */
    @Override
    public void postSyncUserProcess(HttpServletRequest request, HttpServletResponse response, Assertion assertion,
                                    AuthenticationInfo authenticationInfo, String samlResponse) {
        log.info("Custom Audit Log: user {} successfully logged in", authenticationInfo.getUser());

        // This code executes AFTER the user has been synchronized in OAK
        // The user object already exists in the repository at this point
        Session serviceSession = null;
        try {
            // Get a service session - requires "sample-saml-service" to be configured as system user
            // Configure in: "Apache Sling Service User Mapper Service Amendment"
            serviceSession = repository.loginService(SAMPLE_SERVICE_NAME, null);

            // Get the UserManager to work with users and groups
            UserManager userManager = ((JackrabbitSession) serviceSession).getUserManager();

            // Get the authorizable (user) that just logged in
            Authorizable user = userManager.getAuthorizable(authenticationInfo.getUser());

            if (user != null && !user.isGroup()) {
                ValueFactory valueFactory = serviceSession.getValueFactory();

                // Increment login count
                long loginCount = 1;
                if (user.hasProperty(CUSTOM_LOGIN_COUNT)) {
                    loginCount = user.getProperty(CUSTOM_LOGIN_COUNT)[0].getLong() + 1;
                }
                user.setProperty(CUSTOM_LOGIN_COUNT, valueFactory.createValue(loginCount));
                log.debug("Set {} property to {} for user {}", CUSTOM_LOGIN_COUNT, loginCount, user.getID());

                // Save all changes to the repository
                if (serviceSession.hasPendingChanges()) {
                    serviceSession.save();
                    log.debug("Successfully saved custom attributes for user {}", user.getID());
                }
            } else {
                log.warn("User {} not found or is a group", authenticationInfo.getUser());
            }

        } catch (RepositoryException e) {
            log.error("Error adding custom attributes to user repository for user: {}",
                     authenticationInfo.getUser(), e);
        } finally {
            if (serviceSession != null) {
                serviceSession.logout();
            }
        }
    }

    /**
     * This method is called after the SAML response is validated but before the user sync process starts.
     * We can modify the assertion here to add custom attributes.
     *
     * @param request
     * @param assertion
     * @param samlResponse
     */
    @Override
    public void postSamlValidationProcess(@Nonnull HttpServletRequest request, @Nonnull Assertion assertion, @Nonnull Message samlResponse) {
        // Add the attribute "memberOf" with value "sample-group" to the assertion
        // In this example "memberOf" is a multi-valued attribute that contains the groups from the Saml Idp
        log.debug("Inside postSamlValidationProcess");
        Attribute groupsAttr = assertion.getAttributes().get("groups");
        if (groupsAttr != null) {
            groupsAttr.addAttributeValue("sample-group-from-hook");
        } else {
            groupsAttr = new Attribute();
            groupsAttr.setName("groups");
            groupsAttr.addAttributeValue("sample-group-from-hook");
            assertion.getAttributes().put("groups", groupsAttr);
        }
    }

}

Étape 2 : configurer le hook SAML

Le hook SAML utilise la configuration OSGi pour spécifier à quel fournisseur d’identité il doit s’appliquer. Créez un fichier de configuration OSGi dans le projet sous :

/ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.mycompany.aem.saml.CustomSamlHook~okta.cfg.json

{
  "idpIdentifier": "$[env:SAML_IDP_ID;default=http://www.okta.com/exk4z55r44Jz9C6am5d7]",
  "service.ranking": 100
}

Le idpIdentifier doit correspondre à la valeur idpIdentifier configurée dans la configuration d’usine OSGi du gestionnaire d’authentification SAML correspondant (PID : com.adobe.granite.auth.saml.SamlAuthenticationHandler~<unique-id>.cfg.json). Cette correspondance est essentielle : le hook SAML ne sera appelé que pour l’instance du gestionnaire d’authentification SAML qui a la même valeur idpIdentifier. Le gestionnaire d’authentification SAML est une configuration d’usine, ce qui signifie que vous pouvez avoir plusieurs instances (par exemple, com.adobe.granite.auth.saml.SamlAuthenticationHandler~okta.cfg.json, com.adobe.granite.auth.saml.SamlAuthenticationHandler~azure.cfg.json) et chaque hook est lié à un gestionnaire spécifique via le idpIdentifier. La propriété service.ranking contrôle l’ordre d’exécution lorsque plusieurs hooks sont configurés (les valeurs les plus élevées sont exécutées en premier).

Étape 3 : ajouter des dépendances Maven

Ajoutez la dépendance SPI SAML requise au pom.xml du projet principal AEM Maven.

Pour les projets AEM as a Cloud Service, utilisez la dépendance API SDK AEM qui inclut les interfaces SAML :

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>aem-sdk-api</artifactId>
    <version>${aem.sdk.api}</version>
    <scope>provided</scope>
</dependency>

L’artefact aem-sdk-api contient toutes les interfaces SAML Granite Adobe nécessaires, y compris com.adobe.granite.auth.saml.spi.SamlHook.

Étape 4 : configurer l’utilisateur du service (si vous modifiez le référentiel)

Si le hook SAML doit modifier les propriétés de l’utilisateur dans le référentiel (comme illustré dans l’exemple postSyncUserProcess), un utilisateur du service doit être configuré :

{
  "user.mapping": [
    "com.mycompany.aem.core:sample-saml-service=saml-hook-service"
  ]
}

create service user saml-hook-service with path system/saml

set ACL for saml-hook-service
    allow jcr:read,rep:write,rep:userManagement on /home/users
end

Cela permet à l’utilisateur du service de lire et de modifier les propriétés de l’utilisateur dans le référentiel.

Étape 5 : déploiement sur AEM

Déployez le hook SAML personnalisé vers AEM as a Cloud Service :

Considérations importantes

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.

Mise en cache sécurisée lors de l’utilisation de SAML

Sur l’instance de publication AEM, la plupart des pages sont généralement mises en cache. Toutefois, pour les chemins protégés par SAML, la mise en cache doit être soit désactivée soit activée de manière sécurisée à l’aide de la configuration auth_checker. Pour plus d’informations, reportez-vous aux détails fournis ici.

Gardez à l’esprit que si vous mettez en cache des chemins protégés sans activer auth_checker, vous pouvez rencontrer un comportement imprévisible.

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