[JAVA] RMI, come autenticare gli utenti?

[lovaz]

Salve a tutti.

Avendo un'applicazione distribuita multiutente, come riconosco l'utente
che sta effettuando la chiamata?

Ad esempio, se un client chiama un metodo tipo changePassword(...),
il server deve conoscere l'utente di cui cambiare la password.

Io avevo pensato di avere un server per ogni utente autenticato,
oppure di riconoscere l'host del client tramite RemoteServer.getClientHost(),
ma se ci sono più utenti nello stesso host?

Potrei forse intervenire sulle socket factory?

Grazie

[lovaz]

Mi rispondo da solo:
con RMI si possono esportare più server sulla stessa porta,
quindi mi sa che creerò 1 server per ogni utente.

Grazie lo stesso

[^TiGeRShArK^]

ehmm..
ma passare la stringa dell'username nel metodo changePassword?
qualcosa del tipo:

superServerPippone.changePassword("MyUser", "NewPassword");

[lovaz]

Sì, ma se l'utente tizio chiama:

superServerPippone.changePassword("caio","asdfg");

[morskott]

Originariamente inviato da lovaz

Sì, ma se l'utente tizio chiama:

superServerPippone.changePassword("caio","asdfg");

e se fai

superServerPippone.changePassword(SHA("tizio","password attuale"),"pollo")

??

Tecnicamente solo tizio sa calcolare la firma hash con sha di <user,passwordAttuale>. (è la prima tecnica di autenticazione che mi è venuta in mente, se mi ci impegno potrei trovarne di migliori)

[kingv]

Originariamente inviato da morskott

Tecnicamente solo tizio sa calcolare la firma hash con sha di <user,passwordAttuale>. (è la prima tecnica di autenticazione che mi è venuta in mente, se mi ci impegno potrei trovarne di migliori)

se non gli passi l'utente come fa il server a sapere di chi deve cambiare la password?

[morskott]

Originariamente inviato da kingv

se non gli passi l'utente come fa il server a sapere di chi deve cambiare la password?

Semplice, scanna tutti gli user registrati fino a trovare quello giusto (oppure la cambia ad uno random )

Scherzi a parte basta passarglielo nel metodo (che rimane sicuro perchè l'hash lo sa calcolare solo l'utente legittimo), tecnicamente sarebbe passibile di attacco di replay, ma visto che è un metodo di cambio password la vecchia password non sarà piu valida dopo l'invocazione

[lovaz]

Sì, ma mi interessa conoscere l'utente non solo per il cambio password,
ma ad esempio anche per transazioni finanziarie tipo
diminuisci/aumenta credito, ecc.

Praticamente un'autenticazione per ogni chiamata.

Vedrò, intanto mi studio le socket factory ssl, alla prossima...

[morskott]

Originariamente inviato da lovaz

Sì, ma mi interessa conoscere l'utente non solo per il cambio password,
ma ad esempio anche per transazioni finanziarie tipo
diminuisci/aumenta credito, ecc.

Praticamente un'autenticazione per ogni chiamata.

Vedrò, intanto mi studio le socket factory ssl, alla prossima...

Allora puoi fare tipo kerberos (versione semplificata e adattata allo scopo), puoi creare un "Biglietto" che alla prima autenticazione del client col server il client se lo tiene per tutta la sessione e che deve esser presentato ad ogni richiesta che farà in futuro, qualcosa tipo

public class Biglietto{
private String user;
private TimeStamp timeToLive //TimeStamp sarà una classe che dice per quanto tempo il biglietto è valido
private String server;
private String fingerPrint;

//costruttori etc. etc.
}

e ogni chiamata del client al server sarà del tipo[code]Biglietto b=//biglietto ottenuto all'autenticazione
sever.doSomeWork(b,//altri parametri);[code], per l'autenticazione potresti utilizzare una banale sfida

Client

String sfidaDalServer=server.primoPassoAutentica("sonoAlice");
Biglietto b=server.secondoPassoAutentica(calcolaHash(sfidaDalServer,miaPassword));

Il server alla richiesta "primoPassoAutentica" dovrà generare una stringa completamente casuale (ovviamente diversa ad ogni nuova invocazione del primo passo) e calcolare e memorizzare l'hash della sfida che ha mandato e della pass dell'utente, e alla seconda fase il server controlla che l'hash che gli dai sia uguale a quello che si è calcolato lui.
Attenzione che così il server autentica il client, ma il client non è sicuro di parlare col server, per quello ci vorrebbe una autentica a 2/3 direzioni.

Il server avrà un insieme di biglietti validi e ad ogni richiesta del client controlla prima di tutto se il biglietto è valido (tramite confronto con la sua tabella), e poi l'utente che richiede servizio.

[banryu79]

Originariamente inviato da morskott

Semplice, scanna tutti gli user registrati fino a trovare quello giusto...

(poverini... )

[morskott]

Originariamente inviato da banryu79

(poverini... )

la dura vita degli utenti......

[lovaz]

Originariamente inviato da morskott

... per l'autenticazione potresti utilizzare una banale sfida
...
Attenzione che così il server autentica il client, ma il client non è sicuro di parlare col server, per quello ci vorrebbe una autentica a 2/3 direzioni.
...

Infatti alla prima autenticazione faccio così, una getChallenge() e una
sendResponse(), che ritorna un riferimento al server (oggetto remoto)
creato ad hoc per l'utente, che fa quindi le veci del biglietto...
ogni chiamata remota è come se avesse come parametro (nascosto)
il server a cui è diretta.

Poi potrei anche usare le socket factory SSL con autenticazione del client,
ho visto che le modifiche al codice sono minime, il grosso è la generazione
delle keystore/truststore.

Sto facendo delle prove, mi rifaccio vivo fra qualche giorno.

[morskott]

Originariamente inviato da lovaz

Infatti alla prima autenticazione faccio così, una getChallenge() e una
sendResponse(), che ritorna un riferimento al server (oggetto remoto)
creato ad hoc per l'utente, che fa quindi le veci del biglietto...
ogni chiamata remota è come se avesse come parametro (nascosto)
il server a cui è diretta.

Poi potrei anche usare le socket factory SSL con autenticazione del client,
ho visto che le modifiche al codice sono minime, il grosso è la generazione
delle keystore/truststore.

Sto facendo delle prove, mi rifaccio vivo fra qualche giorno.

Oppure, sempre con l'idea della classe "Biglietto" potresti fare questo schema

U->S: sono Alice
S->U: N (il server invia all'utente un nonce (stringa casuale sempre diversa))
U->S: N',H(N,N',S,K)
S->U: H(N,N',K)

doce con K ho indicato la password e con H(..) la funzione di hash, così sono mutuamente autenticati

[lovaz]

N' e S cosa sono?

[morskott]

Originariamente inviato da lovaz

N' e S cosa sono?

N' è un secondo nonce diverso da N e S la stringa che identifica il Server