B2C Admin & Validation API's¶
Admin & Validation son API's utilizadas en el proceso de autenticación cuando se usa Azure B2C.
- Validation: Utilizada dentro de los flujos de Azure B2C para obtener información extra de usuario para una aplicación en particular.
- Admin: Utilizada para realizar la administración de la información almacenada de los usuarios por aplicación, la información por usuario es almacenada en 2 colecciones de MongoDB.
API de autenticación:¶
Está integrada en el flujo de login de Azure B2C. Al realizar la autenticación Azure B2C realiza un post al endpoint /authenticate enviando un body con el usuario y el application id.
{
"username": "usuario@dominio.com",
"appId":"a69523f3-c37a-46ec-814f-f9ebc46ad76"
}
{}
No se encontró el Usuario usuario@dominio.com en la App a69523f3-c37a-46ec-814f-f9ebc46ad76
En caso de encontrar un match devolverá un objeto raw con las propiedades definidas en el documento de MongoDB.
{
"raw": {
"loyaltyID": "87941",
"promoCode": "RCT876",
"nuevaPropiedad": 159
}
}
Cuando la autenticación la realiza B2C la API de validación insertara en el token de respuesta el valor raw
{
"typ": "JWT",
"alg": "RS256",
"kid": "n2seygU0a7RBGdOp9HQJwqjaK7OUKnqgtadIF6QbWWE"
}.{
"exp": 1612890235,
"nbf": 1612883035,
"ver": "1.0",
"iss": "https://andreanib2cdev.b2clogin.com/226a3c28-81b4-4606-9a63-040f553bb647/v2.0/",
"sub": "d3ab8d27-c9e3-49ba-9c3d-5d4d63dc2fbd",
"aud": "27ed4d41-a049-46a8-b9e7-873f80786ac7",
"nonce": "defaultNonce",
"iat": 1612883035,
"auth_time": 1612883035,
"signInNames.emailAddress": "l@prisma.cc",
"name": "Leandro Amore",
"given_name": "Leandro",
"family_name": "Amore",
"raw": "{\r\n \"promCode\": \"7887788\"\r\n}",
"tid": "226a3c28-81b4-4606-9a63-040f553bb647"
}.[Signature]
{
"typ": "JWT",
"alg": "RS256",
"kid": "n2seygU0a7RBGdOp9HQJwqjaK7OUKnqgtadIF6QbWWE"
}.{
"exp": 1612888906,
"nbf": 1612881706,
"ver": "1.0",
"iss": "https://andreanib2cdev.b2clogin.com/226a3c28-81b4-4606-9a63-040f553bb647/v2.0/",
"sub": "d3ab8d27-c9e3-49ba-9c3d-5d4d63dc2fbd",
"aud": "27ed4d41-a049-46a8-b9e7-873f80786ac7",
"nonce": "defaultNonce",
"iat": 1612881706,
"auth_time": 1612881706,
"signInNames.emailAddress": "l@prisma.cc",
"name": "Leandro Amore",
"given_name": "Leandro",
"family_name": "Amore",
"tid": "226a3c28-81b4-4606-9a63-040f553bb647"
}.[Signature]
API de administración¶
La API de administración sólo es accesible internamente y permite gestionar y consultar los documentos de MongoDB, para consultar los endpoints se debe utilizar un header de autenticación X-API-Key
Los endpoints disponibles son:
ListApps¶
Método: GET
Endpoint: /users/{username@dominio.com}/apps
Código de respuesta: 200
El endpoint devolverá un json con todas las aplicaciones en donde el usuario se encuentra registrado, en el usuario inició sesión usando el método /authenticate la respuesta incluirá el último login.
[
{
"appId": "a69523f3-c37a-46ec-814f-f9ebc46ad761",
"lastLogon": 1612875324081
},
{
"appId": "2feb4a4e-92e9-4101-8e57-5036f3897707"
}
]
[]
Paginación¶
Puedes utilizar la paginación para obtener resultados parciales de las aplicaciones del usuario. Para ello, debe incluir los siguientes headers en tu solicitud:
X-page: Especifica el número de página que deseas obtener.X-size: Especifica el tamaño de la página, es decir, la cantidad de aplicaciones que deseas obtener por página.
Ten en cuenta que si no se proporcionan los headers de paginación, se devolverán todos los resultados en una única respuesta. Si hay más resultados disponibles, la respuesta incluirá información adicional para realizar la paginación.
GetClaims¶
Método: GET
Endpoint: /users/{username@dominio.com}/apps/{AppId}
Código de respuesta: 200
El endpoint devolverá un json con las propiedades definidas en el documento de MongoDB
{
"loyaltyID": "87941",
"promoCode": "RCT876",
"nuevaPropiedad": 159
}
{
"type": "about:blank",
"title": "No se encontró el mapping",
"status": 404
}
No se encontró el Usuario usuario@dominio.com en la App a69523f3-c37a-46ec-814f-f9ebc46ad76
UpdateInfo¶
Método: POST
Endpoint: /users/{username@dominio.com}/apps/{AppId}
Código de respuesta: 201
BODY:
{
"loyaltyID": "87941",
"promoCode": "RCT876",
"nuevaPropiedad" : 159
}
Si el update se realiza sobre un documento existente la respuesta será un código http 200, en caso de que el request genere un documento nuevo la respuesta será un código 201. Si el request contiene un body con errores el código http será un 400 con el siguiente body
{
"type": "about:blank",
"title": "En body debe ser un JSON válido",
"status": 400
}
DeleteUserInfo¶
Método: DELETE
Endpoint: /users/{username@dominio.com}/apps/{AppId}
Código de respuesta: 200
En caso de no encontrar el usuario o la app devolverá un codigo http 400 y el detalle en el body
{
"type": "about:blank",
"title": "No se encontró el mapping",
"status": 400
}
GetUsersByApps¶
Método: GET
Endpoint: /apps/{AppId}/users
Código de respuesta: 200
QueryParams: domain
Este método devuelve a todos los usuarios para un AppId, en caso de asignar un dominio en el parametro domain, se filtrara por este.
Respuesta
[
{
"username": "lolivera@andreani.com",
"data": {
"rol": "admin",
"permissions": [
"read",
"write",
"admin"
]
}
}
]
GetUsersByAppsFilters¶
Método: POST
Endpoint: /apps/{AppId}/users
Código de respuesta: 200
Body:
{
"jsonData.rol" = "usuario"
}
UpdateUserBatch¶
Método: PUT
Endpoint: /apps/{AppId}/users
Este endpoint permite enviar una solicitud PUT para actualizar un lote de usuarios.
El cuerpo de la solicitud debe seguir la siguiente estructura:
[
{
"username": "string",
"data": "string"
},
{
"Username": "nombre de usuario 1",
"Data": {
// Datos de actualización para el usuario 1
}
},
{
"Username": "nombre de usuario 2",
"Data": {
// Datos de actualización para el usuario 2
}
}
]
El código de respuesta 200 indica que la solicitud se ha procesado correctamente y los usuarios se han actualizado con éxito.
[
{
"username": "string",
"jsonData": "string"
}
]
En caso de encontrar un error, se devolverá un código HTTP 400 junto con el siguiente detalle en el cuerpo de la respuesta:
[
{
"code": "string",
"property": "string",
"message": "string"
}
]
El método UpdateUserBatchHandler se encarga de manejar la lógica de actualización de usuarios en lotes, utilizando el identificador de la aplicación y los datos de actualización proporcionados en el cuerpo de la solicitud.
MongoDB (DB: APIClaimsb2cDB)¶
La información almacenada se divide en 2 tipos de colecciones. Una colección llamada users que responde al siguiente esquema:
{
"properties": {
"_id": { "bsonType": "objectId" },
"username": { "bsonType": "string" },
"apps": {
"type": "array",
"items" : {
"type" : "object",
"properties" : {
"appId": { "bsonType":"string"},
"appName": { "bsonType":"string"},
"lastLogon": { "bsonType":"long"}
}
}
}
}
}
Luego tenemos una colección por applicationId que generalmente es un GUID como el siguiente a2d64249-d82a-44b9-aaf2-952653aaf3ca, estas colecciones responden al siguiente esquema:
{
"properties": {
"_id": { "bsonType": "objectId" },
"username": { "bsonType": "string" },
"jsonData": {
"type": "object",
"properties" : {
"key1": { "bsonType":"string"},
"key2": { "bsonType":"string"}
}
}
}
}
Las propiedades dentro de jsonData son dinámicas y representan a un diccionario clave-valor, donde se podrán almacenar los valores aleatorios propios de cada aplicación. El contenido de este campo es el valor devuelto por la Validation Api, y el mismo es agregado al token retornado por Azure B2C.