Scrittura di una pagina di accesso personalizzata con autenticazione basata su moduli per SharePoint 2010 - Parte 1

Scrittura di una pagina di accesso personalizzata con autenticazione basata su moduli per SharePoint 2010 - Parte 1

In SharePoint 2007 scrivere una pagina di accesso personalizzata per un sito con autenticazione basata su moduli non è molto difficile. È necessario conoscere alcune informazioni, la maggior parte delle quali non specifiche di SharePoint, e alcuni suggerimenti affinché il modulo di accesso acquisisca l'aspetto di una pagina di layout di SharePoint standard. Se tuttavia si conosce ASP.NET e la classe FormsAuthentication, è possibile in genere procedere senza problemi. Questa attività purtroppo è un po' più complicata in SharePoint 2010.

In questo post verrà illustrato uno scenario di una pagina di accesso personalizzata. In questo esempio si è scelto di creare una pagina di accesso completamente personalizzata. Non verrà semplicemente modificato l'aspetto di una pagina. Verrà creato piuttosto un elemento dell'interfaccia utente completamente diverso. Si supponga ad esempio di voler richiedere le credenziali di appartenenza utilizzate per l'accesso e che un utente immetta un ID di autenticazione secondario, come con SecurID. In tal caso sarà necessario disporre di due caselle di testo in una pagina ASP.NET per il nome utente e la password e utilizzarle per far accedere l'utente a livello di programmazione.

L'aspetto più importante di cui tenere conto è che non è più necessario utilizzare la classe FormsAuthentication. In SharePoint 2010 infatti gli utenti dell'autenticazione basata su moduli sono in realtà utenti delle attestazioni. Anche se si ritiene di utilizzare un utente di appartenenza e un provider di ruoli ASP.NET standard, in realtà tali oggetti dispongono di una nuova shell di autenticazione basata sulle attestazioni. È per questo motivo che sarà necessario utilizzare alcune delle classi di attestazioni di SharePoint per il processo di accesso con autenticazione basata su moduli.

Avvertenza Prima di inserire informazioni in un blog, per procedere in modo ottimale ho sempre l'abitudine di verificare i dati o di confrontarmi con altri. In questo caso, ho tentato ripetutamente di far controllare questo approccio, ma non è stato possibile ottenere alcun riscontro. Ho utilizzato questo codice per un progetto a cui ho lavorato e ha funzionato, ma non dovete preoccuparvi se successivamente puristi del codice dovessero intervenire per indicare alcune modifiche per un approccio migliore o comunque più appropriato. Dopo aver concluso con le premesse, è possibile passare ad analizzare il codice.

Prima di iniziare, sono necessari alcuni riferimenti che probabilmente non sono mai stati utilizzati in precedenza. Il primo è il file Microsoft.SharePoint.Security.dll, contenuto nell'hive 14 della cartella ISAPI. Il secondo è un po' più complicato ed è il motivo principale per cui è stata precedentemente inserita un'avvertenza. È necessario infatti un riferimento a Microsoft.SharePoint.IdentityModel.dll. Se tuttavia si aggiungono i riferimenti, questo assembly non verrà trovato immediatamente. È per questo motivo che mi sono inizialmente espresso con cautela e un po' di imbarazzo. Come già descritto in un altro post, la soluzione migliore è cercarlo nel file system, copiarlo in un percorso facilmente individuabile e aggiungere il riferimento alla versione copiata. A tale scopo, appartenendo alla vecchia scuola, ho preferito aprire una finestra del prompt dei comandi, passare alla radice dell'unità e digitare "dir Microsoft.SharePoint.IdentityModel.dll /s" per trovare il file desiderato. A questo punto, è possibile aggiungere un piccolo elenco di istruzioni using:

using System.Web.Security;

using System.IdentityModel.Tokens;

using Microsoft.SharePoint;

using Microsoft.SharePoint.IdentityModel;

Al termine di questa prima parte poco elegante, quando viene chiamata la classe di attestazioni per convalidare le credenziali dell'utente dell'autenticazione basata su moduli digitate dall'utente stesso, è necessario indicare quali provider di appartenenze e di ruoli devono essere utilizzati. Manca solo un nome. In questo particolare caso, dal momento che erano già stati scritti un provider di appartenenze e un provider di ruoli personalizzati adatti allo scopo, è stato sufficiente enumerare tutti i provider conosciuti dall'applicazione Web per trovare quello desiderato:

//get the provider names for our type

string userProviderName = string.Empty;

string roleProviderName = string.Empty;

//get the membership provider name

foreach (MembershipProvider p in Membership.Providers)

{

if (p.GetType().Equals(typeof(Microsoft.SE.AnonProvider.Users)))

       {

       userProviderName = p.Name;

              break;

       }

}

//get the role provider name

foreach (RoleProvider rp in System.Web.Security.Roles.Providers)

{

if (rp.GetType().Equals(typeof(Microsoft.SE.AnonProvider.Roles)))

       {

       roleProviderName = rp.Name;

              break;

       }

}

 

Dopo aver ottenuto i nomi dei provider, utilizzare il nome utente e la password per ottenere un oggetto SecurityToken. A tale scopo, verrà utilizzata la classe SPSecurityContext, che dispone di un metodo progettato per eseguire questo accesso con autenticazione basata su moduli. Se ha esito positivo, verrà restituito un oggetto SecurityToken, altrimenti verrà restituito un valore null. L'autenticazione delle credenziali utente sarà simile alla seguente:

SecurityToken tk = SPSecurityContext.SecurityTokenForFormsAuthentication(

new Uri(SPContext.Current.Web.Url), userProviderName, roleProviderName,

          UserNameTxt.Text, PasswordTxt.Text);

 

È stato passato un URI per il sito per cui eseguire l'autenticazione, è stato specificato il nome dei provider di appartenenze e di ruoli e sono stati passati i valori di nome utente e password digitati nelle caselle di testo della pagina di accesso. È ora necessario verificare che SecurityToken non sia uguale a null e scrivere un token di sessione. A tale scopo, viene utilizzato SPFederationAuthenticationModule. Dopo aver scritto il token di sessione, è possibile proseguire e reindirizzare l'utente alla pagina o alla risorsa richiesta. Viene riportato di seguito il resto del codice che esegue questa operazione:

if (tk != null)

{

//try setting the authentication cookie

SPFederationAuthenticationModule fam = SPFederationAuthenticationModule.Current;

fam.SetPrincipalAndWriteSessionToken(tk);

       //look for the Source query string parameter and use that as the redirection

       string src = Request.QueryString["Source"];

       if (!string.IsNullOrEmpty(src))

       Response.Redirect(src);

}

else

{

StatusLbl.Text = "The credentials weren't valid or didn't work or something.";

}

 

Dopo aver eseguito con esito positivo tutte le operazioni, viene utilizzato il parametro della stringa di query Source per indicazioni sulla destinazione originale dell'utente. Dopo aver ottenuto queste informazioni, è possibile indirizzare l'utente alla pagina richiesta.

Mi auguro che queste informazioni possano rivelarsi utili. So per certo che non è facile trovare la documentazione relativa alla procedura ottimale per eseguire questa operazione, avendo provato io stesso in prima persona a cercarla. Nella parte 2 questa operazione verrà eseguita in un modo diverso per uno scenario diverso, in cui l'utente dovrà sottoscrivere le condizioni per l'utilizzo del sito Web per utilizzare il sito per la prima volta. A tale scopo, verrà estesa la pagina di accesso di base aggiungendo un gestore nella fase di accesso.

Questo è un post di blog localizzato. L'articolo originale è disponibile in Writing A Custom Forms Login Page for SharePoint 2010 Part 1.