Autenticazione client per certificati in Google APP Engine java

Il punto dei certificati utente è che ci sono elementi che sono memorizzati sul lato utente, in particolare la chiave privata dell'utente . I certificati per l'autenticazione verranno utilizzati come parte di SSL (HTTPS è HTTP-in-SSL).

In SSL le cose vanno come segue:

• Il client si connette. Il client e il server parlano tra loro.
• Il server mostra il suo certificato (che contiene la chiave pubblica del server). Il client verifica che il certificato sia valido (firmato correttamente da una CA attendibile dal cliente, contiene il nome del server previsto, non scaduto e così via) e quindi utilizza la chiave pubblica del server per eseguire lo scambio di chiavi asimmetriche da cui è derivata la chiave di sessione utilizzata per proteggere il flusso di dati successivo.
• Il server potrebbe richiedere un certificato client . In tal caso, il client deve inviare il suo certificato (che contiene la chiave pubblica del cliente) e dimostrare la padronanza della chiave privata corrispondente.

Questi passaggi sono tutti fatti nel protocollo SSL e devi solo lasciarli correre. Il tuo lavoro, tuttavia, sul server, è quello di convalidare il certificato client. Cos'è quello ? Un certificato, di per sé, non prova nulla. In effetti, tutti possono creare un certificato autofirmato con contenuti arbitrari; l'hai appena fatto da solo Ciò che rende un certificato utile è come è stato generato in primo luogo.

Nel tuo caso, ci sono principalmente tre possibilità:

1. Il server ha una copia di tutti i certificati utente (non le chiavi private) e quindi può confrontare il certificato ricevuto con tutti i certificati utente conosciuti. Un certificato è quindi validato in quanto bit-to-bit uguale a un certificato noto. Poiché il certificato è stato creato sul lato client, ciò richiede una fase di registrazione iniziale in cui l'utente presenta il suo certificato al server.

2. Il server emette i certificati agli utenti. Ciò significa che per creare un certificato, un codice sul lato utente (ad esempio nel suo browser) genera una coppia di chiavi privata / pubblica, invia la chiave pubblica al server e il server la inserisce in un nuovo certificato insieme a il nome utente e il server lo firma. Il certificato risultante viene rinviato all'utente. Successivamente, quando l'utente si connette, il server riconosce il certificato utente in quanto è firmato dal server stesso: il server utilizza la propria chiave pubblica per verificare la firma sul certificato utente. Se quella firma è valida, il server sa che i contenuti del certificato sono affidabili, in particolare il nome utente.

3. Stesso sistema della situazione 2, ad eccezione del fatto che l'emissione del certificato è delegata a un altro sistema dedicato che verrà chiamato Certificazione Autorità . L'utente ottiene il suo certificato dalla CA, senza coinvolgere il tuo server. Il server può convalidare il certificato inviato dall'utente verificando che sia firmato correttamente dalla CA; il server ha una copia della chiave pubblica della CA e si fida della CA per l'emissione dei certificati solo agli utenti autenticati correttamente.

In realtà solo il terzo caso ha senso. I certificati sono utili in situazioni in cui l'asserzione di identità (da parte della CA) è disgiunta dall'utilizzo di tale identità (nel proprio server). Se il server è esso stesso la CA, l'utilizzo dei certificati non offre alcun vantaggio rispetto a un'autenticazione più semplice basata su password (la "password" può essere una lunga sequenza memorizzata automaticamente dal browser, nota come cookie ).

Se sei ancora intenzionato a utilizzare i certificati, devi prima essere chiaro su cosa sia una CA, cosa fa e dove si adatta al tuo sistema.

Penso che non sia possibile autenticare il client utilizzando l'handshake SSL / TLS reciproco con GAE.

Per raggiungere questo obiettivo in Java EE dovresti inserirlo in web.xml

<login-config>
    <auth-method>CLIENT-CERT</auth-method>
</login-config>

Fonte: link

Tuttavia, i documenti di AppEngine dicono:

App Engine does not support custom security roles (<security-role>) or alternate authentication mechanisms (<login-config>) in the deployment descriptor.

Fonte: link

Affinché un utente possa presentare un certificato valido per l'autenticazione, è necessario fornire preventivamente il certificato basato sulla propria chiave autofirmata a detto utente. Sulla base del tuo commento sull'estrazione del nome del problema, sembra che dovrai stabilire un'autorità di certificazione (CA) per generare certificati che forniscano in anticipo all'utente detto nome incorporato (e la tua chiave autofirmata alla radice).

Tipicamente quel tipo di provisioning è macchinoso e contrario all'esperienza complessiva del web. Di conseguenza, la tua strategia non viene utilizzata e i browser non sono progettati per supportarlo. Se si desidera continuare lungo queste linee, prendere in considerazione la possibilità di rivedere come SSH può essere autenticato dai certificati (utilizza la chiave pubblica e privata PKI ma non una catena di attendibilità CA, ma la comprensione del metodo dovrebbe comunque essere illuminante).

Ancora una volta i browser degli utenti non sono progettati per offrire questo certificato, quindi dovrai fornire una funzione per caricarli sul tuo server. Per quanto riguarda la convalida e l'estrazione del nome, Java ha le routine necessarie nella funzionalità che fornisce il keytool che hai già utilizzato.