Informationen zu Datenverbindungen, zur Authentifizierung und zur alternativen Zugriffszuordnung

Letzte Änderung: Dienstag, 13. April 2010

Gilt für: SharePoint Server 2010

Inhalt dieses Artikels
Universal Data Connections
Datenverbindungsauthentifizierung
Alternative SharePoint-Zugriffszuordnung und Datenverbindungen

Die Verwendung von Datenverbindungen in browserfähigen InfoPath-Formularvorlagen kann möglicherweise zu Problemen im Hinblick auf Verwaltbarkeit und Authentifizierung führen, die Sie berücksichtigen sollten. Sie können diesen Problemen Rechnung tragen, indem Sie UDC-Dateien (Universal Data Connection) verwenden, um die Datenverbindungsinformationen von der Formularvorlagen zu trennen, indem Sie Secure Store Service (den Ersatz für das Feature für einmaliges Anmelden (Single Sign-On, SSO)) verwenden, um Authentifizierungsanforderungen in mehrstufigen Architekturen gerecht zu werden, und indem Sie den mit InfoPath Forms Services bereitgestellten Webdienstproxy verwenden.

Universal Data Connections

SharePoint Foundation bietet Unterstützung für eine Datenverbindungsbibliothek (Data Connection Library, DCL). Hierbei handelt es sich um eine Bibliothek, die zwei verschiedene Arten von Datenverbindungen, Office Data Connection-Dateien und Universal Data Connection-Dateien (UDC), enthalten kann. Microsoft InfoPath 2010 verwendet Datenverbindungen, die dem UDC-Dateischema entsprechen und üblicherweise die Dateierweiterung UDCX oder XML aufweisen. Durch diese UDC-Dateien, die auf dem Server gespeichert und in Standardformularvorlagen und browserfähigen Formularvorlagen verwendet werden, können unterschiedliche Datenquellen beschrieben werden.

Die Verwendung einer UDC-Datei, die sich in einer Datenverbindungsbibliothek befindet, bietet folgende Vorteile:

• Formulardesigner können Formularvorlagen-Datenverbindungen konfigurieren, die auf dem InfoPath-Client und in InfoPath Forms Services funktionsfähig sind.

• Formulardesigner können eine Formularvorlage auf mehreren Servern veröffentlichen und verschiedene Datenverbindungseinstellungen für jeden Server verwenden, ohne die Datenverbindungsinformationen in der Formularvorlage ändern zu müssen.

• Formulardesigner können eine Domänen-Sicherheitsformularvorlage veröffentlichen, die auf Datenquellen in einer anderen Domäne zugreifen kann.

• Administratoren können Datenverbindungen umleiten, ohne Formularvorlagen, die auf die UDC-Datei verweisen, ändern zu müssen.

• Administratoren können festlegen, welche Verbindungen für den domänenübergreifenden Zugriff zugelassen sind.

• Administratoren können Datenverbindungen auf einem Server veröffentlichen, die dann von mehreren Servern gemeinsam genutzt werden können.

Informationen zum Erstellen einer Datenverbindungsbibliothek finden Sie unter Gewusst wie: Erstellen und Verwenden einer Datenverbindungsbibliothek. Formularvorlagen werden stets unter Verwendung von UDC-Dateien in einer Datenverbindungsbibliothek entworfen; die Verbindung kann jedoch so konfiguriert werden, dass eine zentral verwaltete Version der UDC-Datei verwendet wird. Diese zentral verwalteten UDC-Dateien werden von einem Serveradministrator hochgeladen. Um UDC-Dateien zentral zu verwalten, müssen Sie zur Seite Anwendungsverwaltung der Website für die SharePoint-Zentraladministration navigierenund dann im Abschnitt InfoPath Forms Services auf Datenverbindungsdateien verwalten klicken.

Wenn die UDC-Datei vom Administrator hochgeladen wird, müssen Sie Datenverbindungen so konfigurieren, dass sie die Option Zentral verwaltete Verbindungsbibliothek verwenden. Wählen Sie hierfür im Datenverbindungs-Assistenteneine Verbindung aus, und klicken Sie auf die Schaltfläche Verbindungsoptionen.

Wichtig
Beide UDC-Dateien müssen denselben Namen aufweisen. Die Datenverbindung auf der lokalen Website kann gelöscht werden, nachdem ein Link zur zentral verwalteten Datenverbindung hergestellt wurde. Eine weitere Bearbeitung der Formularvorlage unter Verwendung der gelöschten Datenverbindung ist mithilfe des Datenverbindungs-Assistenten dann jedoch nicht mehrmöglich.

Unterstützte Datenquellen

UDC-Dateien können unterschiedliche Datenquellen beschreiben, da sie, anders als frühere Office Data Connection-Dateien, eine größere Vielfalt von Datenquellen unterstützen. Doch obwohl die meisten Datenquellen, die in einer InfoPath-Formularvorlage konfiguriert werden können, unterstützt werden, gibt es einige Datenverbindungstypen, z. B. E-Mail: Absenden, die nicht in einer UDC-Datei beschrieben werden können.

Zu den zulässigen Datenquellen gehören folgende:

• Microsoft SQL Server-Datenbankabfrage

• Webdienstabfrage oder Webdienst: Absenden

• XML-Dateiabfrage (die XML-Datei befindet sich auf einem Remoteserver)

• SharePoint-Bibliothek: Absenden

• SharePoint-Listenabfrage

• Webserver: Absenden (HTTP Post)

Hinweis
Der Zugriff auf den Datenverbindungs-Assistenten zum Erstellen einer UDC-Datei für eine HTTP Post-Verbindung erfolgt über das Dialogfeld Absendeoptionen, indem Sie auf der Registerkarte Daten auf Absendeoptionen klicken, und nicht über das Dialogfeld Datenverbindungen, das durch Klicken auf Datenverbindungen auf der Registerkarte Daten geöffnet wird.

Datenverbindungsauthentifizierung

Während in InfoPath geöffnete Formulare direkt mit den Datenquellen kommunizieren können, die für die Formularvorlage konfiguriert sind, kommunizieren im Browser geöffnete Formulare direkt mit dem Server mit InfoPath Forms Services (entweder einem einzelnen Server oder einem Web-Front-End). Dies führt zu dem so genannten Problem der doppelten Hops (Double Hop). Das Problem der doppelten Hops (oder genauer gesagt das Problem von Mehrfachhops) stellt ein Authentifizierungsproblem dar: Anmeldeinformationen, die für den Zugriff auf Ressourcen auf einem dritten Computer oder der dritten Schicht benötigt werden, können nicht in den von der zweiten Schicht ausgehenden Anforderungen für diese Ressourcen verwendet werden.

Hinweis
Es wird davon ausgegangen, dass jede Schicht, für die die Authentifizierung erforderlich ist, ein Windows-Computer im Netzwerk ist, dessen Konfiguration die NTLM-Authentifizierung vorsieht.

Angenommen, ein Formular im Browser (erste Schicht) kommuniziert mit einem Server, auf dem InfoPath Forms Services ausgeführt wird (zweite Schicht), der wiederum auf Ressourcen auf einem Datenbankserver oder auf einer Netzwerkfreigabe (dritte Schicht) zugreifen muss. Das primäre Sicherheitstoken, das zwischen dem Browser und dem Server mit InfoPath Forms Services verwendet wurde, kann nicht an den Datenbankserver übergeben werden. Zurückzuführen ist dies auf spezifische Delegierungsbeschränkungen, die dem NTLM-Authentifizierungssystem, das Microsoft Windows zwischen dem Browser und dem Server mit InfoPath Forms Services verwendet, inhärent sind.

Dieses Problem wird Ihnen häufiger im Zusammenhang mit Formularen im Browser begegnen, da Formulare in InfoPath sich direkt bei der Datenquelle authentifizieren können, indem sie das primäre Sicherheitstoken an diesen Server übergeben, so wie es vom Browser an den Server mit InfoPath Forms Services übergeben wird.

Der Secure Store Service stellt die bevorzugte Methode dar, um Probleme der Delegierung in mehrstufigen Architekturen zu lösen. Es gibt jedoch noch andere Möglichkeiten, falls Secure Store Service nicht verfügbar ist.

Delegierungslösungen in mehrstufigen Architekturen, wenn Secure Store Service nicht verfügbar ist

Standard-/Digestauthentifizierung: Diese Art der Authentifizierung wird normalerweise für Standard-HTML-Formulare verwendet und eignet sich für InfoPath-Formulare, die in Extranetszenarios verwendet werden. Dem Benutzer wird ein Dialogfeld zur Eingabe der Anmeldeinformationen angezeigt, die für den Zugriff auf Ressourcen auf dem Webserver der dritten Schicht benötigt werden. Diese Anmeldeinformationen können für einen weiteren Hop zu einem weiteren Windows-Computer verwendet werden. Wenn der Server für die Standardauthentifizierung konfiguriert ist, sendet er diese Anmeldeinformationen unverschlüsselt, wohingegen die Anmeldeinformationen bei der Digestauthentifizierung als MD5-Hash oder Nachrichtenhash über das Netzwerk gesendet werden.

Eingebettete Anmeldeinformationen: Das Einbetten von Anmeldeinformationen in eine UDC-Datei ist ein mögliches Verfahren, das jedoch nur verwendet werden sollte, wenn die Sicherheit der Benutzernamen- und Kennwortinformationen für den Zugriff auf die Ressource nicht gefährdet ist.

Verwenden eines anonymen Kontos/Dienstkontos: Wenn die SharePoint-Website so konfiguriert ist, dass sie den anonymen Zugriff zulässt, verwendet der Server ein anonymes Konto, um auf Ressourcen der dritten Schicht zuzugreifen.

Kerberos: Kerberos ist ein Authentifizierungsprotokoll, das so konzipiert ist, dass die Delegierung in mehrstufigen Architekturen unterstützt wird. Mithilfe von Kerberos kann sich ein Benutzer mit seinem Benutzernamen und seinem Kennwort bei einem Schlüsselverteilungscenter-Server (Key Distribution Center, KDC) authentifizieren und erhält ein Kerberos-Ticket. Das Ticket wird verschlüsselt und durch einen Verifizierer ergänzt und kann nur vom Server entschlüsselt werden. Auf jeder Schicht der Anwendung kann das Ticket unabhängig durch das KDC überprüft werden, ohne dass die Anmeldeinformationen des Benutzers erforderlich sind.

Eingeschränkte Delegierung: Windows Server 2003 umfasst zwei Erweiterungen des Kerberos-Diensts: die eingeschränkte Delegierung und den Protokollübergang. Diese Dienste ermöglichen es Windows, in Extranetszenarios, in denen der Client Kerberos nicht verwenden kann oder der Port 88 (der Kerberos-Port) gesperrt ist, ein Kerberos-Ticket stellvertretend für einen Benutzer zu erhalten. Von den meisten Internetservern und Unternehmensfirewalls wird Port 88 standardmäßig gesperrt. Um die eingeschränkte Delegierung verwenden zu können, muss auf allen Clients mindestens Windows XP und auf allen Servern mindestens Windows Server 2003 ausgeführt werden. Darüber hinaus muss die eingeschränkte Delegierung aktiviert und in Active Directory konfiguriert werden.

Formularbasierte Authentifizierung: SharePoint-Administratoren können die formularbasierte Authentifizierung als Mechanismus angeben, der von Benutzern für die Authentifizierung beim Server verwendet wird. Bei der formularbasierten Authentifizierung geschieht Folgendes:

1. Der Benutzer gibt eine HTTP-Anforderung an das Web-Front-End (WFE) aus.

2. Das WFE gibt eine HTTP 302-Antwort (Umleitung) zurück, die auf ein Webformular zeigt.

3. Der Benutzer gibt Anmeldeinformationen in das Webformular ein.

4. Die Anmeldeinformationen werden durch einen Plug-in-Authentifizierung eines Drittanbieters überprüft und Anmeldeinformationen zugeordnet, die das WFE erkennt (z. B. eine SharePoint-ID).

Am Ende des Prozesses verfügt der Benutzer über eine gültige SharePoint-ID. Allerdings verfügt InfoPath Forms Services nicht über gültige Windows-Anmeldeinformationen, die zum Herstellen einer Verbindung verwendet werden können. Das Formular muss daher SSO oder eine andere Methode verwenden, um Anmeldeinformationen zu erhalten, die zum Herstellen einer Verbindung zur Datenquelle verwendet werden können.

Empfohlene Authentifizierungsmethoden: Secure Store Service und Webdienstproxy

Secure Store Service: Secure Store Service unterscheidet sich von den zuvor beschriebenen Methoden, die verwendet werden können, um alternative Anmeldeinformationen für das Herstellen von Verbindungen zu Ressourcen auf Servern jenseits der zweiten Schicht bereitzustellen. Secure Store Service besteht aus einer Datenbank, die Anwendungen und Benutzeranmeldeinformationen zu anderen Anmeldeinformationen zuordnet, und einer API, die die Secure Store Service-Funktionalität abstrahiert, sodass jeder Anbieter für einmaliges Anmelden, der einen Anbieter für diese API einschließt, verwendet werden kann. Die folgenden Anbieter für einmaliges Anmelden sind dazu geeignet, von einem Serveradministrator verwendet zu werden, der mit InfoPath-Formularen arbeitet:

• Office Server-Anbieter für einmaliges Anmelden

• Drittanbieter für einmaliges Anmelden

Weitere Informationen zum Konfigurieren von Secure Store Service finden Sie unter: Vorgehensweise: Herstellen einer Verbindung mit einem externen System mithilfe des Diensts für Einmaliges Anmelden, Gewusst wie: Herstellen einer Verbindung mit dem externen System mithilfe von Secure Store Service-Anmeldeinformationen, Business Connectivity Services-Sicherheit (Übersicht) (SharePoint Foundation 2010) und Business Connectivity Services-Sicherheit (Übersicht) (SharePoint Server 2010).

Mehrstufige Webdienstauthentifizierung mithilfe des Proxys: Um Webdienstanforderungen in einer mehrstufigen Architektur zu ermöglichen, wird der InfoPath Forms Services-Proxy bereitgestellt, der Webdienst-SOAP-Nachrichten aus dem Browserformular weiterleitet.

Die Option zum Aktivieren des Proxys befindet sich auf der Seite Anwendungsverwaltung der Website fürdie SharePoint-Zentraladministration. Klicken Sie im Abschnitt InfoPath Forms Services auf den Link Webdienstproxy verwalten, um den Proxy für vom Administrator bereitgestellte Formulare und/oder von Benutzern bereitgestellte Formulare zu aktivieren.

Hinweis
Das UseFormsServiceProxy-Attribut in der UDC-Datei muss auf true festgelegt werden, damit die SOAP-Nachricht vom Proxy weitergeleitet wird.

Alternative SharePoint-Zugriffszuordnung und Datenverbindungen

Die alternative Zugriffszuordnung in SharePoint ist ein Mechanismus, der Serverfarmadministratoren das Identifizieren der verschiedenen Verfahren ermöglicht, die Benutzer für den Zugriff auf Portalwebsites verwenden können. Hierdurch ist sichergestellt, dass die URLs in geeigneter Weise unter Berücksichtigung der Methode angezeigt werden, die Benutzer für den Zugriff auf SharePoint-Sites verwenden. Ein Benutzer in einem Unternehmensintranet würde beispielsweise über die URL http://benefits auf die Unternehmenswebsite für Sozialleistungen zugreifen, während ein Mitarbeiter des Unternehmens, der von zu Hause aus über das Extranet auf dieselbe Website zugreift, die URL https://benefits.mycompany.com verwenden würde.

Die alternative Zugriffszuordnung wirkt sich in der Regel nicht darauf aus, wie Datenverbindungen von InfoPath Forms Services gehandhabt werden. Wenn Benutzer jedoch sowohl von Intranet- als auch von Extranetstandorten aus auf Formulare zugreifen, sollte das Authentifizierungsmodell für Datenverbindungen für beide Standorte konfiguriert und getestet werden, um die ordnungsgemäße Funktionsweise sicherzustellen. Verbindungen zu einem Server, für die eine voll qualifizierten URL anstelle eines lokalen Servernamens verwendet wird, sind darauf angewiesen, dass die Konnektivität durch die alternative Zugriffszuordnung sichergestellt wird.

Zum Anzeigen der Einstellungen für die alternative Zugriffszuordnung in der SharePoint-Zentraladministration navigieren Sie zur Seite Vorgänge und klicken dort im Abschnitt Globale Konfiguration auf den Link Alternative Zugriffszuordnungen. Weitere Informationen zur alternativen Zugriffszuordnung erhalten Sie, wenn Sie im Microsoft SharePoint Server 2010 nach "alternative Zugriffszuordnung" suchen im TechNet.

Siehe auch

Konzepte

Gewusst wie: Erstellen und Verwenden einer Datenverbindungsbibliothek