Tipp 2 zu Ansprüchen: Informationen zur anspruchsbasierten Authentifizierung in SharePoint 2010

Artikel
06/24/2015

Zusammenfassung: Hier finden Sie fünf Tipps zur anspruchsbasierten Authentifizierung in SharePoint 2010, u. a. zum Auflösen von Anspruchsnamen, Konfigurieren von ausgewählten Zonen, zu Standardlösungsbereitstellungen und zum Beseitigen von Fehlermeldungen.

Letzte Änderung: Montag, 14. März 2011

Inhalt dieses Artikels
Überblick über den Themenbereich dieses Artikels
Tipp 1: Festlegen, dass ein benutzerdefinierter Anspruchsanbieter nur für ausgewählte Zonen in SharePoint 2010 verwendet wird
Tipp 2: Auflösen von Anspruchsnamen
Tipp 3: Anmelden und die gefürchteten drei Eingabeaufforderungen bei der Authentifizierung
Tipp 4: Hinweis auf die Standardlösungsbereitstellungen für benutzerdefinierte Anspruchsanbieter
Tipp 5: Auflösen eines "TrustedMissingIdentityClaimSource"-Fehlers mit anspruchsbasierter Authentifizierung
Schlussbemerkung
Weitere Ressourcen

Bereitgestellt von: Steve Peschka, Microsoft Corporation

Inhalt

Überblick über den Themenbereich dieses Artikels
Tipp 1: Festlegen, dass ein benutzerdefinierter Anspruchsanbieter nur für ausgewählte Zonen in SharePoint 2010 verwendet wird
Tipp 2: Auflösen von Anspruchsnamen
Tipp 3: Anmelden und die gefürchteten drei Eingabeaufforderungen bei der Authentifizierung
Tipp 4: Hinweis auf die Standardlösungsbereitstellungen für benutzerdefinierte Anspruchsanbieter
Tipp 5: Auflösen eines "TrustedMissingIdentityClaimSource"-Fehlers mit anspruchsbasierter Authentifizierung
Schlussbemerkung
Weitere Ressourcen

Überblick über den Themenbereich dieses Artikels

Dieser Artikel enthält Tipps und Antworten zu häufig gestellten Fragen zur anspruchsbasierten Authentifizierung in Microsoft SharePoint 2010. Zudem werden Tipps und Anleitungen zur Lösung von Problemen im Zusammenhang mit dem Konfigurieren von Ansprüchen bereitgestellt, und es wird auf andere Ressourcen mit weiteren Informationen hingewiesen.

Tipp 1: Festlegen, dass ein benutzerdefinierter Anspruchsanbieter nur für ausgewählte Zonen in SharePoint 2010 verwendet wird

Immer wieder habe ich folgende Frage in Bezug auf ein Nutzungsszenario für Anspruchsanbieter gehört: Wie konfiguriere ich einen benutzerdefinierten Anspruchsanbieter so, dass er nur für eine bestimmte Webanwendung oder mehrere bestimmte Webanwendungen verwendet wird und nicht für alle? Anfangs habe ich gehofft, dass ich dieses Problem einfach lösen könnte, indem ich den Bereich für das Feature für den Anspruchsanbieter auf die Webanwendung beschränke. Doch das funktioniert leider nicht.

Für ein Feature für einen benutzerdefinierten Anspruchsanbieter muss immer die Farmebene als Bereich festgelegt sein. Wenn Sie für das Feature irgendeinen anderen Bereich festlegen, erhalten Sie diese Fehlermeldung: "Die Methode oder Operation wurde nicht implementiert".

Wenn für das Feature die Farmebene als Bereich festgelegt ist, wie konfigurieren wir dann den Anspruchsanbieter so, dass er nur für ausgewählte Webanwendungen oder Zonen verwendet wird? Die Antwort darauf ist kompliziert. Zunächst einmal ist es wichtig, zwei sehr wichtige Eigenschaften für einen Anspruchsanbieter in der SPClaimProviderDefinition-Klasse zu verstehen: die IsEnabled-Eigenschaft und die IsUsedByDefault-Eigenschaft. Wenn Sie ein neues Feature für einen Anspruchsanbieter installieren, sind für den Anspruchsanbieter standardmäßig die IsEnabled- und die IsUsedByDefault-Eigenschaft auf true festgelegt. Das bedeutet, dass der Anspruchsanbieter überall verwendet wird, wo SAML-Ansprüche (Security Assertion Markup Language) in einer Zone aktiviert sind. Um also überhaupt die Möglichkeit zu haben, einen Anspruchsanbieter für die Verwendung nur in ausgewählten Zonen zu konfigurieren, müssen wir zuerst die IsUsedByDefault-Eigenschaft auf false ändern. Solange IsEnabled gleich true und IsUsedByDefault gleich false ist, können wir die Verwendung des Anspruchsanbieters für jede Zone einzeln konfigurieren.

Die nächste Frage ist natürlich: Wie setzt man die IsUsedByDefault-Eigenschaft auf false? Dazu gibt es mehrere Möglichkeiten. Eine Option besteht darin, den Featureempfänger zu verwenden, den Sie für den benutzerdefinierten Anspruchsanbieter erstellen, und die Eigenschaft dort zu konfigurieren. Im Überschreibevorgang für das FeatureActivated-Ereignis (das Sie schon codiert haben sollten), können Sie mithilfe von SPClaimProviderManager einen Verweis auf den Anbieter abrufen und die IsUsedByDefault-Eigenschaft auf false festlegen. Im Folgenden ein Beispiel, das ich in einem meiner Anspruchsanbieter verwendet habe.

SPClaimProviderManager cpm = SPClaimProviderManager.Local;
 
foreach (SPClaimProviderDefinition cp in cpm.ClaimProviders)
{
if (cp.ClaimProviderType == typeof(SqlClaimsProvider.SqlClaims))
       {
       cp.IsUsedByDefault = false;
              cpm.Update();
              break;
       }
}

In diesem Code, in dem typeof(SqlClaimsProvider.SqlClaims) verwendet wird, ersetzen Sie die Assembly und den Klassennamen durch den Anspruchsanbieter, z. B. typeof(MyProvider.MyClaims). Sie können den Code auch in einer benutzerdefinierten Anwendung umschließen. So habe ich es gemacht, und daran erkläre ich auch die restlichen Schritte in diesem Artikel.

Abbildung 1 ist ein Screenshot meiner Anwendung Claims Provider Activation. Auf der linken Seite sehen Sie eine Liste meiner registrierten benutzerdefinierten Anspruchsanbieter (in diesem Beispiel nur einer). Die Kontrollkästchen darunter dienen zum Ändern der IsEnabled- und der IsUsedByDefault-Eigenschaft für den ausgewählten registrierten benutzerdefinierten Anspruchsanbieter.

Hinweis
Die Anwendung "Claims Provider Activation" können Sie unter Configuring a Custom Claims Provider to Be Used Only on Select Zones in SharePoint 2010 herunterladen und ausprobieren.

Abb. 1. Anwendung "Claims Provider Activation" mit registrierten benutzerdefinierten Anspruchsanbietern

Anwendung für die Anspruchsanbieteraktivierung

Zum Festlegen der Eigenschaften wählen Sie zuerst den benutzerdefinierten Anspruchsanbieter aus, aktivieren Sie die entsprechenden Kontrollkästchen, um die IsEnabled- und die IsUsedByDefault-Eigenschaft festzulegen, und klicken Sie dann auf die Schaltfläche Aktualisieren.

Nachdem Sie für den Anspruchsanbieter IsEnabled, aber nicht IsUsedByDefault festgelegt haben, können Sie konfigurieren, wo er verwendet wird. Nach diesem Konfigurationsschritt wird der Anspruchsanbieter nur verwendet, wenn das SPIisSettings-Objekt für eine Zone den Namen des Anspruchsanbieters in der ClaimsProviders-Eigenschaft enthält. Diese Informationen zu erhalten, ist etwas schwieriger, wenn Sie einen generischen Ansatz anwenden, wie ich das für die Anwendung "Claims Provider Activation" getan habe. Der erste Schritt bestand darin, alle Webanwendungen aufzulisten. Dies geschieht mit der SPService-Klasse.

//Get the content service.
SPWebService ws = SPWebService.ContentService;
 
//Get each web application.
foreach (SPWebApplication wa in ws.WebApplications)
{
//Enumerate each zone in each web application.
}

Das Auflisten jeder Zone in einer Webanwendung ist ein weniger üblicher Vorgang. Im Folgenden ein entsprechendes Beispiel.

foreach (SPAlternateUrl aam in wa.AlternateUrls)
{
//Look at each zone to see whether it is using SAML claims.
}

Um festzustellen, ob in einer Zone SAML-Ansprüche verwendet werden, rufe ich zuerst das SPIisSettings-Objekt für die Zone ab. Wie schon erwähnt, brauche ich das zum Hinzufügen oder Entfernen des Anspruchsanbieters in der ClaimsProviders-Eigenschaft ohnehin. Im folgenden Codeausschnitt wird gezeigt, wie ich das SPIisSetting-Objekt für die Zone abrufe.

SPIisSettings curConfig = wa.GetIisSettingsWithFallback(aam.UrlZone);

In meiner curConfig-Variablen kann ich die ClaimsAuthenticationProviders-Eigenschaft überprüfen. Ist für eine Zone die Verwendung von Ansprüchen konfiguriert, dann ist die ClaimsAuthenticationProviders-Eigenschaft nicht null, und der Zähler ist größer als null.

Ich liste alle Anspruchsanbieter auf, und wenn ich feststelle, dass der Anspruchsanbieter mit dem SPIisSettings-Objekt für eine Zone den Namen des Anspruchsanbieters in der ClaimsProviders-Eigenschaft enthält, füge ich die Zone meiner Liste der Zonen hinzu und zeige sie als aktiviert an. Andernfalls kann ich den benutzerdefinierten Anspruchsanbieter nicht mit dieser Zone verwenden. Also füge ich die Zone dennoch der Liste der Zonen hinzu, zeige sie aber als deaktiviert an.

Das sind im Wesentlichen die Schritte, um die Liste der Webanwendungen und Zonen zu generieren und zu ermitteln, welche Zonen einen benutzerdefinierten Anspruchsanbieter verwenden können.

Nachdem diese Zonenliste nun fertig ist, wird der Anspruchsanbieter für eine bestimmte Zone verwendet, wenn der Name des Anspruchsanbieters in der ClaimsProviders-Eigenschaft des SPIisSettings-Objekts enthalten ist.

Die ClaimsProviders-Eigenschaft ist im Prinzip ein IEnumerable vom Typ string. Deshalb ist das Arbeiten mit dieser Eigenschaft ein bisschen umständlich, weil sie keine überladene Methode zum Hinzufügen oder Entfernen von Elementen mit Add bzw. Remove oder RemoveAt enthält. Das Problem umgehe ich, indem ich die Eigenschaft in ein List<string> konvertiere, sodass ich den Namen des Anspruchsanbieters hinzufügen oder entfernen kann, und dann das List<string> wieder der ClaimsProviders-Eigenschaft zuweise.

Es folgt ein entsprechende Codebeispiel.

List<string> providers = theZoneIisSettings.ClaimsProviders.ToList();
 
//NOTE: myClaimProvider is type SPClaimProviderDefinition.
if (EnableProvider)
providers.Add(myClaimProvider.ClaimProvider.Name);
else
       providers.Remove(myClaimProvider.ClaimProvider.Name);
 
//Plug the new values back into the ClaimsProviders Ienumerable.
theZoneIisSettings.ClaimsProviders = providers;
 
//You must get the web application that contains the zone, and then call its
//Update method to save your changes.
theWebApp.Update();

Abbildung 2 zeigt, wie die Webanwendung und die Zonenauswahl in der Anwendung "Claims Provider Activation" aussehen.

Abb. 2. Webanwendung und Zonen für einen bestimmten benutzerdefinierten Anspruchsanbieter in der Anwendung "Claims Provider Activation"

Anwendung und Zonen für die Anspruchsanbieteraktivierung

In diesem Fall wird Enable Basketball Teams angezeigt, weil mein Anbieter "Basketball Teams" nicht für diese Zone aktiviert ist. Wäre dieser Anbieter aktiviert, dann würde Disable Basketball Teams angezeigt. Wie Sie sehen, ist in den Zonen darüber die Webanwendung SharePoint – Anon Profile Test deaktiviert. Der Grund hierfür ist, dass für diese Zonen die Verwendung von SAML-Ansprüchen nicht konfiguriert ist.

So funktioniert das also. Etwa kompliziert, aber mit viel Flexibilität für die Konfiguration.

Tipp 2: Auflösen von Anspruchsnamen

Es ist schon einige Male vorgekommen, dass beim Auflösen von Anspruchsnamen Fehler auftreten. Deshalb möchte ich ein paar Hinweise zu diesem Problem geben, die Ihnen vielleicht helfen, falls Sie gerade bei der Problembehandlung sind. In manchen Fällen hat zum Beispiel die Namensauflösung nicht funktioniert. Wenn Sie beispielsweise einen Namen im entsprechenden Steuerelement eingeben und dann auf die Schaltfläche Auflösen klicken, kann dieses Problem auftreten. Sie können sogar einen Debugger anfügen, wenn Sie einen benutzerdefinierten Anspruchsanbieter entwickelt haben, und Sie sehen vielleicht, dass der Anspruchsanbieter das Richtige tut, aber der Name, den Sie eingegeben haben, ist immer noch rot unterschlängelt und die Suche ergibt keine Entsprechungen.

Sie werden bei diesem Problem feststellen, dass auch die standardmäßigen Anspruchsanbieter nicht mehr funktionieren. Wenn Sie z. B. NT Authority/All Authenticated Users eingeben, kann dies nicht aufgelöst werden.

Was hier passiert, ist, dass irgendwo ein Anspruchsanbieter eine Ausnahme auslöst, wenn sein FillResolve-Überladevorgang aufgerufen wird. Das Beunruhigende daran ist, wie Sie vielleicht aufgrund der Einleitung zu diesem Tipp schon ahnten, dass dies bedeutet, ein einziger fehlerhafter Anspruchsanbieter kann die gesamte Namensauflösung in einer Farm außer Funktion setzen.

Wenn Sie also in der Situation sind, dass die standardmäßigen Anspruchsanbieter keine Namen auflösen können, untersuchen Sie als Erstes die benutzerdefinierten Anspruchsanbieter. Sie müssen sie wahrscheinlich einen nach dem anderen entfernen, um den problematischen Anspruchsanbieter zu finden, wenn Sie nicht alle diese benutzerdefinierten Anspruchsanbieter selbst geschrieben haben. Natürlich ist das Entfernen dieser Anspruchsanbieter nicht ganz ohne, denn wenn Sie sie in einer anderen Reihenfolge wieder hinzufügen, generieren sie nicht die gleichen zugrunde liegenden Ansprüche wie vorher (weil die Ansprüche zum Teil darauf basieren, in welcher Reihenfolge die Anspruchsanbieter hinzugefügt wurden).

Wir wollen uns hier aber in erster Linie damit befassen, wonach wir suchen sollen, wenn dieses Problem mit der Namensauflösung besteht, und wie wir es beheben können.

Hinweis
Ein Punkt, den die obigen Informationen hoffentlich deutlich machen, ist, dass Entwickler von benutzerdefinierten Anspruchsanbietern keine Ausnahmen in Anspruchsanbietern auslösen sollten. Wenn Sie das dennoch tun, riskieren Sie es, der "böse" Anbieter zu sein, der die Namensauflösung in einer Farm möglicherweise unterbindet.

Tipp 3: Anmelden und die gefürchteten drei Eingabeaufforderungen bei der Authentifizierung

Das Problem mit den drei Eingabeaufforderungen bei der Authentifizierung tritt nur allzu häufig auf. Ich hatte dieses Problem erst letztes Wochenende, allerdings auf meinem Active Directory-Verbunddienste-Server (Active Directory Federation Services, AD FS), den ich unglücklicherweise gerade neu erstellte. Die Ursache für die Eingabeaufforderungen liegt meist in einer falsch konfigurierten Einstellung für das Kerberos-Protokoll oder darin, dass ein anderer Name verwendet wird als der Servername für eine Webanwendung (das Szenario mit deaktiviertem Loopback).

Dieses Problem war jedoch anderer Natur und spezifisch für einen AD FS-Server, deshalb wollte ich es zum Nachlesen dokumentieren.

Der Active Directory-Verbunddienste (AD FS) 2.0 ist gut für das Schreiben von Problemen in das Ereignisprotokoll. Wenn Sie die Ereignisanzeige öffnen, sehen Sie einen separaten Knoten für AD FS 2.0. Dieser AD FS 2.0-Knoten ist die richtige Stelle, um herauszufinden, was das Problem ist. In meinem speziellen Fall fand ich die Störquelle hier. Nur brauchte ich dazu eine ganze Weile, weil es mehrere Dinge gibt, die die gefürchteten drei Eingabeaufforderung verursachen können.

Als ich meinen AD FS-Server konfigurierte, tat ich Folgendes:

Ich konfigurierte den AD FS-Server für die Ausführung als Domänenkonto.
Ich verwendete ein Zertifikat, das ich nur für AD FS für die Tokensignatur erstellt hatte.

Das Problem war, dass das Dienstkonto, das ich für AD FS verwendete, nicht die erforderlichen Berechtigungen für den privaten Schlüssel für mein Tokensignaturzertifikat hatte. Das verursachte die drei Eingabeaufforderungen bei der Anmeldung. Das ist interessant und erstaunlich, gleichzeitig aber auch frustrierend.

Führen Sie folgende Schritte aus, um dem Dienstkonto Berechtigungen für den privaten Schlüssel für das Zertifikat zu erteilen:

Führen Sie Microsoft Management Console (MMC) aus.
Fügen Sie das Zertifikat-MMC-Snap-In(Certmgr.dll) für Lokaler Computer hinzu.
Öffnen Sie den Knoten Persönlich.
Klicken Sie mit der rechten Maustaste auf das Tokensignaturzertifikat, und wählen Sie dann Private Schlüssel verwalten aus.

Ich hoffe, diese Hinweise tragen dazu bei, dass irgendjemand später einmal Zeit spart.

Tipp 4: Hinweis auf die Standardlösungsbereitstellungen für benutzerdefinierte Anspruchsanbieter

Ein Freund von mir, Tom W. (der das Whitepaper über SharePoint 2010 Kerberos geschrieben hat), hat die Begrenzungen bei der Lösungsbereitstellung und deren Auswirkungen auf benutzerdefinierte Anspruchsanbieter angesprochen. Ein guter Punkt. Es ist wichtig, daran zu denken, dass ein benutzerdefinierter Anspruchsanbieter, den Sie entwickeln, an mehreren Stellen zusätzlich zu den Webanwendungen für Endbenutzer verwendet werden kann. Wenn Sie beispielsweise Webanwendungsrichtlinien in der Zentraladministration erstellen, wird er dort verwendet. Wenn Sie Benutzerrechte für Meine Website-Websites konfigurieren, wird er dort aufgerufen. Wenn Sie den Einmaliges Anmelden verwenden, wird er auch dort aufgerufen.

Das Problem manifestiert sich, wenn Sie größere Farmen ausbauen. Da diese Dienste Aufrufe in das Framework der benutzerdefinierten Anspruchsanbieter ausführen, muss die Assembly jedes benutzerdefinierten Anspruchsanbieters im globalen Assemblycache auf jedem dieser Server platziert werden. Das SharePoint-Framework zur Lösungsentwicklung stellt Lösungen aber standardmäßig nur auf Web-Front-End-Servern bereit.

Wenn Sie das Schema für die Lösungsbereitstellung betrachten, sind Ihre einzigen Optionen für das DeploymentServerType-Attribut der ApplicationServer-Wert oder der WebFrontEnd-Wert. Sie brauchen in Wirklichkeit beide, und zwar aus folgendem Grund: In größeren Farmen führen Sie den Webanwendungsdienst vielleicht nicht auf den Anwendungsservern aus. Ist das so, dann fehlen die benutzerdefinierten Anspruchsanbieter im globalen Assemblycache auf diesen Servern. Wenn Sie jetzt versuchen, eines der Features zu verwenden, die das Framework für die benutzerdefinierten Anspruchsanbieter aufrufen, verursachen Sie Fehler, weil die Assembly fehlt.

Leider sind die folgenden Behelfslösungen derzeit die einzigen Problemumgehungen:

Führen Sie den Webanwendungsdienst auf allen Servern in der Farm aus.
Schreiben Sie einen benutzerdefinierten Bereitstellungsauftrag, einen Ereignisempfänger, einen Zeitgeberauftrag oder etwas Ähnliches, um die Assembly auf allen Anwendungsservern bereitstellen zu können.
Stellen Sie die Assembly manuell bereit.

Keine dieser Optionen ist besonders reizvoll. Wenn Sie sich für eine entscheiden müssen, würde ich zur ersten Option raten (den Webanwendungsdienst auf allen Servern in der Farm ausführen), wobei Sie diese Server aus dem Lastenausgleichspool für die Endbenutzer heraushalten müssen.

Fürs Erste wollte ich diesen Punkt einfach nur ansprechen, damit Sie sich des Problems bewusst sind und ggf. für Ihre Farm entsprechend planen können. Vielen Dank nochmals an Tom für den Hinweis.

Tipp 5: Auflösen eines "TrustedMissingIdentityClaimSource"-Fehlers mit anspruchsbasierter Authentifizierung

Der Fehler TrustedMissingIdentityClaimSource ist bei anderen und bei mir einige Male aufgetreten, deshalb hier einige Hinweise zur wahrscheinlichen Fehlerquelle. Das Szenario ist folgendes: Sie richten anspruchsbasierte Authentifizierung in SharePoint 2010 ein. Sie sind ziemlich sicher, dass Sie alles korrekt konfiguriert haben.

Dennoch erhalten Sie bei dem Versuch, zu der Website zu navigieren, die standardmäßige Microsoft ASP.NET-Fehlerseite mit der Angabe eines TrustedMissingIdentityClaimSource-Fehlers (unter der Annahme, dass Sie benutzerdefinierte Fehler deaktiviert haben). Am häufigsten tritt dieser Fehler auf, wenn E-Mail-Adressen als Identitätsanspruch konfiguriert sind, die Person, mit deren Daten Sie sich anmelden möchten, aber keine E-Mail-Adresse in Active Directory (oder einem anderen von Ihnen verwendeten Verzeichnis) hat. Verwirrung kann auftreten, weil Sie zu AD FS umgeleitet werden (im Kontext dieser Erklärung hier könnte es jeder beliebige Sicherheitstokendienst für Identitätsanbieter sein). Sie sehen, dass Sie dort authentifiziert worden sind, erhalten dann aber den TrustedMissingIdentityClaimSource-Fehler für Microsoft SharePoint Server.

Dieser Fehler erinnert Sie vielleicht wieder an den Unterschied zwischen der Person, die Sie sind (die Identität, unter der Sie sich anmelden), und anderen Informationen über Sie (z. B. Attribute wie E-Mail-Adresse und andere Ansprüche, die für die Bereitstellung von Berechtigungen in SharePoint 2010 herangezogen werden können).

Wenn Sie diesen Fehler also erhalten, empfehle ich Ihnen, als Erstes zu überprüfen, ob das Benutzerkonto, unter dem Sie sich anmelden, einen Wert für den Identitätsanspruch aufweist, den der Identitätsanbieter erwartet. Bedenken Sie auch Folgendes: Wenn dieses Attribut keinen Wert enthält, wird der Anspruch in der Regel nicht einmal an SharePoint Server gesendet (d. h. er wird z. B. nicht als leerer Zeichenfolgenwert gesendet).

Schlussbemerkung

Dieser Artikel enthält Antworten auf einige häufig gestellte Fragen zur anspruchsbasierten Authentifizierung in SharePoint 2010. Außerdem finden Sie hier fünf Tipps sowie Anleitungen zur Lösung von Problemen im Zusammenhang mit dem Konfigurieren von Ansprüchen, und es wird auf andere Ressourcen mit weiteren Informationen hingewiesen.

Weitere Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen:

Freigeben über