Steffen über SQL Server und Business Intelligence

Steffen Krause - Microsoft Technical Evangelist

Blogs

Single Sign On

  • Comments 1
  • Likes

Zu den am meisten missverstandenen Features von SharePoint und Biztalk gehört der Single Sign On-Dienst. Daher hier einmal ein kleiner Überblick, was SSO eigentlich ist.

Ich erkläre das ganze mal auf Basis Sharepoint.

Der SSO-Dienst in Sharepoint dient dazu, Credentials, d.h. typischerweise Benutzernamen und Kennwörter, für den Zugriff auf Informationsquellen aus SharePoint Portal Server heraus sicher zu speichern und wieder abzurufen. Was bedeutet dieser lange Satz?

Dazu ein Beispiel: Angenommen, eine Firma hat ihre Vertriebsdaten in einer Oracle-Datenbank gespeichert. Diese Vertriebsdaten sollen nun im Vertriebsportal angezeigt werden, wobei die Oracle-Berechtigungen der jeweiligen Benutzer gewahrt werden müssen, damit jeder Nutzer nur die Daten sieht, auf die er Zugriff hat.

Dazu wird im SSO-Modul eine Anwendung "OracleVertrieb" eingerichtet. Der Administrator spezifiziert darin, welche Felder benötigt werden (hier Oracle-User und Passwort) und ob die Windows-Benutzer individuell auf die Oracle-Accounts gemappt werden oder ob Gruppen von Windows-Benutzern auf jeweils einem Oracle-Account zugeordnet werden. Im Beispiel sei die individuelle Zuordnung die richtige.

Wenn nun ein Windows-Benutzer auf die Sharepoint-Seite mit dem Oracle-Webpart zugreift überprüft der Webpart, ob dem angemeldeten Windows-Benutzer ein Oracle-Benutzer und Kennwort zugeordnet sind. Wenn nein gibt er dem Benutzer die Möglichkeit, seine Oracle-Credentials einzugeben. Wenn ja liest der Webpart die zugehörigen Oracle-Credentials aus dem SSO-Modul aus und verwendet sie, um im Namen des Benutzers Daten aus Oracle auszulesen. Was genau mit den Daten geschieht und wie sie dargestellt werden ist allein Sache des Webparts.

Grundsätzlich dient das Sharepoint-SSO-Modul also dazu, aus einem Sharepoint-Webpart heraus Daten aus einer Drittanwendung im Namen des angemeldeten Windows-Benutzers zuzugreifen. Es dient nicht dazu, direkten Zugriff auf Drittanwendungen vom Arbeitsplatz  des Benutzers aus zu ermöglichen.

Das Biztalk und Host Integration Server Enterprise SSO Modul bieten gegenüber dem SSO von Sharepoint erweiterte Möglichkeiten. Insbesondere ist es hier möglich, die Anforderung des Zugriffs und das tatsächliche Auslesen der Zugangsdaten zur Drittanwendung voneinander zu trennen. So wird beim Empfang einer Nachricht aufgezeichnet, welcher Benutzer die Daten anfordert. Diese Information wird verschlüsselt durch den gesamten Biztalk-Prozeß geleitet und erst der Biztalk-Adapter, der tatsächlich Daten aus dem Fremdsystem (z.B. SAP oder AS/400) liest ruft die Zugangsdaten aus dem SSO-Modul ab. Somit wird sichergestellt, dass kritische Accountdaten nur dort zugänglich sind, wo sie tatsächlich benötigt werden.

Die meisten Biztalk-Adapter können von Hause aus Zugangsdaten aus dem Enterprise SSO Modul abrufen, so dass hier die Integration recht einfach von statten geht. Von den Standard Sharepoint Portal Server Webparts kann leider nur das Datenansichts-Webpart aus Frontpage 2003 auf SSO zugreifen. Hier ist also der Programmierer gefordert.

Die beiden grundlegenden Vorteile der SSO-Module von Sharepoint und Biztalk gegenüber "selbstgestrickten" Lösungen besteht in der einfachen Administration (der Administrator kann leicht Anwendungszuordnungen anpassen, ändern, Accountinformationen erzeugen oder löschen (aber nicht auslesen!) oder den Zugang ganz sperren, sowie in der hohen Sicherheit (die SSO-Datenbanken arbeiten mit starker Verschlüsselung und sind gegen viele Angriffsszenarien getestet). Außerdem bieten immer mehr Hersteller Webparts und Biztalk-Adapter an, die sich mit SSO nutzen lassen.

Auf Wunsch kann ich später noch mehr zu SSO schreiben.

Steffen

Comments
  • Your language seems not english
    i can't understander.
    sorry!