À première vue, cette question peut sembler être une situation où l'on compare des pommes et des oranges. Nous verrons qu'il n'en est rien dans certains cas et que le choix stratégique le plus adapté à vos besoins dépend d'un certain nombre de facteurs.
Souvent, dans le cadre du développement de l'entreprise software et de la stratégie d'entreprise, nous prenons notre sac de marteaux et percevons tout comme un clou. Il peut s'agir de la familiarité, du coût perçu ou des promesses de compatibilité. Ces trois solutions ont des cas d'utilisation primaire différents, mais il ne faut pas en choisir une et jeter les deux autres sans réfléchir à la manière dont elles s'intègrent dans votre stratégie IAM globale.
Pour la fédération d'entreprise avec des plateformes SaaS, SAML 2.0 via AD FS 3.0 est presque toujours le bon choix. SAML 2.0 est un protocole très sûr, très bien supporté, et avec AD FS présent en tant que rôle dans Windows Server, le prix est "gratuit", avec un coût de mise en œuvre très faible. La fédération via Azure ACS offre une passerelle vers un grand nombre de fournisseurs SaaS, ce qui simplifie la complexité des partenariats de fédération un-à-plusieurs. (Si votre organisation doit soutenir un partenariat de fédération pour chaque fournisseur ou service, cela augmente à la fois la complexité et le niveau d'effort pour le support et la maintenance. Avec l'entrée en jeu de hubs de fédération comme Azure ACS, les choses sont beaucoup plus simples sur site).
Bien qu'Azure Active Directory prenne en charge OAuth, sur site ou sur mesure, l'intégration d'OAuth peut s'avérer importante pour tirer parti de ce protocole. OAuth est largement utilisé et pris en charge dans les applications "Whole Internet" qui ne sont pas destinées aux entreprises. Si votre organisation a l'intention de déployer des services accessibles à "tout le monde", plutôt qu'aux seuls employés, partenaires et fournisseurs, la stratégie OAuth mérite d'être sérieusement envisagée. De même, si vous envisagez de publier une application mobile - pour les plateformes mobiles, OAuth est le protocole habituel. Bien que nous puissions faire fonctionner SAML 2.0 avec votre application en tant qu'agent utilisateur actif, il est probablement plus judicieux d'utiliser des bibliothèques communes pour OAuth.
Vous direz peut-être : "Lee, pourquoi mentionner Workplace Join dans cet article ?" Eh bien, il est probable que vous ayez des utilisateurs qui souhaitent "apporter leur propre appareil" (BYOD) tout en accédant facilement aux ressources et aux fichiers de l'entreprise. Cette option est sans doute celle qui demande le moins d'efforts. Si vous avez seulement besoin que des appareils ne faisant pas partie du domaine puissent accéder aux ressources du domaine pour des utilisateurs connus, cette voie est beaucoup plus simple que les deux autres. Certes, si vous disposez déjà d'AD FS 2.0 ou 3.0, nous devrons apporter quelques modifications à la configuration pour prendre en charge l'enregistrement des périphériques et Workplace Join.
Comme nous l'avons vu, la mise en œuvre d'OAuth en tant qu'interface d'authentification pour les appareils ne faisant pas partie d'un domaine et les ressources fournies par SaaS est relativement complexe et nécessite un développement. Le développement prendra du temps et nécessitera des efforts. Il est vrai qu'il n'y a pas de coût de licence. En outre, le fait de disposer d'une capacité OAuth peut s'avérer très utile à l'avenir.
En bref : Pour la fédération avec les applications d'entreprise et les principaux fournisseurs SaaS, vous utiliserez SAML 2.0. Pour le déploiement d'applications mobiles ou d'applications Internet qui doivent s'intégrer à des sites tels que Twitter, Google et les applications personnalisées Azure, vous utiliserez OAuth. Et si tout ce dont vous avez besoin, c'est que les utilisateurs BYOD équipés d'iPads ou d'autres appareils iOS, ou les utilisateurs d'appareils Windows 8.1, accèdent à des ressources spécifiques de l'entreprise, jetez un coup d'œil à la mise en œuvre de Workplace Join.
