mifritscher

@NilsK: Ich habe ehrlich gesagt nur wenig Motivation für eine Metadiskussion, lasse uns bitte auf technische Lösungsansätze beschränken. Nur kurz: Das, was ich als "strikte Anforderung" beschrieben habe, _ist_ eine Entscheidung auf höchster Projektebene. War jetzt nicht unsere präferierte Lösung, aber das tut an dieser Stelle nichts zur Sache. Ich weiß, dass die Architektur sagen wir mal komplex/herausfordernd werden wird, aber da müssen wir jetzt nunmal durch. Vielleicht hilft es dir, die Problemstellung max. abstrakt zu beschreiben, wie es 1:1 aus den bisherigen Entscheiden kommt: Personen, die in einer Organisation (Hier müssen 8 eingebunden werden) mit AD, ADFS inkl. einer IdP für SAML, organisiert sind, müssen eine Win32 Anwendung bedienen, die in einer völlig externen Umgebung (technisch wie organisatorisch) läuft. Daneben muss SSO unterstützt werden, das heißt, wenn sich sich die Person an ihren Client der Organisation anmeldet muss diese Person ohne weitere Eingabe von Logindaten diese Win32 Anwendung verwenden können. Diese externe Umgebung soll als SP dienen. AD-Thrusts etc. sind explizit _nicht_ erwünscht. Kurzzusammenfassung ist eben: [quote] Wir haben die strikte Anforderung erhalten, dass man via SAML-Token Zugriff auf eine Windows Applikation erhält, die in einer "fremden" Umgebung lebt. [/quote] Zu deinem letzten Satz: [quote] selbst krude Hacks entwerfen, die Sicherheitsmechanismen außer Kraft setzen [/quote] An welcher Stelle siehst du einen kruden Hack, an welcher Stelle werden Sicherheitsmechanismen außer Kraft gesetzt? Ah, falls das zu einem Missverständnis geführt hat: Die VNC "Lösung" ist jetzt wirklich nicht das, was wir planen umzusetzen.

Ok, danke! 2) Inwiefern "Murks"? Wenn ich mich recht entsinne können bei Windows Profile als "nicht persistent" (im Sinne von https://www.windowspro.de/wolfgang-sommergut/virtuelle-desktops-nicht-persistent-persistent-pooled ) gesetzt werden, das würde hier dicke ausreichen. In diesen Sessions würde genau eine Fachanwendung ausgeführt werden (deren Hersteller im Projekt ist...) @NilsK : Ich bin gerade noch in der "Ideenfindungsphase", ich sammle noch einige Zeit. Deswegen bin ich für Ideen aller Art dankbar, auch als Impuls für weitere Ideen/Ansätze. Keine Sorge, ich werde mich jetzt nicht auf die erstbeste Idee stürzen, sondern sehe sie eher als Grundlage für weitere Recherchen, Anfragen etc. Von daher: Immer her mit den Ideen. Aussortieren können wir sie immer noch - oder im besten Fall verfeinern

@testperson: Das klingt doch schonmal nicht schlecht! Drei Fragen (ich bleibe einfach mal bei der von dir verlinkten Übersicht): 1. Muss das ein 1:1 Mapping sein, oder können mehrere User der ADFS.EXT auf einen User der AUTH.LOCAL gemappt werden? 2. Falls 1. geht: Unterstützt Citrix es, dass gleichzeitig mehrere Sessions eines Users der AUTH.LOCAL gleichzeitig laufen? 2. Kann ein User automatisch angelegt werden, wenn noch kein Mapping existiert? Wobei ich hier auch Workarounds ala "Erster Login schlägt wegen fehlendem Mapping fehl, irgendein Script liest die Logs, legt den User an und erzeugt das Mapping, zweiter Login funktioniert" akzeptiere. Ganz notfalls liese sich das aber vermutlich auch andersweitig (=Prozessseitig) lösen.

Es wäre denkbar, vorher User anzulegen, die dafür verwendet werden. Dann müsste es halt ein Mapping geben, für welchen SAML-User welche Windows-User verwendet werden soll. Dies kann durchaus auch manuell geschehen, solange man den Prozess als solches irgendwie automatisieren/scripten kann. Ich gehe von ca. 50 Benutzern aus, die von 8 verschiedenen IdPs kommen. Alle SAML Benutzer eines IdPs können sich durchaus einen lokalen Windows-Benutzer teilen, solange es eine Möglichkeit gibt, dass der Anwendung mitgeteilt wird, welcher SAML-User da aktiv ist. Ein AD-Forest ist laut Kundenaussage ein no-Go. Allerdings kann der Server, ich nenne ihn mal abstrakt Applikation Server, seine eigene (isolierte) AD haben, in der die Windows-User, die für die Windows-Sessions verwendet werden, existieren. Allerdings muss die Authentifizierung von außen zwingend einzig und alleine über SAML stattfinden.

Auch nicht via RDWeb? Oder allgemeiner ausgedrückt: Es gibt also kein RDP-Gateway, dass dies übernehmen kann? Also dass sich der Benutzer sich via SAML an das RDP Gateway anmeldet, und sich dieses dann mit "irgendwelchen" Windows-Zugangsdaten an den Terminalserver anmeldet? Noch abstrakter: Wir haben die strikte Anforderung erhalten, dass man via SAML-Token Zugriff auf eine Windows Applikation erhält, die in einer "fremden" Umgebung lebt. Wie dies geschieht ist erstmal egal - eine extrem brachiale Möglichkeit wäre ein VNC-Server, dem ein Web-VNC Client vorgeschaltet wird, auf dem wiederum man sich per SAML anmeldet. Diese Möglichkeit würde technisch definitiv gehen - nur schön ist was anderes. Nun geht es darum, diesen Ansatz soweit aufzubessern, dass sie in der Praxis einsatztauglich ist: * einigermaßen performant * Übertragung einer einzelnen Applikation, keinen Desktop * Dateiaustausch zw. Applikation und Client-Rechner * Diese Applikation soll "irgendwie" wissen, welcher SAML-Benutzer das jetzt eigentlich ist * Automatisiert. VMWare Horizon, XenDesktop/XenApp (letzteres klingt auf den ersten Blick sinnvoller) oder eine ähnliche VDI Lösung wäre übrigens auch denkbar. Völlig andere Ansätze auch :-D

Folgende Konstellation: Organisation hat eine AD + eine ADFS Infrastruktur, steht also als SAML IdentityProvider(IdP) zur Verfügung. Kann ein externer Windows Terminal Server, der _keine_ Anbindung an diese AD hat (und auch nicht haben kann), als SP(ServiceProvider) auftreten, sodass User über SAML Windows Sessions eröffnen können? Der für diese Windows Session verwendete Windows Benutzer kann dabei ein temporärer sein, es geht dabei nur darum, via RemoteApp auf eine Applikation zuzugreifen. Diese Applikation würde als I-Tüpfelchen wiederum zumindest den Usernamen, dass im SAML-Token war, wissen müssen.