chore: add es content (#38)

Author: gao-sun

.gitignore

@@ -130,3 +130,4 @@ build
 .strapi-cloud.json
 # generated types
 .astro
+astro_tmp_pages_*

astro.config.mjs

@@ -10,6 +10,7 @@ import { i18n, filterSitemapByDefaultLocale } from "astro-i18n-aut/integration";
 export const defaultLocale = 'en';
 export const locales = Object.freeze({
   en: 'en',
+  es: 'es',
   zh: 'zh-Hans',
   ko: 'ko',
   ar: 'ar',

src/content/terms/ar/implicit-flow.mdx

@@ -80,4 +80,4 @@ curl -X GET "https://authorization-server.com/auth" \
     },
     "https://openid.net/specs/openid-connect-core-1_0.html",
   ]}
-/>
+/>

src/content/terms/ar/pkce.mdx

@@ -1,5 +1,5 @@
 ---
-title: مفتاح إثبات تبادل الكود (Proof key for code exchange, PKCE)
+title: مفتاح إثبات تبادل الكود (Proof Key for Code Exchange, PKCE)
 tags: [oauth 2.0, oidc]
 description: مفتاح إثبات تبادل الكود (PKCE) هو امتداد أمني لـ OAuth 2.0 يحمي رموز التفويض من الاعتراض وسوء الاستخدام. يتم تطبيقه لجميع أنواع العملاء في OAuth 2.1.
 ---

src/content/terms/es/abac.mdx

@@ -0,0 +1,113 @@
+---
+title: Control de acceso basado en atributos (Attribute-based access control, ABAC)
+tags: [authorization]
+description: El control de acceso basado en atributos (ABAC) es un modelo de control de acceso que utiliza atributos (como roles de usuario, propiedades de recursos y condiciones ambientales) para tomar decisiones de control de acceso. Es una forma flexible y dinámica de gestionar el acceso a recursos protegidos.
+---
+
+## ¿Qué es el control de acceso basado en atributos (ABAC)?
+
+ABAC es un modelo de <Ref slug="access-control" /> que utiliza atributos para tomar decisiones de control de acceso. Estos atributos pueden incluir varios factores, como:
+
+- Atributos de usuario: por ejemplo, roles, departamento, ubicación, etc.
+- Atributos de recursos: por ejemplo, nivel de sensibilidad, propietario, tipo, etc.
+- Atributos ambientales: por ejemplo, hora de acceso, ubicación, dispositivo, etc.
+
+Al evaluar estos atributos y ejecutarlos a través de un conjunto de reglas, ABAC puede determinar si un sujeto (por ejemplo, usuario, servicio) debe tener acceso a un recurso. Este enfoque permite un control de acceso detallado y una aplicación dinámica de políticas basadas en el contexto.
+
+## ¿Cómo funciona el ABAC?
+
+ABAC utiliza un enfoque basado en políticas para el control de acceso. Una política ABAC típica consta de:
+
+- **Subject**: La entidad que solicita acceso (por ejemplo, usuario, servicio, dispositivo).
+- **Action**: La operación que se realiza en el recurso (por ejemplo, leer, escribir, eliminar).
+- **Resource**: La entidad a la que se accede (por ejemplo, archivo, base de datos, API).
+- **Environment**: El contexto en el que se solicita el acceso (por ejemplo, hora, ubicación, dispositivo).
+- **Attributes**: Las propiedades del sujeto, recurso y entorno que se evalúan para tomar decisiones de acceso.
+- **Policies**: Un conjunto de reglas que definen las condiciones bajo las cuales se concede o se niega el acceso.
+
+Las políticas ABAC son más complejas que los modelos de control de acceso tradicionales como <Ref slug="rbac" />. Por otro lado, ABAC proporciona más flexibilidad y granularidad en las decisiones de control de acceso.
+
+### Ejemplo de políticas ABAC
+
+Por ejemplo, un sistema tiene varias políticas ABAC:
+
+1. **Política 1**: Permitir el acceso si:
+
+    - (Subject) El rol del sujeto es `manager`.
+    - (Attribute) El nivel de sensibilidad del recurso es `high`.
+    - (Environment) La ubicación es `internal`.
+    - (Action) Cualquier acción.
+    - (Environment) El tiempo es entre las 9 AM y las 5 PM (horas de oficina).
+
+2. **Política 2**: Denegar el acceso si:
+
+    - (Subject) El rol del sujeto no es `manager`.
+    - (Attribute) El nivel de sensibilidad del recurso es `high`.
+    - (Environment) Cualquier ubicación.
+    - (Action) Cualquier acción.
+    - (Environment) Cualquier momento.
+
+3. **Política 3**: Permitir el acceso si:
+
+    - (Subject) El rol del sujeto es `employee` o `manager`.
+    - (Attribute) El nivel de sensibilidad del recurso es `low`.
+    - (Environment) Cualquier ubicación.
+    - (Action) Acción `read`.
+    - (Environment) Cualquier momento.
+
+El motor de evaluación de políticas verificará estas políticas en orden, y la primera política que coincida con las condiciones determinará la decisión de acceso. Mientras tanto, se aplica una política de denegación predeterminada si ninguna otra política coincide.
+
+Veamos algunos escenarios para entender cómo funciona el ABAC:
+
+> **Escenario 1**. Un usuario quiere acceder (realizar la acción `read`) a un documento de alto nivel de sensibilidad (recurso) fuera de la oficina (entorno). El usuario tiene el rol de `manager` almacenado en el sistema.
+  
+**Decisión**: El acceso se niega porque el usuario está fuera de la oficina (la ubicación no es `internal`).
+
+> **Escenario 2**. Un usuario quiere acceder (realizar la acción `read`) a un documento de alto nivel de sensibilidad (recurso) durante las horas de oficina (entorno) en la red de la oficina (ubicación=`internal`). El usuario tiene el rol de `manager`.
+
+**Decisión**: El acceso se concede porque se cumplen todas las condiciones de la Política 1.
+
+> **Escenario 3**. Todas las condiciones en el escenario 2 son las mismas, pero el usuario tiene el rol de `employee` en lugar de `manager`.
+
+**Decisión**: El acceso se niega porque el rol del usuario no coincide con las condiciones de la Política 1.
+
+> **Escenario 4**. Un usuario quiere acceder (realizar la acción `read`) a un documento de bajo nivel de sensibilidad (recurso). El usuario tiene el rol de `employee`.
+
+**Decisión**: El acceso se concede porque se cumplen todas las condiciones de la Política 3.
+
+> **Escenario 5**. Un usuario quiere eliminar (realizar la acción `delete`) un documento de bajo nivel de sensibilidad (recurso). El usuario tiene el rol de `employee`.
+
+**Decisión**: El acceso se niega porque no hay ninguna política que permita la acción `delete` en documentos de bajo nivel de sensibilidad.
+
+Podrás notar que no se requieren todos los atributos en cada política. Esta flexibilidad permite un mecanismo de control de acceso más dinámico y consciente del contexto.
+
+## Consideraciones de implementación
+
+Si bien el ABAC ofrece una forma poderosa de gestionar el control de acceso, también presenta algunas consideraciones de implementación:
+
+- Complejidad del sistema: Las políticas ABAC pueden volverse complejas a medida que aumenta el número de atributos y reglas. La gestión y prueba adecuada de políticas son más laboriosas que los modelos de control de acceso más simples.
+- Rendimiento: Evaluar políticas ABAC complejas puede afectar el rendimiento del sistema. Las técnicas de almacenamiento en caché y optimización pueden ayudar a mitigar este problema.
+- Conflictos de políticas: Las políticas en conflicto pueden llevar a decisiones de acceso impredecibles. La revisión periódica de políticas y la resolución de conflictos deben ser parte del proceso de gestión de políticas.
+
+## ABAC vs. RBAC
+
+Comparar ABAC con <Ref slug="rbac" /> puede ayudarte a comprender las diferencias entre los dos modelos:
+
+|                       | RBAC                               | ABAC                                     |
+|-----------------------|------------------------------------|------------------------------------------|
+| Política de control de acceso | Basada en roles                       | Basada en atributos                      |
+| Granularidad          | Gruesa                             | Fina                                     |
+| Flexibilidad          | Limitada                           | Muy flexible                             |
+| Complejidad           | Más simple                         | Más compleja                             |
+| Impacto en el rendimiento | Mínimo                             | Puede ser significativo                  |
+| Gestión de acceso     | Gestión de roles                   | Gestión de políticas                     |
+| Mejor para            | Estructuras de permisos bien definidas | Control de acceso dinámico y consciente del contexto |
+
+<SeeAlso slugs={["access-control", "rbac", "authorization"]} />
+
+<Resources
+  urls={[
+    "https://blog.logto.io/rbac-and-abac",
+    "https://csrc.nist.gov/publications/detail/sp/800-162/final",
+  ]}
+/>

src/content/terms/es/access-control.mdx

@@ -0,0 +1,88 @@
+---
+title: Control de acceso (Access control)
+tags: [authorization]
+description: El control de acceso es la restricción de quién puede realizar qué acciones sobre ciertos recursos en un sistema. Es un mecanismo de seguridad fundamental para definir y hacer cumplir políticas de acceso.
+---
+
+## ¿Qué es el control de acceso (Access control)?
+
+El control de acceso (Access control) involucra tres componentes principales:
+
+- **Sujeto**: Una entidad que realiza acciones sobre recursos. Los sujetos pueden ser usuarios, servicios o dispositivos.
+- **Recurso**: Una entidad que está protegida por el control de acceso. Los recursos pueden ser archivos, bases de datos, APIs u otros activos digitales.
+- **Acción**: Una operación que un sujeto puede realizar sobre un recurso. Las acciones pueden ser leer, escribir, ejecutar u cualquier otra operación.
+
+```mermaid
+graph LR
+    A(Sujeto) -->|Realiza acciones sobre| B(Recurso)
+```
+
+> El control de acceso (Access control) define la restricción selectiva de acceso a **recursos** basada en el **sujeto** y la **acción**.
+
+Aquí hay algunos ejemplos del mundo real de control de acceso (Access control):
+
+- Un usuario (sujeto) **puede** leer (acción) sus pedidos (recurso) en un sistema de comercio electrónico.
+- Un usuario (sujeto) **no puede** eliminar (acción) el perfil de otro usuario (recurso) en una red social.
+- Un servicio (sujeto) **puede** escribir (acción) datos en una base de datos (recurso) en una arquitectura de microservicios.
+
+A veces, el recurso se ignora en implementaciones técnicas y el control de acceso (Access control) se define como la restricción de quién (sujeto) puede realizar qué acciones. Por ejemplo, el marco básico de OAuth 2.0 solo especifica acciones utilizando scopes (permisos) y no define recursos.
+
+El soporte para el control de acceso (Access control) puede variar dependiendo del <Ref slug="authorization-server" /> o el <Ref slug="identity-provider" />. Algunos sistemas pueden soportar [Resource Indicators for OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc8707), una extensión de OAuth 2.0 que permite a los clientes especificar los recursos a los que desean acceder.
+
+## Modelos de control de acceso (Access control) ||access-control-models||
+
+Decidir restricciones entre unos pocos sujetos y recursos es simple, pero no escalable. Por lo tanto, la industria ha desarrollado muchos modelos de control de acceso (Access control) para gestionarlo de manera efectiva. En el contexto de <Ref slug="iam" />, los siguientes son algunos modelos comunes de control de acceso (Access control):
+
+- <Ref slug="rbac" />: Un modelo que asigna permisos a roles y luego asigna roles a sujetos. Por ejemplo, un rol de administrador podría tener acceso a todos los recursos, mientras que un rol de usuario podría tener acceso a recursos limitados.
+- <Ref slug="abac" />: Un modelo que utiliza atributos (propiedades) del sujeto, recurso y entorno para tomar decisiones de control de acceso (Access control). Por ejemplo, un usuario con el atributo "departamento=ingeniería" podría tener acceso a recursos de ingeniería.
+
+También existen otros modelos de control de acceso (Access control) como [control de acceso basado en políticas (PBAC)](https://csrc.nist.gov/glossary/term/policy_based_access_control). Cada modelo tiene sus propias fortalezas y debilidades, y la elección del modelo depende de tu caso de uso y requisitos.
+
+## Control de acceso (Access control) en OAuth 2.0
+
+En el contexto de OAuth 2.0, el control de acceso (Access control) se implementa típicamente usando <Ref slug="scope">scopes</Ref>. Normalmente, el valor de un scope es una cadena que combina el recurso y la acción. Por ejemplo, `read:orders` o `write:profile`.
+
+> [!Note]
+> El término "scopes" es intercambiable con "permissions" en la mayoría de los casos.
+
+Vale la pena destacar que OAuth 2.0 no define la estructura y el significado de los scopes. La interpretación de los scopes se deja al <Ref slug="resource-server" />, y la emisión de scopes se deja al <Ref slug="authorization-server" />.
+
+Por ejemplo, un usuario (sujeto) necesita acceder a sus pedidos (recurso) en un sistema de comercio electrónico. Al aprovechar OAuth 2.0, puedes definir un scope `read:orders` y una aplicación web (cliente) solicitará este scope desde el servidor de autorización. Aquí hay un flujo simplificado:
+
+```mermaid
+sequenceDiagram
+    participant Usuario
+    participant Cliente
+    participant Authorization Server
+    participant Resource Server
+
+    Usuario->>Cliente: Acceder a la página "Mis Pedidos"
+    Cliente->>Authorization Server: Solicitar access token con scope `read:orders`
+    Authorization Server->>Cliente: Emitir access token
+    Cliente->>Resource Server: Acceder a pedidos con access token
+    Resource Server->>Cliente: Enviar pedidos
+    Cliente->>Usuario: Mostrar pedidos
+```
+
+En este flujo, dependiendo de la arquitectura técnica, el servidor de recursos puede ser un servicio API o puede ser el cliente (aplicación web) en sí, siempre y cuando tenga la capacidad de acceder al recurso (pedidos).
+
+### El parámetro de indicador de recurso (resource indicator)
+
+Aunque las personas a menudo definen scopes con recurso y acción (por ejemplo, `read:orders`, donde `orders` es el recurso y `read` es la acción), la escalabilidad de este enfoque es limitada cuando la cantidad de recursos y acciones crece. RFC 8707 introduce el parámetro `resource` (es decir, <Ref slug="resource-indicator">indicadores de recurso</Ref>) a OAuth 2.0, lo que permite a los clientes especificar los recursos a los que desean acceder.
+
+El RFC especifica que el parámetro `resource` debe ser un URI que represente el recurso. Por ejemplo, en lugar de simplemente usar `orders`, podrías usar `https://api.example.com/orders`. Este método ayuda a evitar conflictos de nombres y mejora la precisión de la coincidencia de recursos al permitir el uso de la URL real del recurso.
+
+### Soporte del servidor de autorización (authorization server)
+
+OAuth 2.0 no define cómo debe llevar a cabo el control de acceso (Access control) el servidor de autorización (authorization server). Deja los detalles de implementación a discreción del servidor de autorización (authorization server). Por lo tanto, la elección del servidor de autorización puede afectar en gran medida el mecanismo de control de acceso (Access control). Por ejemplo, algunos servidores de autorización pueden soportar indicadores de recurso, mientras que otros no. Es importante decidir qué modelo de control de acceso (Access control) utilizar en función de tus requisitos empresariales y luego elegir un servidor de autorización que soporte ese modelo. Si no estás seguro sobre el modelo de control de acceso (Access control), <Ref slug="rbac" /> es suficiente para la mayoría de los casos.
+
+<SeeAlso slugs={["rbac", "abac", "resource-indicator", "authorization"]} />
+
+<Resources
+  urls={[
+    "https://blog.logto.io/mastering-rbac",
+    "https://blog.logto.io/rbac-and-abac",
+    "https://datatracker.ietf.org/doc/html/rfc8707",
+    "https://blog.logto.io/organization-and-role-based-access-control",
+  ]}
+/>