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

java .net (10)

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.

La propuesta de valor de externalizar la identidad está comenzando a aumentar en 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.

¿Es la razón por la falta de conciencia o algo más? ¿Cómo espera aprender sobre los enfoques basados en XACML para el desarrollo de software?

Tenga en cuenta que estoy preguntando sobre la autorización, no la autenticación.

Creo que depende del tipo de proyecto en el que trabajes. 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.

La mayoría de los proyectos que he hecho han sido aplicaciones propietarias para su uso dentro de grandes compañías, 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 llegara 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.

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 tecnológicos. 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.

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 están 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 un ID federado tiene la capacidad (y algunos dirían responsabilidad) de rastrear todas las actividades de sus usuarios, independientemente del sitio para el que usan el ID. Esta es la razón por la cual Google y Yahoo están encantados de proporcionar identificaciones federadas, pero no tan entusiasmados por consumirlas .

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.

Entonces, 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 otra identificación de usuario y 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?

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

¿Confías en tu proveedor de identidad?

Además, creo que puede ser 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.

Creo que la posibilidad de externalizar la autorización es mucho más difícil que la externalización de la autenticació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 nunca se hará, pero honestamente me cuesta mucho encontrar las razones por las que realmente quieres hacer eso. Tal vez para un conjunto de aplicaciones que trabajan codo con codo, pero una vez más, es muy probable que sean compatibles internamente, en lugar de externamente.

Para mí personalmente, esto es lo primero que he escuchado acerca de la Autorización externa ... Por lo tanto, podría tratarse simplemente de falta de conciencia.

Google ahora ...

Como indica otro cartel, la autorización generalmente 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.

Muchas rasones:

Como se demostró en algunos de los comentarios, existe una percepción general de que "la autorización es local", lo que implica que hay poco potencial de reutilización de los "atributos de tema" costosos para mantener a la 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).
Falta de infraestructura de datos: aplicar control de acceso basado en políticas entre organizaciones (el hecho de utilizar / 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 cumplimiento de la ley"? ¿Qué es un "ciudadano de los EE. UU."). 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).
Impacto en roles / responsabilidades: la autorización de externalización, ya sea a "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.
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.
Cuando tiene una regla de política sólida, es probable que descubra que los atributos necesarios para procesarla no existen; por lo general, 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".
Relativamente tratable, pero todavía real, es que muchas aplicaciones COTS muy extendidas no son compatibles con la autorización externa, y muchos desarrolladores de aplicaciones no están acostumbrados a la externalización, por lo que (a) intentarán convencerlo de que no lo haga; 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!