Leider gibt es immer mal wieder Applikationen, welche sich nicht an Best Practices im Webdesign orientieren und es unter Umständen nötig machen ein anderes System anzupassen so das sie funktionieren. Kürzlich hatte ich so einen Fall, bei dem ein SAP System welches die Authentisierung via ADFS (mit dem SAML Protkoll) durchführt, die Login Seite von ADFS als iFrame eingebettet hat. In diesem Beitrag zeige ich eine Möglichkeit, wie das einbetten nur für gewisse URLs zugelassen werden kann.
Ich habe schon verschiedene SaaS Applikationen gesehen, welche es erlauben Rechte in der Applikation anhand eines Claims aus dem SAML Token zu vergeben. Die Implementierung ist von Applikation zu Applikation unterschiedlich, weshalb ich mich in diesem Beitrag möglichst Allgemein halten werde.
Ein mögliches Anwedungsgebiet dafür wäre ein Role Based Access Control (RBAC) in einer Applikation. Dabei wird die Rollenzuweisung vom Service Provider an den Identity Provider delegiert. Der Identity Provider schreibt anhand seiner Claim Regeln eine oder mehrere Rollen in einen entsprechenden Claim Typ.
Ich habe bei einer Migration des Web Application Proxy von Windows Server 2012 R2 auf einen Windows Server 2019 das Problem gehabt, dass der Service mitsamt Health Check lief aber die Verbindung über den Proxy nicht klappte. Also habe ich das Zertifikat überprüft, sowie einen neuen Eintrag von Hand erstellt, bei dem die Verbindung funktioniert hat. Im Eventlog war lediglich der Event 12019 ersichtlich, der den Hinweis enthält, dass der Listener bereits von einer anderen Komponente auf dem Web Application Proxy registriert wurde. Dies kann mit folgendem Befehl überprüft werden netsh http show urlacl
Darauf hin habe ich ein Powershell Snippet geschrieben, mit dem alle Namen der Anbindungen welche ein Slash enthalten zu einem Bindestrich konvertiert werden. Noch den Service neu gestartet und die Verbindungen über den WAP klappten wunderbar.
Der folgende Beitrag zeigt die Migrationsschritte um von ADFS 3.0 auf ADFS 5.0 (mit Web Application Proxy) zu wechseln. Das Ganze soll ohne Unterbruch durchgeführt werden und die Anmeldung muss jederzeit möglich bleiben. Als Datenbank wird die standartmässige Windows Internal Database verwendet.
Zum Visualisieren von Metriken gehört Grafana für mich zu den Top Werkzeugen. In einem grösseren Umfeld kann die Benutzerverwaltung jedoch schnell aufwändig werden und es bietet sich meistens die Möglichkeit einen bereits vorhandenen Identity Provider zu verwenden der die zentrale Benutzer Verwaltung zur Verfügung stellt. Als etablierte Enterprise Web Anwendung verfügt Grafana über Authentifizierungs Möglichkeiten via LDAP, OpenId Connect, SAML und weitere. In einer Cloud orientierten Welt ist natürlich eine Federations basierte Authentifizierung sehr willkommen, weshalb ich die Konfiguration mit ADFS und OpenId Connect beschreibe.
Die Konfiguration eines neuen ADFS Server ist mit dem nicht sehr aussagekräftigen Fehler ID8025 fehlgeschlagen. Die naheliegendste Ursache dafür scheint mir mit dem SSL Zertifikate zusammen zu hängen, da alle anderen Einstellungen Standart sind. Leider liefert mir weder eine Suche nach ID8025 noch das Handbuch von Microsoft einen Hinweis auf den Fehler. Also setzte ich beim Erstellen des Zertifikates an. Da es sich um meine HomeLab Installtion handelt, löse ich das Zertifikat von der Lets Encrypt CA mit dem Kommandozeilen Tool lego.
Mehr oder weniger zufällig fällt mir beim Anschauen der Hilfe für lego auf, dass beim erzeugen des privaten Schlüssel ein Algorithmus basierend auf elliptischen Kurven verwendet wird. Sobald ich das Zertifikat mit dem Argument -k rsa4096 erstelle lässt es sich ohne Probleme für ADFS verwenden.
