Security & Architecture : Sicurezza

Bug Hunter … ovvero una passione

mfontana — Tue, 10 Nov 2009 12:27:57 GMT

Conosco Matteo Carli (sulla destra) diciamo … da moltissimi anni ormai :-) e mi ha fatto veramente piacere vederlo parlare a RAI 3 riguardo all’ottimo lavoro di analisi e ricerca sulle vulnerabilità in campo sicurezza applicativa che ha svolto insieme a Rosario Valotta.

Per maggiori informazioni tecniche su quanto scoperto da Matteo e Rosario leggete il post di Matteo le-webmail-sono-morte-viva-le-webmail.

BRAVO MATTEO ! anche perchè a breve ci sarà un altro video… no?? ;-)

--Mario

Il nuovo Microsoft Baseline Security Analyzer 2.1.1 per Windows 7 e Windows Server 2008 R2

mfontana — Tue, 27 Oct 2009 04:00:00 GMT

E’ disponibile la nuova versione del Microsoft Baseline Security Analyzer (MBSA), un’utility per verificare la compliancy ai Microsoft Security Standars della propria infrastruttura.

Tra le novità spicca il supporto a Windows 7 e Windows Server 2008 R2.

http://www.microsoft.com/downloads/details.aspx?FamilyID=b1e76bbe-71df-41e8-8b52-c871d012ba78&displaylang=en

--Mario

Questionario Osservatorio Attacchi Informatici in Italia

mfontana — Tue, 20 Oct 2009 04:10:00 GMT

Segnalo l’ importante iniziativa della FidaInform, la Federazione dei ClubTI Italiani distribuiti sul territorio nazionale, nel voler ricostituire l’ Osservatorio sugli attacchi informatici in Italia (OAI) tramite un breve questionario aninimo indirizzato ai responsabili IT di aziende di qualsiasi dimensione. L’iniziativa è a livello nazionale con cadenza annuale e vuole rappresentare una fotografia aggiornata della situazione in Italia.

Vi invito a dire la vostra al seguente link

--Mario

The Microsoft SDL : Developer Starter Kit

mfontana — Sat, 17 Oct 2009 04:15:00 GMT

This is a great news !! It’s available for download the new The Microsoft SDL Developer Starter Kit with slides, documents and labs to help you establish a standardized approach to rolling out the Microsoft Security Development Lifecycle (SDL) in your organization—or enrich your existing development practices.

You can decide to download the kit and run it into your environment or you can try it through our Security Virtual Labs.

This material is also correlated to the SDL Optimization model to introduce a gradual and cost-effective implementation of the SDL into the organization.

--Mario

Microsoft SDL : Return On Investment

mfontana — Fri, 16 Oct 2009 10:10:11 GMT

Microsoft and ISec Partners just published a joint whitepaper about Microsoft SDL and the return of Investment to help IT architects and business architects to :

· Understand and communicate the benefits of a structured approach to software security.

· Develop and use metrics for ROI to guide process improvement.

· Get meaningful results from a new program or optimize existing efforts on a limited budget.

You can read more information here.

--Mario

Windows 7 SDK : tutti gli esempi di security

mfontana — Wed, 22 Jul 2009 15:19:00 GMT

[New/updated Security services samples in the Windows SDK for Windows 7]

Può tornare utile questa lista di tutti gli esempi (nuovi e aggiornati) in ambito sicurezza presenti nel nuovo SDK per Windows 7.

Guardo con un filo di commozione gli esempi Retrieve and embed an OCSP response e Sample Certificate Store Provider che in giovinezza (5 o 6 annni fa) dovetti scrivere da zero con le CryptoAPI per un progetto :-)

--Mario

Ancora sull’Application Security : SSL è superato dalle specifiche WS-* ??

mfontana — Mon, 22 Jun 2009 08:01:00 GMT

Non credevo di suscitare tanto interesse con questo mio precedente post :-) ma ne sono contento perchè questo conferma una buona sensibilità verso l’application security.

Ho ricevuto molte email riguardo l’uso di SSL alcune delle quali mi chiedevano se tale protocollo è da considerarsi ancora sicuro. Vedo di sintetizzare un po’ di miei pensieri… sperando di continuare il dibattito :-)

**SSL è superato dal WS-*?**

Assolutamente NO... e ci mancherebbe altro! Sono due mattoni importanti per la messa in sicurezza di un sistema. Sono complementari anche se hanno molte "funzionalità" in comune. Infatti, in alcuni contesti devono essere utilizzati obbligatoriamente entrambi, come ad esempio durante lo scambio di un UsernameToken definito dalla specifica WS-Security:

<xsd:element name="UsernameToken">
   <xsd:complexType>
     <xsd:sequence>
       <xsd:element ref="Username"/>
       <xsd:element ref="Password" minOccurs="0"/>
     </xsd:sequence>
     <xsd:attribute name="Id" type="xsd:ID"/>
     <xsd:anyAttribute namespace="##other"/>
   </xsd:complexType>
</xsd:element>

Infatti, in questo caso durante lo scambio del token il network si deve fare carico dell’encryption del canale! Volendo schematizzare le affinità e le differenze tra l’uso di SSL e lo stack WS-*:

Affinità:

- Entrambi garantiscono Autenticazione, Integrità e riservatezza sebbene lo stack WS-* tramite XMLENC e XMLDSIG sia molto più espressivo.

- E’ sempre il sistemista che interviene sulle configurazioni del server per SSL come può intervenire sulle policy del servizio per modificare le caratteristiche dei messaggi SOAP (+ o -).

Differenze:

molte! Prima di tutto WS-* prevede il supporto a SOAP mentre SSL no, WS-* NON è applicabile in tutti i contesti di Web-Applications invece SSL si.

SSL è implementato al livello 5 della famosa pila mentre i WS-* sono in quello definito “nuovo layer 8”. Questo comporta alcune considerazioni di sicurezza importanti..prima tra tutte che il livello 4 (TCP) e 5 da un punto di vista di sicurezza si occupano solamente del mittente. Non è una cosa da poco. Si pensi agli scenari SOA e SaaS. SSL è semplicemente un canale cifrato tra due end-point e non è possibile estendere il conteso di cifratura ad altri server (intermediari) creando possibili “vulnerabilità” nel flusso dei dati. Il contesto di sicurezza dell’applicazione NON è la sommatoria dei singoli contesti. WS-Security & family, al contrario spostando le informazioni di sicurezza direttamente all’interno dell’header del messaggio SOAP, consente di avere un numero arbitrario di intermediari e di protocolli di rete anche non sicuri garantendo però il contesto di sicurezza dell’applicazione.

SSL è un protocollo“state-full” ovvero deve mantenere uno “stato” tra il client e il server; il client instaura una connessione con un determinato server e il suo flusso non può essere deviato ad altri server (l’handshake tra il client e il server ha lo scopo di scambiarsi delle chiavi simmetriche – tramite delle chiavi asimmetriche - che entrambi utilizzano per cifrare il canale) perchè non sono in possesso delle corrette chiavi simmetriche per decifrare i dati. In questo scenario è indispensabile ricorrere ad un intervento sistemistico impostando i valori di “affinity” che associano un client sempre allo stesso server riducendo notevolmente la scalabilità applicativa. Al contrario WS-Security, basando interamente la propria struttura a livello del messaggio può usufruire di scelte infrastrutturali più scalabili.

Se ci spostiamo su WS-SecureConversation, lo scenario cambia nuovamente, ritorniamo alla necessità di avere una chiave simmetrica condivisa, o meglio, un contesto di sicurezza condiviso (SCT- Security Context Token).Per risolvere la ridondanza dei servizi si hanno 3 opzioni:

1) Sistemistico tramite affinity proprio come SSL.

2) Misto:tramite un database di SCT condiviso da tutti i server bilanciati.

3) Applicativo, estendendo lo schema del SCT. (possibili problemi di compatibilità con terze parti o comunque con software non aware del nuovo schema)

Considerazioni su SSL

SSL è un ottimo protocollo crittografico ma per quanto riguarda la sicurezza (non la crittografia) siamo ben lontani !! Innanzitutto il meccanismo di protezione non è efficace per quegli utenti “distratti” che non vanno a verificare TUTTE LE VOLTE l’URL nel browser con l’indirizzo specificato nel certificato. Inoltre, il famoso warning di incongruenza di dati del certificato viene sempre ignorato (= OK) permettendo, se va male, l’attacchi basato su ip-spoofing,ecc... E’ anche vera una riflessioncina : a prescindere da tutto, se un amministratore di un sito gestisce così il protocollo SSL c’è da chiedersi come gestisca l’intero sistema ...Mah..

A questo proposito a partire da Windows Vista è stato introdotto il supporto agli Extended Validation SSL Certificates http://www.microsoft.com/windows/ev. Sicuramente utile ma prima di tutto devono essere adottatti largamente dai gestori dei siti!!!!

SSL fonda la sua sicurezza pesantemente sulla robustezza dei cifrari asimmetrici e simmetrici utilizzati (come anche WS-*), cambia spesso la chiave di sessione (5min di default) e mitiga il reply tramite il Connect_id.

A questo punto volendo schematizzare i pro e i contro nell’ uso di SSL :

*SSL PRO*	*SSL CONTRO*
Standard	Dispendioso per la CPU
Autenticazione, integrità e riservatezza	Session oriented
Nessun vincolo di linguaggi di programmazione	Implementazione solo su HTTP (non per motivi tecnici o di specifica).
Nessun vincolo di pattern di sicurezza applicativa	Valido solo su singolo hop
“Gratis” per chi disegna ed implementa le applicazioni.	Non assicura i dati una volta arrivati al server.
	NON ESONERA GLI SVILUPPATORI DALLO SCRIVERE CODICE SICURO J

Attacchi e Contromisure

Di SSL ormai si sa (quasi) tutto. Gli attacchi principali al protocollo SSL sono noti mentre per lo stack WS-* se ne conoscono ancora relativamente pochi.

Per quanto riguarda SSL l’ultimo in ordine di tempo è l’ attacco basato sul BVO(Bad-version Oracle). (nulla a che vedere con il famoso produttore di Database :-) )

SSL/TLS utilizza l’encoding PKCS#1 (v1.5) per l’encryption del pre-master-secret (valore utilizzato per la derivazione delle session keys).Un hacker che riesce a recuperare il premaster-secret può decifrare l’intera sessione SSL.L’attacco principale è una derivazione dell’attacco di Bleichenbacher per il PKCS#1.Parte dal presupposto che il meccanismo di versioning del PKCS#1 permette di creare un side-channel che permetta di invertire l’encryption recuperando il premaster-secret e/o firmarndosi come server!Questo attacco riesce entro le 54 ore con chiavi asimmetriche a 1024.

Inoltre, se si dispone di proxy server sarebbe consigliato configurare l’analisi dei primi passi del traffico dell’handshake di SSL per evitare che venga fatto del tunneling di un protocollo non autorizzato su una porta aperta (443 di default).

Per quanto riguarda le contromisure agli attacchi a SOAP/WS-* siamo messi (forse) peggio! Già durante la WPC 2007 ho presentato un sunto di vari attacchi a partire da SOAP fino alle specifiche più complesse come WS-Security e spero a breve di riuscire a sintetizzarli in uno o più post !! In questo articolo prendiamo in esame uno degli aspetti più importanti di WS-Security : la dipendenza da XMLENC e XMLDISG (per sapere come sono fatti leggete qui e qui). Infatti da alcuni anni orami sono noti vari attacchi di tipo DoS a queste strutture. L’attacco verte sulla funzione di verifica/decrypt dei dati. Ad esempio in XMLDSIG l’elemento Reference raccoglie l’informazione da firmare. Lo schema di Reference :

mostra chiaramente che il contenuto da firmare non è il documento stesso, ma bensi l’hash del documento (DigestMethod e DigestValue) più le informazioni di rappresentazione.

Poichè il processo di verifica della firma prevede il ricalcolo dell’hash dell’oggetto firmato, cosa succede se l’URI del Reference indica ad esempio il SP1 di Windows 2003 ?? Il Thread di IIS che sta processando il codice applicativo si scarica 315 Mb per poter calcolare l’hash... moltiplichiamo la richiesta n volte e, etvoilà...HABEMUS DoS Attack...

Contromisure? Beh, applicative e di content analisys da parte dei firewall. In alcuni contesti è possibile implementare alcuni pattern di sicurezza come il Message Validator oppure dedicare uno o più Perimeter Service Router applicativi.

In sintesi le contromisure per gli attacchi a SSL sono di competenza dei sistemisti :-) mentre quelli a livello applicativo spesso sono distribuiti tra sistemisti e architetti/sviluppatori.

E’ però importante sottolineare che per quanto riguarda la messa in sicurezza di una applicazione l’uso di SSL o WS-* non significa NULLA o quasi. Gli attacchi applicativi tipo Buffer Overrun, SQL-Injection, XSS, Code-inj.,Canonicalization attacks, Ecc... avvengono ne più ne meno...perchè il 95% di codesti attacchi è riconducibile ad un unico antipattern tipico di chi sviluppa : (mancanza) di INPUT VALIDATION !!!!

Qunidi, alla domanda più ricorrente che ci sia in questo ambito :”quando una applicazione può esserer considerata (più) sicura? non posso che rispondere in questo modo : quando è stata sviluppata seguendo il processo di SDL fin dal principio :-)

--Mario

PS : Se volete saperne di più sulla sicurezza applicativa, da cosa è composta e come dovrebbe essere affrontata leggete questo mio post dal titolo : Perchè la sicurezza applicativa è così ostica ?

L' Application Security è indietro 10 anni rispetto al Software Development ?

mfontana — Tue, 16 Jun 2009 08:01:00 GMT

“In evolutionary terms, the information security field is more than a decade behind software development” con queste parole inizia un interessante articolo di Gunnar Peterson dal titolo “Service-Oriented Security Indications for Use”. In sistesi Gunner sostiene che a partire dagli anni 90 abbiamo assistito a molteplici evoluzioni nel campo del software development mentre in ambito security siamo rimasti pressochè fermi, immobili.

Io mi trovo pressochè d’accordo con lui anche se man mano proseguivo nella lettura dell’articolo le ragioni del mio essere d’accordo divergevano sempre più da quelle presentate da Gunner. Mi spiego meglio.

In sintesi Gunner sostine cha se dal lato applicativo c’è stata una forte evoluzione partendo dagli anni 90 con lo sviluppo delle prime Web Applications con CGI, passando poi per l’era ASP/JSP, le 3-tiers Apps nel 1998 per arrivare agli anni 2000 dove si inizia a progettare con SOAP, XML e REST per arrivare agli albori del Web 2.0, dal lato security non siamo mai andati oltre i firewalls e SSL. Su questo sono d’accordo anche se a mio avviso è necessario fare un ulteriore distinguo tra le definizione di standard per la sicurezza e relativa adozione di quest’ultimi da parte dell’industria per capire meglio il fenomeno. Infatti non è vero che lato security non c’è stata innovazione!

Tra il 2001 e il 2002 sono comparsi i primi draft delle specifiche che volevano andare oltre la sicurezza del protocollo SSL e di infrastruttura (comunque lato sicurezza applicativa i firewall erano già bypassati con l’introduzione di SOAP/XML, fino alla comparsa delle prime versioni capaci di fare content control su formati XML based). Nacque il così detto stack WS-* ovvero l’insieme di tutte quelle specifiche dedicate prevalentemente al mondo dei Web Services (non solo in ambito Security) e che oggi si riconoscono perchè iniziano tutte con WS- !!

Quindi già dai primi anni del nuovo millennio abbiamo assistito alla comparsa di specifiche che volevano in qualche modo superare i limiti imposti da SSL e indirizzare il problema della sicurezza nel messaggio non solo tra due end-point ma fino al raggiungimento del destinatario finale. Questo scenario diventò sempre più importante in scenari SOA dove la sicurezza è o dovrebbe essere gestita più da un punto di vista delle operations che tecnologico e dove i servizi possono essere distribuiti in security context diversi e/o geograficamente. Una breve analisi del concetto di infrastruttura applicativa a servizi e relativi modelli di autenticazione li potete trovare in questi post : cosa intendiamo per infrastruttura applicativa, autenticazione a livello di canale, autenticazione a livello applicativo, autenticazione a livello di messaggio. Già a partire da Dicembre 2002 con WSE 1.0 (per chi lavorava in ambito .NET) erano a disposizione di architetti e developers i primi bit per disegnare e soprattutto implementare scenari basati su queste nuove specifiche (WS-Security, WS-Routing (ora chiamata WS-Addressing) e poco più.

Questo lato innovazione. Lato adozione lo scenario è effettivamente diverso; tali innovazioni non furono prese molto in considerazione per vari motivi (novità, poca esperienza, pigrizia (tanto c’era SSL) e a mio avviso perchè negli anni le vere potenzialità che possono fornire le architetture a servizi come SOA/EDA sono sempre state sottovalutate. Personalmente lavoro con le specifiche WS-* dalla primissima BETA di WSE (Luglio/Agosto 2002) e ho realizzato molte soluzioni in ambito Enterprise e posso riassumere la mia esperienza in questo modo:

le competenze sui patterns di sicurezza in ambito SOA sono conosciuti e adottati in bassissima percentuale nella fascia dei grandi clienti e quindi non mi meraviglio che in scenari meno enterprise non ci sia traccia di sicurezza se non con firewalls e SSL. Questo almeno fino ad un paio di anni fa.

Fortunatamente questo scenario sta cambiando… l’adozione di patterns per la federazione via WS-Federation e SAML 2.0 Protocol oltre i modelli basati sulla Claims-Based Security ne sono una conferma. Anche in questo caso però sto notando una adozione prima da parte delle aziende ed enti pubblici e poi man mano in scenari sempre meno Enterprise. Personalmente conto molto sulla “democratizzazione” di questi aspetti di security con il Cloud Computing perchè diventa (fortunatamente) sempre più difficile realizzare soluzioni silos e totalmente custom dove al contrario gli aspetti di interoperabilità, sicurezza e distribuzione geografica sono un must fin dalle prime fasi della progettazione!!

Altro ambito in cui negli ultimi anni sto iniziando a vedere un discreto aumento di sensibilità in tutti i settori del mercato IT è quello legato alle best practices sullo sviluppo di codice sicuro. Da qui l’adozione di modelli derivanti dal SDL – Security Development LifeCycle – (ad esempio qui trovate i tool per integrare i principi del SDL con i vari aspetti dell’ ingegneria del software via Visual Studio Team System) e degli sforzi di OWASP – Open Web Application Security Project - per rendere esplicite le best practices in questo ambito.

Quindi tornando all’articolo in oggetto non credo che il mondo della sicurezza sia stato alla finestra a guardare il resto dell’ IT che si evolveva restando inerte. Credo invece che l’intriseca fatica nel capire le evoluzioni in ambito sicurezza legate alla complessità dei nuovi scenari architetturali abbia di fatto rallentato se non fermato per anni l’adozione in ambito IT. Da qui il mio essere d’accordo con l’articolo ma per ragioni diverse.

Mi piacerebbe molto sapere cosa ne pensate :-)

--Mario

Le basi per un Common Identity Framework

mfontana — Tue, 09 Jun 2009 12:41:55 GMT

Per chi come me sta lavorando assiduamente sull’inserimento del modello claims-based nelle attuali architetture dei clienti non può perdere il post e relativo documento di Kim Cameron dal titolo :“Proposal fo a Common Identity Framework: A User-Centric Identity Metasystem” scritto da Kim Cameron, Reinhard Posch e Kai Rannenberg tutti nomi molto conosciuti nell’ambito dell’Identity Management (come potrete leggere dal post di Kim). (download : PDF o DOC)!!!

In questo documento vengono esplicitati i principi base su cui si può fondare un Identity Metasystem capace di integrare e razionalizzare la gestione delle identità indipendentemente dagli stack tecnologici utilizzati. Il tutto, ovviamente, in conformità delle principali leggi sulla sicurezza e sorpattutto sulla privacy. Vi assicuro che questo documento è di estrema utilità perchè evidenzia con chiarezza i principali “blocchi” architetturali e relative dipendenze.

Tra l’altro questo documento è stato inserito nel libro The Future of Identity in the Information Society un trattato che raccoglie ricerche effettuate in vari stati europei sull’identificazione dei cittadini, le ID cards, gli impatti delle leggi sulla privacy e tutti gli aspetti di computer forensics legate ai crimini informatici basati sul furto di identità.

Tre sono gli aspetti di questo whitepaper che mi hanno aiutato (più di tutto) a formalizzare meglio alcuni aspetti del lavoro che sto facendo in questo periodo sulla claims-based security: la suddivisione architetturale fatta tramite gli abstract services, la tassonomia dei claims e il concetto di Data Minimization. Con la definizione degli abstract services si riesce ad avere una visione olistica dell’architettura di un Identity Metasystem senza entrare nei tecnicismi che inevitabilmente vengono introdotti quando si lavora con un determinato vendor/prodotto. Nel documento questi servizi vengono presentati come astratti perchè rappresentano le funzioni di base dell’architettura e successivamente i vendor potranno realizzare i propri sistemi reali calando questa visione astratta nei propri modelli.

Stiamo quindi parlando di abstract services come il Primordial Claim Abstract Service, Registration Abstract Service, Claims Provider Abstract Service, Claims Selector Abstract Service, Claims Approver Abstract Service, Resource Matching Abstract Service.

La tassonomia dei claims invece diventa utilissima quando si lavora a livello architetturale alla definizione dei claims gestibili in azienda e relativa suddivisione per applicazione:

Type of Claim	Comment	Examples
Static	What we have traditionally called “properties” and “attributes” of the subject – static within some window of time	National identifiers and employee numbers Date of Birth Name Address
Relationship	Subject is in some relationship with another subject (and open-ended model with multiple sources and viewpoints)	Member of arbitrary group Member of assigned role Relationship to another subject (e.g. Personal Assistant or Parent) Mandate (e.g. trustee) Acting-as / On-behalf-of relationships
Derived	Claims that convey minimum necessary information by deriving it from facts but not releasing the facts	Over 21 or Under 16 University Student Person in Drug Trial Unmarried Female in 20’s
Capability	Authentication and authorization both based on claims transformation. Capabilities are determined by relying party within a defined scope	Can-read-calendar Can-access-write-operation Denied-update-in-given-scope
Contextual Claims	Factors useful in evaluating the security presentation.	Authentication technology, location, time

Infine gli aspetti di Data Minimization ci permettono di focalizzare quali sono gli ambiti in cui è necessario garantire il minor numero di informazioni personali degi utenti come le collezioni, aggregazioni, storage, retention,replication, distribution,linkage…

Un documento quindi che NON si piò NON leggere se si lavora nel campo dell’ Identity Management !!!

--Mario

Microsoft, Apache… un ossimoro??

mfontana — Sun, 07 Jun 2009 11:06:00 GMT

Innanzitutto prima di generare uno sciopone a qualcuno vi prego di notare la punteggiatura nel titolo di questo post !!! Microsoft VIRGOLA Apache e non Microsoft Apache :-) Nessuna paura quindi , non abbiamo acquistato Apache !!!! Però c’è da dire che questa notizia, come architetto, mi ha reso proprio contento. Alzi la mano (tanto vi vedo) chi di voi si è trovato almeno una volta nella situazione di far parlare del codice .NET con quello JAVA e/o PHP o viceversa? E tenga su la mano chi ha incontrato qualche “piccolissima” difficoltà nella configurazione e settaggi vari nei rispettivi ambienti !!!! Nessuno ?? ok allora questo post non fa per voi :-)

Diciamo che c’è stato un evento epocale… Microsoft partecipa alla keynote della conferenza JavaOne!! Infatti durante la conferenza JavaOne Steven Martin - Senior Director, Developer Platform Product Management – e Aisling MacRunnels - Sun Vice President- hanno annunciato durante la keynote che Sun parteciperà attivamente al progetto open-source Stonehenge inizialmente creato da Microsoft, WS02, University of Moratuwa, Progress Software, Red Hat e Eviware. In particolare Sun si occuperà della realizzazione Java/Metro della soluzione StockTrader.

Microsoft (anche se molti non lo sanno) ha partecipato e sta partecipando a molti progetti open source ma questa è la prima volta che Microsoft partecipa come code contributor in un progetto Apache!!

Lo scopo di questo progetto è nobile : realizzare in concreto degli scenari di interoperabilità e di best practices tra applicazioni e web services sviluppati su stack tecnologici diveri. Come dissi in questo mio post “non basta avere delle specifiche standardizzate per realizzare veramente degli scenari di interoperabilità” (sintetizzato) !!! I motivi sono molteplici : non tutti i vendor implementano le medesime specifiche anche se standardizzate, non sempre è chiaro come configurare i vari ambienti e prodotti, spesso ci sono delle piccole differenze in termini di serializzazione, encoding che se non gestite possono rendere difficile la realizzazione del progetto…

Per questo motivo il progetto Stonehenge realizza delle applicazioni di esempio basate su stack Java, .NET, PHP ma anche Python e Ruby in grado di interoperare utilizzando un set comune di specifiche standard definte dal W3C e OASIS. Stiamo parlando in prevalenza di comunicazioni basate sugli standard WS-*. I vari sorgenti li potete trovare nel repository di stocktrader :

--Mario

Come rendere Sharepoint 2007 Claims-Aware e integrarlo in Geneva Server BETA 2

mfontana — Wed, 27 May 2009 22:40:51 GMT

Grande enfasi sto riscontrando nelle richieste di chiarimenti sulla configurazione di Sharepoint 2007 in “versione” Claims-aware ovvero come poterlo integrare nelle nuove architetture basate su Geneva Server. In questo mio precedente post avevo dato il link al laboratorio che abbiamo messo on-line ma i requirements sono un forte deterrente :

Il laboratorio è composto da 4 macchine virtuali
Il download è poco più di 14Gb
L’ambiente gira su Hyper-V.
Sono necessari un minimo di 8 GB di RAM sulla macchina Host per far girare l’ambiente.

risultato … molte persone non possono provare il laboratorio ma (giustamente) vogliono capire come configurare Sharepoint per parlare la “nuova lingua franca dei claims” :-). A questo proposito nel post mi concentrerò su alcuni aspetti importanti di configurazione di Sharepoint che non sono descritti per intero nel documento di configurazione dello scenario (che è comunque disponibile insieme alle macchine virtuali ma con un download separato) e darò il link per scaricare i files mancanti per una configurazione “fai-da-te” :-) !!

Lo scenario di riferimento è il seguente :

Figura 1 : Struttura dello scenario implementato.

Quindi di fatto stiamo lavorando sulla configurazione della macchina CONTOSOSRV02.

Tornando a noi, i passi minimi per configurare Sharepoint in modalità claims-aware sono quelli descritti nei primi 4 step del documento, ovvero :

Configurare Sharepoint affinchè accetti i token rilasciati da Geneva Server.
Aggiungere il gruppo Domain Admins tra gli amministratori di Sharepoint.
Configurare Geneva Server a rilasciare i token per Sharepoint
Configurare i Ruoli in Sharepoint.

Sebbene i punti 2-3-4 sono ben chiari, il primo viene trattato semplicemente come l’esecuzione dello script ConfigureSharepoint.bat che altro non fa che lanciare lo script SetupSharePointIDFX.vbs con i seguenti parametri:

-appconfig <web.config del portale Sharepoint>.
-adminconfig <web.config del portale di amministrazione di Sharepoint>.
-applicationuri <URL esatto dell’applicazione sharepoint>.
-stsmetadataurl <Il metadata URL del STS (Security Token Service) di Geneva per ottenere i federation metadata . Il formato di questo URL è il seguente : https://server-name/FederationMetadata/spec-version/FederationMetadata.xml ed è definita direttamente al paragrafo 3.2.2 della specifica WS-Federation>.
-fedutilmode <modalità di esecuzione dell’ utility FedUtil.exe>.
-urlZone <la zone di Sharepoint da configurare>.

Nel caso specifico dello scenario avremo i seguenti parametri:

-appconfig C:\\inetpub\wwwroot\wss\VirtualDirectories\docs.contoso.com443\web.config.
-adminconfig C:\\inetpub\wwwroot\wss\VirtualDirectories\3526\web.config.
-stsmetadataurl https://sts1.contoso.com/federationmetadata/2007-06/federationmetadata.xml.
-fedutilmode "silent".
-urlZone "Extranet".

Ma cosa fa esattamente questo script?

Lo script inizia con l’invocazione dell’utility FEDUTIL.EXE (fornita con Geneva Framework) per configurare il Security Token Service (Geneva Server) come un trusted issuer per Sharepoint. Successivamente lo script modifica le configurazioni dei web.config passati come parametro con lo scopo principale di aggiungere i nuovi provider per Sharepoint forniti all’interno di Geneva Framework : nel caso specifico avremo il MembershiProvider (Microsoft.IdentityModel.SharePoint.SharePointClaimsMembershipProvider), il Role Provider (Microsoft.IdentityModel.SharePoint.SharePointClaimsRoleProvider) e infine un HttpModule per gestire correttamente la FBA (Forms Based Authentication) di Sharepoint (Microsoft.IdentityModel.SharePoint.OfficeDiscoveryFormsAuthenticationModule). Infine lo script invoca l’utility STSADM.EXE (fornita con sharepoint) per configurare l’ URL mapping e il metodo di autenticazione impostato a ‘none’ e ASP.NET imporsonate = false.

Una volta terminato lo script con esito positivo (lo si vede dall’output) crea un file contenente i federation metadata per Sharepoint che successivamente dovrà essere dato in pasto a Geneva Server per completare la profilazione del STS o in gergo Geneva l’ Identity Provider (IP)!! That’s all !! A questo punto potete seguire passo passo il documento e continuare la configurazione a mano.

Qui trovi il link del documento di configurazione dello scenario.

Qui puoi scaricare gli script di configurazione.

Buon lavoro…

--Mario

Integrare il processo di Security Development LifeCycle (SDL) con Visual Studio Team System

mfontana — Mon, 25 May 2009 14:33:00 GMT

Tra il dire e il fare c’è di mezzo… il mare?? Beh, quasi sempre si, ma a volte anche un template può bastare :-)

Quindi tra il dire – ovvero tutte le best practices e i processi descritti nel SDL- e il fare – VIsual Studio 2008 e Team System – c’è di mezzo il nuovo template che permette di integrare le policy i processi e i tools aggiornati al Security Development LifeCycle v4.1 con l’operatività del programmatore e dei software architects.

Di seguito le aree di estensione del template:

Installs SDL requirements as work items
Includes SDL-based check-in policies
Customizes security bugs and queries
Includes extensive SDL how-to and guidance documentation
Generates auditable Final Security Review report
Accommodates third-party tool integration, e.g. the SDL Threat Modeling Tool
Includes project plans and security risk assessment templates

Sempre qui trovate anche dei video in stile how-to per installare ed usare il template !!

--Mario

Gli scenari nell’ Identity Developer Training Kit

mfontana — Mon, 18 May 2009 15:32:17 GMT

Il buon Vittorio, tra un impegno e l’altro, ha fatto una utilissima lista esaustiva degli scenari presenti nei lab all’interno dell’ Identity Developer Training Kit.

Un utile riferimento per capire se il Kit comprende lo scenario interessato!

--Mario

Geneva Server : Single Sign On con i Microsoft Online Services

mfontana — Mon, 18 May 2009 08:00:00 GMT

In alcuni casi può essere utile creare una trust relationship tra la propria azienda e il Microsoft Federation Gateway (un Security Token Service/Identity Service in the cloud) per creare ai propri utenti interni una sorta di Signle Sign On verso servizi e risorse Microsoft in the cloud (es: Windows Live Spaces) oppure verso proprie applicazioni su Windows Azure.

In pratica gli utenti interni, una volta loggati al proprio dominio potranno accedere ad applicazioni di terze parti sviluppate su Windows Azure o ai servizi offerti da Microsoft (posta,Skydrive,ecc..) senza dover specificare il proprio Live ID (@hotmail o @live)

Ecco il Whitepaper che descrive step-by-step la procedura di configurazione !!

Maggiori info sempre dal Geneva Team!!!

--Mario

Geneva Server : Claims-Based Security con Office SharePoint Server 2007

mfontana — Fri, 15 May 2009 11:18:18 GMT

Oltre ai whitepapers di interoperabilità tra Geneva Server e Novell Access Manager e Sun OpenSSO il team di Geneva ha pubblicato il laboratorio di Interoperabilità tra Geneva Server e Sharepoint 2007!!

Lo scenario descritto è un tipico caso di utilizzo di Sharepoint come portale di collaboration aziendale che vuole essere condiviso (tutto o spesso in parte) con dei business partners esterni.

Nel whitepaper SharePoint 2007 in CONTOSO (questo brand secondo me vale oro :-)) viene configurato per ottenere le informazioni dell’utente (e rispettivi ruoli) per poter operare i criteri di autorizzazione dal proprio Geneva Server il quale è federato con il Geneva Server della società partner (in questo caso FABRIKAM Suppliers). In questo modo alcuni utenti di FABRIKAM potranno accedere a delle porzioni del portale di Sharepoint in CONTOSO.

Gli aspetti interessanti di questa demo che tra l’altro svelano alcune features introdotte dalla BETA 2 di Geneva sono ovviamente l’integrazione con Sharepoint ma anche l’uso di un attribute store diverso da AD (in questo caso un SQL Server) e l’integrazione con il Digital Rights Management (AD RMS) nell’ambiente federato.

--Mario