none
Modos de autenticación en una misma aplicación RRS feed

  • Pregunta

  • Hola,

    ¿es posible poner en una misma aplicación, con autenticación clásica, seguridad integrada y básica? Sin crear una aplicación extendida de la original.

    Gracias.

     

    lunes, 27 de diciembre de 2010 20:05

Respuestas

  • Hola,

    si te soy sincero, no soy muy partidario de tocar el IIS cuando hablamos de SharePoint (a excepción de asuntos relacionados con certificados). Piensa que otras tecnologías como OWA son aplicaciones web que corren sobre IIS, pero que SharePoint, pese a que corre sobre IIS podría considerarse un servidor de aplicaciones en sí, y todas las peticiones web que haces las gestiona él mismo para devolver contenido alojado en sus bases de datos. De esa manera, si por ejemplo vas la página de una librería de documentos (.../forms/allitems.aspx) dicha página no existe realmente, sinó que se genera dinámicamente en base a los datos que SharePoint obtiene de la URL y de la BBDD. Si SharePoint no reconoce urls de la forma http://www.midominio.com te devolverá un error.

    Soltado este rollo a nivel general ;)... desconozco si un cambio como el que necesitas te dará algún problema, o si existe algún parámetro de configuración que te permita resolverlo. A nivel de desarrollo, que es donde mejor me desenvuelvo, lo que puedes hacer es un custom authentication provider, basado en el LDAPAuthenticationProvider pero que envíe un dominio fijo basado en un parámetro del web.config. Bajo mi punto de vista es matar moscas a cañonazos, porque es un esfuerzo elevado para el beneficio que supone, pero lo que está claro es que a veces esos beneficios son los que más elevan el grado de satisfacción del usuario. Si crees que te merece la pena, te recomiendo este enlace:

    http://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx

    Saludos,
    David Martos
    http://david-martos.blogspot.com

     

     

    • Marcado como respuesta Manuel5 jueves, 30 de diciembre de 2010 18:40
    jueves, 30 de diciembre de 2010 7:46

Todas las respuestas

  • Digo lo de no crear una extendida por lo siguiente.

    Si mi intranet es https://intranet.miempresa.com, con seguridad integrada y quiero que desde fuera de la empresa haya autenticación básica puedo crear https://extranet.miempresa.com, pero esto me obliga a tener otro certificado ¿no?.

    ¿Cómo haría para que cuando se conectan desde fuera, les ponga por defecto el domino miempresa.com y no el nombre de su máquina?

    Gracias.

    lunes, 27 de diciembre de 2010 20:15
  • Hola Manuel,

    ¿estás hablando de MOSS o de SharePoint 2010?

    En cualquier caso, para que desde fuera de tu organización, al navegar a tu sitio, se utilice el dominio miempresa.com tendrías que extender la aplicación web a ese dominio (o crearla inicialmente con ese host header). Hay otras opciones, como que la traducción la haga otro software (por ejemplo ISA Server) pero la mejor opción es la primera. Respecto a los certificados, aunque no dominio la materia al completo, entiendo que puedes disponer de un certificado *.miempresa.com con lo que te serviría para las dos aplicaciones web.

    De todas maneras, y a nivel general, necesitas extender la aplicación web únicamente si el método de autenticación varía de un tipo de acceso a otro (AD y FBA por ejemplo). Si lo único que necesitas son dos urls diferentes, con que establezcas las rutas de acceso alternativas te será suficiente.

    Saludos,
    David Martos
    http://david-martos.blogspot.com

    martes, 28 de diciembre de 2010 8:12
  • Hola Marcos, gracias por contestar.

    No necesito dos urls diferente, si puede ser una mejor.

    Lo del dominio igual no me he explicado bien, cuando los usuarios se conectan desde fuera de la organización, les pide usuario y contraseña (en la organización no porque es windows integrada). El problema es que si meten su usuario, ejemplo: juandiez, les pone el nombre de su equipo por delante EQUIPOPERSONALUSUARIO\juandiez. Para entrar necesitan poner juandiez@miorganizacion.com, que aunque no es un gran problema si que es un poco lata. En los IIS del sitio web he puesto en la autenticación básica, el dominio de mi empresa como dominio predeterminado, pero creo que no me esta haciendo caso porque en una misma aplicación sharepoint no se puede tener mas de un sistema de autenticación salvo que este basado en notificaciones y yo (por compatibilidad con 2007) tengo autenticación clásica.

    Por cierto, hablo de sharepoint 2010.

     

    martes, 28 de diciembre de 2010 19:46
  • Manuel,

    Si estás hablando de SharePoint 2010, entonces debería utilizar Claims para el escenario que comentas. En el blog de David puedes encontrar varios posts a este respecto.

    Saludos!

    martes, 28 de diciembre de 2010 21:10
  • Hola,

    efectivamente, como dice Juan Carlos, deberías usar Claims para llegar a lo que tú quieres y replantearte el uso de directorio activo como método de autenticación para usuarios externos.

    Los usuarios van a tener que poner el dominio porque están fuera de él. Para eliminar esa acción deberás hacer que estén dentro de éste (por VPN por ejemplo). Lo normal cuando hablamos de acceso externo a un sitio web es utilizar autenticación por formularios donde los usuarios están guardados en un sistema como, por ejemplo, un SQL. También los puedes tener en AD y usar LDAP, pero entonces seguirás teniendo que poner el dominio para autenticarte.

    Te dejo aquí más info por si te sirve de ayuda:

    http://david-martos.blogspot.com/2010/03/autenticacion-basada-en-notificaciones_04.html

    Saludos,
    David Martos
    http://david-martos.blogspot.com

     

    miércoles, 29 de diciembre de 2010 8:52
  • Hola David,

    sin embargo otras tecnologías como OWA si que evitan este problema configurando el dominio predeterminado en el IIS. ¿No es posible esto en sharepoint?

    jueves, 30 de diciembre de 2010 5:27
  • Hola,

    si te soy sincero, no soy muy partidario de tocar el IIS cuando hablamos de SharePoint (a excepción de asuntos relacionados con certificados). Piensa que otras tecnologías como OWA son aplicaciones web que corren sobre IIS, pero que SharePoint, pese a que corre sobre IIS podría considerarse un servidor de aplicaciones en sí, y todas las peticiones web que haces las gestiona él mismo para devolver contenido alojado en sus bases de datos. De esa manera, si por ejemplo vas la página de una librería de documentos (.../forms/allitems.aspx) dicha página no existe realmente, sinó que se genera dinámicamente en base a los datos que SharePoint obtiene de la URL y de la BBDD. Si SharePoint no reconoce urls de la forma http://www.midominio.com te devolverá un error.

    Soltado este rollo a nivel general ;)... desconozco si un cambio como el que necesitas te dará algún problema, o si existe algún parámetro de configuración que te permita resolverlo. A nivel de desarrollo, que es donde mejor me desenvuelvo, lo que puedes hacer es un custom authentication provider, basado en el LDAPAuthenticationProvider pero que envíe un dominio fijo basado en un parámetro del web.config. Bajo mi punto de vista es matar moscas a cañonazos, porque es un esfuerzo elevado para el beneficio que supone, pero lo que está claro es que a veces esos beneficios son los que más elevan el grado de satisfacción del usuario. Si crees que te merece la pena, te recomiendo este enlace:

    http://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx

    Saludos,
    David Martos
    http://david-martos.blogspot.com

     

     

    • Marcado como respuesta Manuel5 jueves, 30 de diciembre de 2010 18:40
    jueves, 30 de diciembre de 2010 7:46
  • Hola a ambos,

    Estoy de acuerdo con la apreciación de David en cuanto a que si estamos tratando con SharePoint, el IIS lo tenemos que dejar aparcado y no tocar nada ya que más que solucionar problemas, podemos ocasionar más. Con respecto a crear un proveedor de authenticación propio, estoy con David de que igual no te compensa para lo que necesitas.

    Un saludo!

    jueves, 30 de diciembre de 2010 12:10
  • Hola,

    valoraré si merece la pena desarrollar el custom provider.

    Gracias por la ayuda,

    Manuel.

    jueves, 30 de diciembre de 2010 18:41