Firewall (autenticazione)¶

Quando un utente effettua una richiesta a un URL che è protetto da un firewall, viene attivato il sistema di sicurezza. Il compito del firewall è quello di determinare se l'utente deve o non deve essere autenticato e se deve autenticarsi, rimandare una risposta all'utente, avviando il processo di autenticazione.

Un firewall viene attivato quando l'URL di una richiesta in arrivo corrisponde al valore pattern dell'espressione regolare del firewall configurato. In questo esempio, pattern (^/) corrisponderà a ogni richiesta in arrivo. Il fatto che il firewall venga attivato non significa tuttavia che venga visualizzato il box di autenticazione con nome utente e password per ogni URL. Per esempio, qualunque utente può accedere a /foo senza che venga richiesto di autenticarsi.

Questo funziona in primo luogo perché il firewall consente utenti anonimi, attraverso il parametro di configurazione anonymous. In altre parole, il firewall non richiede all'utente di fare immediatamente un'autenticazione. E poiché non è necessario nessun ruolo speciale per accedere a /foo (sotto la sezione access_control), la richiesta può essere soddisfatta senza mai chiedere all'utente di autenticarsi.

Se si rimuove la chiave anonymous, il firewall chiederà sempre l'autenticazione all'utente.

Controlli sull'accesso (autorizzazione)¶

Se un utente richiede /admin/foo, il processo ha un diverso comportamento. Questo perché la sezione di configurazione access_control dice che qualsiasi URL che corrispondono allo schema dell'espressione regolare ^/admin (cioè /admin o qualunque URL del tipo /admin/*) richiede il ruolo ROLE_ADMIN. I ruoli sono la base per la maggior parte delle autorizzazioni: un utente può accedere /admin/foo solo se ha il ruolo ROLE_ADMIN.

Come prima, quando l'utente effettua inizialmente la richiesta, il firewall non chiede nessuna identificazione. Tuttavia, non appena il livello di controllo di accesso nega l'accesso all'utente (perché l'utente anonimo non ha il ruolo ROLE_ADMIN), il firewall entra in azione e avvia il processo di autenticazione. Il processo di autenticazione dipende dal meccanismo di autenticazione in uso. Per esempio, se si sta utilizzando il metodo di autenticazione tramite form di login, l'utente verrà rinviato alla pagina di login. Se si utilizza l'autenticazione HTTP, all'utente sarà inviata una risposta HTTP 401 e verrà visualizzato una finestra del browser con nome utente e password.

Ora l'utente ha la possibilità di inviare le credenziali all'applicazione. Se le credenziali sono valide, può essere riprovata la richiesta originale.

In questo esempio, l'utente ryan viene autenticato con successo con il firewall. Ma poiché ryan non ha il ruolo ROLE_ADMIN, viene ancora negato l'accesso a /admin/foo. In definitiva, questo significa che l'utente vedrà un qualche messaggio che indica che l'accesso è stato negato.

Infine, se l'utente admin richiede /admin/foo, avviene un processo simile, solo che adesso, dopo essere stato autenticato, il livello di controllo di accesso lascerà passare la richiesta:

Il flusso di richiesta quando un utente richiede una risorsa protetta è semplice, ma incredibilmente flessibile. Come si vedrà in seguito, l'autenticazione può essere gestita in molti modi, come un form di login, un certificato X.509, o da un'autenticazione dell'utente tramite Twitter. Indipendentemente dal metodo di autenticazione, il flusso di richiesta è sempre lo stesso:

1. Un utente accede a una risorsa protetta;
2. L'applicazione rinvia l'utente al form di login;
3. L'utente invia le proprie credenziali (ad esempio nome utente / password);
4. Il firewall autentica l'utente;
5. L'utente autenticato riprova la richiesta originale.

Protezione di specifici schemi di URL¶

Il modo più semplice per proteggere parte dell'applicazione è quello di proteggere un intero schema di URL. Si è già visto questo nel primo esempio di questo capitolo, dove tutto ciò a cui corrisponde lo schema di espressione regolare ^/admin richiede il ruolo ROLE_ADMIN.

È possibile definire tanti schemi di URL quanti ne occorrono, ciascuno è un'espressione regolare.

Capire come funziona access_control¶

Per ogni richiesta in arrivo, Symfony2 verifica ogni voce di access_control per trovarne una che corrisponda alla richiesta attuale. Se ne trova una corrispondente, si ferma, quindi solo la prima voce di access_control corrispondente verrà usata per garantire l'accesso.

Ogni access_control ha varie opzioni che configurano varie cose: (a) se la richiesta in arrivo deve corrispondere a questa voce di controllo di accesso e (b) una volta corrisposta, se alcune restrizioni di accesso debbano essere applicate:

(a) Opzioni di corrispondenza

Symfony2 crea un'istanza di RequestMatcher per ogni voce di access_control, che determina se un dato controllo di accesso vada usato o meno su questa richiesta. Le seguenti opzioni di access_control sono usate per le corrispondenze:

• path
• ip
• host
• methods

Si prende il seguente access_control come esempio:

Per ogni richiesta in arrivo, Symfony2 deciderà quale access_control usare in base a URI, indirizzo IP del client, nome host in arrivo, metodo della richiestsa. Si ricordi, viene usata la prima regola corrispondnete e, se ip, host o method non sono specificati per una voce, access_control corrisponderà per qualsiasi ip, host o method:

(b) Controllo dell'accesso

Una volta che Symfony2 ha deciso quale voce di access_control corrisponda, applica restrizioni di accesso in base alle opzioni roles e requires_channel:

• role Se l'utente non ha il ruolo fornito, l'accesso viene negato (internamente, viene lanciata AccessDeniedException);
• requires_channel Se il canale della richiesta in arrivo (p.e. http) non corrisponde a questo valore (p.e. https), l'utente sarà rinviato (p.e. rinviato da http a https, o viceversa).

Protezione tramite IP¶

In certe situazioni può succedere di limitare l'accesso a una data rotta basata su IP. Questo è particolarmente rilevante nel caso di Edge Side Includes (ESI), per esempio. Quando ESI è abilitato, si raccomanda di proteggere l'accesso agli URL ESI. Infatti, alcuni ESI possono contenere contenuti privati, come informazioni sull'utente attuale. Per prevenire un accesso diretto a tali risorse inserendo direttamnte l'URL nel browser, la rotta ESI deve essere protetta e resa visibile solo dalla cache del reverse proxy.

Ecco un esempio di come si possano garantire tutte le rotte ESI che iniziano per un certo prefisso, /esi, da intrusioni esterne:

Ecco come funziona quando il percorso è /esi/qualcosa dall'IP 10.0.0.1:

• La prima regola di controllo di accesso non corrisponde e viene ignorata, perché path corrisponde, ma ip no;
• La seconda regola di controllo di accesso non corrisponde (essendoci solo path, che corrisponde): non avendo l'utente il ruolo ROLE_NO_ACCESS, perché non definito, l'accesso è negato (il ruolo ROLE_NO_ACCESS può essere qualsiasi cosa che non sia un ruolo esistente, serve solo come espediente per negare sempre l'accesso).

Se ora la stessa richiesta arriva da 127.0.0.1:

• Ora, la prima regola di controllo di accesso corrisponde sia per path che per ip: l'accesso è consentito, perché l'utente ha sempre il ruolo IS_AUTHENTICATED_ANONYMOUSLY.
• La seconda regola di accesso non viene esaminata, perché la prima corrispondeva.

Protezione tramite canale¶

Si può anche richiedere di accedere a un URL tramite SSL, basta usare la voce aggiungere il parametro requires_channel in una voce access_control:

Proteggere un controllore¶

Proteggere l'applicazione basandosi su schemi di URL è semplice, ma in alcuni casi può non essere abbastanza granulare. Quando necessario, si può facilmente forzare l'autorizzazione dall'interno di un controllore:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// ...
use Symfony\Component\Security\Core\Exception\AccessDeniedException;

public function helloAction($name)
{
    if (false === $this->get('security.context')->isGranted('ROLE_ADMIN')) {
        throw new AccessDeniedException();
    }

    // ...
}

È anche possibile scegliere di installare e utilizzare l'opzionale JMSSecurityExtraBundle, che può proteggere il controllore utilizzando le annotazioni:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// ...
use JMS\SecurityExtraBundle\Annotation\Secure;

/**
 * @Secure(roles="ROLE_ADMIN")
 */
public function helloAction($name)
{
    // ...
}

Per maggiori informazioni, vedere la documentazione di JMSSecurityExtraBundle. Se si sta utilizzando la distribuzione standard di Symfony, questo bundle è disponibile per impostazione predefinita. In caso contrario, si può facilmente scaricare e installare.

Protezione degli altri servizi¶

In realtà, con Symfony si può proteggere qualunque cosa, utilizzando una strategia simile a quella vista nella sezione precedente. Per esempio, si supponga di avere un servizio (ovvero una classe PHP) il cui compito è quello di inviare email da un utente all'altro. È possibile limitare l'uso di questa classe, non importa dove è stata utilizzata, per gli utenti che hanno un ruolo specifico.

Per ulteriori informazioni su come utilizzare il componente della sicurezza per proteggere servizi e metodi diversi nell'applicazione, vedere Proteggere servizi e metodi di un'applicazione.

Access Control List (ACL): protezione dei singoli oggetti della base dati¶

Si immagini di progettare un sistema di blog, in cui gli utenti possono commentare i messaggi. Si vuole che un utente possa modificare i propri commenti, ma non quelli degli altri. Inoltre, come utente admin, si vuole essere in grado di modificare tutti i commenti.

Il componente della sicurezza viene fornito con un sistema opzionale di access control list (ACL), che è possibile utilizzare quando è necessario controllare l'accesso alle singole istanze di un oggetto nel sistema. Senza ACL, è possibile proteggere il sistema in modo che solo certi utenti possono modificare i commenti sui blog. Ma con ACL, si può limitare o consentire l'accesso commento per commento.

Per maggiori informazioni, vedere l'articolo del ricettario: Access Control List (ACL).

Da dove provengono gli utenti? (User Provider)¶

Durante l'autenticazione, l'utente invia un insieme di credenziali (di solito un nome utente e una password). Il compito del sistema di autenticazione è quello di soddisfare queste credenziali con l'insieme degli utenti. Quindi da dove proviene questa lista di utenti?

In Symfony2, gli utenti possono arrivare da qualsiasi parte: un file di configurazione, una tabella di una base dati, un servizio web o qualsiasi altra cosa si può pensare. Qualsiasi cosa che prevede uno o più utenti nel sistema di autenticazione è noto come "fornitore di utenti". Symfony2 viene fornito con i due fornitori utenti più diffusi; uno che carica gli utenti da un file di configurazione e uno che carica gli utenti da una tabella di una base dati.

1
2
3

users:
    - { name: 77, password: pass, roles: 'ROLE_USER' }
    - { name: user-name, password: pass, roles: 'ROLE_USER' }

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// src/Acme/UserBundle/Entity/User.php
namespace Acme\UserBundle\Entity;

use Symfony\Component\Security\Core\User\UserInterface;
use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 */
class User implements UserInterface
{
    /**
     * @ORM\Column(type="string", length=255)
     */
    protected $username;

    // ...
}

Codificare la password dell'utente¶

Finora, per semplicità, tutti gli esempi hanno memorizzato le password dell'utente in formato testuale (se tali utenti sono memorizzati in un file di configurazione o in una base dati). Naturalmente, in un'applicazione reale si consiglia, per ragioni di sicurezza, di codificare le password degli utenti. Questo è facilmente realizzabile mappando la classe User in uno dei numerosi "encoder" disponibili. Per esempio, per salvare gli utenti in memoria, ma oscurare le loro password tramite sha1, si può fare come segue:

Impostando iterations a 1 ed encode_as_base64 a false, viene eseguito una sola volta l'algoritmo sha1 sulla password, senza alcuna codifica supplementare. È ora possibile calcolare l'hash della password a livello di codice (ad esempio hash('sha1', 'ryanpass')) o tramite qualche strumento online come functions-online.com

Se si stanno creando i propri utenti in modo dinamico (memorizzandoli in una base dati), è possibile utilizzare algoritmi di hash ancora più complessi e poi contare su un oggetto encoder, che aiuti a codificare le password. Per esempio, supponiamo che l'oggetto User sia Acme\UserBundle\Entity\User (come nell'esempio precedente). In primo luogo, configurare l'encoder per questo utente:

In questo caso, si utilizza il più forte algoritmo sha512. Inoltre, poiché si è semplicemente specificato l'algoritmo (sha512) come stringa, il sistema per impostazione predefinita farà l'hash della password 5000 volte di seguito e poi la codificherà in base64. In altre parole, la password è stata notevolmente offuscata in modo che il suo hash non possa essere decodificato (cioè non è possibile determinare la password partendo dal suo hash).

New in version 2.2: Da Symfony 2.2, si possono usare anche i codificatori PBKDF2 e BCrypt.

1
2
3
4
5
6

$factory = $this->get('security.encoder_factory');
$user = new Acme\UserBundle\Entity\User();

$encoder = $factory->getEncoder($user);
$password = $encoder->encodePassword('ryanpass', $user->getSalt());
$user->setPassword($password);

Recuperare l'oggetto User¶

Dopo l'autenticazione, si può accedere all'oggetto User per l'utente corrente tramite il servizio security.context. Da dentro un controllore, assomiglierà a questo:

1
2
3
4

public function indexAction()
{
    $user = $this->get('security.context')->getToken()->getUser();
}

In un controllore, si può usare una scorciatoia:

1
2
3
4

public function indexAction()
{
    $user = $this->getUser();
}

In un template Twig, si può accedere a questo oggetto tramite la chiave app.user, che richiama il metodo GlobalVariables::getUser():

Utilizzare fornitori utenti multipli¶

Ogni meccanismo di autenticazione (ad esempio l'autenticazione HTTP, il form di login, ecc.) utilizza esattamente un fornitore utenti e, per impostazione predefinita, userà il primo fornitore dichiarato. Ma cosa succede se si desidera specificare alcuni utenti tramite configurazione e il resto degli utenti nella base dati? Questo è possibile attraverso la creazione di un nuovo fornitore, che li unisca:

Ora, tutti i meccanismi di autenticazione utilizzeranno il chain_provider, dal momento che è il primo specificato. Il chain_provider, a sua volta, tenta di caricare l'utente da entrambi i fornitori in_memory e user_db.

È anche possibile configurare il firewall o meccanismi di autenticazione individuali per utilizzare un provider specifico. Ancora una volta, a meno che un provider sia specificato esplicitamente, viene sempre utilizzato il primo fornitore:

In questo esempio, se un utente cerca di accedere tramite autenticazione HTTP, il sistema di autenticazione utilizzerà il fornitore utenti in_memory. Ma se l'utente tenta di accedere tramite il form di login, sarà usato il fornitore user_db (in quanto è l'impostazione predefinita per il firewall).

Per ulteriori informazioni su fornitori utenti e configurazione del firewall, vedere il Riferimento configurazione sicurezza.

I ruoli gerarchici¶

Invece di associare molti ruoli agli utenti, è possibile definire regole di ereditarietà dei ruoli creando una gerarchia di ruoli:

Nella configurazione sopra, gli utenti con ruolo ROLE_ADMIN avranno anche il ruolo ROLE_USER. Il ruolo ROLE_SUPER_ADMIN ha ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH e ROLE_USER (ereditati da ROLE_ADMIN).

Confronto tra stringhe¶

Il tempo impiegato nel confronto tra due stringhe dipende dalle rispettive differenze. Il tempo può essere usato da un attaccante, quando le due stringhe rappresentano una password, per esempio. È noto come Timing attack.

Internamente, quando si confrontano due password, Symfony usa un algoritmo a tempo costante. Si può usare la stessa strategia nel proprio codice, grazie alla classe StringUtils:

1
2
3
4

use Symfony\Component\Security\Core\Util\StringUtils;

// password1 è uguale a password2?
$bool = StringUtils::equals($password1, $password2);

Generazione di un numero casuale¶

Ogni volta che occorre generare un numero casuale sicuro, si raccomanda di usare la classe SecureRandom:

1
2
3
4

use Symfony\Component\Security\Core\Util\SecureRandom;

$generator = new SecureRandom();
$random = $generator->nextBytes(10);

Il metodo nextBytes() restituisce una stringa casuale, composta dal numero di caratteri passati come parametro (10, nell'esempio appena visto).

La classe SecureRandom funziona meglio se è installato OpenSSL, ma, nel caso in cui non lo sia, si appoggia a un algoritmo interno, che ha bisogno di un file seme per funzionare. Basta passare il nome di un file, per abilitarlo:

1
2

$generator = new SecureRandom('/un/percorso/dove/memorizzare/il/seme.txt');
$random = $generator->nextBytes(10);