Utilisation des autorisateurs AWS Lambda

Le flux d'authentification comprend les étapes suivantes :

1. Requête HTTP avec jeton Bearer vers le point de terminaison DICOMweb

2. AWS HealthImaging vérifie l'expiration des jetons

3. Transférer la demande à l'autorisateur Lambda

4. Lambda valide le jeton auprès du fournisseur d'identité (IdP)

5. Lambda renvoie le rôle IAM

6. Évaluation des politiques et authentification des utilisateurs terminées

Prérequis

1. Configuration de l'autorisateur Lambda

• Créez un autorisateur qui accepte AuthInput et renvoie AuthResult

• Validation BearerToken (signature, expiration, champs d'application, émetteur et règles commerciales)

• Renvoie l'ARN du rôle IAM avec les autorisations d' DICOMweb opération requises

• Doit répondre dans un délai inférieur ou égal à 1 seconde (configurer la simultanéité provisionnée)

Implémentez l'extraction de jetons :

// in Node.js
export const handler = async (event) => {
  try {
    const token = event.bearerToken;
    const operation = event.operation;
    }
}
      

2. Configuration de la banque de données

• Activez la fonctionnalité en la fournissant lambdaAuthorizerArn lors de la création

Note

Votre compte AWS est facturé pour les appels Lambda et leur durée. Pour plus d’informations, consultez Tarification AWS Lambda.

Détails du processus d'autorisation

Règles de validation des jetons

HealthImaging évalue les demandes de jetons suivantes :

• exp— Doit être postérieure à l'heure actuelle en UTC

• nbf— Doit être antérieur à l'heure actuelle en UTC

• iat— Doit être antérieur à l'heure actuelle en UTC et PAS plus tôt que 12 heures avant (durée de vie maximale du jeton)

Schémas d'événements et de réponses

AHI appelle votre fonction avec l'entrée suivante et attend la sortie suivante.

Entrée de l'autorisateur

{
  "datastoreId": "{datastore id}",
  "operation": "{Healthimaging API name e.g. GetDICOMInstance}",
  "bearerToken": "{access token}"
}
      

Sortie de l'autorisateur

{
  "isTokenValid": {true or false},
  "roleArn": "{role arn or empty string meaning to deny the request explicitly}"
}
      

Traitement des demandes

Traitement des demandes initiales :

• En l'absence d'autorisation : en-tête du porteur → la demande passe à l'authentification SigV4

• Si le jeton Bearer est présent :

  • Résout les problèmes de banque de données LambdaAuthorizerArn

  • Invoque l'autorisateur à l'aide de sessions d'accès direct (FAS)

Processus d'autorisation Lambda :

• Reçoit AuthInput avec DataStoreID, operation et BearerToken

• La validation doit être terminée dans un délai d'une seconde

• Retours AuthResult avec statut de validation et ARN du rôle

Flux de mise en œuvre

Flux d'authentification côté client

1. Authentification utilisateur : diriger l'utilisateur vers le point de terminaison d'autorisation de l'IdP

2. Acquisition de jetons : code d'autorisation d'échange pour les jetons d'identification et d'accès (JWT)

3. Appel d'API : inclure le jeton d'accès dans l'en-tête HTTP Authorization Bearer

4. Validation des jetons : processus de validation complet par un HealthImaging autorisateur Lambda

Étapes de configuration

Implémentation de Lambda Authorizer

• AuthInput/AuthResult Interface d'implémentation

• Valider le jeton (signature, expiration, émetteur, public, champs d'application)

• Décision de retour et ARN du rôle IAM

Configuration IAM

• Créez une politique avec des autorisations DICOMweb d'exploitation minimales

• Créez un rôle avec une politique de confiance pour medical-imaging.region.amazonaws.com

• Configurer les autorisations d'exécution Lambda

• Ajouter une politique de ressources avec une AllowHealthLakeInvocation déclaration pour l'ARN de la banque de données

L'autorisateur doit avoir la déclaration de politique de ressources suivante :

{
    "Sid": "health-imaging",
    "Effect": "Allow",
    "Principal": {
        "Service": "medical-imaging.region.amazonaws.com"
    },
    "Action": "lambda:InvokeFunction",
    "Resource": "arn:aws:lambda:region:123456789012:function:LambdaAuthorizerName"
}

Pour le rôle IAM renvoyé par Auth Lambda, il doit respecter la politique de relation de confiance suivante :

{
    "Effect": "Allow",
    "Principal": {
        "Service": "medical-imaging.region.amazonaws.com"
    },
    "Action": "sts:AssumeRole"
}

Configuration de la simultanéité

• Configurer la simultanéité provisionnée pour un SLO inférieur ou égal à 1 seconde

• Mettez en œuvre des mesures d'atténuation en cas de démarrage à froid si nécessaire

Modèle d'autorisation Lambda

import jwt from 'jsonwebtoken';
import jwksClient from 'jwks-rsa';

const CACHE_TTL = 10 * 60 * 1000;

const client = jwksClient({
  jwksUri: '{Jwks Url}',
  cache: true,
  cacheMaxEntries: 5,
  cacheMaxAge: 600000,
  rateLimit: true,
  jwksRequestsPerMinute: 10
});

export const handler = async (event) => {
  try {
    console.log(event);
    const token = event.bearerToken;
    const decoded = jwt.decode(token, { complete: true });

    if (!decoded || !decoded.header.kid) {
      console.log('Invalid token structure');
      return generatePolicy(null, false);
    }

    const key = await client.getSigningKey(decoded.header.kid);
    const signingKey = key.getPublicKey();

    const payload = jwt.verify(token, signingKey, {
      issuer: '{issuer to be verified}',
      algorithms: ['RS256'],
      // Additional verification parameters as needed
    });

    return generatePolicy(payload.sub, true);
  } catch (error) {
    console.error('Authorization error:', error);
    return generatePolicy(null, false);
  }
};

function generatePolicy(user, isValid) {
  return {
    isTokenValid: isValid,
    roleArn: user ? `arn:aws:iam::123456789012:role/${user}` : ""
  };
}
      

Validation finale par HealthImaging

Après réception AuthResult, HealthImaging

1. Vérifie toutes les réclamations symboliques (nbf, exp, iat)

2. Valide le format ARN du rôle

3. Assume le rôle

4. Signe la demande initiale avec SigV4 au nom de l'utilisateur

5. Traite la DICOMweb demande

Exceptions

Condition	Réponse de l'AHI
Lambda Authorizer n'existe pas ou n'est pas valide	4.2.4 Mauvaise configuration de l'autorisateur
Autorisateur arrêté en raison d'un échec d'exécution	4.2.4 Échec de l'autorisateur
Toute autre erreur d'autorisation non mappée	4.2.4 Échec de l'autorisateur
L'autorisateur a renvoyé une réponse invalide/mal formée	4.2.4 Mauvaise configuration de l'autorisateur
L'autorisateur a fonctionné plus de 1 s	408 Délai d'expiration de l'autorisateur
Le jeton a expiré ou n'est pas valide	403 Jeton non valide ou expiré
AHI ne peut pas fédérer le rôle IAM renvoyé en raison d'une mauvaise configuration de l'autorisateur	4.2.4 Mauvaise configuration de l'autorisateur
L'autorisateur a renvoyé un rôle vide	403 Accès refusé
Le rôle renvoyé n'est pas appelable (assume-role/trust misconfig)	4.2.4 Mauvaise configuration de l'autorisateur
Le taux de demandes dépasse les limites de la DICOMweb passerelle	429 Trop de demandes
Banque de données, rôle de retour ou autorisateur entre régions Account/Cross	4.2.4 Autorisateur : accès Account/Cross interrégional