Diferencias

Muestra las diferencias entre dos versiones de la página.

--- app:turboresumen [2025/07/13 16:52] – thejuanvisu
+++ app:turboresumen [2025/07/14 14:48] (actual) – [4.1.3 OAuth] thejuanvisu
@@ Línea 526: / Línea 526: @@
   - El servidor crea un ID de sesión y se lo asigna a esa sesión
   - El atacante envía a la víctima un enlace que de alguna manera incluya una URL con el identificador de sesión del atacante
-  - La víctima utiliza el enlace para autenticarsem
+  - La víctima utiliza el enlace para autenticarse, enviando el identificador de sesión que le envió el atacante
+  - la víctima proporciona sus credenciales y pasa a ser una sesión autenticada.
+  - El atacante conoce el identificador de la víctima y lo puede usar para realizar acciones en su nombre.
+Existen otros métodos más sofisticados:
+  * Enviar el identificador de sesión en un campo oculto de usuario
+  * Enviar el identificador de sesión a través de una cookie
+Para prevenir este tipo de ataques se recomienda generar una cookie de sesión nueva cada vez que el usuario se autentica, de esta forma el identificador de sesión que conoce el atacante deja de ser válido.
+==== 2.4.3 Reescritura de URl ====
+Muchos servidores envían el identificador de sesión en la URL, esto propicia que el identificador de sesión sea altamente vulnerable a distintos tipos de sustracción. La cabecera HTTP refer contiene información sobre la web desde la que se origina la petición, por lo tanto, si el atacante consigue redirigir el navegador de la víctima hasta una web que el controla, pude capturar la URL de origen con la cabecera en cuestión. Si la cabecera es el identificador de sesión el atacante lo puede usar para realizar peticiones en nombre de la víctima.
+==== 2.4.4 Política de mismo origen ====
+La Same-origin Policy define una serie de reglas para restringir como un documento o sus scripts pueden interacturar con otros recursos localizados en dominios diferentes. Esta política se implementa en el navegador web. Dos webs tienen el mismo dominio si el protocolo, nombre de dominio y puerto son los mismos.
+  * Los navegadores proporcionan acceso limitado al documento y a la ventanad e otros dominios
+  * La política de mismo origen también define qé interacciones están permitidas entre objetos JS
+    * Window.parent
+    * window.opener
+    * iframe.content.window
+  * Para las cominicaciones entre documetnos de diferentes origenes se puede usar window.postMessage
+  * Tambien impone restricciones sobre cabeceras HTTP
+  * Solo se pueden realizar peticiones AJAX al mismo dominio por defecto
+  * El acceso al almacenamiento de info (localStorage y SessionStorage) está separado por dominios.
+  * Las cookies también están separadas por dominos y una página solo puede establecer una cookie en su dominio.
+  * No se pueden realizar peticiones HTTP a otros dominios desde JS con fetch o con el objeto XmlHttpRequest
+  * JSONP (JSON con Padding) permite realizar llamadas asíncronas a dominios diferente
+==== 2.4.5 CORS ====
+El intercambio de recursos de origenes cruzados permite al navegador solicitar recursos de dominios diferentes. Para permitir al navegador solicitar recursos a troso domios, el servidor web del dominio destino envía ciertas cabeceras http adicionales para aceptar o denegar la solicitud.
+=== 2.4.5.1 CORS en peticiones simples ===
+Son peticiones simples aquellas cuyo método HTTP es HEAD, GET o POST con solicitudes con cabeceras como Accept, Accept-Language, Content-Type...
+El navegador enviará la cabecera Origin en la petición. la respuesta del servidor envía varias cabeceras con el prefijo Access-Control:
+  * Access-Control-Allow-Origin: Indica si están permitidas las peticiones desde el origen. Si la respuesta no incluye esta cabecera, la petición CORS fallará
+  * Access-Control-Expose-Headers: El navegador expondrá más cabeceras a tra´ves del método getResponseHeader()
+  * Access-Control-Allow-Credentials: Indica si el navegador debe exponer o no las credenciales
+=== 2.4.5.2 CORS en peticiones complejas ===
+Se consideran complejas aquellas que no son GET, HEAD o POST, como PUT o DELETE y aquellas que no usen cabeceras simples. Estas solicitudes hacen una solicitud inicial de verificación a través de método OPTIONS con las siguientes cabeceras:
+  * Access-Control-Request-Method: Indica el método que se utiliza en la petición entre dominios.
+  * Access-Control-Request-Headers: Indica la lista de cabeceras no estándar que se utilziarán en la petición
+La respuesta que envía el servidor puede incluir las siguientes cabeceras:
+  * Access-Control-Allow-Origin: Indica si están permitidas las peticiones desde el dominio origen. Esposible especifciar el valor * para permitier que cualquier dominio pueda realziar peticiones. Si esta cabecera falta, CORS fallará.
+  * Access-Control-Allow-Methods: Lista de métodos que se permiten en la petición CORS
+  * Access-Control-Allow-Headers: Lista de las cabeceras no estádnar que se permiten
+==== 2.4.6 CSRF ====
+Cross Site Request Forgery es una vulnerabilidad en la que el atacante usa el navegador de la víctima para ejecutar una petición maliciosa en su nombre sobre una web vulnerable. Al usarse el navegador de la víctima también se añade la cookie de esta, por lo que no es posible diferenciar si la víctima ejecuta la acción voluntariamente o no. Esta vulnerabilidad explota la confianza que tiene un sitio web en sus usuarios.
+===== 2.5 Exposición de Información Sensible =====
+Es una vulnerabilidad transversal relacionada con las otras vulnerabilidades. Abarca un amplio espectro desde el robo de credenciales y ataques man in the middle hasta cualquier otro tipo de caputra de información sin cifrar que pase por la red. Para obtener información sensible del sistema o del usuario se pueden usar las siguientes vulnerabilidades:
+  * Envío de información a través de comunicaciones sin cifrar
+  * Uso de algoritmos de cifrado débiles
+  * Información expuesta por la propia aplciación.
+    * Trazas de error de java
+    * Mensajes de Error SQL
+    * Mensajes de Error PHP
+    * Se puede exponer:
+      * Info de librerías o frameworks
+      * Info del sistema operativo
+      * Info sobre el sistema de ficheros
+      * Info sobre el código fuente de la app
+==== 2.5.1 Man in The Middle ====
+El atacante es capaz de itnerferir en las comunicaciones entre un cliente y un servidor, capturando los mensajes entre ambos interlocutores e incluso inyectando mensajes modificados en el canal de modificación. Con este tipo de ataque es posible ejecutar session hijacking. También puede utilizar:
+  * Sniffing: Captura de tráfico de red
+  * Sidejacking: Capturar paquetes de datos con el objetivo de obtener cookies de sesión
+  * Evil Twin: Se crea una red con el mismo nombre que una legítimas para conseguir que el usuario se conecte a esta.
+===== 2.6 Vulnerabilidades en el control de acceso =====
+Las directivas de control de acceso tienen como objetivo garantizar que los usuarios solo puedan usar las funcionalidades de las que tenga permiso. Las vulnerabilidades de este tipo suelen ser:
+  * Acceso a cuentas sin autenticación
+  * Acceso a funciones de admin desde usuarios sin permisos
+  * Acceso a recursos no permitidos
+El controlde acceso debe seguir el principio de menor privilegio (POLP), que consiste en limitar los permisos de acceso a un usuario a los mínimos posibles para que pueda usar la aplicación. Cuando no existe control de acceso, el atacante puede acceder a algunas zonas de la aplicación a las que no debería.
+==== 2.6.1 Prevención ====
+  * La política por defecto debe ser de denegación de acceso
+  * Los controles de acceso deben implementarse en el servidor
+  * Se debe imponer la propiedad de dueño para que un usuario solo pueda acceder a sus registros
+  * Se deben incluir pruebas de control de acceso
+==== 2.6.2 Directory Traversal ====
+Es una vulnerabilidad que permite a un atacante acceder a ficheros a los que no debería tener acceso. Se explota a través de la concatenación de cadenas y del uso del string "../" para conseguir acceder fuera del directorio raíz de la web. Estos ataques pueden ser mitigados de la misma forma que los ataques de inyección de código.
+===== 2.7 configuración de seguridad incorrecta =====
+Puede lelgar a ser una vulnerabildiad muy importante que peude afectar a cualquier elemento. Destacan los siguientes elementos susceptibles:
+  * Funcionalidades innecesarias habilitadas
+  * Cuentas por defecto habiltadas
+  * Páginas de error por defecto
+  * Control de acceso que permite llamadas usando métodos HTTP no controlados
+También se pueden incluir diferentes parámetros relacionados con el control de acceso:
+  * Limitar el número de sesiones por usuario
+  * Cerrar sesión tras período de inactividad
+  * Bloquear sesión tras cierto tiempo de uso
+  * Limitar el número de registros que puede devolver una consulta
+  * Separar las aplicaciones de usuarios de las de gestión.
+===== 2.8 Monitorización y Log insuficientes =====
+  * la falta de registros de log puede llevar a que no exista información sobre un ataque, dificultando la detección y corrección del problema
+  * Del mismo modo, los logs deben mostrar información clara y concisa, si el log es excesivo y/o poco claro, también resulta difícil estraer info útil.
+  * Lamacenar el log solo de forma local puede ser peligroso si el atacante se hace con el control de la máquina.
+  * Los eventos de inicio de sesión se deben guardar en el log.
+  * Los eventos de control acceso también deben alcacenarse en el log, sobre todo los sospechosos.
+  * Las transacciones relevantes también se deben guardar en el log.
+====== TEMA 3. Ciclos de desarrollo de software seguro ======
+para minimizar los riesgos de que se produzcan vulnerabildiades en el software se deben abordar los aspectos de seguridad en las primeras fases del ciclo de vida de desarrollo. El coste de encontrar vulnerabilidades en las primeras fases es muy inferiror al coste de detectarlas más tarde. El coste de un problema de seguridad puede llegar a multiplciarse por 25 desde la fase de diseño.
+===== 3.1 Secure Development Lifecycle (SDL) =====
+Estandariza un conjunto de buenas prácticas para aplicar durante el desarrollo de una aplicación.
+  * Se define una fase previa al inicio de proyecto para el training
+  * Para cada fase del ciclo de desarrollo se define una serie de tareas
+  * Define contramediadas que se depen poner en marcha cuando se porduce alguna incidencia de seguridad.
+==== 3.1.1 Fase de Formación ====
+Se debe impartir a Desarrolladores, Equipos de pruebas y jefes de proyecto. Esta formación debe ser continuada y periódica para que todos los involucrados en el proyecto estén al día de los cambios en los procedimientos.
+  * Principios de diseño seguro: reducción de la superficie de ataque, principio de menor privilegio...
+  * Modelado de amenazas (Threat Modeling): Proceso de identificar todas las posibles amenazas que pueden afectar a una aplicación
+  * Codificación de forma segura: Gestión de buffers, uso de cifrado...
+  * Pruebnas: Diferencia enrtre pruebas funcionales y pruebas de vulnerabilidades, evaluación de riesgos, pruebas de seguridad...
+  * Privacidad: identifciación de los diferentes tipos de datos confidenciales.
+==== 3.1.2 Fase de Análisis  ====
+Definición de los requisitos de seguridad
+  * Asignación de expertos
+  * cofiguración del sistema de seguimiento...
+Definición de umbrales de calidad que se espera obtener
+Modelado de casos de uso o historias de usuario relacionadas con la seguridad desde el punto de vista de un atacante
+Evaluación de riesgos identificando los elementos funcionales más críticos.
+==== 3.2.3 Fase de diseño ====
+  * Establecimiento de los requerimientos de diseño como la privacidad de los datos y la criptografía
+  * Análisis de las superficies de ataque.
+  * Modelado de las amenazas (Threats modeling): identificación de riesgos y definición de las mediads para contrarrestarlos.
+==== 3.2.4 Fase de implemetnación ====
+  * Se define un documento de buenas prácticas de implementación relacionado con ascpectos de seguridad
+  * Se determina que herramientas se utilizarán para analizar el código y para la ejecución de pruebas automáticas.
+  * Ejecución de análisis estáticos periódicos utilizando herramietnas SAST (Static Application Security Testing)
+    * Diseñadas para analizar el código fuente o compilado para encontrar problemas de seguridad.
+    * Útiles para detectar Inyeccion SQL y Desbordamiento de Buffer
+    * Salida precisa y útil.
+    * El problema es que no son capaces de detectar vulnerabildiades como problemas de unteticación, problemas de control de acceso...
+    * Pueden dar falsos positivos
+    * No detecta errores de configuración.
+    * Ejemplos de Herramientas SAST:
+      * SonarQube
+      * Find Security Bug
+==== 3.2.5 Fase de Pruebas ====
+  * revisión de código por parte de otros miembros del equipo
+  * Realización de pruebas de caja negra
+  * Realización de análisis dinámico y fuzz testing con herramientas DAST (Dynamic Aplication Security Testing). Se introducen en la aplicación datos iválidas, inesperados o aleatorios
+  * Reevaluación de las superficies de ataque
+==== 3.2.6 Fase de pentesting ====
+Son pruebas que se realizan sobre el software simulando ataques que podría realizar un hacker. Pueden ser de caja blanca (El auditor tiene toda la info sobre el sistema) o de Caja Negra (El auditor va a ciegas)
+====== Tema 4: Mecanismos de autenticación, Autorización y control de acceso ======
+{{drawio>app:Tema4DiagSec.png}}
+  * **Autenticación**: Muchas de las funcionalidades que expone el servicio requieren que el usuario de la aplicación cliente se autentique.
+    * una forma trivial de tratar la autenticación sería que el servicio ofreceiese un punto de acceso para que el usuario se autenticase
+      * Recibe Username y Password como parámetros
+      * Comprueba que las contraseñas sean correctas.
+  * **Autorización**: El punto de acceso de autenticación puede devolver un token que autoriza a la aplicación cliente a hacer peticiones al servicio en nombre del usuario.
+    * La aplicación cliente enviará dicho token como parte de cada petición que realice, pudiendose conocer la identidad del usuario y su info a través del token.
+    * El token debe ser seguro, un atacante no debe poder generar un token arbitrario válido para una aplicación que consume un servicio.
+  * **Control de acceso**: Cuando el servicio recibe una petición, su procesamiento no debe estar disponible para cualquier usuario.
+    * El control de acceso comprueba que la petición se puede ejecutar con el token de acceso.
+      * Valida el token de acceso
+        * Si la validación es correcta, la aplicación puede consumir el servicio
+      * Validar que al usuario se le permite la acción
+===== 4.1 Autenticación y Autorización =====
+==== 4.1.1 Autenticación en HTTP ====
+HTTP proporciona cabeceras estándar como Authorization para una petición y WWW-Autehnticate para la respuesta que pueden ser usadas para autenticación y autorización.
+  * **Basic**: Cuando el servicio recibe la petición solo tiene que decodificar la cadena que sigue a Basic para obtener el username y la password.
+    * OJO: estas peticiones se deben mandar en HTTPS.
+    * Si el usuario o la contraseña son incorrectos el servicio responde error 401 incluyendo la cabecera WWW-Authenticate
+    * El problema de este tipo de autenticación es que es ineficiente ya que hay que validar el usuario y contraseña cada vez que se hace una petición y recuperar sus roles de usuario.
+  * **Digest**: Ofrece un esquema más complejo que permite no enviar la contraseña en cada petición, aunque no es muy usado ya que también es bastante ineficiente
+==== 4.1.2 JSON Web Token (JWT) ====
+Define un formato compacto para obtener info JSON de forma segura entre dos partes.
+  * Base64URL: la cabecera y el cuerpo pueden contener caracteres no ASCII
+    * Los algoritmos de firma generan datos binarios
+    * Para que JWT se pueda enviar en protocolos que envían texto ASCII, JWT usa un sistema de codificación que permita codificar los textos binarios en ASCII
+  * Tipos de campos (Claims) en objetos JSON.
+    * Registrados: Están estandarizados pero no son obligatorios
+    * Públicos: Los puede definir cualquiera aunque se pueden  usar proveedores definidos por la IANA para garantizar la compatibilidad
+    * Privados: Los puede definir cualquiera. Los campos se pueden utilizar en contextos locales.
+  * Firma: Un JWT se puede firmar con un algoritmo de criptografía
+    * Con un algoritmo de criptografía simétrica la firma esun MAC, garantizando la integridad y Autenticidad
+    * Con un algoritmo de cirptografía simétrica es una firma digital, lo que garantiza el no repudio
+    * RFC 7515: JSON Web Signature (JSW)
+  * JWTs Cifrados: Si los datos enviados en un JWT son confidenciales, se deben cifrar con RFC 7516 (JSON Web Encription "JWE")
+    * El formato de los tokens cifrados consta de 5 partes separadas por "." y en base64url
+==== 4.1.3 OAuth ====
+Problemas que suelen encontrarse:
+  * Problema 1:
+    * Como obtener el token de acceso para un servicio de otro proveedor
+    * La aplicación necesita 2 tokens de acceso, uno para el backend y otro para el servicio
+    * Para obtener el segundo token no sería seguro que el servicio ofreciese una operación similar a la del backend de la aplicación
+      * El usuario tendría que teclear su usuario y contraseña en un proveedor de servicio externo
+      * La aplicación prodría quedarse con ele identificador y la contraseña del usuario.
+  * Problema 2:
+    * Una empresa dispone de mútiples aplicaciones y servicios corporativos.
+      * Sería necesario implementar un servicio para que las aplicaciones pudieran obtener tokens de acceso para acceder a los servicios que necesitan y una aplicación de gestión de aplicaciones cliente y tokens.
+    * Si no se hace nada especial, cada aplicación cliente tendría que implementar su propio formulario de autenticación.
+OAuth surge para dar solución al problema y en la práctica también resuelve el problema 2. En la actualidad está en su versión 2.0 que no es compatible con la 1.0 ya que usan protocolos distintos.
+  * Con el tiempo surgieron RFCs adicionales que complementan a OAuth 2.0 como PKCE, que se usa en aplicaciones web SPA y en aplicaciones nativas.
+  * Usando las herramientras adminsitrativas de la implementación de OAuth se debe registrar cada aplicación cliente
+    * Datos de entrada
+      * Info básica
+      * URL de redirección
+    * Datos de Salida
+      * client_id: identificador de la app
+      * client_secret: clave secreta de la app
+  * Cliente confidencial:
+    * Aquellos que pueden guardar de forma segura el client_secret
+  * Clientes públicos
+    * Aquellos que no pueden guardar de forma segura el client_secret
+    * Durante el registro no se genera el client_secret.
+=== 4.1.3.1 Flujos ===
+Para soportar distintos escenaros que difieren en el tipo de app cliente o si son o no del mismo proveedor Oauth contempla varios flujos, aunque nos centraremos en el Authorization Code, el más relevante.
+  * response_type: indica el tipo de flujo
+  * redirect_uri: El servidor de autorización, por seguridad, comprueba que el valor del redirect_uri corresponda con una de las url de redirección especificadas durante el registro del client_id
+  * scope: Especifica los permisos que solicita la aplicación cliente
+  * El formulario de autenticación puede permitir Single Sing On (SSO) con una cookie persistente para no tener que volver a autenticar el usuario en el server de autenticacion.
+  * code: Código de autorización que llega en la redirección y que el cliente tendrá que usar posteriormente para solicitar el token, tiempo de vida muy corto inferior a 10 min
+  * El servidor de autorización comprobará que el código de autorización no está caducado y que había sido generado para ese client_id y redirection_uri.
+  * La app guarda el token de acceso en la sesión.
+  * Si el cliente es púlico no se pasa la cabecera Authorization y se incluye el parámetro Client_id en el cuerpo.
+  * Token de Acceso (Access_token):
+    * Ristra de caracteres
+    * Token que usará la APP cliente para acceder al servicio
+    * Expira al poco tiempo
+    * La especificación no indica un formato concreto
+    * Puede ser no autocodificado, una ristra de caracteres no parseables. Puede usar el endpoint /introspect del server de autorización
+    * Puede ser autocodificado, una ristra de caracteres parseables. Puede ser verificado autónomamente.
+      * RFC 9068: Especifica un token en formato JWT
+  * Token de refresco (refresh_token):
+    * La aplicación cliente lo puede usar para solicitar un nuevo token de acceso al servidor de autorización cuando el token de acceso actual expira evitando volver a iniciar el flujo.
+      * Se puede hacer por anticipado o cuando recibe una respuesta de error indicando que el token actual caduco.
+    * Tiempo de vida largo
+    * Se emite solo a clientes confidenciales
+    * Para solicitar un nuevo token de acceso a partir de un token de refresco se usa el endpoint /token.
+  * Verificación de un token de acceso autocodificado
+    * para que el servidor de recursos pueda validar la firma, el token debería estar firmado con un algoritmo de criptografía simétrica.
+      * El server de autorización firma los tokens con clave privada
+      * Los servidores de recursos validan los tokens con clave pública.
+      * Si se usa un algoritmo de cirptografía simétrica, la unica clave tendrá que compartirse entre los servidores de autorización y de recursos.
+  * kid
+    * identifica de forma única la clave pública dentro de un JWK Set
+    * la cabecera de cada token generado por el servidor de autorización incluye el campo kid con el valor que identifica a la clave púlica que permite verificar la firma del token.
+  * El servidor de recursos puede verificar autónomamente los tokens que recibe en su petición.
+    * Recupera claves públicas del servidor de autorizacón GET /jawks y cachea el resultado
+    * Cada vez que recibe una petición
+      * recupera de caché la clave pública correspondiente al kid del token que viene en la petición
+      * Verifica la firma del token
+=== 4.1.3.2 PKCE ===
+El flujo antes descrito está sujeto a dos tipos de vulnerabilidades:
+  * Vulnerabilidad 1 CSRF:
+    * El atacante inicia el flujo
+    * Lo para cuando se devuelve la redirección con el código de autorización
+    * Obtiene un código de autorización válido.
+    * Envía a la víctima el enlace que se le devolvió de la redirección
+    * La victima que asumimos autenticada recibe el correo del atacante
+    * Hace click en el enlace del atacante
+    * La víctima sin saberlo inicial el flujo desde donde lo dejó el atacante.
+    * La aplicación web recibe el código de autorización del atacante y solicita un token de acceso que se almacena en la sesión web
+    * Las acciones que haga a partir de ahora la víctima se verán reflejadas en la cuenta del atacante.
+  * Vulnerabilidad 2:
+    * La víctima inicia el flujo y obtiene el código de autorización
+    * El atacante usando alguna vulnerabilidad consigue obtener el código de autorización de la víctima.
+    * Mientras no expire y no se haya usado dicho código existe una ventana de tiempo en la que el atacante puede obtener el token de acceso a partir del código de autorización de la víctima.
+    * Si el cliente es público el atacante puede pasar directamente al endpoint
+    * No pasa la cabecera Authorization e incluye el parámetro client_id
+    * El atacante puede usar el token de acceso para manejar la aplicación de la víctima.
+Oauth dispone del parámetro state para hacer frente a la vulnerabilidad 1 y la técnica PKCE protege contra ambas vulnerabilidades.
+  * PKCE protege contra la vulnerabilidad 1 por que en la sesión web de la víctima no hay un code_verifier.
+  * PKCE protege contra la vulnerabilidad 2 por que el atacante necesitaría el code_verifier de la víctima.
+==== 4.1.4 OpenID Connect ====
+Es un protocolo de autenticación y autorización consutrido por encima de OAuth, reutilizando los flujos, tokens de acceso y refresco, endpoints Authorization, troken, introspection... Lo que sería todo.
+OIDC añade las siguientes novedades:
+  * Nuevo tipo de token (id_token)
+    * Es un token en formato JWT que contiene info del usuario
+    * En el flujo de codigo de autorización, la respuesta al POST sobre el endpoint TOKEN incluye el id_token
+    * ütil cuando la aplicación del cliente quiere obtener inmediatamente info  sobre el usuario a la vez que recibe el token de acceso.
+  * Estandarización de la información acerca de un usuario
+  * Un flujo adicional
+  * Más endpoints.
+OIDC tiene los siguientes claims y scopes:
+  * Estandariza la ifnormación que se deuvelve sobre un user dentor del id_token, modelándose como claims JWT
+  * Independientemente del flujo utilizado, id_token puede contener claims standar:
+    * iss: identificador de autoridad que expide el token
+    * sub: id del usuario
+    * aud: valor del parámetro client_id
+    * exp: fecha en segundos en la que expira el token
+    * iat: fecha en segundos en la que se generó el token.
+  * La petición de autenticación o autorización en los flujos OAUT incluye el parámetro scaope, OIDC estandariza una serie de valores para el scope que conllevan la aparición de otros claims estándares en el id_token. Siempre debe contener al menos el valor openid.
+OIDC se diferencia de OAuth en que, además de ser un protocolo de autorización, también es un protocolo de autenticación.
+==== 4.1.5 SAML ====
+Security Assertion Markup Languaje es un protocolo de autenticación y autorización estandarizado por OASIS. OIDC es un rediseño conceptual de SAML en base a principios REST y JSON. La mayor parte  de los IdPs proprocionan una implementación de SAML además de OAuth/OIDC.
+  * Contempla varios escenarios de uso llamados perfiles
+  * Suele ir muy ligado al suo de Active directory y LDAP, por lo que suele usarse solo en entornos corporativos.
+  * SAML no es apto para SSO en aplicaciones nativas, aunque existen soluciones comerciales que lo permiten.
+==== 4.1.6 Kerberos y SPNEGO ====
+  * Kerberos es un protocolo de autenticación y autorización bastante complejo basado en criptografía simétrica para establecer conexión entre cliente y servidor. esta pensado para cominicación entre cliente pesado y servicio dentro de la red corporativa de una empresa.
+    * Una vez autenticado el usuario, las aplicaciones que arrancan pueden solicitar tickets (tokens) para los servicios que usan y en los que el usuario esté autorizado sin que el usuario tenga que introducir el nombre y la contraseña en cada aplicación.
+  * SPNEGO: para poder hacer uso de kerberos en aplicaciones web se unsa SPNEGO (Simple and Protected GSSAPI NEGOTIATION MECHANISM), un protocolo para que un cliente y un servicio negocien el uso de un esquema de seguridad para que ambos soporten RFC4178.
+    * Uno de los usos más habiituales de SPNEGO es el esquema negotiate de HTTP Authorization y WWW-Authenticate, que se usa par aautenticar el navegador con una aplicación web, usando kerberos como esquema de autenticación y autorización.
+==== 4.3 Control de acceso ====
+=== 4.3.1 Basado en Roles ===
+  * **Modelo RBAC (Role Based Access Control)**: Se basa en restringir la ejecución de unas operaciones de un servicio a un usuario que tenga uno o varios roles.
+    * El cliente envía una petición en nombre de un usuario e incluye con la petición algún tipo de token
+    * El servicio a recibir la petición tiene que validar el token y a partir de este averiguar los rles de usuario y comprobar si tiene los permisos necesarios para ejecutar la operación solicitada
+=== 4.3.2 Basado en Atributos ===
+Modelo ABAC (Attribute Based Access Control) hace frente a las limitaciones del modelo RBAC.
+  * Se proteje de la ejecución de una operación o acción con una política que permite o deniega en función de los atributos del sujeto que solicita la operación, el recurso sobre el que se realiza la operación y el entorno.
+    * Atributo: Par nombre/valor
+    * Sujeto: quien invoca la operación, un usuario u otro tipo de entidad
+    * Recurso: Objeto sobre el que se realiza la operación, atributos del propio recuros
+    * Entorno: Atributos como el día/hora, ubicación, dispositivo desde el que se accede...
+    * Política: Conjunto de reglas que determinan si se permite la ejecución de una operación en función de los atributos del sujeto, recursos y entorno.
+      * Se define declarativamente.
+    * ABAC busca que las principales políticas de control de acceso no estén cableadas en las aplicaciones y servicios, de forma que si se deciden variar no es necesario actualizar las aplicaciones. Las políticas las pueden editar personas diferentes a los desarrolladores.
+XACML (eXtensible Access Control Markup Languaje) es un estándar de OASIS que define un leguanje XML para la definición de políticas, una arquitectura de control de acceso y el formato de las peticiones /respuestas del PEP al PDP.

Knoppia

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página