Embed Size (px)
Citation preview
Integration von Microsoft .NET Passport in den infoAsset Broker
Jürgen Huber
Software Engineering betrieblicher Informationssysteme (sebis)
(Professor Matthes)
Technische Universität München
Betreuung
Dipl. -Ing. Kathrin Lehmann
21. Juli 2004
2
Gliederung 1. Einleitung......................................................................................................................... 3
1.1. Was ist „Single Sign On”? ...................................................................................... 3 1.2. Der infoAsset Broker ............................................................................................... 4
2. Passport – die Theorie ................................................................................................. 5 2.1. Microsoft .NET Passport......................................................................................... 5 2.2. Funktionsweise ........................................................................................................ 5 2.3. Kids Passport ........................................................................................................... 6 2.4. Passport SDK und Passport Manager ................................................................. 6 2.5. Umsetzung und Implementierung ........................................................................ 7
3. Hindernisse bei der Umsetzung ................................................................................ 9 3.1. Konflikt Java – ASP................................................................................................. 9 3.2. Environments ......................................................................................................... 10 3.3. Die LogoTag() – Methode .................................................................................... 11
4. Die Umsetzung – Integration in den Broker ......................................................... 13 4.1. Problemstellung und Lösungsüberblick ............................................................. 13 4.2. Use Cases .............................................................................................................. 15 4.3. Login ........................................................................................................................ 17 4.4. DefaultHandler ....................................................................................................... 18 4.5. Logout...................................................................................................................... 19 4.6. LogoutSubmitHandler ........................................................................................... 19 4.7. Templates ............................................................................................................... 21 4.8. ASP–Seiten............................................................................................................. 22 4.9. Lösungsalternativen .............................................................................................. 23
5. Passport aus Unternehmenssicht .......................................................................... 25 5.1. Warum „Single Sign On”? .................................................................................... 25 5.2. Möglichkeiten ......................................................................................................... 26 5.3. Schwachstellen ...................................................................................................... 27 5.4. Fazit ......................................................................................................................... 28
6. Literatur.......................................................................................................................... 29 7. Anhang ........................................................................................................................... 31
3
Kapitel 1 1. Einleitung
1.1. Was ist „Single Sign On”?
„Single Sign In“ (SSI) und „Single Sign On“ (SSO) sind Begriffe, die in den letzten
Jahren einiges an Aufmerksamkeit erregt haben. Trotzdem sind die Bedeutungen
dieser Begriffe oft unklar.
Mit steigender Informationsflut und dem Anstieg von Bezahldiensten und
eCommerce im Internet ist auch die Anzahl an Seiten und Diensten gewachsen für
die sich ein Benutzer registrieren muss. Er muss für jede(n) Seite/Dienst die er nutzt
erneut persönliche Angaben (wie beispielsweise Adresse und Bankverbindung)
machen und sich ein neues Login – Passwortpaar generieren und merken.
Um das Problem der wachsenden Anzahl von Login und Passwortpaaren zu lösen
wurden verschiedene SSI – Ansätze ins Leben gerufen. Das Grundprinzip dahinter
ist, dass ein Benutzer einmal ein Login und ein zugehöriges Passwort auf seinen
Namen registriert, und sich mit diesem dann bei allen anderen Seiten und Diensten
die dasselbe Authentifizierungssystem nutzen anmelden kann. Allerdings muss der
Benutzer bei diesem Verfahren immer noch bei jeder Seite seine persönlichen
Angaben hinterlegen. Es wird ihm nur die Authentifizierung erleichtert.
Eine Erweiterung dieses Prinzips1 stellt deshalb SSO dar, das prinzipiell eine Art
„Information-sharing“ darstellt. Der Benutzer hinterlegt zusätzlich zu seinem Login an
einer zentralen Stelle seine persönlichen Angaben auf die die Dienste dann bei
Bedarf zugreifen können. Außerdem bedeutet die Anmeldung bei einem Dienst die
gleichzeitige Anmeldung bei allen anderen Diensten.
1 [PSGK]
4
Es gibt viele Anbieter für SSO – Lösungen, aber die wichtigsten sind derzeit
Microsoft mit seinem .NET Passport Dienst und in direkter Konkurrenz dazu das
Liberty Alliance Project2.
Im Rahmen dieses Systementwicklungsprojektes war Microsoft .NET Passport zu
Authentifizierungszwecken in den infoAsset Broker3 zu integrieren.
1.2. Der infoAsset Broker
Der infoAsset Broker (für dieses Projekt wurde eine Erweiterung für Weblogs, der
Weblogbroker 1.0 verwendet) ist eine Softwarelösung für das Wissensmanagement.
Die Software wird serverseitig installiert. Zur Benutzung ist auf der Clientseite nur ein
Webbrowser notwendig. Es müssen keinerlei zusätzliche Software oder Plug-ins
installiert werden. In erster Linie kann der infoAsset Broker für
Dokumentenmanagement, -bewertung und -veröffentlichung, zur Verwaltung von
Benutzer- und Nutzungsprofilen und zur Zugriffskontrolle verwendet werden.
Vorhandenes Wissen wird dabei klassifiziert, versioniert, bewertet und strukturiert
und damit eine Wissenslandkarte geschaffen. Benutzer können in Gruppen
zusammengefasst werden mit gruppenspezifischen Zugriffsrechten. Die Benutzung
des Brokers kann für jeden personalisiert werden. Es stehen Sammelmappen zur
Verfügung in denen jeder Benutzer Dokumente nach seinen eigenen Interessen und
Vorlieben zusammenstellen und bewerten kann. Durch die Bewertungen entstehen
Benutzerprofile mit deren Hilfe die im Broker vorhandenen Dokumente effektiver
durchsucht werden können.
2 http://www.projectliberty.org/ 3 http://www.infoasset.de/
5
Kapitel 2 2. Passport – die Theorie
2.1. Microsoft .NET Passport
Microsoft .NET Passport ist das SSO System von Microsoft, das ein Benutzer von
Hotmail, dem E-Maildienst von Microsoft, oder von MSN, Microsofts Webportal das
vor allem auf Nachrichten und eCommerce spezialisiert ist, automatisch mitbenutzen
kann. Dabei wird der Passportdienst nur für die Benutzerauthentifizierung verwendet.
Die Erweiterung MSN Wallet wird benutzt um persönliche Daten für eCommerce,
also beispielsweise Adresse und Bankverbindung, zu speichern.
Für Webseitenbetreiber die den Passportdienst nutzen wollen hält Microsoft ein SDK
und Verwaltungstools bereit um die Integration von Passport in die Seite des
Betreibers zu vereinfachen aber auch zu standardisieren.
2.2. Funktionsweise
Wenn .NET Passport zu Authentifizierungszwecken genutzt wird, ist der prinzipielle
Ablauf folgender: Der Benutzer surft mit seinem Webbrowser auf eine Webseite, die
die Passportfunktionalität anbietet um einen Benutzer zu identifizieren. Die Seite
erkennt, dass der Benutzer sich noch nicht bei Passport angemeldet hat. Sie zeigt
ihm deshalb einen Passport Sign-in Button an. Wenn der Benutzer auf diesen klickt
wird er an die Passportserver von Microsoft weitergeleitet. Hier wird ihm eine
Webseite angezeigt, auf der er seinen Benutzernamen und sein Passport eingeben
muss. Das Login – Passwort Paar wird verifiziert und anschließend wird der Benutzer
6
an die ursprünglich aufgerufene Webseite zurückgeleitet. Dem Benutzer wird ein
sogenanntes Ticket in Form eines verschlüsselten Cookies ausgestellt, das ihm die
Authentizität seiner Angaben bescheinigt und das mit einer Gültigkeitsdauer
versehen ist. Darüber hinaus enthält ein zweiter Cookie das persönliche Profil des
Benutzers, also z.B. seine Adresse und seine Emailadresse, und eine „Passport
unique ID“ (ein 16 Zeichen langer Hexadezimalwert) über den der Benutzer eindeutig
identifiziert werden kann. Die ursprüngliche Webseite kann die Daten des Tickets
auslesen und ihm danach die entsprechenden Zugriffsrechte gewähren. Durch das
Verwenden eines Cookies können alle Webseiten, die später angesurft werden und
ebenfalls die Passportfunktionalität nutzen, den Benutzer als bereits angemeldet
erkennen.
Das Logout wird einfach durch Setzen der Cookieinhalts auf „null“ und durch Setzen
der Gültigkeitsdauer auf eine vergangene Zeit realisiert.
2.3. Kids Passport
Darüber hinaus gibt es noch den Kids Passport Service, bei dem die persönlichen
Angaben über die Kinder von den Eltern gemacht werden können und bei dem die
Eltern auch einstellen können welche Daten Webseiten über ihre Kinder sammeln
dürfen und welche nicht. Außerdem können Einschränkungen gesetzt werden
welchen Inhalt Kinder sehen dürfen.
2.4. Passport SDK und Passport Manager
Um Microsoft .NET Passport auf einer Webseite zu integrieren müssen das Passport
Software Development Kit (SDK)4 und der darin enthaltene Passport Manager
installiert werden. Danach ist es erforderlich die eigene Webseite bei den
Passportservern anzumelden. Hier muss zumindest die URL unter der die Webseite
zu erreichen ist, eine URL zu der der Benutzer nach erfolgter Anmeldung
zurückgeleitet wird und die URL unter der das Sign-out implementiert ist, angegeben
werden. Nach erfolgter Anmeldung erhält man eine Site-ID und eine Datei die einen
4 http://msdn.microsoft.com/library/default.asp?url=/downloads/list/websrvpass.asp
7
zur Site-ID passenden Schlüssel enthält. Mit dem Schlüssel kann der Inhalt der
Cookies entschlüsselt werden und mit den Passportservern über einen sicheren
Kanal kommuniziert werden.
Die erhaltene Site-ID wird anschließend im Passport Manager, einem grafischen Tool
zur Wartung der Passporteinstellungen, eingetragen. Hier hat man dann noch die
Möglichkeit zwischen verschiedenen Environments zu wählen. Während der Test-
und Implementierungsphase sollte man das sogenannte „Preproduction-
Environment“ (PREP) einstellen. Microsoft hat einen Klon der Passportserver unter
der URL http://passporttest.net aufgesetzt. Solange sich die Webseite im PREP-
Environment befindet kann für Testzwecke mit diesem Klon kommuniziert werden.
Allerdings besteht hier nur die Möglichkeit Passportaccounts zu erkennen die auch
im PREP-Environment erstellt wurden. Echte Passport Benutzer können sich hier
nicht einloggen. Wenn die Implementierung beendet ist muss ein „Compliance
Review“ angefordert werden, bei dem sich Microsoft vergewissert, dass die Seite den
Passportstandards entspricht. Bei bestandenem Test kann die Seite dann in das
„Production-Environment“ wechseln, also live gehen. Die Compliance Reviews
werden in regelmäßigen Abständen wiederholt und kosten jedes Mal eine Gebühr
von 1.500$. Darüber hinaus wird eine jährliche Gebühr von 10.000$ pro
Unternehmen5 fällig.
2.5. Umsetzung und Implementierung6 7
Hat man diese Vorarbeiten einmal erledigt kann Passport in die eigene Webseite
integriert werden. Hierzu wird einfach ein PassportIdentity Objekt instanziiert, das
aller erforderlichen Methoden bereitstellt um einen Benutzer zu authentifizieren.
Abb.1 : PassportIdentity-Klasse
5 http://download.microsoft.com/download/a/f/4/af49b391-086e-4aa2-a84b-ef6d916b2f08/passport_reviewguide.doc 6 [PSGK], vollständige Dokumentation zum Passport SDK 7 [OC04]
PassportIdentitiy
GetIsAuthenticated(TimeWindow : Integer, ForceLogin : Boolean, UseSecureAuth : Boolean) : BooleanGetFromNetworkServer() : BooleanGetProfileObject(ProfileName : String) : ObjectLogoTag2(ReturnURL : String, TimeWindow : Integer, ForceLogin : Boolean, UseSecureAuth : Boolean) : String
8
Zusätzlich dazu muss in der Datei Web.config die Zeile
<authentication mode="Windows"> auf
<authentication mode="Passport"> gesetzt werden. Damit wird sichergestellt,
dass ein Benutzer nicht über seinen Windows – Account sondern über seinen
Passport – Account authentifiziert wird.
Zur Implementierung werden für eine Grundfunktionalität nur drei Methoden benötigt.
Mit der Methode „GetIsAuthenticated()“ kann überprüft werden, ob der Benutzer
einen gültigen und nicht abgelaufenen Ticketcookie besitzt. Die Gültigkeitsdauer für
das Ticket kann in der Methode bestimmt werden. So kann man zum Beispiel
festlegen, dass sich ein Benutzer innerhalb der letzten Stunde angemeldet haben
muss. Die Methode liefert den Wert „true“, wenn der Cookie den Anforderungen
entspricht.
Die zweite wichtige Methode ist „GetProfileObject()“. Mit ihr können die Attribute der
verschlüsselten Cookies ausgelesen werden. So kann man beispielsweise Name
oder Emailadresse auslesen.
Die Attribute „MemberIDHigh“ und „MemberIDLow“ aneinandergehängt ergeben die
„Passport unique ID“. Als letztes ist noch die „LogoTag()“ Methode zu nennen. Diese
überladene Methode erkennt selbstständig, ob der Benutzer über ein gültiges Ticket
verfügt, oder nicht, und zeigt dementsprechend den Sign-in oder den Sign-out
Button an (s. Abb.2). Es gibt auch noch die „LogoTag2()“ – Methode, die zusätzlich
die Möglichkeit bereithält, dass ein WindowsXP – Benutzer die in WindowsXP
integrierten Passportauthentifizierungsmöglichkeiten nutzt. Die URL die
angesprochen wird, wenn man auf den Sign-in Button klickt wird vom
PassportIdentitiy Objekt automatisch generiert. Sie hat folgende Syntax:
http://current-login.passporttest.com/login.srf?lc=1033&id=44559
Dabei stellt „lc“ die Sprache dar in der der Benutzer zur Eingabe seines Logins und
Passworts aufgefordert wird und „id“ die eigene Site-ID. (In diesem Fall also
Englisch, 1031 für Deutsch, und die Site ID die dieses Projekt zugewiesen bekam).
Abb.2 : Login- und Logout-Button
9
Kapitel 3 3. Hindernisse bei der Umsetzung
3.1. Konflikt Java – ASP
Bei der Integration von Microsoft .NET Passport in den infoAsset Broker gab es
einige Hindernisse, die eine reguläre Umsetzung verhindert haben.
Der augenscheinlichste Punkt ist, dass Passport eine .NET – Anwendung ist. Um sie
zu implementieren und auszuführen wird eine .NET – Umgebung samt zugehörigen
Internet–Information–Diensten (IIS) auf dem Server erwartet. Für gewöhnlich wird
Passport auf Active Server Pages (ASP) implementiert und diese dann unter IIS
ausgeführt. Das hat zur Folge, dass die Webseite die Passportfunktionalität anbieten
will auch als ASP – Seite implementiert sein muss. Da oben genanntes
PassportIdentity – Objekt für die gesamte Kommunikation mit den Passportservern
und die Entschlüsselung und Auswertung des Ticketcookies übernimmt, ist auch die
Tatsache nicht zu umgehen, dass das PassportIdentity Objekt nur in .NET
Umgebungen instanziierbar ist.
Der infoAsset Broker seinerseits ist aber in Java implementiert. Der Broker arbeitet
mit verschiedenen Handlern, die je nach Situation (Benutzer, Rolle, angeforderte
Seite uvm.) vorgegebene Templates mit Inhalt befüllen und daraus dann HTML
Seiten generieren. Diese werden dann dem Benutzer im Webbrowser angezeigt.
Da der Broker unverändert als Javaanwendung bestehen bleiben soll, muss folglich
eine Kommunikation mit den entsprechenden ASP Seiten stattfinden. Zunächst
wurde der Port des Brokers von 80 (der Standardport für http Verkehr) auf 88
(Kerberos war auf dem Server nicht installiert) gesetzt, damit die IIS, die ebenfalls auf
dem Port 80 laufen, nebenher laufen können. Da auf der Startseite des Brokers der
Sign-in Button für Passport angezeigt werden soll, wurde das Bild des Buttons als
10
Link auf die Startseite gesetzt der auf den Loginserver von Passport verweist, da
ohne ein PassportIdentity – Objekt auch nicht die „LogoTag()“ – Methode benutzt
werden kann, die ansonsten für die Anzeige des Buttons zuständig wäre. Als
ReturnURL von den Passportservern wird dann eine ASP – Seite angegeben, die ein
PassportIdentity Objekt instanziiert und das Ticket ausliest. Anschließend wird
automatisch auf die Brokerseite zurückverwiesen. Die Umleitung über die ASP Seite
vollzieht sich vom Benutzer unbemerkt und über einen verschlüsselten Kanal (SSL)8,
da hier seine PuID an den Broker übertragen wird.
Eine Hauptfunktionalität von SSO ist, dass ein Benutzer, wenn er sich bei einer
anderen Seite schon einmal angemeldet hat, sich nicht erneut anmelden muss.
Diese Funktionalität kann mit dieser Art Implementierung niemals verwirklicht werden
wenn die Startseite die Seite des Brokers ist. Wenn die Startseite des Brokers eine
ASP – Seite wäre, könnte über eine Methode des PassportIdentitiy – Objektes
festgestellt werden ob der Benutzer ein gültiges Ticket besitzt. Andersherum, also
wenn ein Benutzer sich am Broker mittels Passport anmeldet und dann auf eine
andere Passport Webseite surft, funktioniert SSO natürlich schon, da andere Seiten
das Ticketcookie des Benutzers wie gewohnt auslesen können.
Beim Logout wird zuerst dem Broker das Logout mitgeteilt und der Benutzer
anschließend ebenfalls unbemerkt an eine ASP – Seite geleitet, die die
Passportcookies invalidiert.
3.2. Environments
Ein weiteres Problem sind die Environments unter denen man entwickelt. Da man
sich solange im PREP-Environment befindet, bis man ein Compliance Review
absolviert hat, kann leider nicht festgestellt werden, ob die Kommunikation auch mit
den echten Passportservern funktioniert und ob echte Passportuser authentifiziert
werden können. Auch andersherum können Webseiten die Passport unterstützen
niemanden authentifizieren der einen Account für das PREP-Environment besitzt.
Des Weiteren hat Microsoft seine PREP-Environment-Server von http://passport-
test.net auf http://www.passport-ppe.com umgestellt. Leider unterstützen diese nicht
mehr die oben erwähnte Syntax für den Anmeldevorgang. Hier muss abgewartet
8 Anleitung für selbstsignierte Zertifikate für den IIS 5: [DB03]
11
werden bis Microsoft sein SDK oder zumindest die zugehörige Dokumentation
erneuert.
Um dennoch die Funktionalität demonstrieren zu können verweist der Sign-In Button
nicht auf die Loginserver, sondern auf eine Seite von der aus eine ausgedachte PuID
an den Broker übertragen wird die im Broker registriert wurde. Außerdem generiert
die Seite die Passportcookies, allerdings ohne Inhalt. Um die SSO Funktionalität zu
zeigen überprüft ein kleines Script ob diese Cookies vorhanden sind und zeigt
dementsprechend eine Login- oder eine Welcomeseite an.
3.3. Die LogoTag() – Methode
Wie erwähnt wurde die „LogoTag()“– Methode nicht verwendet, sondern der Sign-In
Button als Link angezeigt. Falls die „LogoTag()“– Methode doch einmal verwendet
werden soll ergibt sich das Problem, dass der Link zu den Loginservern von dieser
Methode automatisch generiert wird. Es gibt keine Möglichkeit den generierten Link
zu überschreiben. Die Methode verweist im aktuellen SDK noch auf die alte
Internetadresse der Loginserver, so dass sie im aktuellen Zustand unbrauchbar ist.
Deshalb ist zu vermuten, dass Microsoft demnächst ein neues SDK veröffentlicht.
12
13
Kapitel 4 4. Die Umsetzung – Integration in den Broker
4.1. Problemstellung und Lösungsüberblick
Die Problemstellung die es zu lösen galt, lässt sich folgendermaßen beschreiben:
Um Microsoft .NET Passport zu implementieren wird das PassportIdentity-Objekt
samt seiner zugehörigen Methoden zwingend benötigt, da nur so das Passportticket
das der Benutzer nach erfolgreichem Authentifizieren bei den Passport Login-
Servern ausgestellt bekommt entschlüsselt und verifiziert werden kann. Dieses
Objekt lässt sich allerdings nur in einer .NET Umgebung instanziien. Da der infoAsset
Broker aber eine Java-Anwendung ist muss in die Kommunikation zwischen Broker
und Login-Server eine ASP-Seite zwischengeschaltet werden, so dass dann mit Hilfe
des PassportIdentity-Objektes das ausgestellte Ticket überprüft werden kann. Gelöst
wurde dieses Problem indem der Benutzer zuerst an die Passport Login-Server
geleitet wird um sich zu authentifizieren und anschließend unbemerkt über eine ASP-
Seite zurückgeleitet wird auf der das Ticket überprüft wird. Auf der ASP Seite wird bei
gültigem Ticket die PassportID9 ausgelesen und an den Broker über einen sicheren
Kanal übermittelt. Dadurch erfährt der Broker, dass es sich um einen korrekt
authentifizierten Benutzer handelt. Die Zuordnung zwischen PassportID und
Benutzer geschieht in der Datenbank des Brokers.
9 Genaueres s. Kap. 4.3
14
Abb.3 : Deployment Diagramm
15
4.2. Use Cases
Bevor die Integration in den Broker beschrieben wird, sollen kurz die Use Cases
analysiert werden die die Fälle widerspiegeln die bei der Integration berücksichtigt
wurden.
Erster Fall: Benutzer meldet sich am Broker an.
User überprüfen
PuID überprüfenStatus "mit Passport angemeldet" auf true setzen
Anmelden mit Passport
<< include>>
Anmelden ohne Passport
<<include>>
<<include>> Sta tus "angemeldet" auf true se tzen
<<include>><<include>>
<<include>>
Am Broker anme ldenBenutze r
Abb.4 : Use Case „Anmleden“
16
Zweiter Fall: Benutzer meldet sich vom Broker ab.
Abmelden mit Passport Abmelden ohne Passport
Status "angemeldet" auf false setzen
Status "Mit Passport angemeldet" auf false setzen
Passport Ticke t löschen
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Vom Broker abmeldenBenutzer
Abb.5 : Use Case „Abmleden“
Der Broker bietet zwei Grundfunktionalitäten für den Anmeldevorgang. Die erste ist
ein Anmeldevorgang, der wie bisher vonstatten geht. Der Benutzer meldet sich mit
seinem Benutzernamen und Passwort an, die er für den Broker registriert hat. Er
benutzt nicht den Passport–Login–Button. Folglich soll ihm auch nach erfolgreichem
Anmelden weder der Passport–Login noch der Logout–Button angezeigt werden. Um
sich abzumelden wird wie gewohnt der Logoutlink des Brokers benutzt.
Zweitens kann sich der Benutzer via Passport am Broker anmelden. Hierzu wird der
Passport–Login–Button benutzt. Nach der Anmeldung wird auf den Webseiten des
Brokers ein Passport–Logout–Button zusätzlich zum Logoutlink des Brokers
angezeigt. Der Benutzer kann beides benutzen um sich vom Broker abzumelden. In
beiden Fällen wird der Benutzer auch vom Passportdienst abgemeldet um
Missbrauchspotential zu verhindern (genaueres Kapitel 5.3).
17
4.3. Login
Beim Login muss also dem Broker mitgeteilt werden, dass sich der Benutzer
angemeldet hat und wie er das gemacht hat. Deshalb wurde die abstrakte Klasse
„de.infoasset.broker.session.AbstractSession.java“ um die Variable
„loggedInWithPassport“ erweitert. Sie wird mit „false“ initialisiert und auf „true“ gesetzt
wenn der Benutzer beim Anmelden Passport benutzt hat. Die entsprechenden
Methoden um diese Variable zu setzen („setPassportLoggedIn()“) oder auszulesen
(„isPassportLoggedIn()“) sind ebenfalls in dieser Klasse implementiert.
AbstractSessionloggedInWithP assport : BooleanloggedIn : Boolean
setLoggedIn(loggedIn : Boolean)isLoggedIn() : B ooleansetPassportLoggedIn(loggedInWithP assport : Boolean)isPassportLoggedIn() : Boolean
Abb.6 : Klasse AbstractSession.java
Die Definition der beiden Methoden findet sich in der Schnittstelle „Session“, die
diese Klasse benutzt. Diese Variable dient nur dazu festzuhalten wie sich der
Benutzer angemeldet hat. Deshalb muss zusätzlich die Variable „isLoggedIn“ auf true
gesetzt werden, da nur diese den Anmeldestatus repräsentiert.
Dieses Szenario setzt voraus, dass der Anmeldevorgang mit Passport erfolgreich
war. Allerdings sind noch ein paar Schritte auszuführen bis ein Benutzer erfolgreich
angemeldet ist. Der Klick auf den Passport–Button leitet den Benutzer an die
Passport Authentifizierungsserver weiter, bei denen er seinen Benutzernamen und
sein Passwort eingibt. Danach wird er an eine Webseite weitergeleitet, die auf einem
Server des Brokerbetreibers unter IIS läuft. Hier wird die Passport unique ID ermittelt
(siehe Kapitel 4.7) und anschließend über einen sicheren Kanal (SSL) an den Broker
übertragen. Dazu wird die Startseite des Brokers aufgerufen und an die URL
folgende Zeichensequenz angehängt: ?PID=PuID
Hierbei stellt PuID die Passport unique ID dar, die ein 16–Zeichen langer
Hexadezimalwert ist.
18
4.4. DefaultHandler
Jeder Webseite des Brokers ist ein sogenannter Handler zugeordnet. Handler
nehmen Anfragen von Clients entgegen und verarbeiten sie im aktuellen Kontext des
Benutzers. Die Ausgabe wird an ein Template weitergereicht das eine Webseite
erzeugt.
Der „de.infoasset.broker.weblogHandler.home.DefaultHandler.java“ ist der Startseite
des Brokers zugeordnet. Damit für einen Benutzer, der sich mit Passport angemeldet
hat, wie gewohnt nach dem Anmeldevorgang die Startseite für eingeloggte Benutzer
erscheint, musste zuerst der „DefaultHandler“ um die Funktion des Anmeldens
erweitert werden, die zuvor nur im „LoginHandler“ präsent war. Diese Funktion läuft
automatisch ab wenn die Startseite wie oben beschrieben mit angehängter PuID
aufgerufen wird. Der Handler liest die PuID aus und überprüft, ob ein Benutzer mit
dieser ID bekannt ist. Hierzu wurde die Klasse „IMPPersons“ die die Attribute, die
einer Person zugeordnet werden, festlegt um das Attribut „PassportID“ erweitert.
Diese ist standardmäßig auf „null“ gesetzt, außer wenn ein Benutzer Passport
benutzt. Dann ist hier seine PuID gespeichert. Die dauerhafte Speicherung der
Attribute findet in der Datei „content.txt“ statt. Die zugehörigen Methoden
„getPassportID()“ und „setPassportID()“ zum Schreiben bzw. Lesen des Attributs
wurden in der Schnittstelle „Person“ festgelegt und in der Klasse „AbstractPerson“
implementiert. Damit der „DefaultHandler“ die Datei „context.txt“ nach der
entsprechenden PassportID durchsuchen kann wurde eine weitere Methode
„getPersonByPassportID()“ in der Schnittstelle „Persons“ definiert und in der Klasse
„IMPPersons“ implementiert.
Abb.7 : Erweiterte Klassen
Person
AbstractPerson
getPassportID() : StringsetPassportID(PassportID : String)
IMPPersons
getPersonByPassportID(PassportID : String) : PersonPersons
19
Der Handler überprüft also nach dem Auslesen der PuID aus der URL, ob ein
Benutzer mit dieser PassportID bekannt ist. Falls ja wird der Status dieses Benutzers
auf angemeldet gesetzt. Gleichzeitig wird „loggedInWithPassport“ auf „true“ gesetzt.
Falls kein Benutzer unter dieser PassportID gefunden wird, wird die Startseite
angezeigt die auch nicht angemeldete Benutzer sehen können.
4.5. Logout
Da sich der Broker auf diese Weise für jeden Benutzer der angemeldet ist merken
kann, wie sich der Benutzer angemeldet hat, kann auch das Abmeldeverfahren
entsprechend darauf eingehen. Ein Benutzer der sich ohne Passport am Broker
angemeldet hat, bekommt im angemeldeten Zustand nur den klassischen Logoutlink
des Brokers zu Gesicht. Der Passport–Logout–Button wird ihm nicht angezeigt.
Entsprechend verläuft auch der Abmeldevorgang wie bisher. Nach erfolgreichem
Logout wird dem Benutzer die Startseite des Brokers für nicht angemeldete Benutzer
angezeigt.
Wenn der Benutzer sich mit Passport angemeldet hat, wird er unbemerkt nach dem
Abmeldevorgang am Broker auf die ASP Seite geleitet, die die Inhalte der Passport
Cookies auf „null“ und die Gültigkeitsdauer auf ein vergangenes Datum setzt
(Refernzvorgehen von Microsoft). Anschließend wird der Benutzer ebenfalls auf die
Startseite des Brokers für nicht angemeldete Benutzer weitergeleitet.
4.6. LogoutSubmitHandler
Der Passport–Logout–Button ist mit der Logout Seite des Brokers verlinkt auf die
man auch geleitet wird, wenn man auf den normalen Logoutlink klickt. Dieser Seite
ist der so genannte „de.infoasset.broker.weblogHandler.home.LogoutSubmitHandler“
zugeordnet, der beim Laden dieser Webseite aktiv wird und der den Status des
Brokers ändert. Damit unterschieden werden kann ob der Benutzer sich mit Passport
oder klassisch angemeldet hat, wird als erstes mit der Methode
„isPassportLoggedIn()“ die Variable „loggedInWithPassport“ überprüft. Ist das
Ergebnis negativ hat der Benutzer nicht Passport zum Anmelden verwendet und es
20
wird nur die Variable „loggedIn“ auf „false“ gesetzt. Ein vom Broker eventuell
gesetzter Cookie wird abschließend auf „null“ gesetzt.
Ist das Ergebnis positiv, es wurde also Passport benutzt, wird die Variable
„loggedInWithPassport“ zusätzlich zu „loggedIn“ auf „false“ gesetzt.
Abb.8 : Sequenzdiagramm, LogoutSubmitHandler
Darüber hinaus wird jetzt die Weiterleitung an die ASP–Seite aktiv. Dazu wird eine
unsichtbare Shell geöffnet und die Seite über den Standardbrowser aufgerufen. Da
der Aufruf der Shell je nach Betriebssystem unterschiedlich ist, wird zuerst mit der
Methode „System.getProperty()“ der Name des Betriebssystems ausgelesen und
dann eine Fallunterscheidung gemacht. Es wird nach Windows9x, NT, 2000, XP und
UNIX unterschieden. Der Umweg über die Shell wurde deshalb gewählt, weil der
Broker es nicht zulässt von den Handlern aus auf externe Webseiten
weiterzuleiten10.
10 Codeausschnitt siehe Anhang
21
4.7. Templates
Templates sind HTML–Seiten, die so genannte Platzhalter beinhalten. Die Platzhalter
werden von den Handlern, die dem jeweiligen Template zugeordnet sind, mit
Inhalten befüllt. Auf diese Weise werden also Webseiten mit variablen Inhalten
erzeugt und trotzdem ein einheitliches Erscheinungsbild gewahrt. Damit eine
Änderung des Layouts nicht in allen Templates einzeln vorgenommen werden muss,
sind alle Templates einem Mastertemplate unterstellt. Eine Änderung in diesem
Master pflanzt sich in alle unterstellten Templates fort.
Um einen Platzhalter zu definieren wird ein Attributname gewählt und in „$“– Zeichen
eingeschlossen. Dem Attributnamen wird dann in der Datenbank die Ersetzung
zugeordnet. Normalerweise ist dies ein Text in irgendeiner Form der dann mit der
Methode „template.put()“ in die Webseite geschrieben wird.
Für den Passport–Login–Button wurde in das Mastertemplate ein Link eingebaut,
dessen Ziel über einen Platzhalter definiert wird. Da das Ziel in der Datenbank
(„properties.txt“) verzeichnet ist kann also sehr leicht durch den Administrator des
Brokers die Ziel–URL abgeändert werden. Das ist insofern wichtig, da Microsoft die
URL der Loginserver erneut ändern könnte. Dem Link ist einfach das Bild des
Passport Logout Buttons zugeordnet. Die Syntax ist folgendermaßen:
<a href=" $passportloginsite$ " > <img src="../skin/images/global/signin.gif">
Beim Passport–Logout–Button musste leider ein anderes Vorgehen gewählt werden,
da der Button erstens nur den Benutzern angezeigt werden soll die auch Passport
zum Anmelden verwendet haben, und zweitens auch ein Abmelden vom Broker
damit verbunden sein soll. Das Abmelden vom Broker kann aber nicht von einer
externen Seite geschehen auf die man hätte verlinken können. Also wird dem Button
der Link auf die Webseite „home/logoutSubmit“ des Brokers zugewiesen, der der
„LogoutSubmitHandler“ zugeordnet ist, und das Abmelden vom Broker und die
anschließende Weiterleitung auf die ASP–Seite um den Benutzer von Passport
abzumelden in diesem Handler wie oben beschrieben implementiert. Damit der
Button auch nur den Passportbenutzern angezeigt wird, wurde hier ein bedingter
Platzhalter für das Template verwendet. Bedingte Platzhalter haben folgende Syntax:
$[platzhalterName$ Bedingter Inhalt $platzhalterName]$
Der bedingte Inhalt, also der Button, wird in diesem Fall nur angezeigt, wenn der
Platzhaltername (hier „ifPassportLoggedIn“) zu „true“ ausgewertet wird.
22
4.8. ASP–Seiten
Zuerst wird kurz die Referenzimplementierung11 der ASP – Loginseite erklärt und
anschließend die abgeänderte Fassung, die für die Demonstration verwendet wird.
Abschließend wird noch kurz auf die Logoutseite eingegangen.
Der erste Schritt auf der Loginseite ist die Istanziierung des PassportIdentitiy
Objektes. Dieses Objekt bietet dann alle weiteren benötigten Methoden an, um die
Authentifizierung eines Passport–Benutzers abzuwickeln.
Wenn das Objekt instanziiert wurde, wird als erstes mittels der Methode
„GetFromNetworkServer()“ überprüft, ob der Benutzer die Webseite zum ersten Mal
ansurft, oder ob er von den Loginservern auf diese Seite zurückgeschickt wurde. Im
letzteren Fall befindet sich eine lange Zeichenkette am Ende der URL im Browser
des Benutzers. Sie enthält verschlüsselte Informationen für den Ticketcookie, der
beim User angelegt wurde. Damit der Benutzer nicht die ganze Zeit mit der
Zeichenkette im Anhang surfen muss, wird sie durch erneutes Laden der aktuellen
Seite entfernt. Anschließen wird mit der Methode „GetIsAuthenticated()“ überprüft, ob
der Benutzer über ein gültiges Ticket verfügt. Darüber hinaus kann auch eine
Gültigkeitsdauer für ein vorhandenes Ticket angegeben werden, die besagt, wie
lange eine Ausstellung des Tickets maximal her sein darf. Wenn der Benutzer nicht
über ein gültiges Ticket verfügt wird er an die Loginserver zurückverwiesen. Wenn er
über ein gültiges Ticket verfügt wird die PuID ausgelesen. Dies ist ein sechzehn–
Zeichen langer Hexadezimalwert der in eine hohe ID, die ersten acht Zeichen, und
eine niedrige ID, die letzten acht Zeichen, unterteilt ist. Beide werden getrennt
ausgelesen und dann aneinandergehängt um die vollständige ID zu erzeugen.
Anschließend kann eine boolsche Variable auf „true“ gesetzt werden mit deren Hilfe
später entschieden wird, ob Webseiten für angemeldete Benutzer oder für nicht
angemeldete Benutzer angezeigt werden.
Da wie in Kapitel 3.2 schon erwähnt, die Syntax für die neuen Loginserver
abgeändert wurde und das Anmelden bei Passport im jetzigen Zustand nicht
funktioniert, wurde eine abgeänderte Seite zu Demonstrationszwecken erstellt. Sie
überprüft nicht, ob ein Benutzer über ein gültiges Ticket verfügt, da der Benutzer
ansonsten an die Loginserver zurückverwiesen werden würde. Da der User auch
nicht über ein gültiges Ticket verfügt muss eine künstliche PuID verwendet werden.
11 [PSGK]
23
Das Prinzip ist dennoch unverändert geblieben und der Broker überprüft weiterhin
die ID, nur dass sie eben nicht von Passport erzeugt wurde, sondern von der ASP
Seite.
Die Logoutseite ist eine einfache Visual Basic Script-Seite, die die vier von Passport
erzeugten Cookies auf „null“ und das Ablaufdatum auf ein vergangenes Datum setzt.
Die Namen der vier Cookies sind:
• „MSPAuth“ – Das Ticket
• „MSPSecAuth“ – Das Ticket wenn SSL–Seiten verwendet werden
• „MSPProf“ – Das Profil des Benutzers
• „MSPConsent“ – Die Daten, die der Benutzer den Passportseiten zur
Verfügung stellt
4.9. Lösungsalternativen
Zu der eben beschriebenen Lösung sind einige Lösungsalternativen denkbar.
Die erste wäre eine Modifizierung des Übertragungsweges der PuID. Die PuID ist im
bisherigen Verfahren die Schwachstelle, da ein Benutzer der seine PuID oder die
eines anderen Benutzers kennt, sich beim Broker einfach durch Anhängen der PuID
an die URL anmelden kann. Die PuID ist immer unverändert gültig und es wird auch
nicht überprüft, ob diese von der ASP Seite ausgelesen und angehängt wurde. Als
Ausweg könnte der Broker eine so genannte Nonce generieren. Noncen sind
Zufallswerte um genau diese „Wiederholungsangriffe“ wirkungslos zu machen. Am
besten generiert man ein Nonce durch eine Zufallszahl, ein Datum oder eine
Kombination aus Beidem. Wie die Nonce eingesetzt wird hängt im Wesentlichen
davon ab, ob der Broker und die IIS auf demselben Rechner laufen, oder nicht.
Laufen beide auf demselben Rechner generiert der Broker eine Nonce und legt diese
in einem geschützten Speicherbereich beliebiger Art ab auf den nur der Broker sowie
die IIS Zugriff haben. Die Nonce wird generiert, wenn ein Benutzer sich mit Passport
anmelden möchte. Er wird anschließend nach bisherigem Verfahren an die Passport
Login-Server weitergeleitet. Wenn er dann über die ASP-Seiten zurückgeleitet und
dort die PuID ausgelesen wird, holt sich die ASP Seite die Nonce aus dem Speicher
und verwendet sie um die PuID zu verschlüsseln und das Chiffre dann an die URL
des Brokers anzuhängen. Der Broker seinerseits benutzt dieselbe Nonce um aus
24
dem Chiffre wieder die PuID im Klartext zu gewinnen. So ist gewährleistet, dass die
angehängte PuID niemals dieselbe ist. Auf diese Weise ist es nicht einmal mehr
notwendig, dass die Kommunikation zwischen Broker und IIS verschlüsselt abläuft.
Laufen allerdings Broker und IIS auf verschiedenen Rechnern, so muss die Nonce
über einen sicheren Kanal übertragen werden. Bei verteilten Rechnern sollten auch
Zeitsynchronisation und Timeouts in geeigneter Weise verwendet werden.
Bei der zweiten Lösungsalternative werden die ASP-Seiten als Web-Service
verwendet, der für das Entschlüsseln der Passportcookies und das Verifizieren des
Passporttickets zuständig ist. Da in einer Brokersession zumindest die Namen der
Passportcookies gelesen werden können, kann der Broker ein Benutzer direkt an die
Passport Login-Server schicken und dieser dann auch direkt an den Broker
zurückgeschickt werden. Der Broker überprüft bei jedem Request ob eines oder
mehrere der Passportcookies vorhanden sind und leitet den Benutzer im positiven
Fall an die ASP Seite weiter die dann überprüft, ob das gefundene Ticket gültig ist.
Die Antwort an den Broker kann beispielsweise über einen zweiten Kanal zwischen
Broker und IIS realisiert werden. Die Antwort könnte beispielsweise an XML
angelehnt werden und im Fehlerfall als <error/> oder im Erfolgsfall als
<person>personinfo<person/> ausfallen. Bei komplexeren Nachrichten bietet sich
eventuell auch SOAP an.
25
Kapitel 5 5. Passport aus Unternehmenssicht
5.1. Warum „Single Sign On”?
Nach der ersten Euphorie über die neue Technik in der sich viele einen riesigen
Markt erhofften, wurde es sehr still um SSO. Nur in letzter Zeit waren vereinzelt
Kritiken zu hören, dass mit dieser Technik ein Markt bedient wird für den gar kein
großer Bedarf herrscht, oder dass zumindest die Technik noch sehr unausgereift sei
und die Preise für die Softwarelösungen überteuert seien. Einige Analysten raten
sogar dazu sich aus dem Markt ganz zurückzuziehen12. Dennoch bietet diese
Technologie viele Vorteile die in diesem Abschnitt kurz den Nachteilen gegenüber
gestellt werden sollen.
Die Nachteile die am häufigsten genannt werden sind, dass persönliche Daten und
Zahlungsinformationen bei einer zentralen Instanz abgelegt werden, der der
Benutzer vertrauen muss. Außerdem muss der Benutzer nach wie vor bei Seiten die
SSO nicht unterstützen (die Mehrheit) seine Daten eingeben und sich Passwörter
merken. Dadurch, dass es mehrere Anbieter von Softwarelösungen auf dem Markt
gibt, bindet sich ein Teilnehmer fest an die Lösung eines Unternehmens. Speziell bei
Microsoft Passport werden auch oft Sicherheitsbedenken angemeldet bei deren
Lösung man auf Microsoft angewiesen ist, da Passport ein proprietäres Format ist.
Demgegenüber stehen aber viele Vorteile. Daten müssen (im Idealfall) nur einmal
eingegeben werden und man muss sich nur ein Login – Passwort Paar merken. Das
Internet kann personalisierter gestaltet werden. Auch sind spezielle
Schutzmöglichkeiten für Kinder (->Kids Passport, s.u.) umsetzbar. Für Unternehmen
ergeben sich mehr Möglichkeiten gezielt auf die Kunden einzuwirken, da sie Zugriff
12 Essays und Literatur zum Thema [GH03], [PS01]
26
auf viele persönliche Daten haben und den Internetauftritt benutzerfreundlicher
gestalten können.
5.2. Möglichkeiten
Abschließend soll erörtert werden welche Möglichkeiten bestehen, wenn
beispielsweise ein Unternehmen Microsoft .NET Passport einsetzen möchte, um die
Authentifizierung der Mitarbeiter und deren Zugriffsrechte zu regeln.
Zuerst muss erwähnt werden, dass es nicht möglich ist die Zugriffsrechte der
einzelnen Personen bei den zentralen Passportservern von Microsoft und damit auch
in den Cookies festzulegen. Hier ist man auf das beschränkt, was von Microsoft
vorgegeben wird. Microsoft selbst schreibt eine Art „Consent Database“ vor, in der
verzeichnet wird welche Angaben vom Benutzer an die entsprechende Seite
weitergeleitet werden dürfen und welche nicht. Zusätzlich können dann hier auch
Zugriffsrechte abgelegt werden. Das heißt, dass es dem Unternehmen selbst
überlassen bleibt die Zugriffsrechte zu verwalten und zu speichern. Abgesehen von
der Authentifizierung bringt Passport auf diesem Gebiet keine Vorteile.
Es sind mehrere Szenarios als Einsatzgebiete für eine SSO Lösung denkbar. Das
erste Szenario wäre ein Unternehmen, das nur die Authentifizierung der Mitarbeiter
in einer Intranetumgebung realisieren möchte. Falls Zugriffsrechte keine Rolle
spielen kann auf eine Rechtedatenbank verzichtet werden und beispielsweise ein
System wie Kerberos verwendet werden, das von einer zentralen Stelle im
Unternehmen betrieben und gewartet werden kann. Falls auch Zugriffsrechte eine
Rolle spielen, muss zusätzlich eine Rechtedatenbank aufgesetzt werden, die dann
entweder bei jeder Transaktion abgefragt wird, oder die die Rechte in einem Ticket
festhält (nicht im Passportticket). Hier kommt dann allerdings ein weiteres Szenario
ins Spiel, falls das Unternehmen aus Untereinheiten besteht, die ihre Inhalte und die
entsprechenden Rechte selbst verwalten. Hier kann es unter Umständen
problematisch sein Authentifizierung und Rechteverwaltung zentral zu halten. Wenn
jede Untereinheit die Rechteverwaltung selbst realisiert, was zu einer erhöhten
Ausfallsicherheit, einem schnelleren, unbürokratischeren Rechtemanagement und
einer einfacheren Wartung führt, kann ein System wie Passport durchaus von Vorteil
sein, da die Authentifizierung extern vorgenommen wird und der Benutzer dann
27
seine Rechte durch die Untereinheiten direkt zugewiesen bekommt. Eine zentrale
Stelle für die Authentifizierung innerhalb des Unternehmens einzurichten ist
zumindest mit einer erhöhten Bürokratie und einem höheren
Kommunikationsaufwand verbunden, nicht zuletzt wenn die Untereinheiten der Firma
auch geografisch verteilt sind.
5.3. Schwachstellen13
Microsoft .NET Passport machte über die Jahre immer wieder Schlagzeilen mit
gravierenden Sicherheitsmängeln. Daraufhin haben sich einige Forscher mit der
Analyse der Schwachstellen in Passport befasst, deren Ergebnisse hier kurz
vorgestellt werden. Es werden nur grundsätzliche Fehler, also Fehler im Design des
Dienstes erwähnt. Spezifische Angriffe auf den Dienst werden ausgelassen, da diese
von Microsoft meist behoben werden.
Als erstes ist hier das Interface des Dienstes zu nennen. Meist wird der Passport
Dienst zusätzlich zu einem normalen Authentifikationsdienst angeboten. Beim
Ausloggen entfernt Passport nur seine eigenen Rechte (Ticket, Cookie) der normale
Dienst ebenfalls nur von ihm angelegte Rechte. Wenn sich ein Benutzer also mit
Passport anmeldet, aber nicht den Signout-Button von Passport benutzt, so wird er
nur aus der aktuellen Seite ausgeloggt. Er bleibt aber bei Passport weiter
angemeldet. Der unbedarfte Nutzer denkt er sei abgemeldet und der nächste Nutzer
hat vollen Zugriff auf alle Seiten die den Passportdienst unterstützen unter dem Profil
des vorherigen Nutzers. Als Beispiel sei hier Hotmail, der populärste Passportdienst
von Microsoft genannt, bei dem genau das geschehen ist.
Noch eine Stufe gravierender ist die Kompatibilität von Passport mit dem Netscape
Browser. Wenn hier die Option gewählt wird, dass Anfragen für Cookies nur
beantwortet werden, wenn sie von dem Server kommen, der sie auch geschrieben
hat, dann funktioniert das Logout überhaupt nicht mehr.
Ein zweiter Punkt ist das Verschlüsselungsverfahren. Hier verwendet Microsoft
TripleDES14 um die Benutzerdaten zu verschlüsseln. Alle Daten werden mit dem
selben Schlüssel verschlüsselt anstatt die Daten verschiedener Benutzer mit
verschiedenen Schlüsseln zu verschlüsseln. Wenn dieser Schlüssel kompromittiert 13 [KR00] 14 [MSPA]
28
wird liegen alle Passportdaten offen. (Anm.: TripleDES generiert oft schwache
Schlüssel wenn schlechte Zufallszahlen verwendet werden).
Als letztes sei noch ein Problem genannt das alle SSO Dienste plagt. Dadurch, dass
das gesamte System von einer zentralen Instanz abhängt die die Daten verwaltet,
wird das System anfällig für Ausfälle. Hinzu kommt, dass in dieser Instanz auch die
Daten aller Benutzer gespeichert sind, was den Dienst zu einem attraktiven Ziel für
Angriffe macht. Wenn der Dienst ausfällt kann sich auch niemand mehr auf Seiten
authentifizieren, die auf den Passportdienst angewiesen sind. Für skrupellose
Konkurrenten wären also die Passportserver ein lohnendes Ziel für Denial-of-Service
Angriffe. Dies kann aber auch ungewollt eintreten einfach dadurch, dass mit
steigender Benutzerzahl, von der SSO ja lebt, auch die Last auf die Server steigt.
Es gibt keine Informationen dazu, ob Passport mit replizierten Servern betrieben
werden kann um dieses Risiko zu minimieren. Durch die Replizierung würde das
Risiko eines Serverausfalls sinken, andererseits steigt dafür die Gefahr, dass ein
Schlüssel kompromittiert wird, weil dann Kopien auf jedem der Server vorhanden
sein müssen.
5.4. Fazit
Um ein Fazit zu ziehen sind die Sicherheitsrisiken von Microsoft .NET Passport
gegen etwaige Vorteile abzuwägen. Die Vorteile die entstehen, wenn auf ein
bestehendes System zurückgegriffen wird, relativieren sich unter anderem dadurch,
dass Passport kein kostenloser Service ist. Gerade bei großen Firmen sind die
Ressourcen die benötigt werden um ein eigenes System zu realisieren (Server,
Personal) meist sowieso vorhanden. Hinzu kommt, dass das Rechtemanagement
selbst zu implementieren ist. Warum sollte also ein zusätzlicher, kostenpflichtiger
Dienst in Anspruch genommen werden? Im Hinblick auf die Sicherheitsrisiken, die
bei Passport bestehen scheint eine eigene Realisierung eines
Authentifizierungssystems überlegen.
29
6. Literatur
[DB03]
Dylan Beattie, January 2003, Creating a Self-Signed Certificate using OpenSSL for
use with Microsoft Internet Information Services (IIS) 5,
http://www.dylanbeattie.net/docs/openssl_iis_ssl_howto.html
[GH03]
George V. Hulme, InformationWeek, 17. Mai 2003,
Gartner Advises Pulling The Plug On Microsoft Passport,
http://www.internetweek.com/shared/printableArticle.jhtml?articleID=10000198
[KR00]
David P. Kormann and Aviel D. Rubin, AT&T Labs – Research,
Risks of the Passport Single Signon Protocol,
Computer Networks, Elsevier Science Press, volume 33, pages 51-58, 2000.
[MSPA]
Passport Authentication Provider
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconThePassportAuthenticationProvider.asp
[PSGK]
27. Februar 2003, .NET Passport Service Guide Kit, Version 2.5,
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/websrvpass.asp
[PS01]
John Pescatore, Information Security Strategies, David Smith, Internet Strategies,
and Avivah Litan, Financial Services Payment Strategies, 24. September 2001,
Privacy and Security Still Challenge Microsoft Passport,
http://www3.gartner.com/DisplayDocument?doc_cd=101160
30
[OC04]
Olli Cornes, 23. Januar 2004, Passport mit .NET implementieren
http://www.microsoft.com/germany/ms/msdnbiblio/show_all.asp?siteid=546749
31
7. Anhang String passportlogoutsite = session.getServices().getProperties().getProperty("passportlogoutsite");
String execution = "start " + passportlogoutsite;
try {
Process p = null;
Runtime r = Runtime.getRuntime();
String OS = System.getProperty("os.name").toLowerCase();
if (OS.indexOf("windows 9") > -1) {
// Windows
p = r.exec( "command.com /c " + execution );
}
else if ( (OS.indexOf("nt") > -1)
|| (OS.indexOf("windows 2000") > -1
|| (OS.indexOf("windows xp") > -1) ) ){
p = r.exec( "cmd.exe /c " + execution );
}
else {
// Unix: Is there an IIS implementation for Unix?
p = r.exec( "env" + execution);
}
}
catch (Exception e) {
e.printStackTrace();
}
