Auf den ersten Blick mag diese Frage wie ein Vergleich zwischen Äpfeln und Birnen erscheinen. Wir werden feststellen, dass dies in einigen Fällen nicht der Fall ist und dass die beste strategische Entscheidung für Ihre Bedürfnisse von einer Reihe von Faktoren abhängt.
In der Unternehmensentwicklung software und der Unternehmensstrategie nehmen wir oft unsere Hämmer in die Hand und sehen alles als Nagel an. Sei es aus Gründen der Vertrautheit, der wahrgenommenen Kosten oder der versprochenen Kompatibilität. Diese drei Lösungen haben unterschiedliche primäre Anwendungsfälle, aber wir sollten uns nicht für eine entscheiden und dann die anderen beiden Möglichkeiten wegwerfen, ohne zu überlegen, wie sie in Ihre größere IAM-Strategie passen.
Für die Unternehmensföderation mit SaaS-Plattformen ist SAML 2.0 über AD FS 3.0 fast immer die richtige Wahl. SAML 2.0 ist ein sehr sicheres Protokoll, das sehr gut unterstützt wird, und mit AD FS, das als Rolle in Windows Server vorhanden ist, ist der Preis "kostenlos", mit sehr geringen Implementierungskosten. Federation über Azure ACS bietet ein Gateway zu einer großen Anzahl von SaaS-Anbietern und vereinfacht die Komplexität von One-to-Many Federation-Partnerschaften. (Wenn Ihr Unternehmen für jeden Anbieter oder Dienst eine Federation-Partnerschaft unterstützen muss, erhöht dies sowohl die Komplexität als auch den Aufwand für Support und Wartung. Wenn Federation Hubs wie Azure ACS ins Spiel kommen, sind die Dinge vor Ort viel einfacher).
Obwohl Azure Active Directory OAuth-Unterstützung bietet, kann die OAuth-Integration vor Ort oder benutzerdefiniert wichtig sein, um die Vorteile dieses Protokolls zu nutzen. OAuth wird weithin in nicht-unternehmerischen "Whole Internet"-Anwendungen verwendet und unterstützt. Wenn Ihr Unternehmen beabsichtigt, Dienste bereitzustellen, auf die "jeder" zugreifen kann und nicht nur Mitarbeiter, Partner und Anbieter, ist die OAuth-Strategie eine ernsthafte Überlegung wert. Gleiches gilt, wenn Sie planen, eine mobile Anwendung zu veröffentlichen - für mobile Plattformen ist OAuth das typische Protokoll. Zwar können wir SAML 2.0 mit Ihrer Anwendung als aktiven Benutzeragenten zum Laufen bringen, aber gemeinsame Bibliotheken für OAuth sind wahrscheinlich sinnvoller.
Sie werden vielleicht sagen: "Lee, warum erwähnen Sie Workplace Join überhaupt in diesem Artikel?" Nun, es ist wahrscheinlich, dass Sie Benutzer haben, die ihr eigenes Gerät mitbringen (BYOD) und trotzdem problemlos auf Unternehmensressourcen und -dateien zugreifen möchten. Diese Option ist wohl die mit dem geringsten Aufwand verbunden. Wenn Sie nur benötigen, dass Nicht-Domänengeräte auf Domänenressourcen für bekannte Benutzer zugreifen können, ist dieser Weg viel einfacher als die anderen beiden. Zugegeben, wenn Sie bereits AD FS 2.0 oder 3.0 im Einsatz haben, müssen wir einige Konfigurationsänderungen vornehmen, um die Geräteregistrierung und den Workplace Join zu unterstützen.
Wie wir gesehen haben, ist die Implementierung von OAuth als Authentifizierungsschnittstelle für nicht domänengebundene Geräte und SaaS-Ressourcen vergleichsweise komplex und erfordert Entwicklung. Die Entwicklung wird Zeit und Mühe kosten. Zugegeben, es fallen keine Lizenzkosten an. Darüber hinaus kann die OAuth-Fähigkeit mit Blick auf die Zukunft sehr wertvoll sein.
Um es kurz zu machen: Für den Verbund mit Unternehmensanwendungen und großen SaaS-Anbietern werden Sie SAML 2.0 verwenden. Für die Bereitstellung von mobilen Anwendungen oder Internetanwendungen, die mit Websites wie Twitter, Google und benutzerdefinierten Azure-Anwendungen integriert werden müssen, werden Sie OAuth verwenden. Und wenn Sie lediglich BYOD-Benutzern mit iPads, anderen iOS-Geräten oder Benutzern von Windows 8.1-Geräten den Zugriff auf bestimmte Unternehmensressourcen ermöglichen wollen, sollten Sie sich die Implementierung von Workplace Join ansehen.
