Authentification unique single-sign-on
L’authentification unique (SSO) permet à une personne d’accéder à plusieurs systèmes après avoir fourni une seule fois des informations d’identification d’authentification (telles qu’un nom d’utilisateur ou d’utilisatrice et un mot de passe). Un système distinct (appelé authentificateur approuvé) effectue l’authentification et fournit à Experience Manager les informations d’identification de l’utilisateur ou utilisatrice. Experience Manager vérifie les autorisations d’accès et les applique pour l’utilisateur ou l’utilisatrice (c’est-à-dire, détermine les ressources auxquelles l’utilisateur ou l’utilisatrice est autorisé à accéder).
Le service gestionnaire d’authentification SSO (com.adobe.granite.auth.sso.impl.SsoAuthenticationHandler) traite les résultats de l’authentification fournis par l’authentificateur de confiance. Le gestionnaire d’authentification SSO recherche un SSID (identifiant SSO) comme valeur d’un attribut spécial dans les emplacements suivants, dans cet ordre :
- En-têtes de requête
- Cookies
- Paramètres de requête
Lorsqu’une valeur est trouvée, la recherche est terminée et cette valeur est utilisée.
Configurez les deux services suivants pour reconnaître le nom de l’attribut qui stocke le SSID :
- Module de connexion.
- Service d’authentification SSO.
Vous devez spécifier le même nom d’attribut pour les deux services. L’attribut est inclus dans les SimpleCredentials fournies dans Repository.login. La valeur de l’attribut n’est pas pertinente et est ignorée, la simple présence de l’attribut est importante et vérifiée.
Configuration d’authentification unique configuring-sso
Pour configurer l’authentification unique pour une instance AEM, vous devez configurer le gestionnaire d’authentification SSO :
-
Lorsque vous utilisez AEM, plusieurs méthodes permettent de gérer les paramètres de configuration pour ces services. Consultez la section Configuration d’OSGi pour plus de détails et pour connaître les pratiques recommandées.
Par exemple, pour l’ensemble NTLM :
-
Chemin d’accès : en fonction des besoins, par exemple,
/ -
Noms d’en -tête :
LOGON_USER -
Format d’ID :
^<DOMAIN>\\(.+)$Où
<*DOMAIN*>est remplacé par le nom de votre propre domaine.
Pour CoSign :
- Chemin d’accès : en fonction des besoins, par exemple,
/ - Noms des en-têtes : remote_user
- Format d’ID : AsIs
Pour SiteMinder :
- Chemin d’accès : en fonction des besoins, par exemple,
/ - Noms des en-têtes : SM_USER
- Format d’ID : AsIs
-
-
Vérifiez que la connexion unique fonctionne selon vos besoins, y compris les autorisations.
disp_iis.ini- IIS
disp_iis.ini, définissez les éléments suivants :(Voir Installation de Dispatcher avec Microsoft® Internet Information Server pour en savoir plus.)
servervariables=1(transmet des variables de serveur IIS comme en-têtes de requête à une instance distante)replaceauthorization=1(remplace n’importe quel en-tête appelé « Authorization » autre que l’en-tête « De base » par son « De base » équivalent)
-
Désactivez l’accès anonyme.
-
Activez l’authentification Windows intégrée.
Vous pouvez voir quel gestionnaire d’authentification est appliqué à n’importe quelle section de l’arborescence de contenu à l’aide de l’option Authenticator de la console Felix, par exemple :
http://localhost:4502/system/console/slingauth
Le gestionnaire qui correspond le mieux au chemin est le premier à être appelé. Par exemple, si vous configurez le gestionnaire A pour le chemin // et le gestionnaire B pour le chemin /content, alors une demande à /content/mypage.html appellera le gestionnaire B en premier.
Exemple example
Pour une demande de cookie (à l’aide de l’URL http://localhost:4502/libs/wcm/content/siteadmin.html) :
GET /libs/cq/core/content/welcome.html HTTP/1.1
Host: localhost:4502
Cookie: TestCookie=admin
Utilisation de la configuration suivante :
-
Chemin :
/ -
Noms d’en-têtes :
TestHeader -
Noms de cookies :
TestCookie -
Noms des paramètres :
TestParameter -
Format d’ID :
AsIs
La réponse serait :
HTTP/1.1 200 OK
Connection: Keep-Alive
Server: Day-Servlet-Engine/4.1.24
Content-Type: text/html;charset=utf-8
Date: Thu, 23 Aug 2012 09:58:39 GMT
Transfer-Encoding: chunked
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "https://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Welcome to Adobe® CQ5</title>
....
Cela fonctionne également si vous demandez :http://localhost:4502/libs/cq/core/content/welcome.html?TestParameter=admin
Vous pouvez également utiliser la commande curl suivante pour envoyer l’en-tête TestHeader à admin:curl -D - -H "TestHeader: admin" http://localhost:4502/libs/cq/core/content/welcome.html
Supprimer des liens de déconnexion AEM removing-aem-sign-out-links
Lors de l’utilisation de l’authentification unique, la connexion et la déconnexion sont gérées en externe, de sorte que les liens de déconnexion AEM ne sont plus applicables et doivent être supprimés.
Le lien de déconnexion sur l’écran de bienvenue peut être supprimé en procédant comme suit.
-
Recouvrez
/libs/cq/core/components/welcome/welcome.jspsur/apps/cq/core/components/welcome/welcome.jsp. -
Supprimez la partie suivante du JSP.
<a href="#" onclick="signout('<%= request.getContextPath() %>');" class="signout"><%= i18n.get("sign out", "welcome screen") %>
Pour supprimer le lien de déconnexion disponible dans le menu personnel de l’utilisateur ou de l’utilisatrice dans le coin supérieur droit, procédez comme suit :
-
Recouvrez
/libs/cq/ui/widgets/source/widgets/UserInfo.jssur/apps/cq/ui/widgets/source/widgets/UserInfo.js. -
Supprimez la partie suivante du fichier :
code language-none menu.addMenuItem({ "text":CQ.I18n.getMessage("Sign out"), "cls": "cq-userinfo-logout", "handler": this.logout }); menu.addSeparator();