Démonstration de l’intégration AEM et SAML

AEM fournit la prise en charge pour la requête d'authentification SAML 2,0 et agit comme prestataire de services SAML. Cet article fournit un exemple pour l’installation et la configuration de vos tests locaux pour réaliser une connexion web unique au-delà ou à l'intérieur des limites organisationnelles.

Voir aussi la documentation du produit en ligne pour le gestionnaire de authentification saml.

Logiciel utilisé pour la configuration

Les fichiers binaires utilisés sont décrits ci-dessous. Vous pouvez utiliser le même ou un équivalent.

Installation et configuration

Installation et configuration de OpenDS LDAP

Suivez les instructions d’installation de OpenDS. Pendant l’installation, choisissez de charger les données de test pour éviter la création de l’utilisateur. N’oubliez pas le mot de passe de l'administrateur fourni pendant l’installation. La capture d’écran ci-dessous illustre l’option sélectionnée lors de l’installation.

Installez Shibboleth IDP

Décompressez le binaire téléchargé (shibboleth-identityprovider-2.4.0-bin.zip) et exécutez le fichier install.bat. L’installation crée l’ID d’entité de IdP, les métadonnées initiales, un ensemble de fichiers de configuration IdP et une paire de clés self-signed utilisée pour signer/chiffrer.

Installation et configuration de Tomcat

1. Décompressez le fichier apache-tomcat-6.0.37-windows-x64.zip dans n'importe quel répertoire (par exemple, C:\demo\appserver\apache- tomcat-6.0.37-windows-x64).

2. Créez un certificat auto-signé SSL.

3. Appliquez le certificat à tomcat <TOMCAT_HOME>/conf/server.xml.

4.   Copiez « idp.war » de <SAML_IDP_HOME>/war/idp.war à <TOMCAT_HOME>/webapps.

5.   Créez le répertoire <TOMCAT_HOME>/endorsed et copiez les fichiers .jar inclus dans le répertoire approuvé par la source IdP dans le répertoire que vous venez de créer.

6.   Test rapide : allez à https://localhost:8443/idp/profile/Status returns OK.

Configuration du simulateur Shibboleth :

1. Modifiez <SAML_IDP_HOME>/conf/idp-metadata.xml pour vérifier tous les points d'attribut d'emplacement à l'application idp sur tomcat 8443.

2.   Modifiez <SAML_IDP_HOME>/conf/attribute-resolver.xml pour ajouter la définition de l'attribut et la chaîne de connexion LDAP.

3.   Modifier <SAML_IDP_HOME>/conf/handler.xml pour supprimer toutes les entrées pour l'authentification, sauf "UsernamePassword" et "PreviousSession."

4.   Modifier <SAML_IDP_HOME>/conf/logging.xml afin d'obtenir la trace de débogage.

5.   Modifier <SAML_IDP_HOME>/conf/login.config.

6.   Modifier <SAML_IDP_HOME>/conf/relying-party.xml

7.   Modifiez /conf/attribute-filter.xml pour libérer l’UID et le groupe.  

8.   Ajoutez le fichier de métadonnées suivant à <SAML_IDP_HOME>/metadata/adobecq.xml.

Configuration AEM

1.   Installez AEM suivant http://dev.day.com/docs/en/cq/current/deploying/installing_cq.html.

2.   Sous /etc/key dans le référentiel, créez un noeud appelé « saml ». Dans ce nœud, ajoutez une nouvelle propriété binaire appelée "idp_cert" pour le certificat public du fournisseur d’identité.  En d’autres termes, téléchargez le fichier à partir de <SAML_IDP_HOME>/credentials/idp.crt.

3.   Configurez le gestionnaire d’authentification.

4.   Configurez ReferrerFilter.

Vérification

1.   Création d'une requête AEM à http://<host>:<port>/ provoque une redirection sur la page de connexion IDP.

2.   Connectez-vous en tant que user.2 avec mot de passe car le « mot de passe » vous dirige vers la page d'accueil AEM. Consultez l’instantané de la réponse de suivi saml & la création crx automatique ci-dessous :

Amélioration avec AEM 6 +

À partir d'AEM 6 SP1, ajout de la prise en charge pour

• Capacité d'un flux unique pour la fermeture d'une session (déconnexion).
• Synchroniser les attributs.
• Groupe configurable par défaut.

La section ci-dessous fournit la mise à jour obligatoire dans la démonstration de configuration ci-dessus pour le test local de déconnexion et la synchronisation de l'attribut courrier.

Mises à jour de la configuration dans Shibboleth IDP.

1.   Modifier <SAML_IDP_HOME>/conf/attribute-filter.xml & <SAML_IDP_HOME>/conf/attribute-resolver.xml pour libérer l'attribut courrier.

2.   Modifiez le fichier de métadonnées à <SAML_IDP_HOME>/metadata/adobecq.xml pour inclure SingleSignoutService.

Mises à jour de configuration dans AEM :

1.   Sous /etc/key/saml dans le référentiel, ajoutez une nouvelle propriété binaire nommée « privée » contenant la clé du certificat public du fichier des métadonnées (adobecq.xml).  En d’autres termes, téléchargez le fichier demoprivatekey.pem depuis le package de téléchargement de démonstration.

2.   Mettez à jour le gestionnaire d’authentification avec l’URL de déconnexion et synchronisez l’attribut.

Processus

1.   Connectez-vous à AEM à http://<port>:<port>/ using user.0, puis la fermeture de la session vous redirigera vers la page de connexion IDP.  

2.   La propriété Mail est synchronisée.

Restrictions   

L'utilisateur doit exister dans AEM
Les utilisateurs qui se connectent via le gestionnaire doivent exister ou si manquant doivent être créés dans, AEM (“Autocreate CRX Users” doit être vérifié). Ceci est dû au fait que la structure d’authentification Sling, qui fait partie de la classe SamlAuthenticationHandler, fait partie des informations d’identification de l’utilisateur et se connecte au référentiel JCR à l’aide de ces informations d’identification.

L'accès anonyme à L'échelle du site, avec authentification facultative
Le gestionnaire d'authentification est construit autour de la protection de contenu de l'accès anonyme par le biais de la configuration du tracé. Si toutes les pages du site AEM doivent être accessibles de manière anonyme, mais que l’authentification a également besoin d'être une option, la valeur de la configuration du Chemin peut être définie sur un chemin non existant. L'authentification SAML autorise alors l'accès anonyme à toutes les pages du site. Si cette stratégie est utilisée, assurez-vous que les publications de SAMLReponse au tracé saml_login correct (voir l'élément suivant).

La configuration et la connexion saml_login
SAMLResponse d'IdP doit être publié sur la page ‘saml_login’. Toutefois, la page « saml_login » doit se trouver dans le chemin que le gestionnaire d’authentification protège (c’est-à-dire la configuration de chemin). Par exemple, si le chemin de configuration est « / »le fournisseur d'identité peut publier sur http://localhost:4502/saml_login.  Si le chemin est « /content/geometrixx » le fournisseur d'identité peut publier sur http://localhost:4502/content/geometrixx/saml_login ou http://localhost:4502/content/geometrixx/does-not-exist/saml_login mais http://localhost:4502/content/saml_login ne fonctionnera pas.

L'IdP a lancé la connexion et RelayState
En SP1, en assurant qu'un utilisateur revient à la page d'ouverture de session avant que la connexion est réalisé avec le cookie saml_request_path et non le paramètre type RelayState détecté avec la plupart des implémentations SSO. Par conséquent, si l’authentification initiée par IdP sera terminée, l’utilisateur final n'envoi pas à la page spécifiée par RelayState. Par conséquent, si un lien de connexion personnalisé est implémenté sur une page AEM (nom de connexion du détenteur de licence), assurez-vous de définir le cookie saml_request_path avant d’envoyer le navigateur au IdP.

Erreur aucune ressource trouvée
Ces résultats les plus susceptibles de l'utilisateur connecté qui ne possède pas les autorisations appropriées pour afficher la page. Pour résoudre ce problème, assurez-vous que l’utilisateur SSO dispose de droits de lecture pour des dossiers tels que /content. Cela se produit en configurant le gestionnaire d’authentification pour ajouter des utilisateurs SSO à un groupe d’utilisateurs dont les autorisations requises sont définies.

Téléchargement

Les informations d’identification de signature d’IdP, les informations d’identification de chiffrement, les fichiers de configuration, les métadonnées utilisées dans ce script de démonstration peuvent être téléchargées ici.