TsgcWSAPIServer_WebAuthn

Il componente TsgcWSAPIServer_WebAuthn fornisce una soluzione semplice ma potente per implementare il server Relying Party WebAuthn, abilitando l'autenticazione senza password nella propria applicazione web. Un'applicazione WebAuthn è composta da un server WebAuthn che gestisce la registrazione e l'autenticazione lato server e da un'applicazione lato client che di solito è un'applicazione javascript.

 

WebAuthn richiede l'uso di connessioni sicure (SSL/TLS), quindi le librerie OpenSSL devono essere distribuite e configurate con il server.

 

È supportata solo l'API OpenSSL 3.0.0+, pertanto le versioni precedenti di OpenSSL potrebbero non funzionare.

 

Configurazione

 

Il TsgcWSAPIServer_WebAuthn deve essere collegato a un server HTTP, TsgcWebSocketHTTP_Server o TsgcWebSocketServer_HTTPAPI utilizzando la proprietà Server. Può configurare gli endpoint del server che gestiranno le opzioni di registrazione e autenticazione, e le opzioni WebAuthn come gli algoritmi supportati, le origini e altro.

 

Opzioni degli endpoint

Qui è possibile configurare gli endpoint del server che gestiranno le richieste HTTP/JavaScript per utilizzare WebAuthn come autenticatore. Il componente è già configurato con endpoint predefiniti, ma è possibile modificarli tutti per adattarli alle proprie esigenze.

 

• AuthenticationOptions: per impostazione predefinita è /sgcWebAuthn/Authentication/Options
• AuthenticationVerify: per impostazione predefinita è /sgcWebAuthn/Authentication/Verify
• RegistrationOptions: per impostazione predefinita è /sgcWebAuthn/Registration/Options
• RegistrationVerify: per impostazione predefinita è /sgcWebAuthn/Registration/Verify
• Webauthn: include la libreria javascript utilizzata per impostazione predefinita. È possibile disabilitare questa proprietà e utilizzare la propria libreria webauthn.
• Test: per impostazione predefinita è disabilitato; usarlo solo per testare la funzionalità WebAuthn.

 

Esempio: se il server è in ascolto sul dominio www.test.com, la richiesta alle opzioni di autenticazione per impostazione predefinita sarà http://www.test.com/sgcWebAuthn/Authentication/Options

 

Opzioni WebAuthn

In questa proprietà può configurare le opzioni principali del componente WebAuthn Server.

 

• RelyingParty: una proprietà obbligatoria in cui deve essere definito il nome DNS del server. Esempio: se il server è in esecuzione sul dominio www.test.com, impostare questa proprietà su "www.test.com".

 

WebAuthn utilizza le origini per applicare i vincoli della politica same-origin, essenziali per prevenire phishing e attacchi cross-site. Durante i processi di registrazione e autenticazione WebAuthn, l'origine viene rigorosamente validata dal browser e dall'autenticatore.

 

• Origins: Se le richieste possono provenire da origini diverse, utilizzare la proprietà Origin per impostare le origini aggiuntive. Esempio: se le richieste possono provenire da login.test.com e www.test.co.uk, configurare la proprietà Origins con i valori: https://login.test.com e https://www.test.co.uk

 

• TopOrigins: Normalmente, WebAuthn si basa sull'origine del frame chiamante (ovvero quello che richiama navigator.credentials.create() o navigator.credentials.get()). Tuttavia, le pagine web possono essere incorporate in iframe, che potrebbero provenire da un'origine diversa rispetto alla pagina di primo livello. Questo apre potenziali rischi di abuso o attacchi di tipo clickjacking. Per mitigare questo problema, la specifica WebAuthn Level 2 introduce TopOrigin, dove è possibile definire i TopOrigins.

 

In WebAuthn, crossOrigin è un parametro booleano che indica se l'operazione WebAuthn viene eseguita da un contesto cross-origin, ad esempio un iframe incorporato da un'origine diversa rispetto al contesto di navigazione di primo livello.

Questo parametro è stato introdotto per aiutare browser e autenticatori a gestire in modo sicuro le richieste di autenticazione in ambienti incorporati, uno scenario comune nelle moderne applicazioni web.

 

• AllowCrossOrigins: se true, indica che le richieste provenienti da un iframe cross-origin (ad esempio un iframe su https://auth.example.com incorporato in una pagina su https://app.example.org) sono consentite. Per impostazione predefinita è disabilitato.

 

WebAuthn supporta una varietà di algoritmi crittografici per la generazione e la verifica delle credenziali a chiave pubblica. Questi algoritmi vengono utilizzati durante la registrazione delle credenziali (con navigator.credentials.create()) e l'autenticazione (con navigator.credentials.get()), e garantiscono la firma e la validazione sicure delle challenge utilizzando coppie di chiavi asimmetriche. Il server è configurato per impostazione predefinita con ES256 e RS256, che sono gli algoritmi più comuni. È possibile modificare in qualsiasi momento quali algoritmi sono supportati dalla proprietà Algorithms. Sono supportati i seguenti algoritmi:

 

• ES256
• ES384
• ES512
• RS256
• RS384
• RS512
• PS256
• PS384
• PS512
• RS1
• EdDSA

 

In WebAuthn, l'attestazione è un meccanismo opzionale che consente all'autenticatore (ad esempio dispositivo o chiave di sicurezza) di fornire informazioni sul proprio produttore, modello e caratteristiche di sicurezza durante la creazione delle credenziali. Queste informazioni aiutano la Relying Party (RP) a decidere se fidarsi dell'autenticatore.

 

Diversi formati di attestazione definiscono come questi dati sono strutturati e verificati. Tre formati comunemente utilizzati sono android-key, packed e altri come fido-u2f, apple o none. Per impostazione predefinita, tutti i formati di attestazione sono abilitati. Di seguito è riportato l'elenco dei formati di attestazione supportati:

 

• NoneAttestation: in questo caso non vengono restituiti dati di attestazione. Privilegia la privacy dell'utente evitando l'esposizione degli identificatori del dispositivo. Comune nelle applicazioni che non si preoccupano della provenienza del dispositivo.

 

• PackedAttestation: è un formato flessibile e compatto utilizzato da molti autenticatori. L'autenticatore restituisce un certificato di attestazione e una firma. Può essere: Full attestation: Firmato con una chiave e un certificato forniti dal produttore, oppure Self attestation: Firmato utilizzando la chiave privata della credenziale. Il più utilizzato su diverse piattaforme (es. YubiKey, Windows Hello).

 

• TPMAttestation: Utilizzato da dispositivi con un Trusted Platform Module (TPM). L'attestazione è firmata utilizzando le chiavi del TPM e include una catena di certificati. Utilizzato da desktop/laptop aziendali con chip TPM (ad esempio, macchine Windows).

 

• AndroidKeyAttestation: Utilizzato dai dispositivi Android con l'Android Keystore. La chiave viene generata in hardware e l'attestazione include informazioni firmate da una catena di certificati emessa dal produttore del dispositivo. Utilizzato dai telefoni Android con keystore basati su hardware (TEE o StrongBox).

 

• AppleAttestation: Utilizzato dagli autenticatori di piattaforma Apple, come Touch ID e Face ID. L'attestazione viene generata dalle API interne di Apple e include un formato di certificato speciale. Utilizzato su Safari tramite la biometria Apple.

 

• FidoU2FAttestation: Formato di attestazione legacy utilizzato dagli autenticatori FIDO U2F. Restituisce un certificato e una firma compatibili con U2F. Utilizzato da chiavi di sicurezza più vecchie (ad es. i primi YubiKey) che supportano FIDO U2F.

 

Nell'API WebAuthn, AllowCredentials è un campo facoltativo utilizzato durante il processo di autenticazione (tramite navigator.credentials.get()). Specifica un elenco di ID credenziale autorizzati ad autenticare l'utente per una determinata Relying Party (RP). Questo meccanismo consente alla RP di controllare quali credenziali sono considerate valide per un tentativo di accesso. La proprietà credentials contiene i seguenti campi:

 

• AllowCredentials: se abilitato (false per impostazione predefinita) specifica un elenco di ID credenziali autorizzati ad autenticare l'utente

 

• ExcludeCredentials: dato un nome utente, mostra tutte le credenziali esistenti già memorizzate nel componente server.

 

• Limit: il numero massimo di credenziali che verranno inviate quando ExcludeCredentials è true.

 

Protocollo WebAuthn

 

• Registrazione WebAuthn: Il server genera una sfida e la invia al client, che utilizza un autenticatore (ad esempio una chiave di sicurezza o un dispositivo biometrico) per creare una coppia di chiavi. La chiave pubblica viene inviata e memorizzata dal server per le autenticazioni future. Di seguito sono riportate ulteriori informazioni sugli eventi del flusso di registrazione:
  • Richiesta di registrazione WebAuthn
  • Risposta di registrazione WebAuthn
  • Risultato di registrazione WebAuthn

 

• Autenticazione WebAuthn: Il server invia una sfida al client, che la firma usando la chiave privata precedentemente registrata memorizzata nell'autenticatore. La risposta firmata viene verificata dal server usando la chiave pubblica memorizzata per confermare l'identità dell'utente. Di seguito ulteriori informazioni sugli eventi del flusso di autenticazione:
  • Richiesta di Autenticazione WebAuthn
  • Risposta di Autenticazione WebAuthn
  • Risultato di Autenticazione WebAuthn

 

• MDS: Il FIDO Alliance Metadata Service (MDS) è un repository centralizzato di dichiarazioni di metadati utilizzato dalle parti di riferimento per validare l'attestazione degli autenticatori e verificare l'autenticità del modello del dispositivo.

 

 

• Autorizzazione: Il client può richiedere un token bearer dal server durante il flusso di autenticazione. Questo token può essere utilizzato in seguito per aprire una nuova connessione WebSocket o HTTP senza dover effettuare nuovamente il login tramite passkey.
  • Autorizzazione WebAuthn WebSocket
  • Autorizzazione WebAuthn HTTP