Archiv der Kategorie: Authentifizierung

Nützlicher Schalter beim Anlegen eines Identity Providers: SignOutUrl

Vor Kurzem habe ich festgestellt, dass eine derzeit noch undokumentierte Eigenschaft in SharePoint gibt, die es einem erlaubt, beim Anlegen (und auch danach) eines Identity Providers in SharePoint eine SignOut-URL anzugeben.
Dies ist sehr nützlich, da hiermit das Ausloggen aus einer SAML-basierte Infrastruktur, wie z.B. ADFS möglich ist.

Die neue Option lässt sich bei der Verwendung von “New-SPTrustedIdentityTokenIssuer” mit dem Parameter SignOutUrl nutzen oder später mit Hilfe der Eigenschaft ProviderSignOutUrl festlegen.

Für die Nutzung in Verbindung mit ADFS könnte das Setzen der Eigenschaft per PowerShell beispielsweise so aussehen (vorausgesetzt, es gibt nur einen Identity Provider):

$ti = Get-SPTrustedIdentityTokenIssuer
$ti.ProviderSignOutUri = "https://login.firma.de/adfs/ls/?wa=wsignout1.0&wreply={UrlZurWeiterleitungNachSignOut}
$ti.Update()

Damit erspart man sich das leidige Anpassen der Login-Infrastruktur per Code. Die Eigenschaft kam mit einem der letzten Post-SP1-Updates, also zwischen April und Juli.

Probleme bei TMG und Web Application Proxy

Heute hatte ich mal wieder eine interessant Konstellation: Für eine ADFS-Authentifizierung für Office 365 sollte ein ADFS Proxy über das Internet verfügbar gemacht werden. In Windows Server 2012 R2 gibt es hierfür den Web Application Proxy, der gleichzeitig ADFS Proxy ist. Eine separate Rolle gibt es in ADFS 3.0 nicht mehr.

Sollte eigentlich einfach sein: TMG ist bereits im Einsatz, Listener ohne Authentifizierung und mit passendem Zertifikat existiert bereits. Also einfach neue Web Publishing Rule anlegen, mit der entsprechenden URL und auf den WAP zeigen lassen.

Resultat:

Obwohl die Pfade und Adressen alle stimmen, sagt er, er könne den Host nicht finden.

Lösung: Derzeit gibt es keine für dieses Szenario, der Web Application Proxy kann nicht über eine Web Publishing Rule veröffentlicht werden. Wenn man allerdings den ADFS Server direkt published, funktioniert es, aus Sicherheitsgründen empfiehlt es sich aber nicht.

Es gibt zwei Möglichkeiten, dieses Szenario umzusetzen:

  1. Authentifizierung auf TMG und Kerberos-Authentifizierung am ADFS. Nachteil: Der eingegeben Benutzername im Office 365 wird nicht in das TMG-Formular übernommen, das müsste dann noch per JavaScript implementiert werden. Und damit geht natürlich auch nur die interne Authentifizierung, kaskadierte ADFS-Konstrukte sind damit nicht möglich.
  2. Port-Weiterleitung auf den WAP. Sollten allerdings noch andere Publishing Rules auf dem Listener liegen und keine weitere IP-Adresse zur Verfügung stehen, müssen die bestehenden Veröffentlichungen dann auch auf den WAP umgezogen werden und damit der TMG komplett umgangen werden.

Änderungen der Forefront-Roadmap: FIM und UAG

Gestern gab es Neuigkeiten im Server & Cloud-Blog von Microsoft zum Forefront Identity Manager und Unified Access Gateway:

Im ersten Halbjahr soll eine neue Version des Identity Managers erscheinen, die vor allem Verbesserungen in den Bereichen Hybrid Environments mit Windows Azure, Benutzerverwaltung und Compliance bringen soll.

Das Forefront UAG jedoch wird Microsoft zum 01. Juli 2014 nicht mehr verkaufen. Die Supportzeiträume entsprechen denen vom TMG. Einige Features von Windows Server 2012 R2 stellen die Funktionalitäten hinsichtlich Application Publishing bereit (Web Application Proxy), womit der Haupteinsatzzweck von TMG und UAG rudimentär abgedeckt werden soll.

Den ganzen Beitrag finden Sie hier

On Breaking SAML: Single-Sign-On Systeme anfällig

Die Ruhr-Universität Bochum hat vor kurzem eine Untersuchung veröffentlicht, in der verschiedene auf SAML basierende Single-Sign-On-Systeme auf Sicherheitslücken untersucht wurden.

Von den 14 untersuchten Frameworks waren danach 12 anfällig für eine XML Signature Wrapping Attacke. Untersucht wurden unter anderem:

  • Apache Axis 2
  • Windows Identity Framework
  • OpenSAML
  • Salesforce
  • SimpleSAMLphp
  • WSO2
  • OneLogin

Bei einer XML Signature Wrapping Attack wird das XML-Dokument mit den SAML Assertions (die Identifikation des Benutzers) mit weiteren Assertions angereichert. Das Dokument ist in der Regel signiert, jedoch lassen sich die anfälligen Systeme austricksen, in dem die zusätzlichen Assertions in einem nicht signierten Bereich des Dokuments untergebracht werden. Bei den anfälligen Systemen sind die Signaturverifikation und die Regelverarbeitung getrennt, sodass die zusätzliche Assertions akzeptiert und verarbeitet werden, auch wenn sie nicht signiert sind.

Die beiden nicht anfälligen Systeme waren SimpleSAMLphp und das Windows Identitiy Framework, das auch das SAML-Framework für SharePoint 2010 und Active Directory Federation Services 2.0 darstellt.

Die anfälligen Frameworks werden beispielsweise in Shibboleth, Joomla, WordPress, SugarCRM, Drupal und von Salesforce verwendet.