Socios

Un socio es uno de tus propios clientes que llama a tu plataforma Lerian desde sus propios sistemas. Access Manager permite dar a cada socio credenciales propias. Tú decides qué puede hacer el socio, en qué parte de tus datos, desde qué direcciones de red y por cuánto tiempo. Piensa en un edificio con muchas oficinas. Tú eres el dueño y tienes todas las llaves. Un socio recibe una credencial que abre solo las puertas que eliges, funciona solo en el horario que defines y deja de funcionar en el momento en que la cancelas.

​

Por qué segregar el acceso

---

Cuando varios clientes llaman a tu plataforma, una credencial compartida da a cada uno de ellos el acceso de todos. Los socios reemplazan eso por un conjunto de límites para cada cliente:

• Mínimo privilegio. Cada socio recibe solo las acciones y los datos que necesita, y nada por encima de lo que tu propio equipo puede hacer.
• Credenciales por socio. Cada socio tiene sus propias credenciales. Puedes revocar un socio sin tocar a los demás.
• Revocación inmediata. Suspender un socio, o llegar al fin de su ventana de validez, rechaza su siguiente solicitud, incluso con un token que ya tiene.
• Restricción de red. Un socio solo puede llamar desde las direcciones que listas para él.
• Ventanas de validez. El acceso puede empezar y terminar en las fechas que eliges. Un piloto que termina en una fecha no necesita un recordatorio para apagarse.
• Responsabilidad clara. Cada solicitud lleva la credencial del propio socio, así que cada acción apunta a un único socio.

​

Los bloques de construcción

---

Un tenant contiene organizaciones, y una organización contiene ledgers. Un socio es un registro del tenant, y las filas que lo siguen describen lo que recibe un socio.

​

Cómo encajan las piezas

---

El tenant es un límite rígido. Los datos de tu tenant de staging nunca se mezclan con los datos de tu tenant de producción. Dentro de un tenant, las organizaciones y los ledgers separan tus datos de forma lógica: Access Manager usa el ámbito de cada socio para mantener a cada socio dentro de su propia parte.

• Tenant: Producción. Tu tenant de staging es otro, separado.
  • Organización Norte
    • Ledger N1. El Socio A escribe cuentas y transacciones aquí.
    • Ledger N2
      • Cuentas 1 y 2. El Socio C lee solo estas dos cuentas.
  • Organización Sur. El Socio B lee la organización entera, por 90 días.
    • Ledger S1
    • Ledger S2

Los tres socios viven en el mismo tenant. Ninguno de ellos ve la parte de otro.

​

Ejemplo: tres socios en un tenant

---

Tu empresa usa un tenant por entorno. El tenant de producción tiene dos organizaciones de Midaz, Norte y Sur. Tres de tus clientes necesitan acceso a la API.

​

Socio A: escribe en un ledger, desde una dirección

Tampoco puedes dar al Socio A el derecho de crear ledgers. Crear un ledger actúa sobre toda la organización, que es más amplia que un ledger. Access Manager rechaza ese cambio con IDE-1056, y Console muestra la línea como “Outside the scope”.

​

Socio B: lee una organización entera por 90 días

​

Socio C: lee dos cuentas y después se suspende

​

Cómo se decide una solicitud

---

Las verificaciones de abajo se ejecutan en cada solicitud que la credencial de un socio envía a un producto. Se ejecutan en este orden, y la primera que falla detiene la solicitud.

1. Token. El sistema del socio cambia su client ID y su client secret por un token de acceso, y envía el token con la solicitud.
2. Socio. Access Manager encuentra el socio al que pertenece la credencial.
3. Dirección de red. Access Manager compara la dirección de quien llama con la lista propia del socio. Un socio sin lista propia usa la lista de tu tenant. Un rechazo devuelve 403 con AUT-0021.
4. Estado y validez. Un socio suspendido, o fuera de su ventana de validez, se rechaza con 401: AUT-1009 si está suspendido, AUT-1010 si está fuera de la ventana.
5. Permisos. El producto, el recurso y la acción deben estar en los permisos del socio. Un rechazo devuelve 403.
6. Ámbito. La organización, el ledger, la cuenta u otro elemento que nombra la solicitud debe estar dentro del ámbito del socio. Un rechazo devuelve 403.
7. Si todas las verificaciones pasan, el producto ejecuta la solicitud.

El producto no dice a quien llama si fueron los permisos o el ámbito los que rechazaron la solicitud. Los dos devuelven el mismo 403, así que un socio no puede usar los rechazos para descubrir qué elementos existen fuera de su ámbito.

​

Lo que necesitas saber

---

• Los permisos y el ámbito deben coincidir los dos. Un socio alcanza solo lo que ambos permiten. No se pueden guardar permisos sin ámbito en un producto con una restricción obligatoria.
• La suspensión y el fin de la ventana de validez se aplican al instante. La siguiente solicitud del socio se rechaza, incluso con un token que ya tiene. Un socio suspendido tampoco puede obtener tokens nuevos.
• Cualquier otro cambio se aplica desde la siguiente solicitud. Eso incluye permisos nuevos, un ámbito más estrecho y una nueva lista de IP permitidas.
• Un socio nunca recibe más de lo que tiene tu tenant. El techo es lo que tiene el rol de editor del producto en tu tenant. Si ese rol pierde un permiso después, el socio también lo pierde.
• Access Manager no verifica que los IDs del ámbito existan en el producto. Guarda los IDs que ingresas. Cópialos de la propia API o de Console del producto.
• Un producto que se muestra como “isn’t ready for partners yet” todavía no publicó su lista de restricciones. No puedes dar a un socio acceso a ese producto hasta que la publique.
• Una solicitud que deja fuera un elemento que el ámbito restringe se rechaza. Por ejemplo, un socio restringido a algunos ledgers no puede listar todos los ledgers de la organización.
• Un socio con aplicaciones no se puede eliminar. Elimina primero sus aplicaciones. Para pausar un socio, suspéndelo. La suspensión es reversible; la eliminación no.
• La lista de IP permitidas propia de un socio reemplaza la lista de tu tenant. No se suma a ella. Una dirección que está solo en la lista de tu tenant no funciona para ese socio. La lista del socio se aplica incluso cuando la lista de tu tenant está apagada.

​

Productos que aceptan socios

---

Cada producto declara, en su manifiesto de permisos, qué restricciones acepta: por ejemplo organización, ledger, cuenta, portafolio o segmento. Hoy Midaz (el ledger) y Tracer aceptan socios. Midaz exige una organización para cada socio y acepta restricciones opcionales en ledgers, cuentas, alias de cuenta, activos, portafolios, segmentos, titulares y otros elementos. Tracer acepta restricciones opcionales en reglas, límites, validaciones de transacciones, cuentas, portafolios, segmentos y comercios.

​

Próximos pasos

---