¿Hay alguna razón por la cual los desarrolladores de software no están externalizando la autorización?

Question

La proposición de valor de externalizar la identidad está comenzando a aumentar cuando muchos sitios ahora aceptan OpenID, CardSpace o identidad federada. Sin embargo, muchos desarrolladores aún no han dado el siguiente paso para externalizar la autorización y usar enfoques basados ​​en XACML.

¿La razón es falta de conciencia o algo más? ¿Cómo espera conocer los enfoques basados ​​en XACML para el desarrollo de software?

Tenga en cuenta que estoy pidiendo autorización, no autenticación.

Answer 1

Creo que la posibilidad de externalizar la autorización es mucho más difícil que la autenticación de externalización (OpenID, CardSpace, etc.). Esto se debe principalmente al hecho de que la autorización es mucho más específica de la aplicación. Lo que la persona A está autorizada a hacer en mi aplicación puede no ser capaz de hacerlo en su aplicación, y eso incluso suponiendo que exista un paralelismo común entre mi aplicación y la de usted, que probablemente no exista.

No quiero decir que la autorización de externalización será nunca hecho, pero sinceramente me cuesta pensar en las razones por las que realmente querría hacer eso. Tal vez para un conjunto de aplicaciones que trabajan codo con codo, pero una vez más, es muy probable que sea compatible internamente, en lugar de externamente.

Answer 2

Creo que depende del tipo de proyecto en el que trabaje. Si el cliente quiere almacenar la autorización, no hay forma de usar OpenID ... Desarrollo un pequeño proyecto usando el motor de aplicaciones de Google y por eso utilizo Google para hacer la autorización. Por lo tanto, depende en gran medida del tipo de proyecto.

Answer 3

La razón principal por la que seguimos lanzando la nuestra es que las opciones como openid et al aparentemente solo son compatibles con los sitios de tecnología. Somos un jugador más pequeño, por lo que no comenzaremos a utilizar un proveedor externo hasta el momento en que haya una aceptación mucho mayor por parte del usuario.

No queremos que lo primero que un usuario tenga que hacer en nuestro sitio implique ir a otro sitio.

Answer 4

La mayoría de los proyectos que he hecho han sido aplicaciones propietarias para su uso dentro de grandes empresas, y en esos casos los servicios de autenticación externa rara vez son una opción, pero la autenticación es manejada por algún servicio interno (como Active Directory).

Si llegase a formar parte de un proyecto que construiría un sitio web público, definitivamente intentaría usar algo como OpenID en lugar de alojar mi propia autenticación.

Answer 5

Además, recuerde esa autorización! == autenticación. El hecho de que un usuario esté autenticado no significa que haya resuelto la parte de autorización de su sitio. Aún necesita determinar quién puede hacer qué y cuándo.

Answer 6

Un problema es una combinación de No inventado aquí y desconfianza de las autoridades externalizadas para identidad (incluso seudónoma). Un buen artículo es aquí:

• Do You Trust your Identity Provider?

Además, creo que puede ser la inercia. Sin una aplicación asesina para alimentarlo, las personas tardan en migrar. Dado el aumento en la cantidad de integraciones de Facebook que he visto últimamente, creo que estamos en lo alto de una pendiente pronunciada, a punto de ingresar a ese mundo.

Answer 7

Parece que he caído en el malentendido que tienen los demás: la pregunta era sobre la autorización externa. Personalmente, solo confiaría en la autorización distribuida en una red local donde tengo control sobre los servidores de autenticación y autorización. Nunca usaría autorización externa en un sitio web.

A continuación se presentan mis comentarios sobre OpenID como un servicio de autenticación.

1) Como se señaló, autorización! = Autenticación. OpenID maneja la autenticación, pero el propietario de la aplicación web todavía tiene control total sobre los derechos asignados a ese inicio de sesión. Esto es positivo, pero la confusión sobre esto es negativa.

2) No puedo encontrar el enlace, pero OpenID está abierto a ingeniería social/principal en el medio/ataques de phishing. Los proveedores intentan evitar esto (imágenes de identificación, certificados de navegador, verificación de devolución de llamada, etc.) pero no ayuda cuando el sitio de black hat muestra un diálogo/página que dice "ingrese su nombre de usuario y contraseña de OpenID" y el genio el usuario cumple.

3) Cada proveedor de una identificación federada tiene la capacidad (y algunos dirían responsabilidad) de rastrear todas las actividades de sus usuarios, independientemente de para qué sitio utilicen la ID. Esta es la razón por la que Google y Yahoo están encantados de proporcionar identificaciones federadas, pero no tan entusiasmados con consumir ellos.

4) Contrariamente a un comentario anterior, comúnmente el uso de OpenID reduce la barrera para el registro, especialmente cuando una UI útil señala que un nuevo usuario probablemente ya tenga un OpenID. Esto es aún más cierto cuando usa una solución combinada de OpenID/OAuth como RPX.

Por lo tanto, desde mi punto de vista, los riesgos de usar OpenID están en el usuario, no en el sitio web. No puedo evitar que el usuario sea atacado haciéndoles tratar de recordar otro ID de usuario & contraseña. Además, Black Hats no necesita hacer nada más nefasto que almacenar las contraseñas de usuario para su sitio en texto plano para obtener acceso a las otras cuentas de un usuario. ¿Cuántas personas usan una contraseña diferente para cada sitio web en el que inicie sesión?

Answer 8

Para mí personalmente, esto es lo primero que he escuchado acerca de la autorización externa ... Así que podría ser solo una falta de conciencia.

buscar en Google ahora ..

Answer 9

Como otro cartel indica, en general, la autorización es específica de la aplicación. Lo que puede hacer en una aplicación varía significativamente de lo que puede hacer en otra. Especialmente en aplicaciones comerciales listas para usar, la aplicación generalmente maneja de forma más natural la autorización.

El rendimiento es otra preocupación. Esto puede verse al obtener la implementación XACML de Sun y al usarla para externalizar alguna autorización. Usted incurre en costos de red en ambos lados de la solicitud que (dependiendo de la forma en que la solicitud/respuesta de arquitecto, etc.) puede superar con creces el costo real de la decisión de autorización. Constrúyalo en una aplicación COTS, donde tiene menos libertad para la optimización del rendimiento y las cosas empeoran.

Sin embargo, creo que algunas de las áreas prometedoras están relacionadas con el cumplimiento normativo. Hay algunas autorizaciones que no varían según la aplicación. Transferencia de información o materiales patentados o clasificados, por ejemplo. En estos casos, se puede presentar un caso sólido para el mismo control existente en cada aplicación, porque el inverso es tan malo. Tener cualquier cantidad de implementaciones y reglas para el mismo control de acceso es una pesadilla de gestión.Un lugar fácil para comenzar con un marco de control como XACML puede ser comenzar con lo que alguien puede ver y luego determinar qué puede hacer alguien.

Answer 10

varias razones:

1. Como algunos de los comentarios demostrado, hay una percepción general de que "la autorización es local", que implica que hay pocas posibilidades de reutilización de la cara-a-mantener-a "atributos de sujeto" de alta calidad necesarios para importantes decisiones de acceso. (Creo que existe un alto potencial de reutilización dado que algunas leyes/reglas son ampliamente aplicables, pero la discusión completa de esto es demasiado larga para este formato.)
2. Falta de infraestructura de datos: aplicar control de acceso basado en políticas entre organizaciones (yo usar/confiar en la información de autorización de otra organización ("AuthZ") para desbloquear el acceso a mis datos) requiere, como mínimo, que entienda la semántica del atributo (¿qué es un "oficial de aplicación de la ley"? ¿Qué es un "US Ciudadano ".) Después de eso, sería bueno tener estándares de calidad de atributos fáciles de entender y la certificación de terceros de los mismos. (Algunos pueden observar que estos requisitos son análogos a los requisitos para la interoperabilidad PKI: ¿cómo va eso? Y eso es solo para una pieza de datos, más material de apoyo.)
3. Impacto en roles/responsabilidades: autorización de externalización, ya sea para " roles "o a" atributos "o a" atributos con política digital ", significa que el" propietario de los datos "pierde el control del recurso. También descarga considerable trabajo y responsabilidad para mantener listas de usuarios. Este tipo de cambio eleva la implementación de AuthZ externo de un problema técnico a una cuestión organizativa con un lado de la política.
4. La mayoría de las organizaciones no saben y no han escrito cuáles son sus políticas. El acceso puede ser "quien pregunta" o "quien pregunta y me gusta" o "quien me puede dar algo, como el acceso a sus datos". Las reglas reales aplicadas pueden ser bastante feas cuando se las expone forzosamente al expresarlas en un lenguaje de políticas. Y las habilidades establecidas para una buena interpretación de las políticas escritas en las políticas digitales tampoco crecen en los árboles. De hecho, el conjunto de habilidades es analista de negocios o abogado, no un técnico de TI, y las herramientas para esas personas son raras o inexistentes.
5. Cuando tiene una regla de política sólida, es probable que descubra que los atributos necesarios para procesarla no existen; normalmente no son el tipo de cosas que ya encuentra en AD. El número de teléfono NO es útil como atributo de AuthZ, e incluso la "Organización" probablemente no sea apropiada para la mayoría de las leyes o reglamentos que puede documentar. Eso ni siquiera menciona las soluciones alternativas y las aproximaciones que debe implementar (y obtener la aprobación) para expresar los requisitos de la política como "causa probable".
6. relativamente manejable, pero sigue siendo real, es que muchas de las aplicaciones COTS muy extendidas no son compatibles con la autorización externa, y muchos app-desarrolladores no están acostumbrados a hacer externalización, y así serán (a) tratar de hablar de ella; o (b) aprenda en su moneda de diez centavos, y hágalo mal.

---

suena bastante mal, ¿verdad? Entonces, permítanme terminar diciendo que creo que el juego vale la pena a pesar de todo esto. La lista de beneficios potenciales es para otra publicación en otro momento.

¡Buena suerte!