Actualmente estoy trabajando en un proyecto de SharePoint 2010 donde el entorno se configura con una aplicación web de SharePoint utilizando autenticación basada en notificaciones. La aplicación web se crea en el puerto 8081 usando la Autenticación de Windows para autenticación, y se extiende al puerto 80 utilizando la Autenticación basada en formularios.Diferenciar entre autenticación de Windows y formularios Autenticar usuarios al autenticarse contra el mismo DA con SharePoint 2010 usando autenticación basada en notificaciones
El proveedor de autenticación de formularios está configurado para usar el mismo directorio activo que el sitio basado en Windows auth, usando las siguientes entradas en la aplicación web.config (las entradas están en la administración central y en los archivos web.config del servicio de token de seguridad como bien):
<membership defaultProvider="i">
<providers>
<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add name="FBA_AD_MP" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ADFBAConnectionString" enableSearchMethods="true" attributeMapUsername="userPrincipalName" />
</providers>
</membership>
El uso de esta configuración funciona como se esperaba; los usuarios que visitan la aplicación en el puerto 8081 se presentan con un desafío de autenticación de Windows estándar, aquellos en el puerto 80 se dirigen al formulario de inicio de sesión personalizado. Al agregar usuarios al sitio a través de las herramientas de administración listas para usar, una búsqueda de un usuario en particular como [email protected] arrojará dos visitas, una del proveedor de autenticación de Windows, una del proveedor de autenticación de formularios. Agregar ambos usuarios a un sitio revela que SharePoint almacena el nombre de la cuenta con un identificador agregado al frente. El usuario de autenticación de Windows se traduce a i: 0 # .w | mydomain \ johnsmith, el usuario de FBA se traduce a i: 0 # .f | fba_ad_mp | [email protected]
Aquí es donde entra el problema. Estamos creando colecciones de sitios a granel utilizando una herramienta personalizada que analiza una hoja de cálculo de entrada, crea colecciones de sitios y agrega los usuarios apropiados al sitio creado usando el siguiente método:
private static void AddUser(SPSite site, String userName, String spGroupName)
{
try
{
SPUser spUser = site.RootWeb.EnsureUser(userName);
if (spUser != null)
{
site.RootWeb.Groups[spGroupName].AddUser(spUser);
}
}
catch(Exception ex)
{
SharePointManager.Counter.Warnings++;
SharePointManager.Logger.Warn(String.Format("\t\tUnable to add user {0} to group {1} at site {2}: {3}", userName, spGroupName, site.RootWeb.Url, ex.ToString()));
}
}
El parámetro de nombre de usuario pasado es, siguiendo el ejemplo, [email protected] Sin embargo, el usuario agregado al sitio siempre es el usuario basado en la autenticación de Windows, i: 0 # .w | mydomain \ johnsmith.
¿Cómo especifico qué proveedor de autenticación sondear cuando llamo a EnsureUser para garantizar que el usuario correcto se agregue al sitio?
veo el mismo comportamiento desde el selector de personas (no buscar), pero el método de usuario garantizar no le gusta ese formato. Sin embargo, funciona bien si antepongo el nombre de usuario con "i: 0 # .f | fba_ad_mp |". Por ahora estoy bien haciendo de esto un elemento de configuración ... pero tengo curiosidad de saber en qué parte del modelo de objetos podría encontrar estos prefijos para escenarios más complejos. –