Archive for February, 2009

Questo è uno degli argomenti più *insider* dell’universomondo di SharePoint, non solo per la sua complessità ma sopratutto per la scelta implementativa che esso comporta.

L’utilizzo di CST (Custom Security Trimmer) è la soluzione proposta da Microsoft per il problema del *trimming* all’interno di operazioni di ricerca e presentazione dei risultati offerte da MOSS. In particolare, ogni volta che un utente esegue una qualsiasi ricerca all’interno del portale, il suo profilo viene utilizzato in fase di *query time* per effettuare il check su quali dei contenuti indicizzati, quindi interessati dalla ricerca che si sta effettuando, l’utente abbia accesso per poi presentarli in fase di visualizzazione.

Può capitare quindi che su di un monte di 100 documenti disponibili, l’utente corrente abbia dei permessi validi solo su di una piccola parte di questi (10?), quindi visualizzerà come risultati soltanto quest’ultimi senza avere coscenza dell’esistenza dei restanti 90. Più che sacrosanto direi!!

L’utilizzo del trimming è un’aspetto fondamentale dell’architettura di collaboration proposta da Microsoft e la maggior parte delle volte viene presentato e percepito giustamente come un grande vantaggio nell’utilizzo del portale anche come unico punto di accesso alle informazioni. Ovviamente rimane una scelta vincente l’utilizzo di MOSS in questi scenari, anzi non si potrebbe immaginare una soluzione migliore, ma ahimè occorre considerare anche architetture in qui questa funzionalità deve essere momentaneamente messa da parte per far posto a soluzioni custom, frutto cioè di una politica di profilazione *differente* da ciò che MOSS offre in modalità Out Of The Box.

Pensate a scenari in qui le vostre applicazioni utilizzano MOSS come base documentale, molto spesso eseguendo operazioni di gestione documentale magari utilizzando un service account, il risultato è abbastanza banale: l’utente anche se in qualche modo legato alla finalità del documento non viene riconosciuto come propeietario a meno che in fase di manipolazione dei dati la vostra applicazione non si preoccupi anche di attribuire specifici permessi.

Scendendo ancora nel particolare, può capitare che processi di archiviazione documentale, ad esempio, eseguano operazione di migrazione massiva di contenuti da un sito all’altro senza preoccuparsi di mantenere la politica di permessi del sito di origine: anche qui ahimè vi ritrovereste senza alcun risultato durante la vostra ricerca, pur avendo in qualche modo partecipato alla pratica di formazione di un determinato documento ora archiviato.

Quindi bene in questo caso adottare una buona politica di CST, magari accompagnata da un corretto urilizzo dell’impersonificazione del service account in fase di ricerca ma in alcuni casi anche questo non basta.

In questi ultimi periodi capita frequentemente, visto anche il *successo* di MOSS come Application Platform, di utilizzare questo prodotto come motore documentale per 100, 1000 attività trasversali al document management, quindi capita che i permessi settati sui singoli documenti o elenchi rientrino in una più grande e variegata policy interna all’applicazione che viene ospitata in MOSS.

A prescindere da quale livello di granularità si intenda adottare su siti, liste e/o documenti, non si può prescindere dal considerare anche che l’applicazione host deve in qualche modo poter vivere di vita propria, nello specifico, specializzare e/o estendere le policy native di MOSS anche all’interno di essa, proporre profili personalizzati di utenza che debbano inevitabilmente uscire fuori dal contesto documentale.

Un piccolo esempio: la gestione della qualità.

Una soluzione integrata in MOSS per la gestione della qualità, ha si una profilazione per il gestore documentale ma deve preoccuparsi di mantenere anche altre 10/15 profilazioni a livello applicativo e spesso se questa soluzione è agganciata ad un BPM, il profilo deve essere il più possibile vicino a quello rappresentato dell’organizzazione (ufficio, divisione, settore) di appartenenza senza tralasiare anche le spcifiche competenze di determinati ruoli.

Non è sempre facile mantenere o estendere profilazioni interne a MOSS, in quanto alcuni ruoli applicativi non possono, per natura, essere riportati o re-interpretati su scenari applicativi del tutto esterni a MOSS.

In questi scenari il collo di bottiglia potrebbe essere l’utilizzo di un CST *as Microsoft suggest*, proprio quando dobbiamo uscire fuori dalla profilazione offerta da MOSS, quindi effettuare un match tra policy interne ed esterne al motore di gestione documentale.

Per rendere più esplicativo il problema vi propongo un esempio di CST *as-is*, il codice che riporto può essere consultato qui.

Il metodo core è la funzione di check che deve restituire una array di GUID che andranno a formare la lista di informazioni restituite dalla ricerca. Possiamo intervenire appunto su questa lista, scegliendo quali di questi risultati concorrerrano alla formazione dei risultati di ricerca:

   1: public BitArray CheckAccess(IList<String> documentcrawlURLs, IDictionary<String, Object> sessionProperties)

   2: {

   3:    BitArray retArray = new BitArray(crawlURLs.Count);

   4:    

   5:    for (int x = 0; x < crawlURLs.Count; x++)

   6:    {

   7:      /*

   8:        To fully implement the security trimmer,

   9:        add code to perform the security check 

  10:        and determine if strUser can access crawlURLs[x].

  11:        If strUser can access crawlURL[x], then:

  12:       */

  13:        retArray[x] = true;

  14:      //If not:

  15:        retArray[x] = false;

  16:    }

  17:    return retArray;

  18: }

Implementando la logica di comportamento del metodo non dovremmo riscontrare alcun problema in condizioni *normali* ma tutto cambia se ci troviamo a dover effettuare un match con profilazione applicative, quindi proprie della nostra applicazione. In questo caso  i problemi possono dimostrarsi numerosi e particolarmente *fastidiosi* sopratutto in termini di efficienza di tempo impiegato e di risorse di calcolo.

Problema 1: Impersonificazione

L’impersonificazione del service account che molto spesso deve avere il *monopolio* del patrimonio documentale è spesso requisito fondamentale in quanto il trimming mantiene le informazioni dell’utente che sta eseguendo l’operazione di ricerca, quindi mantiene le sue credenziali. E’ necessario impersonificare un utente di livello più elevato per fare in modo che il monte di documenti ritornato sia il più amio possibile.

Problema 2: Parsing del documentcrawlURLs

Un problema non da poco è l’identificazione delle informazioni del documnto all’interno della lista di input della funzione CheckAccess.

La funzione presenta ogni item alla logica di profilazione nel seguente modo:

   1: sts3://moss/siteurl=/siteid={86051521-13de-4dac-80d1-231406b51b57}

   2: /weburl=/webid={e67908fc-024b-4689-b854-4837d0d32abb}

   3: /listid={30dc794a-c5b6-4c86-97f6-2ed65133149d}/viewid={efc86211-

   4: 96e2-4443-9dfc-5d8e42daf285}

Quella rappresentata è la classica quaterna formata dall’url della site colelction, url del web site, guid della lista ed il guid della view. Da qui dobbiamo in qualche modo implementare del codice per l’identificazione del documento o della lista ed effettuare un check sulle permission di questi ultimi, in più eseguire un match con le policy della nostra applicazione, quindi decidere se aggiungere o meno l’item all’array che ritornerà la funzione CheckAccess.

Problema 3: Manutenzione della soluzione

La DLL che implementeremo oltre che essere registrata nella GAC (ovvio) necessiterà anche di alcune operazioni di amministrazione in MOSS ed in più lo stesso CST dovrà esseere aggiornato mano a mano che la crescita delle SiteCollection interessate dall’applicazione crescerà di numero o di dimensione.

In generale più è complessa la logica delle funzioni di CheckAccess che implementiamo, più perde di efficienza l’intera architettura di ricerca, in quanto le operazioni di check vengono chiamate durante l’attesa della visualizzazione dei dati da parte dell’utente, a *query time* per l’appunto.

Test su quantità di documenti (>10000) già richiedono un incremento dell’attesa di + di 0,05 secondi. Consideriamo anche che il problema n.1 (Impersonificazione) ovviamente incide molto sulle performance in quanto utilizzando un account con elevati privilegi la quantità di documenti posta a CST è molto spesso la totalità dei documenti a disposizione della nostra organizzazione.

Per chi di voi necessità di effettuare profilazioni complesse e che necessitano uan esternazione applicativa da MOSS una strada efficiente, mantenibile ed altamente customizzabile risiede il più delle volte in questa semplice best practice:

• Utilizzo del query object model per effettuare la ricerca;
• Passaggio delle informazioni inerenti al documento (questa volta no GUID) ad una Stored Procedure per il parsing e profilazione;
• Presentazione dei risultati

Questo utilizzo può abbassare di molto i tempi di esecuzione richiesti da MOSS anche se confrontato con quelli attesi in normali condizioni di trimming.