Autenticazione/crittografia di Windows in WCF con NetTcpBinding

Question

Sto cercando di capire in che modo l'autenticazione/crittografia di Windows funziona con NetTcpBinding in WCF. Ho bisogno di sapere esattamente quale algoritmo di crittografia è utilizzato per crittografare i dati che attraversano il filo (e qualche documentazione per dimostrarlo). L'autenticazione/crittografia di Windows funzionerà ancora se il client e/o l'host non si trovano su un dominio?

Answer 1

Il netTcpBinding che utilizza le credenziali di Windows richiede che il chiamante e il servizio si trovino nello stesso dominio, o almeno su domini che si fidano reciprocamente. In caso contrario, il server non sarà in grado di verificare le credenziali di Windows e rifiuterà la chiamata di servizio.

Come per la crittografia: puoi anche scegliere quale scegliere! :-) TripleDES, AES: lo chiami anche con lunghezze di tasti variabili.

Vedere l'articolo Fundamentals of WCF Security: parla di tutti gli aspetti della sicurezza e della crittografia; vedi anche MSDN Docs su Securing Services che va in maggiore dettaglio; è possibile trovare una buona panoramica here che mostra le proprietà dell'elemento di sicurezza del trasporto di base HTTP.

Answer 2

L'anno scorso ho dovuto implementare un sistema distribuito utilizzando wcf che richiedeva un meccanismo sia sicuro che performante su tutti gli strati del sistema. Abbiamo deciso di creare la nostra architettura di sicurezza creando un token crittografato binario. Il token crittografato conteneva tutte le autorizzazioni di un determinato utente.

Quindi, ad esempio, un utente accederà al sistema e, se correttamente autenticato, riceverà un token crittografato. Questo token è stato archiviato localmente sul client web. Tutte le ulteriori richieste dell'utente conterranno quel token. Il token è stato utilizzato in diversi livelli dell'architettura. Il server web lo userebbe per decidere quali elementi visivi abilitare o disabilitare. Poiché il livello di servizio era esposto a Internet, ogni porta aperta controllava il token per l'autenticazione e verificava se quel token avesse il permesso appropriato per eseguire una determinata attività. Il livello aziendale potrebbe verificare nuovamente per un diritto più specifico incluso nel token.

I vantaggi:

• Non importava se stessimo usando NetTcpBinding o qualsiasi altro tipo di legame (e abbiamo usato più di un tipo di associazione).
• Abbiamo risparmiato un sacco di andata e ritorno al database
• Potremmo usare lo stesso motivo su diverse piattaforme

So che probabilmente non risponde alle vostre domande specifiche, ma sarà forse dare qualche per spunti di riflessione mentre stai ancora decidendo l'architettura interna del tuo sistema.