Come da Roadmap annunciata durante PDC 2008, Geneva (AKA Identity Platform) è andata in beta 2.
Per chi non lo sapesse ancora alcuni dati essenziali di Geneva:
- A PDC 2008 è stato detto che Geneva rimpiazzerà totalmente il modello a Claim attuale di WCF che diventa obsoleto e con notevoli breaking changes: i Claim di WCF attuali sono differenti da quelli di Geneva sia per proprietà che concettualmente.
Dopo un primo sobbalzo quando li vidi in Zermatt (la ‘alpha’ release di Geneva) devo dire che il modello di Geneva vale tutte le breaking changes - Geneva Framework rende semplice sviluppare scenari con Claim ed STS (Secure Token Service) pur conservando tutto ciò che si è fatto con i ruoli. Questo vale sia per applicazioni asp.net che per servizi WCF.
- Geneva Framework rende facile sviluppare custom STS. Sebbene questo sia un task molto delicato, sono dozzine i casi reali in cui questo è fortemente richiesto e motivato.
- Geneva Server è un STS che usa Active Directory come provider di identità per generare token in formato SAML.
- Geneva Cardspace è la versione 2 di Cardspace e introduce molte novità rispetto al suo predecessore.
- A PDC 2008 è stato detto che le future versioni di SQL Server saranno in grado di “parlare” con le applicazioni Geneva-Enabled, quindi digerire i token SAML. Questo avrà un impatto enorme sull’architettura delle applicazioni in quanto il token SAML in scenari di delegation si porta dietro almeno due identity. Di questo parlerò in un altro post.
Ma torniamo alla beta 2 …
Nessuna major changes. I miei samples non ricompilano ma a prima vista le modifiche sono minori. Il modello ad oggetti dei claim è definitivo e tutti i concetti e le classi che costituiscono lo scheletro di Identity Platform sono definitive in questo stadio. A meno di grosse sorprese la RTM dovrebbe solo vedere consolidarsi il tutto, RTM che è stata annunciata a PDC per fine anno 2009.
Come attesi ci sono:
- nuovi wizard per vs.net per una migliore integrazione
- nuove classi per la configurazione che rende possibile integrare Geneva senza modifiche al ServiceHost e permettendo il riutilizzo del self-hosting di vs.net (cosa che non era possibile nella beta 1)
Novità interessanti:
- FedUtil era prima disponibile solo per scenari asp.net adesso è usabile anche in scenari WCF tradizionali
- ClaimsAuthorizationManager dal nome super promettente. Un manager della fase di autenticazione per i Claim.
- Una lunga serie di eventi per il FederatedAuthenticationModule di asp.net che rende più semplice intervenire durante il processo di logon
- Un nuovo behavior che abilita Geneva senza dover scrivere codice nel service host
Le novità, oltre a leggerle nella documentazione che compara beta 1 e beta 2, sono ben spiegate dal blog del team.
Ho già modificato il mio esempio più semplice: una piccola console che crea delle managed card per Cardspace. È semplicissimo ed estremamente pratico in uno scenario WCF + STS in cui Geneva Framework rende tutto più semplice.
SvcUtil permette di creare automaticamente la configurazione client di un servizio WCF.
Tra le cose che vengono create c'è l'encoding in Base64 della chiave pubblica del certificato usato dal server
1: <identity>
2: <certificate encodedValue="AwAAAA ...." />
3: </identity>
Naturalmente SvcUtil ricava questa informazione dai metadati.
Sfortunatamente ci sono casi in cui la configurazione del servizio è complessa e non si riesce in modo semplice ad abilitare l'endpoint dei metadati. Guardacaso mi è capitato e il certificato delle due macchine di sviluppo erano diverse.
Apparentemente la soluzione è semplice:
1: private static string GetEncoded(X509Certificate2 cert)
2: {
3: byte[] export = cert.Export(X509ContentType.SerializedCert);
4: string encoded = Convert.ToBase64String(export);
5: return encoded;
6: }
Questo valore è corretto per molti certificati ma ha un side-effect pericolosissimo. Il metodo Export esporta il certificato nella sua interezza, cioè compresa la chiave privata, se presente. Quando viene fatto il deploy di un certificato nello store si può scegliere se installarlo con o senza chiave privata.
Questo significa che la funzione GetEncoded ricava la stessa stringa di SvcUtil per i certificati con sola chiave pubblica, ma dal momento in cui ci imbattiamo in un certificato con chiave privata esportiamo anche quella. Dare una chiave privata in giro equivale a dare una copia delle chiavi di casa a tutti quelli che incontriamo. Non è proprio quello che si dice una cosa saggia.
Così ho cercato di eliminare la chiave privata dal certificato prima di esportarla. Dopo un po' di tentativi andati a vuoto mi sono rivolto al buon amico Mario Fontana (anche se lo tiene nascosto bene, un po' di codice delle CAPICOM viene dalla sua tastiera) che mi ha fatto notare che il formato DER dei certificati si può ottenere semplicemente esportando con l'opzione "X509ContentType.Cert".
1: byte[] der = certRaf.Export(X509ContentType.Cert); // solo public key
A noi però interessa la SerializedCert e quindi non ci resta che re-importare il certificato appena esportato con "Cert"
1: private static X509Certificate2 ImportFromBlob(byte[] certBlob)
2: {
3: X509Certificate2Collection certs = new X509Certificate2Collection();
4: certs.Import(certBlob);
5: X509Certificate2 imported = certs[0];
6: return imported;
7: }
Ed infine richiamare la GetEncoded per ottenere la magica stringa che viene usata nella configurazione client di WCF.