Utilisation de WIF dans le service ASP.NET Web API

Question

Je cherche à faire quelque chose comme ça :

1. J'ai une application Web MVC4 et un service Web-API (hébergé sur deux rôles distincts dans Azure)
2. Un autre rôle exécute CustomSTS1.
3. L'application Web MVC fait confiance au CustomSTS1
4. Maintenant, lorsque le client se connecte au site, il est redirigé vers la page de connexion STS.
5. Une fois connecté, il est redirigé de nouveau vers le site Web MVC.
6. À partir de ce site Web, le client effectue des actions, qui à leur tour invoquent le service Web-API.

J'ai le jeton SAML dans l'application web, que je transmets au service WebAPI.

Maintenant, lorsque j'essaie de valider le jeton SAML du côté du Web API, je reçois un

Message=ID1032: Au moins un 'audienceUri' doit être spécifié dans la exigence de jeton de sécurité SAML lorsque AudienceUriMode est défini sur 'Always' ou 'BearerKeyOnly'. Ajoutez les valeurs d'URI valides à la propriété AudienceUris de SamlSecurityTokenRequirement, ou désactivez la vérification en spécifiant un AudienceUriMode de 'Never' sur SamlSecurityTokenRequirement.

Ceci est sans que le service Web API ne fasse confiance au CustomSTS1

Une fois que j'ai configuré la confiance, Je reçois toujours un HTTP 401: UNAUTHORIZED, chaque fois que j'essaie de faire une requête HTTP GET vers le service Web API.

Maintenant, Ma Question est, (Je sais que ma démarche actuelle est définitivement mauvaise)

1. Comment puis-je configurer la relation de confiance avec CustomSTS1, de telle sorte que le service WebAPI puisse faire un ActAS au nom de l'utilisateur connecté au site MVC ?

OU

1. Cette architecture est-elle incorrecte ?
2. Y a-t-il un autre moyen d'atteindre cela ?

Answer 1

Cette approche est incorrecte conceptuellement. L'application MVC devrait négocier un nouveau jeton pour l'API Web dans le STS en utilisant ActAs. C'est ainsi que cela fonctionne traditionnellement pour les services SOAP. Cependant, les API Web s'éloignent de SAML car il s'agit d'un format complexe qui repose sur différentes spécifications WS-*. OAuth 2.0 devient la norme dans ce domaine si vous souhaitez prendre en charge une SSO à ce niveau.

Une autre approche consiste à établir une confiance implicite entre l'application MVC et l'API Web, de sorte que tous les appels à l'API Web depuis l'application MVC soient effectués via un mécanisme d'authentification Http plus standard comme Basic Auth en utilisant un ensemble spécifique d'identifiants que seule l'application MVC connaît. Les informations sur l'utilisateur connecté dans l'application MVC sont transmises en tant qu'informations supplémentaires.

Cordialement, Pablo.