Utilizzo del servizio di archiviazione sicura in un provider di attestazioni personalizzate con SharePoint 2010

Di recente, utilizzando il servizio di archiviazione sicura in un provider di attestazioni personalizzate su cui lavoravo, ho scoperto un insolito stratagemma. Lo scenario è interessante, perché riguarda qualcosa che molte altre persone desiderano effettuare: l'aumento delle attestazioni personalizzate. A questo scopo, ho dovuto connettermi a un'origine dati remota per eseguire query su alcune informazioni aggiuntive su ogni utente e quindi utilizzare tali informazioni per determinare le attestazioni da aumentare e quelle da non aumentare.

Come linee guida generali per l'utilizzo di origini dati in provider di attestazioni personalizzate, è importante ricordare che l'assembly del provider di attestazioni personalizzate verrà mantenuto attivo in memoria dal processo di SharePoint Team Services. Questo aspetto semplifica notevolmente il recupero delle "informazioni", sia che si tratti di un set di dati, un set di credenziali o altro, archiviandole in una variabile a livello di classe e quindi rendendole disponibili per l'utilizzo fino al successivo comando IISRESET. Il grande limite in questo caso è che non tutte le risorse della farm di SharePoint possono essere disponibili nel momento in cui viene creata un'istanza della classe del provider di attestazioni predefinite e questo è l'aspetto più istruttivo di tutta l'esperienza.

In questo caso specifico ho voluto recuperare dati dal servizio di archiviazione sicura nel costruttore per il mio provider di attestazioni personalizzate e quindi utilizzarli per qualcos'altro, ovvero per creare una variabile WindowsIdentity da un dominio tramite un trust unidirezionale, in modo da poterla utilizzare per creare un contesto di rappresentazione dotato delle autorizzazioni necessarie per eseguire query sul servizio Active Directory remoto. Il problema era che quando tentavo di utilizzare in qualsiasi modo il riferimento al servizio di archiviazione sicura nel costruttore, si verificava SEMPRE un timeout del riferimento. Indipendentemente dal metodo chiamato nel servizio di archiviazione sicura, il metodo generava un errore di timeout dopo 60 secondi.

La correzione consiste semplicemente nello spostare il codice all'esterno del costruttore. Lo stesso identico codice funziona perfettamente se richiamato dall'override del metodo FillClaimsForEntity. Poiché sono riuscito a venire a capo del problema solo per un colpo di fortuna e dopo svariati tentativi ed errori, ho ritenuto utile condividere questo suggerimento.

Nel caso di questo particolare problema, relativo ad accesso a un domino remoto e rappresentazione, vale probabilmente la pena provare un altro schema che ho ideato e un altro espediente piuttosto strano.

Come ho descritto prima, poiché l'assembly resta caricato nel processo del servizio di archiviazione sicura, è possibile mantenere attive le variabili a livello di classe. Poiché ovviamente non volevo accedere ripetutamente al dominio remoto su cui dovevo eseguire query, ho creato una variabile a livello di classe da WindowsIdentity. Lo schema che ho utilizzato è simile al seguente:

1. Verifico se ho già recuperato le credenziali del servizio di archiviazione sicura
   1. In caso negativo, eseguo il codice che:
      1. Recupera le credenziali dal servizio di archiviazione sicura
      2. Utilizza l'API LogonUser per accedere al dominio remoto tramite le credenziali ottenute dal servizio di archiviazione sicura
      3. Crea un'istanza della variabile WindowsIdentity in modo da disporre delle credenziali dell'utente remoto
2. Verifico se la variabile WindowsIdentity è o meno null
   1. In caso negativo, eseguo il codice che:
      1. Crea una nuova istanza di un oggetto WindowsImpersonationContext da WindowsIdentity.Impersonate()
      2. Esegue una query sul dominio remoto
      3. Chiama Undo in WindowsImpersonationContext

Tale schema sembra funzionare correttamente e al momento mi offre le migliori prestazioni possibili. L'altra scoperta consiste invece nel fatto che in genere si preferisce NON chiamare Impersonate() nell'istanza di WindowsIdentity e quindi NON si chiama Undo nell'oggetto WindowsImpersonationContext risultante successivamente. Per quanto ho riscontrato, se la rappresentazione non viene annullata, non verrà più eseguito il rendering del sito. Riaggiungete la chiamata ad Undo e tutto tornerà a funzionare di nuovo.

Questo è un post di blog localizzato. Consultate l'articolo originale: Using Secure Store Service in a Custom Claims Provider with SharePoint 2010