Potentialanalyse zur innerbetrieblichen Prozessoptimierung mittels Single Sign On

Aus Winfwiki

Name des Autors:	Sebastian Köwitsch
Titel der Arbeit:	"Potentialanalyse zur innerbetrieblichen Prozessoptimierung mittels Single Sign On"
Hochschule und Studienort:	FOM Essen

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Tabellenverzeichnis 4 Einleitung 4.1 Problemstellung 4.2 Ziel der Arbeit 5 Begriffsdefinitionen und Grundlagen 5.1 Authentifizierung 5.2 Autorisierung 5.3 Single Sign On 5.3.1 Funktionsweise von Single Sign On 5.3.2 Active Directory Single Sign On 5.3.3 Enterprise Single Sign On 5.3.4 Web Single Sign On 6 Fallbeispiel 6.1 Ist-Zustand 6.1.1 Praxisanalyse 6.1.2 Mängel-/Wunschliste 6.2 Soll-Zustand 6.2.1 Kritische Erfolgsfaktoren 6.2.2 Risikoanalyse 6.3 Nutzwertanalyse 6.4 Kritische Betrachtung des SSO Systems 7 Fazit 8 Fußnoten 9 Literatur- und Quellenverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
AD	Active Directory
ADSSO	Active Directory Single Sign On
ESSO	Enterprise Single Sign On
KIS	Krankenhaus Informations System
LAN	Local Area Network
RFID	Radio Frequency Identification
SSO	Single Sign On
WLAN	Wireless Local Area Network
WSSO	Web Single Sign On

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	Authentifizierung, Autorisierung und Geschäftsanwendung
2	Anmeldevorgang mit Single Sign On
3	Enterprise Single Sign On
4	Web Single Sign On
5	Ergebnisse der Mitarbeiterbefragung
6	Nutzwertanalyse

3 Tabellenverzeichnis

Tab.-Nr.	Tabelle
1	Mängel- / Wunschliste vor der SSO Einführung
2	Risikoanalyse

4 Einleitung

Unternehmen stehen häufig vor der Herausforderung ihre IT-Benutzerverwaltung sicher, hochverfügbar und zugleich anwenderfreundlich und performant auszulegen. Eine Möglichkeit zur Kombination der genannten Anforderungen könnte in der Implementierung einer SSO Lösung bestehen, deren Chancen und Risiken in den folgenden Kapiteln untersucht werden.

4.1 Problemstellung

Da in vielen Unternehmen die Problematik einer sicheren und zugleich anwenderfreundlichen Benutzerverwaltung bekannt ist, wurden diverse Statistiken aufgestellt, die die am häufigsten auftretenden Schwierigkeiten verdeutlichen. Beispielhaft seien folgende genannt:

• "Statistics for soft-dollar costs — costs in terms of the time an end-user spends on the logon process — range from a low of 3-hours-per year to a high of 44-hours per year."
• "Users who forget their passwords ask the help desk or their system administrator to “reset the password.” For example, one help desk reports that 70% of its 90 to 100 calls per day are requests to reset passwords. Time spent resetting passwords impairs the help desk’s ability to support other, perhaps more significant, requests"^[1].
  

Die Ergebnisse dieser Statistiken sind nicht weiter verwunderlich, wenn man die Größe und Komplexität heutiger IT-Landschaften betrachtet. Anwender müssen sich mehrere Zugangsdaten für das tägliche Arbeiten mit den verschiedenen Systemen merken, was dazu führen kann, dass Passwörter vergessen werden und ein Anruf im Callcenter nötig ist, um dieses zurücksetzen zu lassen. Weiterhin werden aufgrund der Vielzahl von Passwörtern häufig die gleichen Passwörter für verschiedene Systeme oder aber sehr leichte Passwörter gewählt, was aus Gründen der Sicherheit nicht zu verantworten ist^[2].

4.2 Ziel der Arbeit

Das Ziel dieser Arbeit besteht darin, anhand eines Fallbeispiels aufzuzeigen, in wie weit die innerbetrieblichen Prozesse eines Unternehmens durch die Einführung eines Single Sign On Systems (kurz: SSO) verbessert werden können. Dabei stehen insbesondere eine detaillierte Analyse der Ist-Situation sowie die Ergebnisse einer Nutzwertanalyse, aus welcher das Potential eines SSO Systems ersichtlich werden soll, im Vordergrund.

5 Begriffsdefinitionen und Grundlagen

Im folgenden Kapitel werden die für diese Arbeit wichtigen Begrifflichkeiten sowie die Funktionsweise von SSO kurz erläutert.

5.1 Authentifizierung

Immer dann, wenn einer Person Zugriff auf einen geschützten Bereich gewährt werden soll, muss sich diese Person authentifizieren. Damit soll sichergestellt werden, dass die Person auch tatsächlich diejenige ist, für die sie sich ausgibt. Eine Authentifizierung ist mittels dreier unterschiedlicher Faktoren möglich:

• Das was jemand weiß (z.B. PIN Code, Passwort)
• Das was jemand besitzt (z.B. Token, EC Karte)
• Das was jemand ist (z.B. der persönliche Fingerabdruck)

Häufig werden diese Faktoren auch untereinander kombiniert. Bei der elektronischen Gesundheitskarte beispielsweise muss die Person nicht nur im Besitz der Karte sein, sondern auch einen entsprechenden PIN Code wissen^[3].
Für die Authentifizierung werden die vom Benutzer eingegebenen Anmeldeinformationen (meist Benutzername und Kennwort) mit einer Liste bekannter Daten verglichen. Wird eine Übereinstimmung zwischen den eingegebenen Daten und denen innerhalb der Liste gefunden, so wird der Benutzer authentifiziert. Wird keine Übereinstimmung gefunden, wird dem Benutzer der Zugang zum System nicht gewährt^[4].

5.2 Autorisierung

Bevor eine Person autorisiert werden kann, ist eine Authentifizierung erforderlich. Ist diese erfolgt, können dem Benutzer bestimmte Berechtigungen für Objekte (z.B. Laufwerke, Dateien oder Drucker) zugeteilt werden. Die Berechtigung, eine Datei zu lesen oder in eine Datei zu schreiben, ist ein Beispiel für eine Autorisierung^[5].
Der Autorisierungsvorgang entscheidet demnach über die Rechte, welche einem Benutzer innerhalb einer Anwendung zur Verfügung stehen. Entgegen der häufigen Annahme, dass die Autorisierung eine Art Sicherheitsfunktion darstellt, ist sie vielmehr eine "Geschäftsentscheidung". Eine „Geschäftsentscheidung“ in diesem Zusammenhang bedeutet eine Entscheidung darüber zu treffen, welcher Benutzer welche Berechtigungen erhält. Um eine solche Entscheidung zu treffen, gibt es definierte Regeln („Geschäftsregeln“), welche aber nicht Bestandteil einer Sicherheitslogik sind. Infolge dessen sollte es eine Sicherheitsinfrastruktur geben, welche der Geschäftsentscheidung den Zugriff auf die jeweilige Benutzeridentität ermöglicht. Im Anschluss daran kann ein Benutzer durch die Sicherheitsinfrastruktur einer bestimmten Gruppe oder bestimmten Rollen (Zusammenfassung bestimmter Berechtigungen) zugeordnet werden, so dass eine Person für seine Anwendung(en) autorisiert werden kann^[6]. Abbildung 1 verdeutlicht diese Argumentation noch einmal. Ein Anwender authentifiziert sich an einem System und über eine Sicherheitsinfrastruktur werden die Identität sowie die Berechtigungen überprüft. Anschließend wird dem Benutzer, sofern die eingegebenen Benutzerdaten korrekt waren, mit der angegebenen Identität Zugang zu einer Anwendung gewährt.

5.3 Single Sign On

Die nachfolgenden grundlegenden Begriffe und Techniken im Zusammenhang mit SSO geben zunächst einen Überblick über die aktuell vorhandenen Techniken und sind die Grundlage für die danach aufgeführten Argumentationen und Darstellungen.

5.3.1 Funktionsweise von Single Sign On

SSO steht im Allgemeinen für eine einmalige Anmeldung an einem System, welches sämtliche Berechtigungen, die innerhalb eines bestimmten Systems (z.B. in einem LAN) benötigt werden, festlegt und verwaltet. Dabei automatisiert das System nach erfolgter Erstanmeldung die Anmeldevorgänge an weiteren Anwendungen, die durch den Benutzer gestartet werden^[7].
Ein SSO System kommt häufig dann in Betracht, wenn innerhalb eines Unternehmens eine Vielzahl verschiedener Anwendungen genutzt werden und daraus resultierend meist mehrere verschiedene Benutzerkennungen für die Anwender verwaltet werden müssen. Zur Veranschaulichung dient hier beispielhaft die Funktion eines Hausmeisters, der i.d.R. einen großen Schlüsselbund mit sich trägt, um Zugang zum jeweiligen Raum zu erhalten. Da in der heutigen Zeit die meisten Zugriffskontrollsysteme elektronisch arbeiten, hilft der Schlüsselbund an dieser Stelle nicht mehr weiter. Stattdessen könnte ein SSO System zentral und automatisiert die Funktion des Schlüsselbunds übernehmen^[8].
Bei SSO ist es ausreichend, sich durch ein einmaliges Sign-on bei allen Zugangskontrollsystemen zu identifizieren und zu autorisieren. Mögliche Sign-on Verfahren sind beispielsweise die Kombination von Chipkarte und Passwort oder biometrische Verfahren, wie die Überprüfung des Fingerabdrucks. Die einfacheren Verfahrensweisen für den Benutzer gehen allerdings einher mit höherem Administrationsaufwand und hohen Anforderungen an das SSO System. Durch eine zentralisierte Anmeldung muss das System möglichst ausfallsicher und dementsprechend hochverfügbar sein. Weiterhin sollten die Daten innerhalb des SSO Systems sehr gut geschützt sowie eine gute Skalierbarkeit gegeben sein, um auch zukünftig performant mit dem System arbeiten zu können^[9].

5.3.2 Active Directory Single Sign On

Eine der bekanntesten Formen des SSOs stellt das Active Directory (kurz: AD bzw. ADSSO) von Microsoft dar. Hierbei werden sämtliche Berechtigungen des Anwenders im Account (Benutzername) gespeichert, welcher im AD hinterlegt ist. Berechtigungen sind beispielsweise der Zugriff auf bestimmte Ressourcen (Netzlaufwerke, Drucker, etc.) oder das Öffnen und Bearbeiten von Dateien. Sämtliche Anwendungen authentifizieren den Benutzer anhand des im AD hinterlegten Accounts, was voraussetzt, dass die Anwendungen mit dem AD kompatibel sind. Doch selbst in reinen Microsoft Infrastrukturen ist noch keine vollständige AD Authentifizierung umgesetzt. Erst durch aufwendige Schemaerweiterungen konnte beispielsweise die Exchange Userverwaltung an das AD angebunden werden, im Gegensatz zur SQL Server Benutzerverwaltung, bei der noch häufig individuelle Authentifizierungsmethoden implementiert sind^[10].

5.3.3 Enterprise Single Sign On

Beim ESSO soll eine einmalige Benutzeranmeldung auch ohne Bezug zum AD möglich sein. Das Einsatzgebiet geht also über das von reinen Microsoft AD Strukturen hinaus und soll eine Einbindung von Anwendungen in den SSO-Prozess ermöglichen, die keine Schnittstelle zum AD besitzen. Dies bedeutet für die zuständigen Systemadministratoren zunächst einen Mehraufwand, da eine Verwaltungslogik implementiert werden muss, welche im Hintergrund die Anmeldevorgänge für den Anwender übernimmt. Der Anwender selbst muss sich nur ein Mal zu Beginn authentifizieren, danach übernimmt die Login-Software alle weiteren Anmeldungen.^[11]. Dementsprechend wird mit ESSO eine automatisierte Anmeldung an Systemen ermöglicht, die von unterschiedlichen Herstellern entwickelt wurde und die dementsprechend auch unterschiedliche Benutzerverwaltungen implementiert haben (in Abb. 3 bspw. SAP und Lotus Notes).

5.3.4 Web Single Sign On

Diese Lösung erstreckt sich im Gegensatz zu ADSSO und ESSO über das lokale Unternehmensnetz (LAN) hinaus. Aufgrund der zunehmenden Vernetzung nationaler und internationaler Unternehmensstandorte, des Datenaustauschs mit Partnerunternehmen sowie der steigenden Zahl verfügbarer Internetdienste, wird immer häufiger nach einem vereinfachten Datenzugriff über die Infrastruktur des Internets verlangt. Je nach Anzahl der benötigten Applikationen werden auch bei dieser Form des Datenzugriffs unterschiedlich viele Zugangsdaten benötigt, was dem Anwender durch eine WSSO Lösung vereinfacht werden soll. Durch die einmalige Anmeldung an einem Webportal werden diese Zugangsdaten an die jeweilige Applikation, die durch den Anwender ausgeführt wird, weitergereicht, um so eine automatisierte Anmeldung im World Wide Web zu ermöglichen^[12].

6 Fallbeispiel

Auf Grundlage der unter Punkt 4.1 genannten Problemstellung wurden in einem Krankenhaus die Chancen einer SSO Implementierung untersucht. Dabei wurde zunächst die Ist-Situation analysiert, um möglichst genau zu erfassen, bei welchen Prozessen welche Probleme auftreten. Als Fokus für die Ist-Analyse dienen alltägliche Schwierigkeiten im Umgang mit Anmeldedaten sowie daraus resultierende Folgeprobleme. Um diese Problemstellungen zu verdeutlichen, wurden Mitarbeitern aus den vier größten Bereichen des Krankenhauses verschiedene Fragen rund um das Thema Benutzeranmeldung und der damit verbundenen Schwierigkeiten gestellt. Aus den Ergebnissen der Ist-Analyse lässt sich dann eine Liste erstellen, welche die momentan vorhandenen Mängel sowie die Wünsche bzw. Ansprüche an ein SSO System übersichtlich auflistet.

6.1 Ist-Zustand

Aufgrund der Vielzahl eingesetzter Software-Produkte müssen die Anwender viele verschiedene Zugangsdaten im Kopf behalten. Zugangsdaten werden u.a. für das Abfragen von E-Mails, die Anmeldung in einer Terminal-Server-Umgebung sowie die Anmeldung am Krankenhaus-Informationssystem benötigt. Die Vielzahl an Zugangsdaten führt zu unterschiedlichen Problemen. So erhalten die Mitarbeiter des Helpdesks zum Einen täglich Anfragen, die Kennwörter vieler Benutzeraccounts zurückzusetzen, was sehr viel Zeit kostet. Von den Anwendern werden zum Anderen häufig sehr triviale, leicht zu merkende Passwörter vergeben und teilweise die kompletten Zugangsdaten auf Notizzetteln am Monitor oder anderen leicht zugänglichen Stellen hinterlegt, um darauf möglichst schnell zugreifen zu können. Dies birgt ein deutliches Sicherheitsrisiko in sich, da nicht autorisierten Personen der Zugang zu einem datentechnisch sensiblen Bereich erheblich vereinfacht wird.
Ein weiteres Problem, was sich besonders in einem Krankenhaus bemerkbar machen kann, sind die so genannten Sammelaccounts, also Zugangsdaten, die von mehreren Personen gemeinsam genutzt werden. In diesem Zusammenhang ist es auch möglich, dass Anwender ihre Zugangsdaten weitergeben, da Kollegen für bestimmte Vorgänge keine ausreichenden Berechtigungen besitzen oder um den Arbeitsablauf zu vereinfachen. Dadurch ist allerdings keine rechtssichere Dokumentation der Datenzugriffe mehr möglich, so dass, gerade bei Rechtsstreitigkeiten, keine eindeutige Zuordnung der Abläufe und Änderungen zu einer Person gegeben ist.
Darüber hinaus kann es passieren, dass gerade bei größeren Unternehmen die Kommunikation zwischen der Personalabteilung und der IT nicht einwandfrei funktioniert. Von der Personalabteilung kommt in diesem Fall keine Rückmeldung, wenn ein Mitarbeiter aus dem Unternehmen ausscheidet. Somit ist es möglich, dass teilweise noch mit Zugangsdaten gearbeitet wird, welche einem bereits ausgeschiedenem Mitarbeiter zugeordnet sind.
Weitere Probleme zeigen sich bei Systemen, die von den Anwendern einen regelmäßigen Wechsel ihres Passworts verlangen. Vielfach ist den Anwendern dieser zusätzliche Sicherheitsaspekt zu aufwendig, was sich in Beschwerden oder genereller Verärgerung äußert.
In IT-Landschaften, in denen viele verschiedene Software-Produkte zum Einsatz kommen, müssen häufig mehrere Benutzerdatenbanken gepflegt werden. Die Interoperabilität verschiedener Software beschränkt sich oft auf den Bereich des Austausches von Bewegungsdaten, aber nur selten auf den Bereich der Benutzerverwaltung. Gemeinsame Benutzerverwaltungen gestalten sich in so fern schwierig, als das der Bestimmungszweck einer Software normalerweise nicht dem der anderen Software entspricht. Ein E-Mail Programm hat nur sehr geringe Gemeinsamkeiten mit dem Abrechnungssystem der Verwaltung. Das Resultat sind komplett verschiedene Prozesse und dementsprechend auch verschiedene Benutzerkonzepte, was i.d.R. zur Verwaltung mehrerer Benutzerdatenbanken führt. Dies hat zur Folge, dass der administrative Aufwand und die Kosten durch den Mehraufwand steigen.
Im nächsten Schritt soll konkretisiert werden, ob die in der Theorie erfassten Probleme auch in der Praxis existieren, bzw. welchen Aufwand die Anwender mit dem momentanen Ablauf der Anmeldevorgänge und Benutzerverwaltung haben.

6.1.1 Praxisanalyse

Vor dem eigentlichen Projektbeginn wurden aus den Bereichen ärztlicher Dienst, Pflegepersonal, Verwaltung und sonstige Einrichtungen jeweils 20 Anwender zu den folgenden Punkten befragt:

• In wie vielen Programmen müssen Sie sich täglich durchschnittlich anmelden?
• Wie viel Zeit benötigen Sie durchschnittlich für diese Anmeldevorgänge?
• Wie viele verschiedene Anmeldedaten müssen Sie sich merken?
• Wie häufig müssen Sie sich am Tag durchschnittlich in einem Programm neu anmelden (Computer gesperrt, Sitzung abgelaufen etc.)?
• In wie vielen Programmen müssen Sie regelmäßig Ihr Passwort ändern?
• Wie häufig benötigen Sie Unterstützung vom Helpdesk bzgl. Ihrer Zugangsdaten?
  

Das Ergebnis wurde in Tabellen (s. Abb. 5) festgehalten und soll zeigen, ob die theoretischen Ausführungen des Ist-Zustands (Kapitel 6.1) auch in der Praxis zutreffen.
Bei genauerer Betrachtung der Angaben zum Zeitbedarf für Anmeldevorgänge fällt auf, dass sich hier das in Kapitel 4.1 beschriebene Problem des hohen Zeitaufwands bei Anmeldeprozessen bestätigt. Am Beispiel der Ärzte lässt sich errechnen, dass durchschnittlich 63,5 Std. pro Jahr (bei 254 Arbeitstagen jährlich) für die Anmeldeprozesse von ca. sechs Anwendungen aufgebracht werden müssen. Ärzte müssen sich täglich im Durchschnitt an fünf verschiedenen Anwendungen anmelden (nicht jede Anwendung wird täglich benötigt), und müssen weiterhin sechs verschiedene Anmeldedaten dauerhaft im Kopf haben. Am „leichtesten“ haben es an dieser Stelle die sonstigen Einrichtungen mit durchschnittlich drei Anmeldungen pro Tag und vier verschiedenen Anmeldedaten. Private Anmeldedaten sind in dieser Statistik nicht erfasst. Diese können aber durchaus zu Verwechslungen mit den Daten im Unternehmen führen, was wiederum den Zeitbedarf für die Anmeldedaten aufgrund falsch eingegebener Zugangsdaten oder gesperrter Accounts durch zu häufige Fehleingaben erhöht. Die Zahl der Passwortänderungen, welche bei den Ärzten mit drei regelmäßigen Änderungen recht hoch ausfallen, könnten zum Einen Sicherheitsprobleme nach sich ziehen und zum Anderen erneut den Zeitbedarf für Anmeldedaten sowohl für die betreffende Person, als auch für den Helpdesk erhöhen. Die Sicherheit könnte durch zu einfache Passwörter gefährdet sein, die man sich bei regelmäßiger Änderung leichter merken kann und der Zeitbedarf erhöht sich durch vergessene Passwörter, bzw. gesperrte Accounts, nach einer Passwortänderung.
Als Ergebnis der Praxisanalyse bleibt festzuhalten, dass im Bereich der Benutzerverwaltung ein enormes Verbesserungspotential besteht. Dieses Potential wird in Form von Mängeln und Wünschen im nächsten Schritt zusammengefasst.

6.1.2 Mängel-/Wunschliste

Nach der Analyse des Ist-Zustands in der Theorie und in der Praxis kann nun folgende Mängel-/Wunschliste erarbeitet werden:

Kategorie (M = Mangel, W= Wunsch)	Leistungshemmnis/Verbesserungsmöglichkeit	Konkrete Vorschläge/Verbesserungshinweise/Lösungen
M	Viele Zugangsdaten merken	Einführung einer SSO Lösung
M	Die Passwörter müssen häufig geändert werden	Einführung einer SSO Lösung
M	Kein Informationsaustausch, wenn Mitarbeiter das Unternehmen verlassen	Die Ausgabe und die Rückforderung der SSO Zugänge (Token, USB Stick, etc.) muss durch die Personalabteilung verwaltet werden
M	User verwenden einfache Passworte, die nicht sicher sind	User muss sich kein Passwort merken, was hoch kryptische Passworte für das SSO System ermöglichen würde
M	Keine Sammelaccounts mehr zulassen	Auch ohne SSO möglich; erschwert jedoch in manchen Bereichen die Prozessabläufe
M	Hoher Zeitaufwand für die Administration der eigenen Zugangsdaten	Einführung einer SSO Lösung
M	Hoher Zeit- und dementsprechend auch Kostenaufwand am Helpdesk bzgl. der Benutzerzugangsdaten	Einführung einer SSO Lösung
M	Hohe Anzahl an Anmeldevorgängen pro Tag	Einführung einer SSO Lösung
W	Ein zentraler Zugang zu den Applikationen	Einführung einer SSO Lösung
W	Einheitliche Benutzerverwaltung	Einführung einer SSO Lösung
W	Steigerung des Benutzerkomforts durch SSO	-
W	Entlastung des Callcenters in dem die Zahl der Anfragen reduziert wird, bei denen die Rücksetzung des Passwortes verlangt wird	Einführung einer SSO Lösung
W	Unterbinden, dass Mitarbeiter ihre Zugangsdaten weitergeben	Hier gibt es keine 100%ige Sicherheit, da auch bei SSO das Token, der PIN Code usw. weitergegeben werden können

Tabelle 1: Mängel- / Wunschliste vor der SSO Einführung

Diese Tabelle bietet zum Einen eine Übersicht über das Verbesserungspotential bezogen auf die Anmeldeprozesse im Unternehmen und zum Anderen kann sie als eine Art Kontrollstruktur im weiteren Projektverlauf verwendet werden, anhand derer das Ziel oder die erreichten Ziele eines SSO Projekts abgelesen werden können.

6.2 Soll-Zustand

Ziel der Einführung von SSO ist, das Anmeldeverfahren sicherer und einfacher zu gestalten und weiterhin den administrativen Aufwand der IT für die Benutzerverwaltung zu minimieren. Es sollen nur noch aktive, im Unternehmen beschäftigte Mitarbeiter Zugang zu den Systemen erhalten. Dies bedeutet, dass alle Zugänge personalisiert werden müssen und es zukünftig keine Sammelaccounts mehr geben darf. Das bereits vorhandene ADSSO soll durch ein ESSO System sinnvoll ergänzt werden. Die Anmeldevorgänge innerhalb des Unternehmensnetzwerks sollen für sämtliche Applikationen über das AD hinaus nach einmaliger, initialer Benutzerauthentifizierung automatisiert werden. Der Zugriff auf Anwendungen über das Internet wird nur in einem sehr kleinen Rahmen benötigt, so dass eine WSSO Lösung in diesem Fall nicht in Betracht gezogen wird.

6.2.1 Kritische Erfolgsfaktoren

Im Vorfeld wurden durch die IT die Faktoren zusammengetragen, welche aus IT Sicht die notwendigen Ansprüche an ein SSO System darstellen. Kann einer dieser Ansprüche nicht umgesetzt werden, könnte dadurch die Einführung einer SSO Lösung scheitern. Aufgrund unterschiedlicher Gegebenheiten und Ansprüche in den Unternehmen kann sowohl die Anzahl als auch die Art der kritischen Erfolgsfaktoren eines SSO Projekts sehr unterschiedlich sein. Im beschriebenen Fallbeispiel dieser Arbeit werden die nachfolgend genannten Anforderungen als kritisch für die Einführung des SSO Systems betrachtet:

• Schneller Anmeldevorgang:

Der SSO Anmeldevorgang sollte für die Endanwender einfach zu bedienen sein. Darunter fallen sowohl eine kurze Anmeldedauer, möglichst wenige Mausklicks für den Anmeldevorgang, als auch ein schnelles Ummelden beim Benutzerwechsel, was weniger als 5 Sekunden entspricht. Dauern die für den User offensichtlichen Funktionen von SSO, wie das An- und Abmelden, zu lange, besteht die Gefahr, dass das System von den Endanwendern nicht akzeptiert wird.

• Ein Notfallzugriff für alle Anwender bei Ausfall des SSO Systems muss möglich und die Vorgehensweise bei vergessenen Zugangsdaten (Token, USB Stick etc.) muss abgestimmt und festgelegt sein:

Bei der Einführung sollte ein funktionierendes Notfallsystem existieren, was die Vorgehensweisen für einen Ausfall des SSO Systems und den Verlust bzw. das Vergessen der SSO Zugangsdaten beschreibt. Hierbei ist es wichtig, die für den Anwender ohnehin bestehende Verzögerung so gering wie möglich zu halten. Telefonate über mehrere Personen, zu lange Reaktionszeiten in der IT oder eine einzige zentrale Ausgabe für Ersatz-Zugangsdaten sollten dementsprechend vermieden werden.

• Die Umstellung auf SSO muss auch bereichsweise vollzogen werden können:

Gerade im Krankenhausbereich ist es erforderlich, dass neue Systeme bereichsbezogen eingebunden werden können. Dies hat den Vorteil, dass neue Anwendungen zunächst in einzelnen Bereichen oder auf einzelnen Klinikstationen getestet werden können, um flächendeckende Probleme zu vermeiden und das neue System erst dann auszurollen, wenn eine voll funktionale Lösung gegeben ist.

• Gute Skalierbarkeit des SSO Systems:

Auch die unterstützten Applikationen sowie die Erweiterbarkeit einer SSO Lösung sollten an dieser Stelle betrachtet werden. Sinn und Zweck von SSO ist es, den Anwendern eines Unternehmens mit nur einer Anmeldung Zugang zu allen, für den jeweiligen Benutzer freigeschalteten Anwendungen zu gewähren. Dabei ist es nicht ausreichend, diese Funktion nur innerhalb des KIS zu benutzen, sondern bei allen Anwendungen, deren Benutzung eine Authentifizierung erfordert. Die Einbindung weiterer Software, die auch zukünftig erfolgen kann, sollte ohne großen Aufwand durch einen Administrator möglich sein, um die Zukunftsfähigkeit der SSO Lösung zu verifizieren.

• Die Ausgabe der Zugangsberechtigung soll durch die Personalabteilung erfolgen:

Die Ausgabe der Zugangsberechtigungen sollte ohne hohen administrativen Aufwand durch Mitarbeiter der Personalabteilung möglich sein. Nur so kann sichergestellt werden, dass der Account von Mitarbeitern, welche das Unternehmen verlassen, nicht weiter benutzt wird.

• Ein Benutzerwechsel im Kontext einer laufenden Applikation soll möglich sein:

Da sich häufig mehrere Mitarbeiter einen Computer teilen, sollte eine Benutzerummeldung im Kontext der jeweiligen Applikation möglich sein. Aus Zeit- und Effizienzgründen wäre es von Vorteil, dass durch eine Ummeldung die bereits gestarteten Programme nach der Ummeldung direkt wieder zur Verfügung stehen und nicht erneut geöffnet werden müssen.

• Das System soll auch bei mobilen Systemen (z.B. Laptops, die über WLAN an das Unternehmensnetz angebunden sind), an einem MAC oder an Thin Clients funktionieren:

Die Funktionalität sollte nicht nur an festinstallierten Arbeitsplatz-PCs gegeben sein, sondern z.B. auch bei Laptops oder Thin Clients. Je nach Verbreitung der Geräte können hier ggf. Abstriche gemacht werden, jedoch sollten stets auch zukünftige Entwicklungen in die Anforderungen miteinbezogen werden. Gerade die Nutzung von mobilen Endgeräten wie Laptops, die über WLAN angebunden sind, könnte in den nächsten Jahren noch stärker zunehmen.

6.2.2 Risikoanalyse

Zur besseren Darstellung der potentiellen Risiken, welche in diesem Fallbeispiel eintreten könnten, wurde zunächst eine Tabelle erstellt, anhand derer die anschließende Bewertung der Risiken erfolgt. Die Tabelle enthält nur eine Auswahl aller erfassten Risiken, um die verwendete Vorgehensweise im Fallbeispiel zu verdeutlichen.

Risiko	Eintritts-Wahrscheinlichkeit (0,1 - 1)	Was kann getan werden
Widerstand in der Personalabteilung bzgl. der Ausgabe von Zugangsdaten	0,6	Projektmarketing
Schwierigkeiten mit dem SSO System unter Windows Server 2008 64Bit	0,7	Herstellerseitige Anpassung des Systems
Eingeschränkte Funktionalität auf bestimmten Endgeräten (z.B. MAC, Thin Client oder Notebook)	0,5	Abwägen wie wichtig die Funktionalität dieser Endgeräte ist, bzw. den Hersteller um Anpassung bitten
Anschlussmöglichkeiten an den Endgeräten nicht ausreichend (z.B. zu wenig freie USB Schnittstellen)	0,2	Alternativen prüfen (z.B. Einsatz eines USB Hubs oder der Einsatz von Smart-Cards mit RFID)
Funktionierendes Notfallkonzept	0,6	Vor Projektstart mit dem Hersteller absprechen und testen

Tabelle 2: Risikoanalyse

In der Risikoanalyse sollten die Punkte erfasst werden, deren Eintreten negative Auswirkungen auf das weitere Vorgehen haben könnte. In Tabelle 2 wurden nur Risiken mit einer Eintrittswahrscheinlichkeit bis 0,7 erfasst. Alles was über 0,7 liegt, wurde direkt als Problemstellung mit in die Planung aufgenommen, da diese Punkte im beschriebenen Fallbeispiel nicht mehr als Risiko, sondern als existierendes Problem zu bewerten sind.
Die identifizierten Risiken sollen Probleme aufdecken, die direkten bzw. indirekten Einfluss auf die erfolgreiche Implementierung eines SSO Systems nehmen können. Bei der Risikoanalyse hat sich herausgestellt, dass es Schwierigkeiten mit dem SSO System unter Windows Server 2008 64 Bit gibt, da dass System nicht einwandfrei arbeitet. Für die Zukunftssicherheit ist der Betrieb auf einem aktuellen Betriebssystem aber notwendig. Aus diesem Grund stellt dieses Problem ein Risiko in Bezug auf die Erreichung der Projektziele dar. Weiterhin sollten auch vermeintliche Randbedingungen wie das Vorhandensein entsprechender Hardwareressourcen und die Funktionalität des SSO Systems auf möglichst allen Endgeräten mit einbezogen werden. Kritische Punkte wie ein funktionierendes Notfallkonzept sollten hier ebenfalls aufgenommen und mit entsprechend hoher Priorität beobachtet werden.

6.3 Nutzwertanalyse

Da es sich bei der Entscheidung ein SSO System einzuführen im Fallbeispiel dieser Seminararbeit um eine strategische Entscheidung mit Ausrichtung auf die Zukunft handelt, sollte im Vorfeld dieser Entscheidung der zu erwartende Nutzen analysiert werden.
Bei der Nutzwertanalyse werden die Zielwerte von Handlungsalternativen mittels vergleichender Gegenüberstellung betrachtet. Das Verfahren kommt häufig dann zur Anwendung, wenn nicht monetäre Faktoren (z.B. Qualität oder Bedienkomfort) miteinander verglichen werden sollen. Für den Vergleich wird eine metrische Skala vorgegeben, die häufig von 1 (schlechteste Zielerreichung) bis 10 (beste Zielerreichung) reicht. Da nicht alle Kriterien gleich wichtig sind, wird ihre Bedeutung durch verschiedene Gewichtungsfaktoren ausgedrückt. Die Multiplikation der Einzelwerte mit den Gewichtungsfaktoren überführt diese in gewichtete Einzelwerte (Nutzwerte). Letztendlich ergibt die Summe aller Nutzwerte den Gesamtwert einer Handlungsalternative^[13].
Im beschriebenen Fallbeispiel wurde eine Nutzwertanalyse für eine heterogene Benutzerverwaltung (1. Handlungsalternative, nachfolgend H1 genannt) und eine SSO Benutzerverwaltung (2. Handlungsalternative, nachfolgend H2 genannt) durchgeführt. Dabei wurden die für die Bewertung relevanten Kriterien in die vier Gruppen Administrationsaufwand, Benutzerfreundlichkeit, Zukunftssicherheit / Skalierbarkeit und Sicherheit unterteilt. Zu jeder Gruppe wurden drei bis vier Kriterien erarbeitet, die durch Multiplikation ihrer Einzelgewichtung mit dem zu erwartenden Nutzwert in die Gesamtbewertung eingeflossen sind. Die Einzelgewichtungen wurden durch die Projektverantwortlichen der IT Abteilung festgelegt und beruhen auf den bereits in der Praxis gewonnenen Erkenntnissen zur heterogenen Benutzerverwaltung und aus den verschiedenen implementierten Teststellungen von SSO Systemen. Zur besseren Übersicht der Nutzwertanalyse wurde zu jeder Kriteriengruppe auch die Teilsumme der erreichten Punkte innerhalb dieser Gruppe angegeben. Durch Addition aller vier Teilsummen wurde zuletzt das Gesamtergebnis für die oben genannten Handlungsalternativen errechnet:



Das Endergebnis der Analyse fällt sehr deutlich zu Gunsten der SSO Benutzerverwaltung aus. Sie erhält 278 Punkte mehr als die heterogene Benutzerverwaltung und erhält somit die klare Empfehlung zur Implementierung. Um das Zustandekommen des Endergebnisses zu verdeutlichen, sollten die Hintergründe für die Berechnung der Einzelwerte betrachtet werden.
Beim Administrationsaufwand schneidet H1 sogar noch etwas besser ab als H2. Dies ist damit begründet, dass der Administrationsaufwand für sämtliche Abteilungen sehr gering gewichtet ist und dementsprechend weniger Punkte für H2, trotz deutlich weniger Aufwand, errechnet werden konnten. Der Ausfall bei einem Wartungsfenster sollte allerdings so gering wie möglich gehalten werden und hat deshalb eine sehr hohe Gewichtung. Da bei einem Ausfall des SSO Systems durch eine Wartung jedoch keine an das SSO angebundene Anmeldung mehr funktioniert, stellt dies sowohl die IT als auch den Anwender nicht zufrieden. Bei H1 funktionieren dagegen lediglich die vom Wartungsfentser betroffene(n) Anwendung(en) nicht mehr.
Bei der Benutzerfreundlichkeit wurde das mit Abstand beste Ergebnis für H2 ermittelt. Eines der Hauptprobleme in einer heterogenen Benutzerumgebung sind die bereits erwähnten vielen verschiedenen Zugangsdaten, langwierige An- und Abmeldevorgänge und ein hoher Zeitbedarf für die Administration der Zugangsdaten sowohl auf Seiten der Anwender als auch der IT. Da SSO in dieser Kategorie, im Gegensatz zu H1, durchweg gute Zielwerte erreichen kann, durch weniger Supportaufwand, bessere Integration in die verschiedenen Arbeitsprozesse sowie ein deutlich vereinfachter Anmeldevorgang, ist das Ergebnis durchaus realistisch.
Bei der Zukunftssicherheit bzw. der Skalierbarkeit schneidet H1 nur minimal schlechter ab als H2. Problematisch ist an dieser Stelle vor allem die Erweiterbarkeit des SSO Systems um neue Applikationen. Während bei der heterogenen Umgebung zwar neue Zugangsdaten erforderlich, sonst aber keine größeren Arbeiten in Bezug auf die Benutzerverwaltung nötig sind, muss bei SSO die neue Anwendung zunächst in das SSO System eingebunden werden. Das heißt z. B., dass die Anmeldemaske erkannt werden muss und die jeweiligen Benutzer in der neuen Anwendung vorhanden sein müssen. Der Ressourcenbedarf ist bei H1 sehr viel höher als bei H2. Die Berechnung des Wertes erfolgt an dieser Stelle auf Grundlage der Effektivität. Bei H1 wird für jede Anwendung i.d.R. ein Server, Speicherplatz und ein Administrator zu Betreuung des Systems benötigt. Bei H2 wird ein zentrales System benötigt, um dieses in vielen Bereichen anwenden zu können.
Einen der wichtigsten Bereiche stellt die Sicherheit des Systems dar. Hier liegt H2 ebenfalls deutlich vorne, allerdings sorgt der Punkt Ausfallsicherheit hier für deutliche Einbußen. Dieser Punkt geht einher mit dem Ausfall bei einem Wartungsfenster, bei welchem die Problemstellung aber unterschiedlich ist. Bei der Ausfallsicherheit wird der Ausfall des Systems durch eine ungewollte Störung, wie den Defekt eines Servers, betrachtet. Bei H2 besteht an dieser Stelle ein so genannter Single Point of Failure, also ein Punkt, dessen Ausfall den Ausfall eines ganzen Systems nach sich zieht. Fällt die Anmeldelogik des SSO Systems aus, sind keine Anmeldungen an sämtlichen Applikationen, die an dieses System angebunden sind, mehr möglich. Bei H1 ist i.d.R. nur eine Applikation betroffen, was letztlich den besseren Wert für H1 ergibt. Bei Betrachtung der Passwortsicherheit und des Passwortschutzes hingegen schneidet H1 zwei Mal mit den schlechtesten Werten ab. Die Hauptgründe für das Zustandekommen der schlechten Zielwerte sind u.a. die Tatsache, dass Zugangsdaten auf einen Zettel geschrieben und an den Monitor geklebt werden und dass Passwörter aufgrund ihrer Vielzahl sehr einfach gewählt und teilweise auch ohne Aufforderung an Kollegen weitergegeben werden. SSO hingegen setzt genau bei dieser Problematik an und zielt darauf ab durch einen zentralen Zugang, wie z.B. über einen USB Stick + PIN, die Weitergabe der Zugangsdaten überflüssig zu machen und für die automatisierte Anmeldung an den Systemen hoch komplexe Passwörter wählen zu können. Beim Passwortschutz wurde die Bewertung allerdings erneut aufgrund des Single Point of Failure Problems herabgesetzt. Gelangt jemand in den Besitz der Zugangsdaten eines Anwenders, so hat dieser Zugang zu allen Applikationen, die für diesen Anwender freigeschaltet sind.
Abschließend ist festzuhalten, dass ein SSO System einige Kriterien bzw. Wünsche nicht oder nur teilweise erfüllen kann. Dafür leistet es auf der anderen Seite bei wichtigen Kriterien wie der Sicherheit oder der Benutzerfreundlichkeit sehr gute Ergebnisse, die ein solches System auszeichnen und nach möglicher Implementierung einen großen Schritt nach vorne bedeuten würden.

6.4 Kritische Betrachtung des SSO Systems

Bei allen Vorteilen, die ein SSO System mit sich bringt, sollten aber auch potentielle Nachteile bzw. technisch bedingte Probleme, die durch die Einführung eines solchen Systems entstehen können, analysiert und ausgewertet werden.
Zunächst sollte durch die Firmen, welchen für eine mögliche Umsetzung des Projekts in der engeren Auswahl sind, eine Teststellung durchgeführt werden. Im hier beschriebenen Fallbeispiel wurde erst durch eine Teststellung ersichtlich, dass SSO Systeme in den folgenden Situationen nicht korrekt funktionierten:

• Benutzerwechsel im Kontext

Ein Benutzerwechsel im Kontext ist z.B. dann erforderlich, wenn eine Pflegekraft ihre Dokumentation zu einem Patienten bearbeitet und ein Arzt die ärztliche Dokumentation am selben Rechner durchführen möchte. Eine Neuanmeldung wäre an dieser Stelle für den Arzt zu aufwendig, so dass lediglich ein Benutzerwechsel stattfindet, der Patientenkontext aber erhalten bleiben muss. Ein weiteres Beispiel wäre ein Schichtwechsel von Mitarbeitern. Die Frühschicht meldet sich ab und die Spätschicht kann umgehend im selben Kontext wie die Frühschicht weiter arbeiten. Problematisch ist der Benutzerwechsel dann, wenn er in einer Terminal-Server Umgebung stattfindet. Beim Benutzerwechsel muss die Terminal Sitzung aktiv bleiben, wohingegen die Anmeldung am Programm in der Sitzung getrennt und mit den Daten des neuen Benutzers wieder aufgenommen werden muss.

• Freigabe von Aufträgen

Hier ist es ähnlich wie beim Benutzerwechsel im Kontext. Jemand möchte etwas beauftragen, für das er keine Berechtigung hat. Der Auftrag wird also durch eine „unberechtigte “ Person erstellt und ein anderer Benutzer mit entsprechenden Rechten authentifiziert sich im Anschluss um den Auftrag freizugeben. Dabei darf aber keine Ummeldung in anderen Applikationen bzw. der Terminal Sitzung erfolgen.
Folgendes Beispiel dient der Veranschaulichung dieses Problems: eine Pflegekraft soll für einen Patienten eine Untersuchung beauftragen. Das Untersuchungsformular kann durch die Pflegekraft auch ausgefüllt und gespeichert werden, aber die Freigabe muss durch einen Arzt erfolgen um sicher zu stellen, dass alle Eingaben korrekt vorgenommen wurden. Die Freigabe erfolgt durch Eingabe seines Benutzers und seines Passworts.

• Authentifizierung mehrerer Benutzer in einer Maske

Es ist durchaus möglich, dass Computerprogramme Eingabemasken bereitstellen, welche die Authentifizierung mehrerer Benutzer verlangen. Im OP eines Krankenhauses müssen bestimmte Verbrauchsgüter von mindestens zwei Personen gezählt und kontrolliert werden. Die Korrektheit dieser Überprüfung muss dann in einer Maske bestätigt werden, welche die Eingabe der Benutzerdaten von zwei Personen verlangt. Die Schwierigkeit für ein SSO System besteht demnach darin, die Benutzerdaten verschiedener Personen zu erkennen und korrekt an die Eingabemaske zu übergeben.
Die Erfahrungen im Fallbeispiel haben gezeigt, dass die Funktionalität von SSO Systemen bei standardmäßiger Anwendung sehr gut funktioniert. Standardmäßig bedeutet, dass ein Benutzer mit seinem Account in jeder Anwendung dauerhaft angemeldet ist bzw. sich bei Verlassen des Arbeitsplatzes ordnungsgemäß abmelden kann. Die Standardfunktionalität ist in vielen Fällen jedoch nicht ausreichend. Die oben genannten Beispiele zeigen anhand des hier beschriebenen Fallbeispiels, dass anwendungs- bzw. unternehmensspezifische Prozesse und Abläufe zu einem Fallstrick für SSO Systeme werden können. Daher sollten besondere Abläufe zunächst getestet und analysiert werden, um dadurch die Gewissheit zu bekommen, ob auch solche Anforderungen durch das SSO System erfüllt werden können. Sollten bestimmte Funktionen nicht gegeben sein, ist das Unternehmen im schlimmsten Fall auf die Entwicklungsabteilung des SSO Anbieters angewiesen, welche für die Lösung der unternehmensspezifischen Probleme neue Algorithmen entwickeln muss.

7 Fazit

Die Einführung eines SSO Systems bedeutet für ein Unternehmen zunächst einen größeren Aufwand, vor allem in der IT. Dieser Aufwand kann sich finanziell, in Mehrarbeit oder auch in Prozessumstellungen auswirken. Fraglich ist an dieser Stelle demnach, ob der Mehraufwand, welcher durch die Implementierung eines SSO Systems entsteht, in Relation zum erwarteten Nutzen dieses Systems nach der Einführung steht. Im Hinblick auf die zunehmende Automatisierung von Prozessen in vielen Unternehmensbereichen und wachsenden Ansprüchen an die IT-Sicherheit sowie an den Bedienkomfort von IT-Systemen, sind Lösungen zur innerbetrieblichen Prozessoptimierung äußerst begehrt. Die mögliche Einführung eines SSO System in einem Krankenhaus war in dieser Seminararbeit der Gegenstand zur Beantwortung der Frage, ob mit diesem System tatsächlich die Prozesse eines Unternehmens verbessert werden können.
Nach einer detaillierten Analyse der Ist-Situation konnten in Form einer Mängel- / Wunschliste, die Punkte zusammengetragen werden, welche ein deutliches Verbesserungspotential bieten. Aufgrund der Erfahrungen der IT und der Auswertung der Mitarbeiterbefragung wurde deutlich, dass vor allem in den Bereichen Sicherheit und Benutzerfreundlichkeit im Bereich der Benutzerverwaltung mangelhafte Prozessabläufe bestehen. Um dem entgegenzuwirken wurde die Implementierung einer SSO Lösung in Erwägung gezogen. Dabei wurde der zu erwartende Nutzen des SSO Systems den Ansprüchen und Erwartungen der IT an die Umsetzung des Projekts gegenübergestellt. Deutliche Fortschritte durch SSO sind in den Bereichen Sicherheit und Benutzerkomfort zu erwarten. In diesen Bereichen wird u.a. ein schnelleres An- und Abmeldeverfahren ermöglicht und ein zentraler Zugang je Benutzer eingeführt, was produktiveres Arbeiten und eine deutliche Zeitersparnis, in Bezug auf Supportanfragen beim Helpdesk sowie das tägliche häufige An- und Abmelden, ermöglicht. Weiterhin können die SSO Zugangsdaten zentral in der Personalabteilung verwaltet bzw. ausgegeben werden, was momentan durch den hohen administrativen Aufwand bei der heterogenen Benutzerverwaltung nicht realisierbar ist. Der Vorteil dieser Änderung wäre, dass im Unternehmen nur noch die Zugänge der Mitarbeiter aktiv sind, welche noch im Unternehmen beschäftigt sind. Verlässt jemand das Unternehmen, führt der Weg nicht an der Personalabteilung vorbei, wohl aber an der IT, so dass der Zugang zeitnah deaktiviert werden kann.
Allerdings ist auch ein SSO System nicht durchweg positiv zu bewerten. Solange mit SSO routinemäßige Probleme, wie z. B. das lokale Arbeiten mit einer zentralen Anmeldung an seinem eigenen Arbeitsplatz, gelöst werden sollen, arbeitet das SSO System sehr gut. Werden jedoch unternehmensspezifische Probleme betrachtet, die mitunter als Ausschlusskriterium für die Umsetzung des Projekts dienen, wurden einzelne Abläufe gefunden, bei denen die Software des SSO Systems nicht funktionierte. Dies war beispielsweise bei einem Benutzerwechsel im Kontext der Fall, bei dem eine Anmeldung im Hintergrund geöffnet bleiben muss, während zeitgleich eine Kontextummeldung innerhalb einer Applikation erfolgen muss. Hier kommt es auf die Bereitschaft des jeweiligen SSO Anbieters an, eine entsprechende Lösung für diese Problemstellung zu finden und diese ggf. zu programmieren. Das Problem des Single Point of Failure sollte ebenfalls mit in die Gesamtbetrachtung einbezogen werden. Durch ein durchdachtes Ausfallkonzept kann dieser Negativaspekt jedoch deutlich abgeschwächt werden.
In der Gesamtbetrachtung überwiegen zuletzt die Vorteile eines SSO Systems, so dass einer solchen Lösung abschließend und bezogen auf das hier beschriebene Fallbeispiel, ein hohes Potential zur innerbetrieblichen Prozessoptimierung zugesprochen werden kann.

8 Fußnoten

1. ↑ Network Applications Consortium (1996), S. 9, 11.
2. ↑ Vgl. Müller, K.-R. (2005), S. 262.
3. ↑ Vgl. Allen, R., Lo, N., Brown, S. (2009), S. 155 f.
4. ↑ Vgl. Lhotka, R. (2004)
5. ↑ Vgl. Swoboda, J., Spitz, S., Pramateftakis, M. (2008), S. 18.
6. ↑ Vgl. Lhotka, R. (2004)
7. ↑ Vgl. Traeger, D. H., Volk, A. (2002), S. 377.
8. ↑ Vgl. Müller, K.-R. (2008), S. 226 f.
9. ↑ Vgl. Müller, K.-R. (2008), S. 227.
10. ↑ Vgl. Baumeister, J. (2010)
11. ↑ Vgl. Baumeister, J. (2010)
12. ↑ Vgl. Baumeister, J. (2010)
13. ↑ Vgl. Hoffmeister, W. (2010), S. 278.

9 Literatur- und Quellenverzeichnis

Literaturquellen
Allen, R., Lo, N., Brown, S. (2009), Zend Framework im Einsatz, München 2009
Hoffmeister, W. (2008), Investitionsrechnung und Nutzwertanalyse, 2. überarbeitete Auflage, Berlin 2008
Müller, K.-R. (2005), Handbuch Unternehmenssicherheit, Wiesbaden 2005
Müller, K.-R. (2008), IT-Sicherheit mit System, 3. Auflage, Wiesbaden 2008
Network Application Consortium (1996), Enterprise-Wide Security: Authentication and Single Sign-On - A NAC Position Paper, San Francisco 1996
Swoboda, J., Spitz, S., Pramateftakis, M. (2008), Kryptographie und IT- Sicherheit, Wiesbaden 2008
Traeger, D. H., Volk, A. (2002), LAN: Praxis lokaler Netze, 4. Auflage, Stuttgart/Leipzig/Wiesbaden 2002

Internetquellen
Baumeister, Johann: Mögliche Single-Sign-on-Szenarien unter einer Oberfläche vereinen, 13.01.2010
http://www.searchsecurity.de/themenbereiche/identity-und-access-management/single-sign-on/articles/245444/index.html (04.06.2010, 16:01 Uhr)
Koch, Christian: Single Sign On – Komfort für den Benutzer oder ein Sicherheitsrisiko?, 05.2006
http://www.securitymanager.de/magazin/artikel_996_single_sign_on_komfort_fuer_den_benutzer_oder.html (03.06.2010, 16:32 Uhr)
Lhotka, R.: Authentifizierung und Autorisierung, 29.06.2004
http://msdn.microsoft.com/de-de/library/bb978972.aspx (27.06.2010, 14:35 Uhr)