Spesso si ospitano dei servizi Windows Communication Foundation (WCF) in IIS ma non è l'unico modo per esporli ai client. Un qualsiasi applicativo di tipo console o anche una semplice applicazione Windows Forms possono ospitare dei servizi e ci sono alcuni casi in cui questa opzione non è poi così assurda come potrebbe sembrare.
Una alternativa host per WCF propriamente confrontabile con IIS è un servizio di Windows, capace di partire in modo automatico/unattended all'avvio del sistema e pensato per operare 24x7.
In questo post racconto la mia esperienza di deployment di un servizio Windows. Questi sono i passi che ho seguito:
- Registrare il certificato se, come me, avete scelto di implementare un servizio che usa:
- sicurezza a livello di messagio
- credenziali di sicurezza UserName
- un validatore custom per le credenziali
- Registrazione namespace
- MSMQ, privilegi di accesso e registrazione certificati
Certificato
Il certificato, pubblicamente verificabile ed emesso da una Certification Authority (CA), può essere registrato nel server usando l'add-in Certificate in una console MMC. Lanciare mmc.exe, menu File, voce Add/Remove Snap-in, aggiungere Certificate, selezionare quale certificate store gestire.
Nel mio caso ho scelto di registrare il certificato a livello di computer account, tra i Trusted Publishers. Questa impostazione deve coincidere con quanto riportato nella configurazione del servizio WCF.
Il certificato viene utilizzato dal servizio WCF per gestire la crittografia delle comunicazioni client-server e quindi l'account con cui viene eseguito il servizio Windows deve avere accesso alla chiave privata.
Il servizio Windows può utilizzare un qualsiasi account predefinito, come LocalSystem, o del dominio. Nel mio caso ho deciso di creare un account di dominio specifico per il servizio WCF, al fine di controllare facilmente i privilegi di accesso alle diverse risorse del dominio.
WinHttpCertCfg.exe (MSDN e Support) è uno strumento da linea di comando per verificare e concedere l'accesso al certificato.
Nel mio scenario ho eseguito questo comando per verificare gli account che hanno già accesso alla chiave:
winhttpcertcfg -l -c LOCAL_MACHINE\TrustedPublisher -s <nome certificato>
Questo comando invece per assegnarlo all'utente desiderato :
winhttpcertcfg -g -c LOCAL_MACHINE\TrustedPublisher -s <nome certificato> -a <dominio>\<utente>
Namespace
Probabilmente il servizio WCF da esporre ha degli endpoint con binding http e se il sistema server è Windows 2003 Server SP1, Windows Vista o Windows XP SP2 è necessario avere a che fare con HTTP.SYS. Rimando a questo articolo per i dettagli su HTTP.SYS.
Per quanto ci interessa ai fini di WCF, solo gli amministratori hanno il diritto di registrare un namespace arbitrario, senza previa autorizzazione, mentre l'account che si usa per il servizio Windows non ha privilegi così elevati.
Per registrare il namespace si utilizza lo strumento da linea di comando HttpCfg.exe (MSDN), già presente in XP SP2, installabile con i support tools in Windows Server 2003.
Il problema di HttpCfg.exe, per chi è allergico agli strumenti da riga di comando, è la complessità dei parametri. Dominick Baier ha realizzato HttpSysCfg.exe, un utilissimo strumento che semplifica le operazioni.
Nel mio caso ho selezionato l'account per il servizio Windows ed ho aggiunto l'URI del servizio, nella forma:
http://+:<porta>/<TuaApplicazione>
L'URI è diverso da un caso all'altro. Lo strumento ha bisogno di HttpCfg.exe per funzionare. Per i dettagli si vedano questo post e anche questo.
Su Vista non è presente il tool HttpCfg.exe e si utilizza il comando netsh.exe per configurare HTTP. Si può anche installare HttpCfg.exe ma per la registrazione del namespace netsh.exe è altrettanto "semplice". Con netsh.exe il comando avrà una sintassi di questo tipo:
netsh http add urlacl http://+:<porta>/<TuaApplicazione> user=<utente>
MSMQ
Nel mio scenario ci sono anche degli enpoint con binding msmq (molto interessante). Si deve verificare che all'account del servizio Windows siano concessi i privilegi necessari per accedere propriamente alla coda.
Uilizzando MSMQ ho anche incontrato un errore inatteso. Quando il servizio WCF tentava l'accesso alla coda per inserire un messaggio, riceveva una eccezione del tipo: "No internal Message Queuing certificate exists for the user".
Per risolvere il problema e non perdere troppo tempo ho preferito usare le maniere forti. Ho lanciato MMC utilizzando (RunAs) l'account per il servizio Windows, ho apero lo strumento di amministrazione di MSMQ (Computer Management) ed ho registrato lo user certificate (Technet). Immagino ci siano altri modi per affrontare il problema.
Conclusione
Avendo iniziato ad usare WCF nel 2003, mi lascia abbastanza perplesso la mancanza di strumenti amministrativi visuali in grado di coprire queste semplici esigenze. I tool di integrazione di WCF in Visual Studio 2005 non sono ancora giunti alla versione definitiva e potrebbe spuntare qualcosa di nuovo nelle prossime settimane (o mesi).
Immagino che tutto quanto ho descritto si possa realizzare con delle custom actions nel setup del servizio Windows ma nel mio scenario sarebbe stato un overkill.
Ovviamente ho raccontato la mia personale esperienza, ho tralasciato molti dettagli e sottinteso alcuni concetti di WCF. Per maggiori informazioni su WCF questo è un ottimo punto di partenza.
Post
