Last week from PDC 2009 comes the identity developer training kit...
http://www.microsoft.com/downloads/details.aspx?familyid=C3E315FA-94E2-4028-99CB-904369F177C0&displaylang=en
You could find interesting this resources as well :
WIF SDK and this whitpaper about WIF for developer
Finally look at this post of geneva team blog giving some suggestion about WCF - WIF interaction scenarios : http://blogs.msdn.com/card/archive/2009/11/19/using-wif-on-a-wcf-client.aspx
Geneva, I'm coming 
The release of Windows Identity foundation come to light ,it's a framework to help developing claim based authentication without developer headache 
Look at this post of the geneva team blog... it sounds really good
Time to experiment....one more time..
I don't know how but after years during wich Microsoft told us that UML was good just to exchange ideas between programmer scratching UML diagrams on the bathroom’s door., in VS 2010 they will include some useful uml modeling tools and a new project template for modeling. This tools have a lot of integrated advantages in the code managing. Nice Job Microsoft , keep it on…
Just a sample screenshoot :
That’s incredible, but true :D
the .net 3,5 SP1 introduce a strange behavior using transaction on a OracleDB connection.
From microsoft support (http://support.microsoft.com/kb/958484/en-us) :
“AutoCommit behavior in Oracle transactions is different in the .NET Framework 2.0 SP1 from the behavior in the .NET Framework 2.0 SP2. In the .NET Framework 2.0 SP2, if an application starts a transaction, completes the transaction, and then starts a new transaction on the same connection, all the commands that are executed in the second transaction execute in auto-commit mode. The changes that are made by those commands are committed to the database even if the transaction is rolled back”
uhmmm, it doesn’t sound good.. isnt’it ?
On the support page you will find a LONG list of issues solved by the patches..
The patches are a available here :
http://support.microsoft.com/kb/959209/en-us
Hope this helps
Did you find your BiztalkMsgBoxDB (or any other sql server 2005 DB ) in suspect mode ?
What to do to repair it? Ok, please don’t cry and execute this script in your sqlserver management studio:
Declare @DB sysname;
set @DB = 'BizTalkMsgBoxDb';
-- Put the database in emergency mode
EXEC('ALTER DATABASE [' + @DB + '] SET EMERGENCY');
-- Set single user mode
exec sp_dboption @DB, 'single user', 'TRUE';
-- Repair database
DBCC checkdb (@DB, repair_allow_data_loss);
--Or REPAIR_FAST or REPAIR_REBUILD to avoid data loss
-- Turn off single user mode
exec sp_dboption @DB, 'single user', 'FALSE';
--
EXEC('ALTER DATABASE [' + @DB + '] SET ONLINE');
That’s it .. :D
Nel titolo c'è il problema che mi affligeva , nel link sottostante la soluzione più semplice che ho trovato:
Web Services Security - HTTP Basic Authentication without Active Directory
Nel codice di esempio utilizza un file xml come store, ma customizzando il codice potrete utilizzare anche al sim del telefonino volendo... 
In realtà non è esattamente una "best practice", l'appilcazione corretta dovrebbe richiedere l'utilizzo di SSL per proteggere il canale altrimenti le credenziali sono obbiettivamente carta straccia.
Comunque supponendo di volerlo utilizzare in un ambiente di test realizzate un binding con security "transportcredentialonly" e la voce "basic" in trsaport...
Per essere più chiari
<basicHttpBinding>
<binding name="basic">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Basic"/>
</security>
</binding>
</basicHttpBinding>
Su delle richieste arrivate sui certificate andando in girpo per google ho trovato questo articolo di MS molto ben fatto : "Support Certificates In Your Applications With The .NET Framework 2.0"
Spiega come utilizzare i certificati nei vari scenari (firma, cifratura, SSL, autenticazione WS ecc... )
Si trova qui : http://msdn.microsoft.com/en-us/magazine/dvdarchive/cc163454.aspx
Questo articolo di Roman Kiss sembra molto interessante:
VirtualService for ESB
Del resto il buon Roman tira fuori degli articoli sconvolgenti sin dai tempi di remoting 
L'uscita non è recentissima (agosto 2008) ma posto comunque l'indirizzo come promemoria , su codeplex è diponibile la guida sulla sicurezza in WCF
La trovate qui ::
http://www.codeplex.com/WCFSecurityGuide/Release/ProjectReleases.aspx?ReleaseId=15892
Per i nostalgici ( o quelli che loro malgrado sono vincolati ai vecchi asmx ) questa è la versione precedente basata su WSE3 :
http://download.microsoft.com/download/8/d/6/8d608524-0763-48b5-840b-0ae446996a14/MS_WSS_Dec_05.pdf
Installato il mio Reporting Services (SSRS) 2008 nuovo di pacca vado a esplorare le meravigliose nuove potenzialità, fra cui quella che mi entusiasmava di più : agganciare il datasource del report direttamente a un webservice.
In un mondo in cui anche andare dal macellaio comporta l'integrazione con un Web Service la prospettiva è ghiotta ma la sorpresa se non è amara è agrodolce..
SSRS 2008 si collega si a un web service ma in realtà supporta solo meccanismi di windows authentication o di anonymous user (detto in soldoni le modalità di autenticazione base dei vecchi asmx) , sarebbe stato bello riuscire a utilizzare anche il mio servizio WCF che utilizza i meccanismi di autenticazione di WS-Security senza dovere spaccarmi la testa per aggirare il problema...
Esplorerò le possibilità di customizzazione per vedere se è possibile affronatare il problema in maniera generale senza dovere fare estensioni custom per ogni web service o wrapper strani di vario tipo..
To be continued...
Visto che ormai se ne sente parlare sempre più spesso in giro , riprendo il contenuto di un mio post precedente su un altro blog. Una piccola guida per tirarsi fuori dai guai
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
- 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:
- aprite la mmc di windows e aggiungete lo sna p in certificati relativi al local computer (ovvero lo store di sistema "localMachine" )
- per prima cosa importate il certificato della CA(il nostro file tempCA.cer) nello store delle Trusted Certification Authorities
- 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
Ciao a tutti rieccoci,
tengo a specificare che non sono matto (o almeno ono completamente ) per quelli che si troveranno a spulciare questo blog e vedranno un pò di roba in inglese e un pò di roba in italiano, essendo uno storico seguace di biztalkia ho seguito anche i suoi cambiamenti...
Adesso dopo essere sparito per un pò cercherò di riprendere la mia vita nella community, e seguendo la nuova veste Biztalkia ricomincerò a scrivere in italiano ...
see you soon [;-)]
Ale
Creating webservices with WCF is very easy. Tell to VS 2008 "create a wcf service for me" and it's done: you are the proud owner of a Service over WSHttpBinding.
Wcf hides all the low level stuff to the developers making all the "dirty" job in a really transparent way.
This is great but what about your java colleague that come asking for a web service in Soap 1.1 ? In a "soa world" this happens..
So you grab the dig and start googling... Maybe you will get here to read that your WSHttpBinding web services is Soap 1.2 compliant
Nice to know it, but how you can say it looking at the message? It's not so intuitive but you can solve the "dilemma" looking the soap envelope
If you read this: <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> you are using a Soap 1.1 envelope to describe your message.
Else : <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> then you are on soap1.2 envelope
In a wsdl you can have endpoint using different bindings (WSHttpBinding and CustomBinding as well) looking at the wsdl definition, you will find together
<wsdl:definitions name="Service1" targetNamespace="http://tempuri.org/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
…..
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
..>
In the binding description you can see the reference to the first one or the second one schema. A message exchanged on that bindig will have the soap envelope definition you see before…
PS
About the Java colleague, in one of the next post I'll try to satisfy his request ;)
Hi to everyone,
I'm here ready to start again in the new Biztalkia's adventure on his brand new charming site ..
Ok, let's go, I hope to be an active part of this new community experience and in english
So sorry for my mistake , probably it will be often a little "out of order"... ;)
see you
A.
More Posts
Next page »