Saltar al contenido principal
Un socio puede llamar a Midaz con su propia credencial. En Midaz, restringes esa credencial a una organización y, si quieres, a algunos elementos dentro de ella. Esta página muestra cómo elegir ese ámbito, qué alcanza cada opción y qué recibe el socio cuando sale de él. Todo socio de Midaz necesita un ámbito. La organización siempre es obligatoria.

​
Paso a paso

1

Elige dónde actúa el socio

Elige el ámbito más estrecho que cubra lo que el socio necesita. Cada fila es una restricción que puedes agregar. El campo en la API es el field de una entrada de ámbito; la Console muestra el nombre de la primera columna.El catálogo de ámbito lista todas las restricciones de Midaz, incluidas las que no están en esta tabla. Léelo con Consultar el catálogo de ámbito de un producto para midaz.Algunas reglas valen para todo ámbito:
  • Una solicitud que no nombra un elemento de un tipo restringido se rechaza cuando actúa sobre lo que esa restricción limita. Por ejemplo, un socio restringido a algunos ledgers no puede listar todos los ledgers de su organización. Una solicitud fuera de lo que la restricción limita solo necesita la organización.
  • Una solicitud que lista varios valores, como varios alias en un cuerpo o en una query, se rechaza cuando cualquiera de ellos está fuera del ámbito.
  • Las rutas que actúan sobre todo el tenant, como listar organizaciones o leer la configuración del tenant, se rechazan a todo socio.
2

Da al socio sus permisos y su ámbito

Crea el socio, o cámbialo, en la Console o con la API de Identity. El identificador del producto es midaz.
  • Agrega la entrada de ámbito de la organización, con exactamente un valor. Sin ella, Access Manager rechaza el socio con 400 y IDE-0001. Con dos organizaciones, rechaza con IDE-0002.
  • Agrega las otras restricciones que elegiste en el paso 1.
  • Marca los recursos y las acciones. Lo máximo que puedes dar es lo que el rol midaz-editor-role tiene en tu tenant. Por encima de eso, Access Manager rechaza con IDE-1043.
Access Manager verifica cada escritura que das contra el ámbito:
  • Una escritura que actúa sobre todo el tenant, como crear una organización, nunca se da a un socio.
  • Una escritura que actúa por encima del ámbito del socio se rechaza. Por ejemplo, un socio restringido a un ledger no puede recibir el derecho de crear, cambiar o eliminar ledgers, titulares, o rutas de operación y de transacción: esas escrituras actúan sobre toda la organización.
  • Los dos rechazos responden 400 con IDE-1056. La Console marca la línea como Outside the scope.
Para dar lectura de las rutas de operación o de transacción, lista los IDs de las rutas en el ámbito. Sin ellos, Access Manager rechaza el socio con 400 y IDE-1052. Access Manager no verifica que el ID de una ruta pertenezca al ledger del socio: el socio lee toda ruta cuyo ID listas. Lista solo las rutas de sus propios ledgers.No des transactions con post a un socio restringido solo por cartera, segmento o titular. Access Manager lo acepta, pero toda transacción de ese socio se rechaza.
3

Crea su aplicación de Midaz

Crea la aplicación del socio con el producto midaz. Consulta cómo crear las aplicaciones del socio en la guía de la API o en la Console. Envía el client ID y el client secret al socio por un canal seguro.
4

Indica al socio cómo nombrar sus elementos

El socio nombra sus elementos en los paths, queries y cuerpos que Midaz ya tiene. No se envía nada extra. Estos casos requieren atención:
  • Cuentas filtradas por cartera, segmento o titular. Envía portfolio_id, segment_id o holder_id en la query de la lista de cuentas.
  • Cuentas de un titular. Envía ledger_id en la query, con un ledger dentro del ámbito. La respuesta trae solo las cuentas de ese ledger.
  • Cuentas nuevas. Un socio restringido por cartera o segmento envía su propio portfolioId o segmentId en el cuerpo. Un socio restringido por cuenta envía una de sus propias cuentas en parentAccountId.
  • Transacciones en las rutas /v2/transactions (direct, hold, block, unblock y batch). Cada débito y cada crédito nombra una organización y un ledger dentro del ámbito. Un socio restringido por alias solo puede usar sus propios alias en los dos lados, así que solo mueve dinero entre sus propias cuentas.
  • Transacciones en las rutas de ledger de /v1 (json, outflow, annotation, block y unblock). Los alias de origen en send.source.from[].accountAlias deben ser del socio.
En las rutas de transacción de /v1, solo se verifican las cuentas de origen. Un socio restringido por alias puede enviar dinero desde sus propios alias a cualquier cuenta de su ledger. Para mantenerlo entre sus propias cuentas, dale solo las rutas /v2/transactions, o no le des transactions con post.
Un socio restringido por cuenta o alias no puede usar estas rutas de transacción: inflow en /v1, y confirmar, cancelar, revertir, cambiar, leer por ID o listar. Puede crear una retención, pero no puede confirmarla ni cancelarla. Un socio restringido por ID de cuenta no puede crear transacciones en las rutas de /v1. Para que mueva dinero desde cuentas específicas, restríngelo por alias.
5

Confirma que funciona

Esta verificación supone que el socio tiene el recurso accounts con la acción get en Midaz, y un ámbito restringido a una organización y a uno o más de sus ledgers. Usa la credencial del socio. Lista las cuentas de un ledger dentro de su ámbito. La respuesta es 200:
Envía la misma solicitud con un ledger de la misma organización que está fuera del ámbito. La respuesta es 403 con el código AUT-1020.

​
Si algo falla

La respuesta no indica si fueron los permisos o el ámbito los que rechazaron la solicitud. Es intencional: un socio no puede usar un rechazo para saber qué elementos existen fuera de su ámbito. Para todos los demás códigos, consulta la lista de errores de Midaz. Para los rechazos al crear o cambiar un socio, consulta los códigos de error de la guía de la API.