Attestazioni di accesso
Header e claim che l’applicazione deve verificare nelle richieste Zero Trust.
Loclix rimuove gli header X-Loclix-Access-* inviati dai visitatori. Le richieste autorizzate all’origine ricevono:
| Header | Valore |
|---|---|
X-Loclix-Access-Jwt-Assertion | JSON Web Token (JWT) firmato con RS256 |
X-Loclix-Access-Subject | ID del provider e identificativo immutabile del soggetto |
X-Loclix-Access-Provider | ID del provider configurato |
X-Loclix-Access-Email | Email verificata, quando disponibile |
Configurazione attendibile
Verifica l’attestazione firmata prima di considerare attendibile qualsiasi header di identità. Leggi i claim di identità solo dopo la verifica. Imposta issuer e audience attesi tramite la configurazione attendibile dell’applicazione. Non scegliere mai un endpoint delle chiavi dai claim di un token non verificato.
Issuer: https://APPLICATION-HOST/_loclix/access/
Audience: APPLICATION-ID
Public keys: https://APPLICATION-HOST/_loclix/access/jwks.json
Algorithm: RS256
Lifetime: 60 secondsClaim
L’endpoint delle chiavi pubbliche restituisce un JSON Web Key Set (JWKS), con un kid per selezionare la chiave.
Le attestazioni contengono iss, aud, sub, exp, nbf, iat, jti, application_id, provider, email, email_verified, name, host, method, uri e origin_uri.
Il claim sub usa lo stesso formato specifico del provider dell’header del soggetto.
uri include il percorso pubblico con i caratteri codificati e la stringa di query. origin_uri contiene il percorso finale all’origine dopo le riscritture delle route Loclix.
Verifica
L’origine deve verificare la firma RS256, issuer e audience configurati, scadenza e istante di inizio validità.
Deve confrontare host, metodo e origin_uri firmati con l’hostname pubblico atteso e la richiesta ricevuta.
Se un altro proxy attendibile riscrive le richieste, conserva i valori originali attraverso la sua connessione autenticata.
Usa il claim email solo quando email_verified è true. Usa l’identificativo immutabile del soggetto come identificativo dell’account applicativo.
Non registrare nei log né restituire i token di attestazione. Sono credenziali bearer e possono essere riutilizzati per la stessa richiesta durante la loro breve validità.
Limita l’accesso diretto all’origine con un firewall o con l’autenticazione delle connessioni da Loclix per ridurre il rischio di riutilizzo fuori da Loclix.