Il blog di Alessandro Damiani

E' sicuramente una cosa banale ma  mi sono accorto che in molti fanno giri strani per fare partire in debug diverse istanze di progetti all'interno della medesima soluzione (talvolta anche aprire 2 volte la stessa soluzione e fare attach strani per poter andare in debug .. )

Per quelli che non lo sanno butto lì un suggerimento, il visual studio ci viene incontro semplificandociparecchio  la vita :  facendo click con il bottone destro del mouse sul progetto che volete far partire in debug o di cui volete una nuova istanza (per esempio per simulare diversi client ) basta selezionare la voce  "debug\avvia nuova istanza" (debug\start new instance nella versione inglese, se volete simulare diverse istanze aperte basta ripetere il procedimento.

Il passo della predaia, un panorama da togliere il fiato e il silenzio assoluto  (dopo avere spento la moto)

Naturalmente con una naked... la mia!!!!  :D. Basta fermarsi prima della pista bianca a quel punto diventa veramente un pò complicato...  

Ho visto che ci sono tanti motociclisti in Ugi, perché non creare un ugidotnet motor club ?  ;)

ps

La seconda foto è fatta con il telefonino e terribilmente controluce vista  l'ora , la prima ,dato che la mia non rendeva l'ho tirata giù da internet , non so se si nota la differenza... :D

Ale

In questi giorni mi trovo a litigare con header soap e standard WS -* vari.  Uno dei problemi era di capire cosa wcf mette a disposizione.. beh  ... un mare di roba!!

Molti standard sono implementati out of the box  , esempio : ws addressing, ws reliable messaging, ws atomic transaction, ws security ...e non li ho citati tutti (per una visione di insieme sui vari standard  : Making Sense of all these Crazy Web Service Standards)

Per avere dei riferimenti sul mapping wcf /ws* potete leggere questo articolo davvero utile su topxml.

Non solo vi parla del mapping binding ma dà anche qualche dritta sugli switch di configurazione che permettono di configurare il wcf in modo che l'header soap esca nel formato desiderato.

Facciamo un esempio  pratico, supponiamo di volere realizzare un'autenticazione consumer - service tramite scambio di certificati , senza entrare nel merito della configurazione (mi riprometto di scrivere qualcosa di completo su questo fra qualche giorno) 

Nel codice del contratto mettiamo pure quello che vogliamo nell'ambito della decenza informatica :)  basta non inserire codice per bypassare la configurazione.

Utilizzando in modo "normale" gli attributi (tipo l'esempio generato dal visual studio nella creazione di un servizio WCF ) usare servizi non protetti in basic http, piuttosto che protetti con token di vario genere e natura diventa solo un problema di configurazione totalmente trasparente a chi sviluppa il codice.

Mettiamo su la nostra infrastruttura di sicurezza :

Nel behaviour specifichiamo le credenziali con le quali il servizio si presenterà al client  e il modo in cui il servizio autenticherà il client:

<serviceBehaviors>
    <behavior name="CertBehavior">
     <serviceMetadata httpGetEnabled="true" />
     <serviceCredentials>
      <clientCertificate>
       <authentication certificateValidationMode="ChainTrust" revocationMode="NoCheck" />
      </clientCertificate>
      <serviceCertificate findValue="CN=DEVCER" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectDistinguishedName" />
     </serviceCredentials>
    </behavior>
   </serviceBehaviors>

Utilizziamo per il nostro endpoint il seguente Binding :

 <wsHttpBinding>
    <binding name="SecuredByCertificate">
     <reliableSession enabled="false" />
     <security>
      <transport clientCredentialType="None" />
      <message clientCredentialType="Certificate" negotiateServiceCredential="false" establishSecurityContext="false" />
     </security>
    </binding>
   </wsHttpBinding>

Occhio alla parte in rosso ci servirà più avanti..

Il servizio sarà configurato cosi :

   <service behaviorConfiguration="CertBehavior" name="WcfService1.Service1">
    <endpoint address="" behaviorConfiguration="CustomBehav" binding="wsHttpBinding"      bindingConfiguration="SecuredByCertificate" contract="WcfService1.IService1">
     <identity>
      <dns value="DEVCER" />
     </identity>
    </endpoint>
   </service>

Questo è un estratto della policy di sicurezza nel wsdl ottenuto dal  binding con i nostri switch impostati a false , ingrandendo l'immagine si nota  che si utilizza un X509Token

Adesso invece reimpostiamo a true i nostri famosi flag di configurazione  : "negotiateServiceCredential="true" establishSecurityContext="true"

Quello che otteniamo è un policy di sicurezza abbastanza diversa basata su  SCT (security context token) ovvero stiamo applicando la policy di WS-SecureConversation

Sottolineo che  se non avessimo spulciato il wsdl  ( o l'header soap che evito di allegare perché un tantinello ingombrante ) e avessimo utilizzato un consumer .Net che abbiamo tranquillamente agganciato al servizio utilizzando l'add service reference di VS 2008, non ci saremmo minimamente accorti che il meccanismo di autenticazione  utilizzato è sostanzialmente diverso(salvo sentire le imprecazioni del collega java che si aspettava un'altra policy di sicurezza )  : nel caso dell'X509 token fondamentalmente viene utilizzato un meccanismo di cifratura a chiave asimmetrica, mentre nel caso dell'sct si utilizza un meccanismo di cifratura a chiave simmetrica (più efficiente computazionalmente) ma che comporta una serie di chiamate in più per lo scambio in sicurezza della chiave simmetrica.

Grazie ai sopravvissuti arrivati fin qui nella lettura   

                   Ale

Questi articoli sulla usabilità sono interessanti e scritti con un pò di sano umorismo che non guasta mai..   ;)

The Myth of the Genius Designer

Top-10 Application-Design Mistakes

Buona lettura :D

Dopo aver installato i reporting services di sqlserver 2005 per cominciare a fare le mie "sporcherie  autodidattiche"  vado tutto contento a testare l'app web e BOOOM!!!

Eccezione e disperazione : "System.Web.Hosting.HostingEnvironmentException: Failed to access IIS metabase. The process account used to run ASP.NET must have read access to the IIS metabase ".

Dopo un attimo di disperazione  (l'ultima volta che ho avuto problemi con al metabase di IIS 5 non sono più neache riuscito a far partire la console di amministrazione di IIS e collegarla al localhost.. ) ho seguito la via che indicava l'eccezione, portandomi al provvidenziale articolo sulla KB di microsoft.

Utilizzando asp.net 2 è possibile recuperare i diritti di accesso alla metabase per l'utente aspnet lanciando il comando :

aspnet_regiis -ga aspnet

E miracolosomente la mia applicazione è tornata a vivere..  (meno male)

Per IIS 6 sostituite aspnet con l'utente con cui gira l'app pool dell'applicazione (anche se su IIS 6 non ho mai avuto questo tipo di problemi fino ad ora.. )

Attenzione che il metabase è un oggettino con cui scherzare poco, l'avviso sull'articolo citato è poco incoraggiante ma esplicativo :"Edit the metabase at your own risk." ;)

Lunghe ore di lotta con la creazioni di certificati e la configurazione del server per fare parlare un token issuer e dei servizi WCF. Un piccolo riassunto per i malcapitati che si trovassero in situazioni simili

1. Creazione dei certificati

Un certificato è ottenibile o facendo richiesta a una certification authority (CA)o creandolo con  il tool make cert. Il certificato fai da te è vivamente sconsigliato per applicazioni da portare in produzione ma va bene per i propri esperimenti di sviluppo. Per creare dei certificati per lo scambio di informazione solitamente si utilizza il formato pkcs#12 che si "manifesta" in un file con estensione .pfx.

Sia con il makecert che con la cert. auth. di windows 2003 non si riesce ad ottenere un file di certificato in quel formato (se qualcuno sa indicarmi la via gli sarò grato per avermi fatto rispamiare un passaggio :) ) Quello che si ottiene è un file di certificato .cer e una chiave privata memorizzata su un file (di solito con estensione .pvk)

Per ottenere un certificato da una CA basta fare una richiesta di certificato nell'apposito form web che i server CA mettono a disposizione e aspettare che qualcuno approvi la richiesta e vi fornisca il file di certificato approvato.

Per generare un certificato in proprio utilizzando il make cert possiamo fare come segue e volendo fare le cose per bene ci generiamo anche una CA casereccia che garantisca il certificato :

makecert -pe -n "CN=TempCA" -r -a sha1 -sky signature -sv TempCA.pvk TempCA.cer

Il risultato dell'operazione saranno i due file .cer e .pvk

Ok, a questo punto generiamo il nostro certificato per il servizio WCF firmato dalla prestigiosissima TempCA appena creata :)

Makecert -pe -ic TempCA.cer -iv TempCA.pvk -iky signature -sky exchange     -eku 1.3.6.1.5.5.7.3.1 -sp "Microsoft RSA SChannel Cryptographic Provider" -n "CN=SVCWCFCER" -sy 12 -sv svc_cert.pvk svc_cert.cer

i parametri -ic e -iv si riferiscono ai file della CA che abbiamo ottenuto nel primo passo, particolarmente importante è il parametro -sky exchange che sottolinea l'uso della chiave per effettuare encryption.

Adesso per potere sfruttare il nostro certificato ci serve il famoso file .pfx, rilanciamoci a riga di comando per ottenerlo

pvk2pfx -pvk svc_cert.pvk -spc svc_cert.cer -pfx svc_cert.pfx

Abbiamo cosi ottenuto il nostro svc_cert.pfx pronto per l'uso. Il tool pvk2pfx lo potete trovare anche nell'sdk di vista..

2. Importazione nello store della localMachine

Adesso non resta che configurare la macchina che andrà ad utilizzare il certificato, per fare questo:

1. aprite la mmc di windows e aggiungete lo sna p in certificati relativi al local computer (ovvero lo store di sistema "localMachine" )
2. per prima cosa importate il certificato della CA(il nostro file  tempCA.cer) nello store delle Trusted Certification Authorities 
3. Nella cartella local computer\Personal (che corrisponde allo store localMachine\my) importate il certificato svc_cert.pfx

Se l'operazione al secondo punto fallisce dandovi l'errore :  "An internal error occurred. This can be either the user profile is not accessible or the private key that you are importing might require a cryptographic service provider that is not installed on your system"

In questo caso probabilmente avete qualcosa che non va nella configurazione dell'accesso alla cartella "....\Documents and settings\All Users\Application Data\Microsoft\Crypto\RSA" in questo caso date un'occhiata a questo articolo che vi spiega come rimediare.

Un consiglio non installate il certificato dal wizard che viene fuori dal doppio click sul file .pfx perchè solitamente vi installa il certificato nello store dell'utente corrente e anche se poi lo spostate tramite console nello store della localmachine la chiave privata fa giri strani e poi ci si incasina con le autorizzazioni di accesso sulla chiave..

A questo punto per concludere il tutto (in base all'utilizzo di cui avete bisogno )basta specificare il certificato nel webconfig (o appconfig) e fornire all'utente con cui gira l'host del servizio che utilizzerà il certificato le autorizzazioni di accesso alla chiave privata del nostro "CN=SVCWCFCER" , la maniera più semplice  e consigliata per farlo è utilizzare il tool di WSE 3, altrimenti andate nella famosa cartella "\Documents and settings\All Users\Application Data\Microsoft\Crypto\RSA" e cercate di capire qual'è la chiave che vi interessa (probabilmente la più recente della cartella ;) ) 

PS

Per chi non volesse crearsi una CA per il certificato può in alternativa creare un certificato self signed e importarlo sia nella localmachine\my che nella trusted root CAs. Il comando per generare il certificato in questione è questo :

 Makecert -pe -r -sky exchange     -eku 1.3.6.1.5.5.7.3.1 -sp "Microsoft RSA SChannel Cryptographic Provider" -n "CN=SVCWCFCER" -sy 12 -sv svc_cert.pvk svc_cert.cer

Questo articolo su SOA antipatterns scritto da IBM è divertente , per spiegare i sintomi del verificarsi degli abusi comuni del termine  SOA o della nube di fraintendimento che ruota intorno ad esso, si lancia in analisi di tipo psicologico che neanche la definizione delle cause delle sindrome da stress post traumatico :-)

Chi si è trovato in una conversazione su SOA sicuramente si sarà trovato davanti a casi conclamati di "Technology Bandwagon" o "bigbang" (se volete scoprire cosa sono leggete l'articolo  ) alzi la mano chi non ha mai sentito almeno una volta casi come quelli descritti...

La versione Microsoft  non usa la psicologia per descrivere le cause dell'adozione di antipattern ma porta altri elementi di riflessione chi volesse può trovarla qui :