Single Sign-On (SSO) consente a un utente di accedere a più sistemi dopo aver fornito le credenziali di autenticazione, ad esempio un nome utente e una password. L'autenticazione viene eseguita da un sistema separato, denominato autenticatore attendibile, che fornisce agli Experienci Manager le credenziali utente. Experience Manager verifica e applica le autorizzazioni di accesso per l’utente (ovvero determina quali risorse l’utente può accedere).
Il servizio Gestore autenticazione SSO ( com.adobe.granite.auth.sso.impl.SsoAuthenticationHandler
) elabora i risultati di autenticazione forniti dall'autenticatore attendibile. Il gestore di autenticazione SSO cerca un SSID (SSO Identifier) come valore di un attributo speciale nelle posizioni seguenti in questo ordine:
Quando viene trovato un valore, la ricerca viene completata e questo valore viene utilizzato.
Configura i due servizi seguenti per riconoscere il nome dell'attributo che memorizza l'SSID:
È necessario specificare lo stesso nome di attributo per entrambi i servizi. L'attributo è incluso nel SimpleCredentials
fornito a Repository.login
. Il valore dell’attributo è irrilevante e ignorato, la sua mera presenza è importante e verificata.
Per configurare SSO per un’istanza AEM, è necessario configurare Gestore autenticazione SSO:
Quando si lavora con l’AEM, esistono diversi metodi per gestire le impostazioni di configurazione per tali servizi; vedi Configurazione di OSGi per ulteriori dettagli e le pratiche consigliate.
Ad esempio, per il set NTLM:
Percorso: secondo necessità; ad esempio, /
Nomi intestazione: LOGON_USER
Formato ID: ^<DOMAIN>\\(.+)$
Dove <*DOMAIN*>
viene sostituito dal nome di dominio dell’utente.
Per CoSign:
Percorso: secondo necessità; ad esempio, /
Nomi intestazione: utente_remoto
Formato ID: AsIs
Per SiteMinder:
/
Verificare che Single Sign-On funzioni come richiesto, inclusa l'autorizzazione.
Assicurati che gli utenti non possano accedere direttamente all'AEM se SSO è configurato.
Richiedendo agli utenti di passare attraverso un server web che esegue l'agente del sistema SSO, si garantisce che nessun utente possa inviare direttamente un'intestazione, un cookie o un parametro che porti l'utente ad essere considerato attendibile dall'AEM, in quanto l'agente filtrerà tali informazioni se inviate dall'esterno.
Qualsiasi utente che può accedere direttamente all’istanza AEM senza passare per il server web sarà in grado di agire come qualsiasi altro utente inviando l’intestazione, il cookie o il parametro, se i nomi sono noti.
Inoltre, accertati che tra intestazioni, cookie e nomi dei parametri di richiesta, sia configurato solo quello necessario per la configurazione SSO.
Il Single Sign-On viene spesso utilizzato in combinazione con LDAP.
Se utilizzi anche il Dispatcher con Microsoft Internet Information Server (IIS) sarà necessaria una configurazione aggiuntiva in:
disp_iis.ini
In entrata disp_iis.ini
imposta:
(vedere installazione di Dispatcher con Microsoft Internet Information Server per maggiori informazioni)
servervariables=1
inoltra le variabili del server IIS come intestazioni di richiesta all’istanza remotareplaceauthorization=1
(sostituisce qualsiasi intestazione denominata "Authorization" diversa da "Basic" con il suo equivalente "Basic")In IIS:
disable Accesso anonimo
abilita Autenticazione integrata di Windows
Puoi vedere quale gestore di autenticazione viene applicato a qualsiasi sezione della struttura del contenuto utilizzando Autenticatore della console Felix; ad esempio:
http://localhost:4502/system/console/slingauth
Viene eseguita prima una query sul gestore che corrisponde meglio al percorso. Ad esempio, se configuri il gestore A per il percorso /
e handler-B per il percorso /content
, quindi una richiesta a /content/mypage.html
eseguirà prima la query del gestore B.
Per una richiesta di cookie (utilizzando 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
Utilizzando la seguente configurazione:
Percorso: /
Nomi intestazione: TestHeader
Nomi cookie: TestCookie
Nomi parametri: TestParameter
Formato ID: AsIs
La risposta sarebbe:
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>
....
Questo funziona anche se richiedi:
http://localhost:4502/libs/cq/core/content/welcome.html?TestParameter=admin
Oppure puoi utilizzare il seguente comando curl per inviare il TestHeader
intestazione a admin:
curl -D - -H "TestHeader: admin" http://localhost:4502/libs/cq/core/content/welcome.html
Quando utilizzi il parametro request in un browser, vedrai solo alcuni dei HTML, senza CSS. Questo perché tutte le richieste del HTML vengono effettuate senza il parametro di richiesta.
Quando si utilizza l’SSO, l’accesso e la disconnessione vengono gestiti esternamente, pertanto i collegamenti di disconnessione di proprietà dell’AEM non sono più applicabili e devono essere rimossi.
Il collegamento per la disconnessione nella schermata di benvenuto può essere rimosso seguendo la procedura riportata di seguito.
Sovrapposizione /libs/cq/core/components/welcome/welcome.jsp
a /apps/cq/core/components/welcome/welcome.jsp
rimuovi la parte seguente da jsp.
<a href="#" onclick="signout('<%= request.getContextPath() %>');" class="signout"><%= i18n.get("sign out", "welcome screen") %>
Per rimuovere il collegamento di disconnessione disponibile nel menu personale dell'utente nell'angolo in alto a destra, eseguire la procedura seguente:
Sovrapposizione /libs/cq/ui/widgets/source/widgets/UserInfo.js
a /apps/cq/ui/widgets/source/widgets/UserInfo.js
Rimuovere la parte seguente dal file:
menu.addMenuItem({
"text":CQ.I18n.getMessage("Sign out"),
"cls": "cq-userinfo-logout",
"handler": this.logout
});
menu.addSeparator();