Anforderungsbasierte Authentifizierung - SharePoint und allgemein

Question

Alle,

Ich habe viel über die Claims Based Authentication gelesen und bin immer noch ein wenig verwirrt. Ich versuche mein Verständnis zu vertiefen, speziell in Bezug auf SharePoint 2010/2013, aber auch allgemein (d. H. ASP.NET).

Mein Verständnis von verschiedenen Stücken von Technologie Terminologie ist wie folgt:

• WIF (Windows Identity Foundation) - eine .NET-Bibliothek (Satz von APIs), die für die Nutzung von Identitätsansprüchen und die Erstellung benutzerdefinierte STSs verwendet werden usw.

• Vertrauende Partei - ein "Verbraucher" von Ansprüchen (dh SharePoint, ASP.NET Web Site etc.). Ansprüche werden über eine STS (nur eine IP-STS?) Gestellt.

• STS (Sicherheitstokendienst) - ein spezieller Webdienst, der Sicherheitstoken ausstellt. Kommt in zwei Geschmacksrichtungen, und einige STS sind möglicherweise beide Geschmacksrichtungen gleichzeitig?

  • RP-STS (Relying Party Security Token Service)
  • IP-STS (Identity Provider Security Token Service)

• Trusted Identity Provider (Sharepoint-Terminologie) - AKA. IP-STS.

• SharePoint 2010/2013 STS - eine SharePoint-Dienstanwendung, die mit WIF entwickelt wurde und nur als RP-STS fungiert. Funktioniert als ein steckbarer Aggregationspunkt für eine Anzahl von benutzerkonfigurierbaren Trusted Identity Providern (IP-STSs). Diese könnten manuell mit WIF erstellt werden, falls erforderlich.

• ADFS 2.0 - eine Windows-Rolle, die speziell für die Verknüpfung einer Organisation mit einer Active Directory-Instanz entwickelt wurde. Macht einen IP-STS-Endpunkt verfügbar, der mit WIF erstellt wurde. Nach meinem Verständnis von ADFS 2.0 können Sie keine anderen Identitätsanbieter "aggregieren". Sie können sich nur bei einer bestimmten AD-Instanz authentifizieren, die möglicherweise nicht lokal für Sie ist und daher zur Unterstützung von SSO eingebunden werden muss .

• Windows Azure ACS 2.0 - ein Dienst, der speziell für die Verbindung von konfigurierten Drittanbieter-Identitätsanbietern (z. B. Microsoft-Konto, Google, Facebook, ADFS 2.0) entwickelt wurde. Funktioniert als ein steckbarer Aggregationspunkt für andere Identity Provider, für die er ein wenig wie eine Relying Party agiert. Macht einen IP-STS-Endpunkt verfügbar, der mit WIF erstellt wurde. Die Identity-Provider, die es aggregiert, sind nicht unbedingt IP-STSs, aber ACS 2.0 macht alles über Claims verfügbar, indem es seinen eingebauten IP-STS verwendet.

Sharepoint 2010/2013 Fragen:

Mein Hauptproblem ist, dass ich ein paar Artikel gesehen sprechen über ADFS 2.0 und Sharepoint, die als fast lesen, wenn Sie sind die ersetzende 2010 integrierte Sharepoint/2013 STS mit ADFS 2.0! Dies ist hoffentlich nur meine Lektüre, aber es verwirrte mein Verständnis.

1. Können Sie das tatsächlich tun? Ich sehe keinen Grund, warum Sie nicht könnten, wenn Sie wirklich wollten, aber ich nehme an, Sie müssen die SharePoint STS deaktivieren und viele manuelle Konfiguration vornehmen?
2. Warum möchten Sie dies tun?

2.1. Die AD-Authentifizierung wird bereits als OOTB Trusted Identity Provider-Option von SharePoint STS unterstützt. Wenn Sie stattdessen ADFS 2.0 verwenden möchten, können Sie dies einfach als vertrauenswürdigen Identitätsanbieter (IP-STS) hinzufügen, für den ich Blogposts gesehen habe.

2.2. Basierend auf meiner Beschreibung von ADFS 2.0 würde eine Änderung für den SharePoint STS Ihnen eine weniger flexible Lösung bieten?

Statements:

• Sie können die Sharepoint-STS konfigurieren verwenden ADFS 2.0 ein Trusted Identity Provider (IP-STS) sowie oder anstelle von lokalen AD.
• Sie können den SharePoint STS so konfigurieren, dass Windows Azure ACS 2.0 als vertrauenswürdiger Identitätsanbieter (IP-STS) verwendet wird. Dies würde es sehr einfach machen, Authentifizierungsanbieter von Drittanbietern zu unterstützen, ohne ein eigenes IP-STS mit WIF zu entwickeln.

ASP.NET WIF Fragen:

1. Mein Verständnis ist, dass, um das Vertrauen Verhandlungen zu führen und Ansprüche tauschen ein RP-STS zu einem IP-STS sprechen muss. Ist das richtig?
2. Daher im Zusammenhang mit der Erstellung einer forderungsbasierten ASP.NET-Webanwendung (Relying Party) bei der Verwendung von WIF müssten Sie daher eine RP-STS entwickeln/wiederverwenden und in die App aufnehmen und mit dieser eine Vertrauensbeziehung aufbauen ein IP-STS? Wenn nicht, können Sie Identity direkt von einem IP-STS mit WIF bekommen?

Wenn ich nur schreibe, hilft es mir, das aus meinem Kopf zu bekommen, aber jede Hilfe bei Ungenauigkeiten/über Simplikationen/offene Unwahrheiten wäre dankbar zu schätzen!

Grüße,

Michael Taylor

Answer 1

Die SP STS ist ein RP-STS heißt es nicht einen Berechtigungsnachweis Speicher gegen authentifizieren muss. Deshalb müssen Sie es mit ADFS föderieren, das ein IP-STS ist, d. H. Es authentifiziert sich gegen ein AD in seiner Domäne.

ADFS kann entweder ein RP-STS oder ein IP-STS sein, z. Sie könnten den Pfad haben - SP-App. -> SP STS -> ADFS (RP) -> ADFS (IP) -> AD.

Die IP-STS, die Sie mit SP verbinden, muss nicht ADFS sein - es kann alles sein, das das WS-Federation-Protokoll unterstützt, z. OpenAM, PingIdentity, Azure ACS. Der Hauptpunkt ist, dass am Ende der Kette ein Berechtigungsnachweisspeicher vorhanden sein muss, um sich zu authentifizieren.

Dieser Berechtigungsnachweis muss nicht AD sein, z. ADFS -> IdentityServer -> SQL Server.

ADFS kann mit vielen verschiedenen IP-STS verbunden werden. Der Benutzer kann auswählen, welcher für die Authentifizierung verwendet werden soll.

ADFS unterstützt SAML2 und WS-Fed als Verbundprotokolle. Der SP RP-STS unterstützt nur WS-Fed.

Die vorherige Version von ADFS (d. H. 1.0) ist die Version, die auf Windows Server 2008 installiert ist. Sie müssen ADFS 2.0 herunterladen. Leider gibt es eine Reihe von Blog-Posts, die den Begriff ADFS verwenden, sich aber auf ADFS 1.0 beziehen. Vorsicht - ADFS 1.0 ist ein völlig anderes Biest.

WIF ist nur eine Gruppe von .NET-Klassen. Es ist kein STS. Sie können gehen WIF -> IP-STS oder WIF -> RP-STS -> IP-STS usw.

Hoffentlich beantwortet dies einige Ihrer Fragen, sondern wegschießen, wenn etwas noch nicht klar ist.

Update:

Die einzigen STS die ich dieses einzuarbeiten WIF kennen, sind ADFS und IdentityServer. Die meisten der oben genannten sind Java-basiert.

Der Grund, dass Sie ADFS über IWA auswählen würden, ist, dass beide sich gegen AD authentifizieren, aber nur ADFS SSO- und Federation-Funktionalität hinzufügt. ADFS stellt außerdem alle anspruchsbasierten Installationen zur Verfügung - SAML-Token usw.

Wenn Sie ADFS einbinden, können Sie sich bei mehreren Anmeldeinformationsspeichern authentifizieren. Wenn Sie sich jedoch für eine Instanz von ADFS authentifizieren, wird das AD-Repository verwendet. Wenn Sie ADFS installieren, wird die Instanz von AD in ihrer Domäne gefunden. Das ist es, das es benutzt.