Product-apim: Prise en charge de l'authentification de base pour les abonnés

La nouvelle version d'APIM 3.0.0 prend en charge l'authentification de base. Nous l'utilisons actuellement dans notre environnement.

Oui pour les points de terminaison principaux. Pour Api, je n'ai pas trouvé l'option.

Éditeur d'API -> Configurations d'exécution -> Sécurité au niveau de l'application

@Tomas-Mrazek correct, maintenant nous prenons également en charge l'authentification de base pour les clients API. Vous pouvez activer l'option Basic sous la sécurité au niveau de l'application, comme indiqué ci-dessus. Cela permettra aux consommateurs d'API d'appeler cette API en utilisant leur combinaison nom d'utilisateur et mot de passe.

Ok, on dirait que je cherchais au même endroit. Je viens de tester et ça marche.

Cela amène plus de questions.

Comment les abonnements fonctionnent-ils avec l'authentification de base ? On dirait que n'importe quel utilisateur peut invoquer n'importe quelle API, indépendamment des abonnements ? Existe-t-il un moyen d'« affecter » des utilisateurs à des applications spécifiques afin qu'ils puissent invoquer uniquement l'API à laquelle l'application est abonnée ?

Si Prod et Sandbox partagent la même passerelle, comment déterminer laquelle est invoquée lors de l'authentification de base ?

Ces deux questions n'auraient pas besoin de réponse si nous devions utiliser la clé d'application et le secret d'application au lieu du nom d'utilisateur et du mot de passe dans l'authentification de base.

Peut-être qu'il me manque quelque chose, ce serait donc bien si vous pouviez m'indiquer la documentation.

Comment les abonnements fonctionnent-ils avec l'authentification de base ? On dirait que n'importe quel utilisateur peut invoquer n'importe quelle API, indépendamment des abonnements ? Existe-t-il un moyen d'« affecter » des utilisateurs à des applications spécifiques afin qu'ils puissent invoquer uniquement l'API à laquelle l'application est abonnée ?

Non, cela devrait fonctionner de la même manière qu'avec le jeton oauth2. Seul l'utilisateur abonné peut invoquer l'API, peu importe que ce soit via un jeton ou une authentification de base.

Vous ne pouvez pas affecter d'utilisateurs à des applications, car cela fonctionne de manière opposée : les applications appartiennent à l'utilisateur. Si vous souhaitez un contrôle plus précis, créez des rôles dans la console /carbon et attribuez-les aux utilisateurs. Dans l'éditeur d'API, accédez aux paramètres de l'API, modifiez la visibilité sur le portail de développement pour un rôle spécifique. Créez ensuite des étendues avec un rôle spécifique pour chaque ressource, attribuez cette étendue à la ressource, activez la sécurité. Les utilisateurs abonnés qui peuvent évoquer l'API, mais sans que vous leur attribuiez un rôle, ils ne peuvent appeler aucune ressource protégée.

Si Prod et Sandbox partagent la même passerelle, comment déterminer laquelle est invoquée lors de l'authentification de base ?

Bonne question. Je ne connais pas la réponse.

Soit dit en passant, cela ne fonctionnerait pas avec la clé et le secret du consommateur. Le point de terminaison est spécifié lors de la génération de /token AFAIK.

Salut @Tomas-Mrazek et @tmkasun , c'est exactement mon problème avec l'authentification de base maintenant. Permettez-moi d'essayer de résumer mes réflexions sur l'authentification :

OAuth2 - nous souscrivons l'application à une API. Sur la base de la clé et du secret, nous connaissons l'application et l'environnement. Donc, pour permettre à App d'utiliser Api, il suffit de s'y abonner. Ensuite, n'importe quel utilisateur peut appeler cette Api étant donné qu'il connaît la clé et le secret.

Clés d'API statiques - ici, nous connaissons la clé, et cela donne suffisamment d'informations pour savoir quelle application appelle l'API et quel environnement elle utilise. Le concept d'abonnement de l'App à l'Api pour l'utiliser s'applique toujours. Nous avons seulement besoin de souscrire l'application à une Api.

Authentification de base telle qu'elle est maintenant - je l'appellerai "authentification de base basée sur l'utilisateur". Il abandonne complètement le concept d'application et d'abonnement et nécessite l'utilisation d'un concept différent (autorisations basées sur l'utilisateur) et de différents outils comme l'utilisation de Carbon admin au lieu de Publisher ou Store/DevPortal. Et il ne peut pas faire la distinction entre l'environnement de production et l'environnement sandbox lorsqu'une seule passerelle est utilisée pour les deux. Cela donne également un niveau supplémentaire de complexité à configurer et à administrer. Maintenant, il ne suffit pas de regarder la liste des applications abonnées, il faut aussi aller sur carbon admin et regarder les utilisateurs et les autorisations. Et si je veux limiter le taux d'une application spécifique pour une API, ou avoir différents niveaux d'abonnement, je ne peux pas le faire pour l'utilisateur.

Ce que je considérerais comme une manière "correcte" de prendre en charge l'authentification de base serait la suivante :

Authentification de base au niveau de l'application - Nous supprimons l'utilisateur du concept (comme avec les clés statiques) et utilisons à la place l'authentification de l'application. L'application doit encore s'abonner à l'Api. La clé du consommateur et le secret du consommateur sont utilisés comme informations d'authentification de base. De cette façon, nous conservons le concept d'abonnement App / Api, pouvons continuer à utiliser les mêmes outils que pour tout le reste (éditeur / devPortal, pas besoin de Carbon Admin), et nous savons quelle application utilise quelle Api et quel environnement en fonction des clés.

Comment aller là?

Il y a deux options. Remplacez l'implémentation de base actuelle par celle proposée ci-dessus ou implémentez-en une nouvelle appelée "authentification App Basic".
Il existe également une troisième option, pour prendre en charge à la fois user/pass et key/secret dans l'authentification de base existante, mais c'est la plus sale.

La mise en œuvre de l'authentification de base n'est pas suffisante. Par exemple, vous pouvez limiter la visibilité de l'API sur le devportal en fonction des rôles -> qui doivent être créés et associés à l'utilisateur via la console Carbon.

Salut @Tomas-Mrazek et @markokocic
Merci pour vos suggestions, veuillez trouver mes réponses en ligne.

Comment les abonnements fonctionnent-ils avec l'authentification de base ? On dirait que n'importe quel utilisateur peut invoquer n'importe quelle API, indépendamment des abonnements ? Existe-t-il un moyen d'« affecter » des utilisateurs à des applications spécifiques afin qu'ils puissent invoquer uniquement l'API à laquelle l'application est abonnée ?

La prise en charge de l'authentification de base pour les demandes des clients ne nécessite pas la présence d'abonnements. Si un créateur d'API a activé la prise en charge de l'authentification de base pour une API particulière, cette API peut être appelée sans s'abonner à cette API (par application).
et @markokocic oui, le fonctionnement de l'abonnement est , An Application subscribed to an API .

De plus avec l'autorisation Baisc :
vous obtenez toujours :

• Limitation au niveau des ressources ou au niveau de l'API
• Validation de la portée des ressources

vous n'obtiendrez pas :

• Limitation du niveau d'abonnement
• Différenciation de l'environnement de production et de bac à sable

Si Prod et Sandbox partagent la même passerelle, comment déterminer laquelle est invoquée lors de l'authentification de base ?

Oui, nous n'avons pas pu différencier l'environnement par nom d'utilisateur et mot de passe. Par conséquent, lors de l'utilisation de l'authentification de base, vous n'aurez pas la possibilité de sélectionner l'environnement, le point de terminaison de production sera utilisé.

@Tomas-Mrazek

Le point de terminaison est spécifié lors de la génération de /token AFAIK.

Non, les points de terminaison (Prod & Sandbox) sont définis par le créateur de l'API lors de la création de l'API, les consommateurs d'API peuvent fournir une URL de rappel pour une application s'ils souhaitent utiliser des types d'attribution basés sur la redirection (c'est-à-dire implicites)

@markokocic concernant

Authentification de base au niveau de l'application

Cela est également possible avec la mise en œuvre actuelle. Vous pouvez utiliser le type d'octroi d'informations d'identification client pour obtenir une paire de jetons au nom du propriétaire de l'application.

Authentification de base au niveau de l'application

Cela est également possible avec la mise en œuvre actuelle. Vous pouvez utiliser le type d'octroi d'informations d'identification client pour obtenir une paire de jetons au nom du propriétaire de l'application.

@tmkasun
Oui, il est possible d'utiliser l'authentification de base pour générer un jeton à l'aide des informations d'identification du client. Vous utilisez quelque chose comme ceci :

curl -k -X POST https://localhost:8243/token -d "grant_type=client_credentials" -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

Cependant, pour utiliser l'API, votre consommateur doit toujours être capable de :

• générer le jeton en utilisant la méthode ci-dessus
• définissez-le comme un en-tête http "Authorization" avec Bearer et Token pour la demande d'API réelle
• éventuellement prendre en charge l'expiration et l'actualisation du jeton

Ce n'est pas grave si un programmeur programme votre consommateur, ou si vous avez un fournisseur qui peut le faire. Comme décrit, le problème concerne de nombreux clients d'entreprise hérités qui ne sont pas personnalisables. Par exemple, dans SAP, si vous souhaitez utiliser un service externe, la seule chose que vous pouvez définir est l'URL, et éventuellement le nom d'utilisateur et le mot de passe pour l'authentification de base. Là, vous n'avez pas la possibilité de récupérer un jeton ou de définir des en-têtes personnalisés.

Ce que j'ai décrit comme l'authentification de base au niveau de l'application ci-dessus est en fait la possibilité d'ignorer l'étape de génération de jetons et d'utiliser directement l'authentification de base basée sur les informations d'identification du client pour appeler l'API.

Quelque chose comme:

curl -k -X POST https://localhost:8243/my/nice/Api/doSomething -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

Cela me permettrait d'utiliser toujours le même modèle d'abonnement App to API de manière uniforme, sans avoir besoin de créer, configurer et gérer des utilisateurs.

Autre avantage, étant donné que la norme d'authentification de base offre la possibilité d'inclure un en-tête d'autorisation dans l'URL, nous pourrions même prendre en charge les anciens consommateurs avec quelque chose comme ceci :

curl -k -X POST https://consumer-key:consumer-secret<strong i="25">@localhost</strong>:8243/my/nice/Api/doSomething

EDIT : Maintenant que j'y pense, le nom le plus clair serait peut-être l'authentification de base basée sur les informations d'identification du client pour l'API.