Il caching sensibile alle autorizzazioni consente di memorizzare in cache le pagine protette. Dispatcher controlla che l’utente sia autorizzato ad accedere a una pagina memorizzata in cache prima di distribuirla.
Dispatcher include il modulo AuthChecker che implementa il caching sensibile alle autorizzazioni. Quando il modulo viene attivato, Dispatcher richiama un servlet AEM per eseguire l’autenticazione e l’autorizzazione dell’utente per il contenuto richiesto. La risposta del servlet determina se il contenuto viene consegnato o meno dalla cache al browser web.
Poiché i metodi di autenticazione e autorizzazione sono specifici per la distribuzione AEM, è assolutamente necessario creare il servlet.
Utilizza i filtri deny
per applicare le restrizioni di sicurezza predefinite. Utilizza il caching sensibile alle autorizzazioni per le pagine configurate per consentire l’accesso a un sottoinsieme di utenti o gruppi.
I diagrammi seguenti illustrano l’ordine degli eventi che si verificano quando un browser web richiede una pagina per la quale viene utilizzato il caching sensibile alle autorizzazioni.
Per implementare il caching sensibile alle autorizzazioni, esegui le operazioni sotto riportate:
In genere, le risorse protette vengono memorizzate in una cartella separata rispetto ai file non protetti. Ad esempio, /content/secure/
Crea e distribuisci un servlet che esegua l’autenticazione e l’autorizzazione dell’utente che richiede il contenuto web. Il servlet può utilizzare qualsiasi metodo di autenticazione e autorizzazione, come l’account utente AEM e le ACL dell’archivio oppure un servizio di ricerca LDAP. Distribuisci il servlet all’istanza AEM utilizzata da Dispatcher come rendering.
Il servlet deve essere accessibile a tutti gli utenti. Pertanto, il tuo servlet deve estendere la classe org.apache.sling.api.servlets.SlingSafeMethodsServlet
che fornisce l’accesso in sola lettura al sistema.
Il servlet riceve solo richieste HEAD dal rendering, pertanto devi semplicemente implementare il metodo doHead
.
Il rendering include l’URI della risorsa richiesta come parametro della richiesta HTTP. Ad esempio, un servlet di autorizzazione è accessibile tramite /bin/permissioncheck
. Per eseguire un controllo di sicurezza sulla pagina /content/geometrixx-outdoors/en.html, il rendering include il seguente URL nella richiesta HTTP:
/bin/permissioncheck?uri=/content/geometrixx-outdoors/en.html
Il messaggio di risposta del servlet deve contenere i seguenti codici di stato HTTP:
Il seguente esempio di servlet ottiene l’URL della risorsa richiesta dalla richiesta HTTP. Il codice utilizza l’annotazione Felix SCR Property
per impostare il valore della proprietà sling.servlet.paths
su /bin/permissioncheck. Nel metodo doHead
, il servlet ottiene l’oggetto sessione e utilizza il metodo checkPermission
per determinare il codice di risposta appropriato.
Il valore della proprietà sling.servlet.paths deve essere abilitato nel servizio Sling Servlet Resolver (org.apache.sling.servlets.resolver.SlingServletResolver).
package com.adobe.example;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Service;
import org.apache.felix.scr.annotations.Property;
import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.SlingHttpServletResponse;
import org.apache.sling.api.servlets.SlingSafeMethodsServlet;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import javax.jcr.Session;
@Component(metatype=false)
@Service
public class AuthcheckerServlet extends SlingSafeMethodsServlet {
@Property(value="/bin/permissioncheck")
static final String SERVLET_PATH="sling.servlet.paths";
private Logger logger = LoggerFactory.getLogger(this.getClass());
public void doHead(SlingHttpServletRequest request, SlingHttpServletResponse response) {
try{
//retrieve the requested URL
String uri = request.getParameter("uri");
//obtain the session from the request
Session session = request.getResourceResolver().adaptTo(javax.jcr.Session.class);
//perform the permissions check
try {
session.checkPermission(uri, Session.ACTION_READ);
logger.info("authchecker says OK");
response.setStatus(SlingHttpServletResponse.SC_OK);
} catch(Exception e) {
logger.info("authchecker says READ access DENIED!");
response.setStatus(SlingHttpServletResponse.SC_FORBIDDEN);
}
}catch(Exception e){
logger.error("authchecker servlet exception: " + e.getMessage());
}
}
}
La sezione auth_checker del file dispatcher.any controlla il comportamento del caching sensibile alle autorizzazioni. La sezione auth_checker include le seguenti sottosezioni:
url
: il valore della proprietà sling.servlet.paths
del servlet che esegue il controllo di sicurezza.
filter
: filtri che specificano le cartelle alle quali viene applicato il caching sensibile alle autorizzazioni. In genere, il filtro deny
viene applicato a tutte le cartelle, mentre i filtri allow
vengono applicati alle cartelle protette.
headers
: specifica le intestazioni HTTP che il servlet di autorizzazione include nella risposta.
Quando Dispatcher viene avviato, il file di registro di Dispatcher include il seguente messaggio a livello di debug:
AuthChecker: initialized with URL 'configured_url'.
Nell’esempio che segue, la sezione auth_checker configura Dispatcher per l’utilizzo del servlet trattato nell’argomento precedente. La sezione dei filtri stabilisce che i controlli delle autorizzazioni vengano eseguiti solo sulle risorse HTML protette.
/auth_checker
{
# request is sent to this URL with '?uri=<page>' appended
/url "/bin/permissioncheck"
# only the requested pages matching the filter section below are checked,
# all other pages get delivered unchecked
/filter
{
/0000
{
/glob "*"
/type "deny"
}
/0001
{
/glob "/content/secure/*.html"
/type "allow"
}
}
# any header line returned from the auth_checker's HEAD request matching
# the section below will be returned as well
/headers
{
/0000
{
/glob "*"
/type "deny"
}
/0001
{
/glob "Set-Cookie:*"
/type "allow"
}
}
}