Wir haben eine Webanwendung, die in Windows Azure ausgeführt wird und bei der sich verschiedene Kunden anmelden können. In letzter Zeit haben immer mehr von ihnen nach einer Art Single-Sign-On-Lösung gefragt oder zumindest nach einer Synchronisierung ihrer lokalen/Domänenbenutzer mit denen in unserer Anwendung. Ich habe mir mehrere Optionen angesehen, aber keine gefunden, die mir wirklich machbar erscheint. Im Folgenden habe ich aufgelistet, was ich mir angesehen habe, aber im Grunde hätte ich gerne einige Ratschläge, wie ich dieses Problem angehen soll.
Es gibt Dienste von Drittanbietern, die dies möglicherweise können, aber normalerweise ist die Implementierung für uns und unsere Kunden mit mehr oder weniger Aufwand verbunden. Dies könnte auch bedeuten, dass wir je nach Kundenwunsch mehrere oder viele dieser Lösungen implementieren müssen.
Die meisten unserer Kunden, wenn nicht alle, verfügen über ein lokales Active Directory und es wäre perfekt, wenn wir dieses irgendwie auch mit unserer Anwendung nutzen könnten. Unsere Web-App mit einem lokalen AD zu verbinden, ist keine wirkliche Option, da uns Systemadministratoren (verständlicherweise) keinen Zugriff darauf gewähren.
Wir können auch ein AD in Azure einrichten. Also dachte ich, dass wir vielleicht vom lokalen AD mit unserem AD in Azure synchronisieren und dann von dort aus weitermachen könnten. Beim Testen des Azure Active Directory Connect-Tools von Microsoft wurde ich jedoch nach einem Administrator-Login für unsere Azure-Umgebung gefragt. Natürlich möchten wir unseren Kunden keinen Zugriff auf unser Azure-Portal gewähren, also sieht es so aus, als würde das nicht so gut funktionieren.
Ein weiteres Problem bei all dem ist, dass ich Programmierer bin und der ganze AD-Kram etwas außerhalb meiner Komfortzone liegt und ich vielleicht an den falschen Stellen suche.
Hat jemand damit Erfahrung und kann mir den richtigen Weg weisen?
Antwort1
ADConnect ist die Möglichkeit, das lokale Verzeichnis mit Ihrer Cloud zu synchronisieren. Sie müssen einen Benutzernamen und ein Passwort eingeben, um die erste Synchronisierung einzurichten und Änderungen an der Synchronisierung vorzunehmen, wenn Sie sich erneut mit dem Tool anmelden. Während der Einrichtung benötigen Sie außerdem ein DA-Konto für einen lokalen Administrator. Wenn Sie über keines der beiden Konten verfügen, können Sie die Einrichtung nicht abschließen.
Nach Ihrem Vorschlag ist Azure B2C das, was Sie einrichten möchten. Richten Sie andernfalls eine ADFS-Föderation zwischen Ihren Domänen und den Kundendomänen ein, damit Sie nicht nach Benutzernamen/Passwörtern fragen müssen. Ich gehe davon aus, dass Ihre Anwendungen Ansprüche berücksichtigen und Sie über ein eigenes Windows AD verfügen, damit ADFS konfiguriert werden kann.
Wenn Sie versuchen, eine ADFS-Testumgebung einzurichten, habe ich beim Aufbau meines ersten Labors die Anweisungen des 4-teiligen Blogs befolgt – hoffentlich sollte es bei Ihnen auch problemlos funktionieren.
http://blogs.technet.com/b/askpfeplat/archive/2013/12/09/how-to-build-your-adfs-lab-on-server-2012-part-1.aspx http://blogs.technet.com/b/askpfeplat/archive/2013/12/23/how-to-build-your-adfs-lab-on-server-2012-part2-web-sso.aspx
Antwort2
Wenn Sie die Anwendung so konfigurieren, dass sie SAML-Authentifizierung unterstützt, kann ein Kunde sein ADFS (oder ein anderes) so konfigurieren, dass es mit seinem AD funktioniert. Dies wird normalerweise für SSO bei Drittanbieteranwendungen gehandhabt.
Das funktioniert so, dass Sie weiterhin Identitäten und den Zugriff auf die Anwendung verwalten, die Kunden dies jedoch übernehmen und an ihren eigenen „Anspruch“ binden können, der AD-Benutzernamen enthalten kann. Dies ist, was ADFS und andere föderierende Identitätsplattformen tun (der Föderationsteil). Sie müssen jedoch eine Möglichkeit bereitstellen, das Vertrauen zwischen Identitätsanbietern (Ihrem und ihrem) herzustellen.
Sie können auf Ihrer Seite einen benutzerdefinierten Identitätsanbieter erstellen, einen Drittanbieterdienst verwenden oder einen Verbundserver wie ADFS einsetzen. Es gibt aber auch andere (sowohl kommerzielle als auch Open Source) wie PingFederate und Shibboleth. Es gibt dort buchstäblich Hunderte von Optionen. Wenn Sie ein SDK möchten – Ping Identity (Entwickler von PingFederate) bietet eines für mehrere Sprachen (Java, C# usw.) an. Ich bin sicher, dass es auch Open-Source-SDKs gibt, die dabei helfen.
Identität ist ein komplexes Thema. Je mehr Sie davon an ein dediziertes Unternehmen oder Team auslagern können, desto besser ist es für Sie (Azure B2C befindet sich, wie in anderen Antworten angegeben, in der Vorschauphase, aber wenn Sie schneller vorankommen möchten, sollten Sie sich Drittanbieter anschauen).