www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Dokumentation LDAP Version 1.2, 01. November 2006 DI Peter Danner peter.danner@egiz.gv.at DI Thomas Knall thomas.knall@egiz.gv.at Zusammenfassung: Die Bürgerkarte bietet eine hochqualitative Identifizierung und Authentifikation eines Benutzers. In typischen Betriebsumgebungen sind aber mittelfristig weiterhin Systeme und Online-Applikationen mit konventionellen Mechanismen, bei denen für verschiedene Anwendungen unterschiedliche Benutzernamen und Passwörter zu verwenden sind, zu unterstützen. Hier sind Single-Sign-On Lösungen, die die Identifikation über Bürgerkarte auf diese Systeme abbilden sinnvoll. Diese Webanwendung stellt eine Ablösung der konventionellen Anmeldung über Benutzernamen und Passwort dar. Die Anwendung gliedert sich in zwei Teile: einem Webbasierten Benutzermanagement und einem Plugin für den MOA-ID-Proxy, welches diesen um einen Resolver für Logindaten erweitert. Es wird mit diesem Dokument die Anwendung dokumentiert. Dabei werden sowohl die Benutzung (), als auch die Konfiguration sowie die Installation beschrieben (Deployment und Auslieferung). Anmerkung: Zur besseren Lesbarkeit wurde in diesem Dokument teilweise auf geschlechtsspezifische Formulierungen verzichtet. Die verwendeten Formulierungen richten sich jedoch ausdrücklich an beide Geschlechter. Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz
Inhaltsverzeichnis: Inhaltsverzeichnis: Inhaltsverzeichnis:...2 Abbildungsverzeichnis...3 Revision History...4 1 Kurzbeschreibung...5 1.1 Grundlagen 5 1.2 Funktionsbeschreibung 5 1.3 Voraussetzungen zur Nutzung der Anwendung 6 2...7 2.1 Starten der Benutzerverwaltung 7 2.2 Allgemeines 9 2.3 Konfiguration der Benutzerverwaltung 10 2.4 Verwaltung von Personen 16 2.5 Verwaltung von Anwendungen 17 2.6 Single-Sign-On über den MOA-ID-Proxy 28 3 Deployment...33 3.1 Systemanforderungen 33 3.2 Abhängigkeiten 34 3.3 Installation 34 3.4 MOA-ID-Proxy 36 3.5 Benutzerverwaltung 41 4 Auslieferung...43 4.1 Struktur 43 Literaturverzeichnis...45 2
Abbildungsverzeichnis Abbildungsverzeichnis Abb. 2.1: Anmeldefenster zur Benutzerverwaltung...7 Abb. 2.2: Anmeldung mit Bürgerkarte...8 Abb. 2.3: Startseite der Benutzerverwaltung mit einer Übersicht registrierter Personen...9 Abb. 2.4: Allgemeine Einstellungen...10 Abb. 2.5: Persönliche Einstellungen...11 Abb. 2.6: Übersicht der eingetragenen LDAP-Server...11 Abb. 2.7: Hinzufügen eines LDAP-Servers...12 Abb. 2.8: Konfiguration eines LDAP-Zugangs...13 Abb. 2.9: Liste aller eingetragenen Administratoren...14 Abb. 2.10: Hinzufügen eines neuen Administrators...14 Abb. 2.11: Konfiguration der Organisationseinheit...16 Abb. 2.12: Hinzufügen einer Person...16 Abb. 2.13: Editieren einer Person...17 Abb. 2.14: Übersicht der MOA-ID Proxy Anwendungen...18 Abb. 2.15: Hinzufügen einer neuen MOA-ID Proxy Anwendung...19 Abb. 2.16: Hinzufügen eines Benutzers...22 Abb. 2.17: MOA-ID Proxy Benutzer-Übersicht...23 Abb. 2.18: MOA-ID Proxy Legende zu den Farben der Benutzeransicht...23 Abb. 2.19: Bearbeiten eines Benutzerzugangs...25 Abb. 2.20: Auswahl der Importgrundlagen...27 Abb. 2.21: Import aus einer bestehenden MOA-ID-Proxy-Konfiguration...28 Abb. 2.22: Import aus einem LDAP-Verzeichnisdienst...28 Abb. 2.23: Verweigerung des Zugangs zu einer Online-Applikation...29 Abb. 2.24: Ablauf der Zugangsprüfung einer MOA-ID-Proxy-Anwendung...30 Abb. 3.1: Modifizierte Variante des Login-Dialogs...35 Abb. 3.2: Initialisierungsdialog für den Superuser "root"...36 3
Revision History Revision History Version Datum Autor(en) 0.1 29.03.2006 T. Knall erster Entwurf, Deployment 0.2 10.04.2006 T. Knall 0.3 04.05.2006 T. Knall Überarbeitung 0.4 06.05.2006 P. Danner Durchsicht, Anmerkungen 0.5 09.05.2006 T. Knall Überarbeitung 0.6 12.05.2006 H. Leitold Durchsicht, Anmerkungen 0.7 14.05.2006 P. Danner Durchsicht, Anmerkungen 1.0 15.05.2006 T. Knall Überarbeitung 1.1 26.09.2006 T. Knall Anpassung der Screenshots 1.2 01.11.2006 P. Danner Update mit Weiterentwicklungen 4
Kurzbeschreibung 1 Kurzbeschreibung 1.1 Grundlagen Konventionelle Mechanismen zur Anmeldung an Systemen und Online-Applikationen basieren auf einer Zuordnung von Passwörtern zu Benutzernamen. Dadurch ergeben sich einige Nachteile: Die Benutzer müssen sich für verschiedene Anwendungen unterschiedliche Benutzernamen bzw. Passwörter merken. Unterschiedliche Benutzernamen bzw. Passwörter für verschiedene Anwendungen stellen eine potentielle Fehlerquelle dar. Die Verwaltung von Benutzern stellt eine beträchtliche Aufwandskomponente dar. Die Bürgerkarte dagegen bietet eine hochqualitative Identifizierung und Authentifikation von Benutzern. Die Modifikation bestehender Anwendungen zur Verwendung von Bürgerkarten stellt einen nicht zu vernachlässigenden (Kosten-)Aufwand dar. Aus diesem Grund wurde in diesem Projekt eine Single-Sign-On Lösung vorgestellt, die die Identifikation über Bürgerkarte auf bestehende Systeme abbildet. Dadurch wird der Aufwand zur Verwaltung von Benutzern minimiert, was wiederum zu zeitlichen und finanziellen Ersparnissen sowie zu einer Verminderung von Fehlerquellen führt. 1.2 Funktionsbeschreibung Das hier erläuterte Zugangsmanagement demonstriert die Ablösung einer auf einer XML- Konfigurationsdatei basierenden Anmeldung durch eine auf einer Datenbank basierenden Anmeldung. Das Webservice ermöglicht formularbasierte Datenmanipulation. Ausgehend von der Konfiguration der verschiedenen Online Applikationen und der Stammdaten der Personen können die Benutzerzugänge konfiguriert bzw. gewartet werden. Die Importfunktion für XML-Konfigurationsdateien sorgt für die reibungslose Übernahme von Bestandsdaten und ermöglicht somit ein einfaches Upgrade. Die Abgleichmöglichkeit mit LDAP-Verzeichnissen sorgt für die einfache Übernahme bestimmter Personen- und Anmeldedaten. Eine Unterteilung in unterschiedliche Organisationseinheiten und Bearbeitungshierarchiestufen (Administrator, Sachbearbeiter) schafft Beschränkungsmöglichkeiten und somit unterschiedliche Sichten auf die Daten. Durch die Mehrfachkonfiguration von Online Applikationen können Gruppen realisiert werden (beispielsweise durch jeweils unterschiedliche LDAP-Anbindungen). Die Gegenstelle zur Benutzerkonfigurationsverwaltung stellt ein Plugin für den MOA-ID- Proxy ([MOA-ID13]) dar. Dabei handelt es sich um einen Resolver für die Logindaten aus der Datenbank, die durch das User Management manipuliert wird. Es sucht die Personendaten (bzw. das (w)bpk) in der Datenbank und löst im Berechtigungsfall die Anmeldedaten für den Proxy auf, der den Benutzer mit diesen Daten je nach Bindung (siehe Abschnitt 2.5.1) anzumelden versucht. 5
Kurzbeschreibung 1.3 Voraussetzungen zur Nutzung der Anwendung Zur Verwendung des Zugangsmanagements mit LDAP-Einbindung werden folgende Voraussetzungen getroffen: ein Web-Browser Anmeldung für eine A1-Signatur, sofern diese Art der Authentifikation gewählt wird. Die Anmeldung kann über folgende Website erfolgen: http://www.a1.net/signatur/info eine lokal installierte Bürgerkartenumgebung, die die Security Layer Spezifikation v1.2 unterstützt (siehe Abschnitt 3.1.2). Java 2 Plattform v1.4.2 oder neuer (inkl. Unlimited Strength Jurisdiction Policy Files & eine JCE-Implementierung; siehe Abschnitt 3.1.1) eine SQL-kompatible Datenbank z.b. MySQL v4.1.18 6
2 Der nachfolgenden Beschreibung des Zugangsmanagements wird folgende Terminologie bzw. werden folgende Parameter zu Grunde gelegt: Parameter Name Beispielwert Beschreibung %HOSTRECHNER% test0815.iaik.tugraz.at Kennzeichnet den vollen Namen des Host- Rechners auf dem das Zugangsmanagement läuft. 2.1 Starten der Benutzerverwaltung Die Benutzerverwaltung wird über folgende URL aufgerufen: http://%hostrechner%:8080/moa-id-proxy-umgmt/ Da die Authentifikation über eine Bürgerkarte stattfindet, wird der Benutzer zunächst aufgefordert, die Ausprägung auszuwählen. Er kann sich zwischen einer Anmeldung mit einer Signaturkarte und der Anmeldung über eine A1-Signatur entscheiden. Abb. 2.1: Anmeldefenster zur Benutzerverwaltung 7
Abb. 2.2: Anmeldung mit Bürgerkarte In weiterer Folge wird dem Anwender ein Antrag zum Login über die lokal installierte Bürgerkartenumgebung gezeigt, den er dann mit seinem geheimen Signatur-PIN signiert. War der Vorgang erfolgreich wird nun die Benutzerverwaltung mit einer Übersicht der registrierten Personen als Einstiegsseite angezeigt: 8
2.2 Allgemeines Die Oberfläche (Abb. 2.3) der Benutzerverwaltung stellt sich im typischen Look&Feel einer Webanwendung dar. Neben einer Kopfzeile mit allgemeinen Informationen wie zum Beispiel einer Erläuterung von Symbolen oder der Anzeige des aktuell angemeldeten Administrators/Sachbearbeiters befindet sich am linken Rand der Seite eine Navigationsspalte, die ein schnelles Auffinden der Funktionen bzw. Funktionsgruppen der Anwendung ermöglicht. Den Großteil der Oberfläche stellt der Inhaltsteil dar, der die zur jeweiligen gewählten Funktion passenden Inhalte anzeigt. Abb. 2.3: Startseite der Benutzerverwaltung mit einer Übersicht registrierter Personen Navigation Die Navigationsspalte gliedert sich in zwei große Teilbereiche. Der erste Teilbereich "MOA-ID Proxy" stellt die eigentliche Benutzerverwaltung für den MOA-ID-Proxy dar. Hier können sowohl Personen als auch Anwendungen verwaltet werden (siehe Abschnitte 2.4 und 2.5). Der zweite Teilbereich enthält Einstellungsmöglichkeiten für die Oberfläche der Benutzerverwaltung, für die Verwaltung der Administratorkonten und Konfigurationsmöglichkeiten für LDAP-Zugänge (siehe auch Abschnitt 2.3). 9
Suche Im unteren Bereich der Navigationsspalte befindet sich ein Feld "Suchbegriff eingeben" über das kontextabhängig nach Personen bzw. Benutzern 1 gesucht werden kann. Wonach im einzelnen Fall gesucht wird hängt davon ab, welcher Inhalt aktuell dargestellt wird. Bei einer Anzeige von Personen wird innerhalb des Personenkreises gesucht, bei der Anzeige von Benutzern wird ausschließlich nach Benutzern gesucht. 2.3 Konfiguration der Benutzerverwaltung Die Gliederung der hier beschriebenen Benutzerverwaltung richtet sich im Großen und Ganzen nach der Darstellung der Konfigurationsmöglichkeiten in der Navigationsspalte. Dies erleichtert dem Nutzer das Finden von Informationen zu gerade verwendeten Funktionen. 2.3.1 Allgemeine Einstellungen Die allgemeinen Einstellungen beschränken sich auf die Festlegung eines Servers zum Versand von Mails. Das Versenden von Bestätigungsmails ist beim Anlegen und Freischalten von Administrator-Konten erforderlich (siehe Abschnitt 2.3.4). Abb. 2.4: Allgemeine Einstellungen Die Konfiguration umfasst die Festlegung eines SMTP-Servers (HOST), eines Ports und eines Standardbetreffs. 2.3.2 Persönliche Einstellungen Diese Seite ermöglicht neben der Anzeige des Zeitpunkts der letzten Anmeldung die Festlegung persönlicher Einstellungen. Dies betrifft einerseits die Anzahl der dargestellten Einträge pro Seite (beispielsweise bei der Anzeige von Benutzerlisten) andererseits die Daten des eigenen Administrator-Kontos. 1 Es wird hier bewusst zwischen "Person" und "Benutzer" entschieden. Unter einem "Benutzer" wird eine Person verstanden, die einer bestimmten Anwendung zugeordnet ist. 10
Abb. 2.5: Persönliche Einstellungen Möchte der Anwender sein eigenes Passwort ändern, muss er aus Sicherheitsgründen sein bisheriges Passwort zusätzlich zum neuen Passwort angeben. 2.3.3 LDAP Einstellungen In diesem Konfigurationsmenü können LDAP-Zugänge eingetragen, konfiguriert und gelöscht werden. Zunächst wird eine Übersicht der bereits eingetragenen LDAP-Server in einer Tabelle angezeigt. LDAP-Einträge können weiters mit einem Bezeichner versehen werden. Dies erleichtert die Unterscheidung von Mehrfacheinträgen (durch die Möglichkeit, Filter zu verwenden, sind mehrfache Einträge desselben LDAP-Servers denkbar). Die Übersicht bietet Informationen über die eingetragenen LDAP-Hosts, die verwendeten Ports sowie über die jeweiligen Base Distinguished Names (Base DN) und definierte Filter. Abb. 2.6: Übersicht der eingetragenen LDAP-Server Hinzufügen eines LDAP-Zugangs Um einen neuen LDAP-Zugang einzurichten ist ein Klick auf "LDAP Server hinzufügen" erforderlich. Abb. 2.7 zeigt den Dialog zum Hinzufügen eines neuen LDAP-Servers. Zwingende Angaben sind der Hostname sowie der Port des Servers. Um eine Unterscheidung der Zugänge bei Mehrfacheinträgen zu erleichtern besteht die Möglichkeit, dem Zugang einen Bezeichner als eine Art Beschreibung zuzuweisen. Zusätzlich kann festgelegt werden, ob der Zugang über SSL (LDAPs) erfolgen soll. Weiters können ein Base DN sowie ein Filter für LDAP-Daten angegeben werden. Der Einsatz eines Filters empfiehlt sich bei umfangreichen LDAP-Verzeichnissen. 11
Schließlich ist es möglich eventuell erforderliche Zugangsdaten, bestehend aus Benutzer DN und Passwort, festzulegen. Nähere Informationen zu LDAP entnehmen Sie bitte einer LDAP-Dokumentation oder dem entsprechenden RFC ([RFC1487]). Abb. 2.7: Hinzufügen eines LDAP-Servers Nach der Speicherung des Formulars hat der Anwender die Möglichkeit Zuordnungen (Mappings) zwischen RDN-Bezeichnern (Relative Distinguished Names) und den in der Web-Anwendung verwendeten Bezeichnern zu treffen (siehe auch nächster Abschnitt). Konfigurieren eines LDAP-Zugangs Abb. 2.8 zeigt den Zuordnungsdialog für einen LDAP-Zugang. Neben den bereits bekannten Zugangsdaten (Hostname, Port, eventuell Benutzer DN und Passwort), dem Bezeichner, des Base DN sowie eines Filters ist es nun möglich Zuordnungen zwischen RDN-Bezeichnern und den in der Web-Anwendung verwendeten Bezeichnern festzulegen. Die linke Spalte stellt die von der Anwendung verwendeten Bezeichner dar, die rechte Spalte muss selbst mit Bezeichnern, die mit dem LDAP-Verzeichnis korrespondieren gefüllt werden. Die Mappings werden bei der Anwendungskonfiguration zum automatisierten Erstellen von Benutzer-Konten über einen LDAP-Abgleich (siehe Abschnitt 2.5.2) verwendet. 12
Abb. 2.8: Konfiguration eines LDAP-Zugangs 2.3.4 Administratoren verwalten In diesem Konfigurationsabschnitt können Administratoren für die Benutzerverwaltung eingerichtet werden. Administratoren unterliegen keinerlei Beschränkungen und dürfen alle in dieser Dokumentation beschriebenen Funktionen nutzen. Neben Administratoren gibt es noch die Benutzergruppen "Sachbearbeiter" und "Sachbearbeiter (eingeschränkt)". Sachbearbeiter unterliegen der Einschränkung, dass sie nur ihre eigenen persönlichen Einstellungen vornehmen können. Die Accountdaten der Administratoren und anderen Sachbearbeiter, sowie Organisationseinheiten können sie nicht einsehen, ändern, anlegen oder löschen. Auch die LDAP Administration ist für sie unzugänglich. Somit ist es möglich, LDAP-Zugangsdaten vor Sachbearbeitern zu verbergen bzw. Änderungen zu verhindern. Eingeschränkte Sachbearbeiter unterliegen zusätzlich der Einschränkung, dass sie keine neuen Anwendungen hinzufügen dürfen. Zunächst wird dem Benutzer eine Liste aller eingetragenen Administratoren gezeigt (siehe Abb. 2.9), wobei der erste Administrator eine besondere Rolle einnimmt. Es ist weder möglich, diesen Administrator zu löschen, noch ist es möglich ihn zu deaktivieren oder seinen Benutzernamen zu verändern. Nähere Details zu diesem Administrator werden in Abschnitt 3.3.1 erläutert. 13
Abb. 2.9: Liste aller eingetragenen Administratoren Hinzufügen eines neuen Administrators Um einen neuen Administrator hinzuzufügen ist zunächst der Klick auf den Link "Neuen Administrator hinzufügen" erforderlich. Nun wird das in Abb. 2.10 gezeigte Formular präsentiert. Abb. 2.10: Hinzufügen eines neuen Administrators Nun müssen Vorname, Familienname, E-Mail-Adresse, Geburtsdatum, die Rolle (Status), der Benutzername und ein frei wählbares Passwort angegeben werden. Zusätzlich kann ein bereichsspezifisches Personenkennzeichen (bpk) eingegeben werden sofern dieses bereits bekannt ist. Das bpk dient zur eindeutigen Identifikation des Administrators über seine Bürgerkarte. 14
Üblicherweise wird das Feld jedoch leer gelassen und dem neuen Administrator ein Aktivierungscode per E-Mail zugesandt. Dies erfolgt durch Klick auf den Button "Aktivierungscode generieren und per E-Mail versenden". Der neue Administrator erhält dann eine E-Mail mit einem Link, mit dem er sein Benutzerkonto freischalten kann. Ihm wird dabei ein Formular gezeigt, das er mit seiner Bürgerkarte signiert. Nun wird ein bpk generiert und in seinem persönlichen Profil wie in Abb. 2.10 gezeigt gespeichert (gleiches Vorgehen bei der Aktivierung von Benutzerzugängen in der Verwaltung von Benutzern). Zukünftige Logins erfolgen nun ausschließlich mit der Bürgerkarte. Editieren von Administratoren Das Editieren von Administratoren/Sachbearbeitern erfolgt nach einem Klick auf den Namen des jeweiligen Administrators in der Übersichtstabelle (Abb. 2.9). Das Editierungsformular entspricht dem Formular zum Anlegen von Administrator-Konten (Abb. 2.10), wobei die zu ändernden Daten bereits eingetragen sind. Löschen von Administratoren Zum Löschen von Administratoren/Sachbearbeitern muss das zu löschende Konto in der Übersichtstabelle über die jeweilige Checkbox ausgewählt werden. Dann kann das Konto durch Klick auf "Markierte Administratoren löschen" gelöscht werden. 2.3.5 Organisationseinheiten verwalten Organisationseinheiten ermöglichen unterschiedliche Sichten auf Daten. Sie können über das Initialisierungsformular der Web-Anwendung (siehe Abschnitt 3.3.1) erstellt und verwaltet werden. Mit ihnen können getrennte (MOA-ID-Proxy-)Anwendungen über eine einzige Web-Applikation bzw. eine einzige Datenbank realisiert werden. Der hier vorliegende Dialog erlaubt die Konfiguration der aktuellen Organisationseinheit. Es kann ein Name angegeben werden, der auf Wunsch am Seitenkopf angezeigt wird. Weiters kann eine Verwaltungseinheit mit E-Mail-Adresse definiert werden. Der nächste Abschnitt enthält Angaben zur Adresse der Organisationseinheit. Über den dritten Abschnitt kann das aktuell angezeigte Logo geändert werden. 15
Abb. 2.11: Konfiguration der Organisationseinheit 2.4 Verwaltung von Personen Bei Aufruf der Personenverwaltung wird zunächst ein Überblick über bereits registrierte Personen in Form einer Tabelle (siehe auch Abb. 2.3) gezeigt. Diese Tabelle präsentiert persönliche Informationen wie Nachname, Vorname und Geburtsdatum. Die Spalte "Einträge" bezeichnet die Anzahl der Anwendungen für die die jeweilige Person bereits registriert wurde. Eine weitere Spalte registriert den Zeitpunkt des letzten Loginversuchs. Die letzte Spalte zeigt, ob der Benutzer aktiv gesetzt ist, d.h. sich derzeit bei Anwendungen anmelden darf oder nicht. Hinzufügen von Personen Zum Hinzufügen einer Person ist der Link "Neue Person hinzufügen" zu wählen. Die im darauf folgenden Formular (siehe Abb. 2.12) einzugebenden Personendaten beschränken sich auf den Vornamen, den Familiennamen sowie das Geburtsdatum. Zusätzlich kann der Status des Benutzerkontos (aktiv oder nicht aktiv) festgelegt werden. Abb. 2.12: Hinzufügen einer Person 16
Durch das Abspeichern des Formulars wird nun eine Person erstellt, die vorerst keiner der eingetragenen Anwendungen zugeordnet ist. Editieren von Personen Um die Daten einer Person zu ändern, ist deren Name in der jeweiligen Zeile in der Personenübersicht anzuklicken. Das daraufhin erscheinende Formular (siehe Abb. 2.13) ist dem Formular zum Hinzufügen eines Benutzers sehr ähnlich. Was jedoch die beiden Formulare unterscheidet, ist die Übersicht der Anwendungen, in die der Benutzer eingetragen ist. Die Spalte "Letzter Loginversuch" enthält anwendungsbezogen den Zeitpunkt des jeweiligen letzten Loginversuchs. Abb. 2.13: Editieren einer Person Löschen von Personen Zum Löschen einer oder mehrerer Personen sind diese zunächst über die Checkbox in der ersten Spalte in der Personenübersicht auszuwählen. Das Löschen erfolgt dann mit Klick auf "Markierte Personen löschen". 2.5 Verwaltung von Anwendungen Die Verwaltung von Anwendungen stellt den umfangreichsten Bereich der Web-Anwendung dar. Wird die Anwendungsverwaltung aufgerufen, erfolgt zunächst ein Überblick über alle eingetragenen Anwendungen in Form einer Tabelle (Abb. 2.14). 17
Abb. 2.14: Übersicht der MOA-ID Proxy Anwendungen Die Tabelle zeigt den Titel der jeweiligen Anwendung, sowie das entsprechende PublicURLPräfix (siehe unten). Eine weitere Spalte "(w)bpk" enthält einen Hinweis ob es sich bei der Anwendung um eine (w)bpk-anwendung handelt oder nicht. Die nächsten Spalten enthalten die Anzahl der für die jeweilige Anwendung eingetragenen Benutzer sowie einen Hinweis auf den derzeitigen Status der Anwendung. Eine Anwendung kann analog zu einer Person "aktiv" bzw. "inaktiv" sein. (Ist eine Anwendung deaktiviert, dann ist es den eingetragenen Benutzern nicht erlaubt, sich anzumelden.) PublicURLPräfix Eine Anwendung wird vom MOA-ID-Proxy eindeutig über ihr PublicURLPräfix (Eintrag publicurlprefix in der entsprechenden MOA-ID-Proxy Konfigurationsdatei) identifiziert. Der Proxy ersetzt bei allen Anfragen, die über ihn laufen, das PublicURLPräfix durch die tatsächliche URL der Anwendung. Der Anwender sieht jedoch ausschließlich das PublicURLPräfix. Durch diese Abstraktion wird zum einen ein sicherer Zugang gewährleistet, zum anderen braucht der Anwender die wirkliche Anwendung, mit der der Proxy kommuniziert, nicht zu kennen bzw. ist diese vom Anwender aus gar nicht direkt erreichbar. 18
2.5.1 Anwendung konfigurieren Wählt der Administrator die Funktion "Neue Anwendung hinzufügen" dann wird folgendes Formular (Abb. 2.15) angezeigt. Das Formular ist mit dem Formular zum Editieren einer bestehenden Anwendung identisch. Abb. 2.15: Hinzufügen einer neuen MOA-ID Proxy Anwendung Nun müssen zunächst der Name der Anwendung und das PublicURLPräfix angegeben werden. Hinweis: Das an dieser Stelle angegebene PublicURLPräfix muss mit dem Konfigurationsparameter publicurlprefix der entsprechenden MOA-ID-Konfiguration korrespondieren (siehe "Proxy-Eintrag für die Online Anwendung", Abschnitt 3.4.1.1) damit der MOA-ID-Proxy die entsprechende Anwendung zuordnen kann. Die Web-Adresse enthält den Link an den nach erfolgter Account-Aktivierung/Änderung der Benutzern weitergeleitet werden soll. Im nächsten Schritt kann nun festgelegt werden, ob die Anwendung eine bpk- oder eine wbpk-anwendung darstellt. Auch diese Einstellung muss mit der über die MOA-ID-Proxy- Konfiguration definierten Einstellung übereinstimmen (Abschnitt 3.4.1.1). Wird auf eine zwingende (w)bpk-anmeldung verzichtet, dann erfolgt beim Loginprozess auch ein Vergleich des in der MOA-ID-Datenbank eingetragenen Namens und Geburtsdatums der Person mit den Daten aus der Personenbindung der Bürgerkarte. Ist die Anwendung eine Anwendung des öffentlichen Bereiches (bpk gewählt), so ist das Target dem entsprechend einzutragen. Es wird zur Berechnung der Zugangs-bPK s der Benutzerzugangskonfigurationen benötigt. Ist hingegen die Anwendung eine Anwendung in der Privatwirtschaft, MUSS das User-Management auch auf Basis einer wbpk-anmeldung 19
laufen. Dadurch können nur wbpk s eines Bereiches verwendet werden. Dies ist in der Begründung zu suchen, dass die Berechnung des wbpk s in der MOA-ID Konfiguration fixiert ist und pro Online-Applikation nur ein Konfigurationsparameter IdentificationNumber möglich ist, und somit bei einer MOA-ID Anmeldung vorbestimmt wird, wie das wbpk berechnet wird.. Binding Das Binding stellt einen wesentlichen Anteil des Loginprozesses dar. Es beschreibt die Bindung der Bürgerkarte an die Online-Anwendung und bestimmt dadurch, auf welche Weise der MOA-ID-Proxy den Benutzernamen bzw. das Passwort für die jeweilige Online- Anwendung ermittelt. Die folgende Tabelle gibt einen Überblick über die vier Bindungs-Möglichkeiten: Bindung full nomatch username none Erläuterung Die Bindung des identifizierten Benutzers an die Onlineapplikation ist durch die Konfiguration vorgegeben. Eine Anmeldung wird automatisch durchgeführt. Benutzername und Passwort sind in der Konfiguration hinterlegt. Der Vorteil dieser Möglichkeit liegt in der Einfachheit der Verwendung für den Benutzer, da er nach der Identifizierung keine weitere Anmeldung mehr durchführen muss. Diese Lösung stellt eine Möglichkeit der Realisierung einer Single-Sign-On Lösung dar. Wie full, jedoch wird bei nicht erfolgreichem Passwort beim Benutzer rückgefragt und dann das Passwort eingetragen. Der identifizierte Benutzer kann sich nur unter dem ihm zugeordneten Account anmelden. Eine eindeutige Beziehung von Bürgerkarte zum Account der Online- Applikation ist gegeben. Vorteil dieser Variante ist, dass Passwort-Änderungen nicht zusätzlich in den Konfigurationen nachgezogen werden müssen, sondern Passwörter immer aktuell geprüft werden. Es erfolgt keine Bindung an die per MOA-ID identifizierte Person. Nach Identifikation kann sich der Benutzer unter jedem ihm bekannten Account anmelden (sinnvoll etwa für Tests). Externe Anbindung Die dieser Dokumentation zugrunde liegende Web-Anwendung erlaubt die komfortable Übernahme bzw. Generierung von Zugangsdaten aus Attributen eines LDAP-Verzeichnisdienstes. Voraussetzung dafür ist die Wahl eines solchen Dienstes über das Drop-Down- Feld in der Spalte "LDAP-Zuordnung". Für einen LDAP-Abgleich stehen die Eingabefelder "User-ID", "Passwort", "Parameter 1", "Parameter 2" und "Parameter 3" sowie die in Abschnitt 2.3.3 erläuterten Mappings der LDAP-Attribute zu Verfügung. Diese Mappings können benutzt werden, um bei einem Abgleich mit einem LDAP- Verzeichnisdienst automatisiert Konten mit unterschiedlichen Benutzernamen, Passwörtern und eventueller zusätzlicher Parameter zu erstellen. Hierfür müssen zunächst Schablonen mit Hilfe der folgenden zu Verfügung stehenden LDAP-Mappings definiert werden: bpk birthdate city cn givenname gvgid gvopk gvouid mail opt1 20
opt2 opt3 personaltitle postalcode street surname telephonenumber Die Repräsentationen der LDAP-Attribute können als Variablen bzw. Platzhalter zwischen Prozentzeichen geschrieben werden, ein Beispiel dafür ist %surname%, was für eine Person "Max Muster" substituiert "muster" ergibt. Dabei wird Groß- und Kleinschreibung unterschieden, sodass durch unterschiedliche Schreibweise der Feldwerte eine unterschiedliche Schreibweise der Feldinhalte erzwungen werden kann. Unterschieden wird dabei zwischen vier Schreibweisen. Die folgende Tabelle demonstriert die Anwendung der Schablonen anhand des Feldes surname mit Inhalt "Mustermann von Hohenzollern": Schreibweise Beispiel Originalschreibweise %surname% ergibt "Mustermann von Hohenzollern" UPPERCASE %SURNAME% ergibt "MUSTERMANN VON HOHENZOLLERN" lowercase %surname% ergibt "mustermann von hohenzollern" UpperCamelCase %SurName% ergibt "Mustermann Von Hohenzollern" Um einen Teilstring eines Feldinhalts zu erhalten muss das Mapping in eckige Klammern [ ] gesetzt werden, gepaart mit der Zahlenangabe für Start- und Endposition des Teilstrings, bzw. Position des zu extrahierenden Buchstabens. So ergibt [%surname%1] angewandt auf "Mustermann von Hohenzollern" den Teilstring "M" und [%surname%7-10] "mann". Geht die Endposition über die Textlänge hinaus, so wird der Text am Ende abgeschnitten. Die Felder dürfen beliebig miteinander kombiniert, beliebig oft wiederholt und mit normalem Text verwendet werden. So lässt sich ein Benutzername der Form "erster Buchstabe des klein geschriebenen Vornamens" + "." + "die ersten 10 Buchstaben des klein geschriebenen Nachnamens" durch folgendes Konstrukt abbilden: [%givenname%1].[%surname%1-10] Auf äquivalente Weise können die Felder für das Passwort bzw. für zusätzliche Parameter mit Inhalten versehen werden. Hinweis: Es können nur jene Felder verwendet werden, die unter "Mögliche Variablen" (siehe Abb. 2.15) über das in Abschnitt 2.3.3 erläuterte Mapping von LDAP-Attributen definiert sind. 2.5.2 Benutzer verwalten Dieser Abschnitt behandelt die Verwaltung der Benutzerkonten von registrierten Online- Anwendungen. Hinweis: Die Nutzung der Funktionalität der Benutzerverwaltung erfolgt größtenteils über Symbole innerhalb der Anwendungsübersicht (siehe Abb. 2.14). Neuen Zugang anlegen Von der im Abschnitt 2.5.1 beschrieben Möglichkeit der automatisierten Erstellung von Benutzerkonten über einen LDAP-Abgleich abgesehen ist es auch möglich, einzelne Konten manuell zu erstellen. Dies erfolgt durch Klick auf das Symbol in der MOA-ID-Proxy- Anwendungsübersicht (siehe Abb. 2.14). Im nachfolgenden Dialog (Abb. 2.16) können nun Zugangsdaten des neuen Benutzers eingegeben werden. Einstellungen, die aus der 21
Anwendungskonfiguration stammen, werden grau unterlegt dargestellt. Diese Einstellungen können an dieser Stelle nicht verändert werden. Im Großen und Ganzen entsprechen die Felder den bereits in Abschnitt 2.5.1 erläuterten Feldern. Neu ist hier die Möglichkeit, eine Bindung über das (w)bpk an eine bestimmte Bürgerkarte vorzunehmen. Weiters können an dieser Stelle eine E-Mail-Adresse, eine Organisation sowie eine Teilorganisation angegeben werden. Abb. 2.16: Hinzufügen eines Benutzers Verwalten von Benutzern Die Verwaltung von Benutzern, die für eine bestimmte Online-Anwendung registriert sind, erfolgt durch Klick auf das Symbol in der Zeile der entsprechenden Online-Anwendung. Abb. 2.17 zeigt die typische Benutzerübersicht einer Online-Anwendung. 22
Abb. 2.17: MOA-ID Proxy Benutzer-Übersicht Die Übersicht zeigt den Benutzernamen, den dazugehörenden Vor- und Zunamen sowie das Geburtsdatum des jeweiligen Benutzers. Die beiden letzten Spalten zeigen an, ob der Benutzer aus einem LDAP-Verzeichnis importiert wurde und ob er gerade "aktiv" gesetzt ist. Einen Sonderfall stellen Einträge ohne namentliche Registrierung dar (siehe z.b. erster Eintrag in Abb. 2.17). Die Identifikation erfolgt in diesem Fall ausschließlich über das (w)bpk, das über die Bürgerkarte des Anwenders berechnet wird. In der MOA-ID Proxy Benutzer-Übersicht erfolgt die Darstellung der einzelnen Benutzerkonten je nach Art des Kontos unter Umständen in verschiedenen Farben. So werden aus LDAP gelöschte Benutzer Rot dargestellt, während aktive LDAP-Benutzer Blau gezeigt werden. Abb. 2.18 gibt einen Überblick über die verwendeten Farben. Abb. 2.18: MOA-ID Proxy Legende zu den Farben der Benutzeransicht Das Managen von Benutzern beschränkt sich auf das Löschen (Klick auf "Markierte Benutzereinträge löschen") sowie auf die Editierung von Konten. Hinweis: Der Eintrag "Benutzer" unter der Rubrik "Anwendungen" in der Navigationsspalte zeigt alle dem Benutzermanagement bekannten Benutzer in einer Tabelle (identisch mit der Tabelle in Abb. 2.17) unabhängig von der jeweiligen Online-Anwendung an. Editieren eines Benutzerzugangs Um einen Benutzerzugang zu ändern, ist auf den Benutzernamen innerhalb der Benutzerübersicht zu klicken. Das Formular zum Editieren von Benutzern die einzeln erstellt 23
wurden bzw. die aus einem Import einer MOA-ID-Proxy XML-Konfigurationsdatei stammen, entspricht im Wesentlichen dem Formular zum Hinzufügen eines Benutzers (Abb. 2.16). Stammt das Benutzerkonto jedoch aus einem LDAP-Abgleich, dann sind einige Gesichtspunkte zu beachten. Wichtigster Aspekt ist die Eigenschaft, dass LDAP-basierte Benutzerkonten grundsätzlich nicht veränderbar sind. Dies wird durch graue Feldinhalte ausgedrückt (siehe Abb. 2.19). Einzig der Löschstatus 2 und der Aktiv/Inaktiv-Status können gesetzt werden. Um ein Benutzerkonto aus einer LDAP-Quelle nun tatsächlich editieren zu können, muss zunächst ein Duplikat erstellt werden (über den Button "Manueller Eintrag"), das dann entsprechend verändert werden kann. Der Anwender wird beim Editieren eines solchen Duplikats speziell darauf hingewiesen, dass es sich hierbei um eine "Datenquelle Manuell" handelt. Die Unterscheidung zwischen "Datenquelle Manuell" und "Datenquelle LDAP" verhindert auch dass "manuelle" Benutzerkonten bei einem LDAP-Abgleich überschrieben bzw. verändert werden. Ein LDAP-Abgleich hat ausschließlich Auswirkungen auf Benutzerkonten des Typs "Datenquelle LDAP". 2 Eine Löschung kann durch einen LDAP-Abgleich verursacht werden. 24
Abb. 2.19: Bearbeiten eines Benutzerzugangs Ein weiterer Unterschied zu nicht-ldap-benutzern besteht darin, dass in diesem Formular die Möglichkeit besteht, einen LDAP-Abgleich für den aktuell editierten Benutzer über den Button "Mit LDAP-Verzeichnis abgleichen" vorzunehmen. Hinterlegen von Anwendungspasswörtern Um die Bindings full und nomatch effizient nutzen zu können ist es notwendig die Zugangsdaten zur Anwendung vorzuhalten. Zur Gewährleistung einer hohen Sicherheit von Passwörtern ist es möglich diese verschlüsselt zu speichern. Bei der Hinterlegung von Passwörtern werden zwei verschiedene Modi unterschieden: 25
1.) verschlüsselt: ist im Feld für das (w)bpk in vollständiges Personenkennzeichen (>20 Zeichen) eingetragen, so wird der Feldeintrag für das Passwort, beim Speichern automatisch mit den letzen (>20 Zeichen des (w)bpk s), mittels symmetrischer Verschlüsselung verschlüsselt und diese letzten Stellen des (w)bpk s, welche als Verschlüsselungspasswort dienen, entfernt. Dadurch ist es nur mehr dann möglich das Passwort zu entschlüsseln, wenn der Benutzer sich in bzw. kurz nach einem Anmeldevorgang befindet, wo das (w)bpk sich in der Session befindet. In der Datenbank ist die notwendige Information zum Entschlüsseln des Passwortes nicht mehr vorhanden. Damit sind die Zugangsdaten geschützt abgelegt und ermöglichen eine automatische Login-Möglichkeit an der Zielanwendung. 2.) plain: ist das Feld für das (w)bpk leer oder bereits zur Verschlüsselung verwendet worden - (w)bpk ist auf 20 Zeichen gekürzt so resultiert jede Änderung des Passwortes in einer unverschlüsselten Verspeicherung. Benutzer können auch selbst Ihr verschlüsseltes Passwort eintragen, indem ein Link dafür über die Benutzerverwaltung gesendet wird. Nach einer Anmeldung über MOA-ID mit dem Target der eingetragenen Anwendung, kann der Benutzer das Passwort für den Zugang zur Anwendung über einen Dialog festlegen. Gekennzeichnet ist ein verschlüsseltes Passwort durch eine Checkbox in der Benutzerverwaltung neben dem Eingabefeld für das Passwort, welches den aktuellen Status bezüglich Verschlüsselung anzeigt. LDAP-Abgleich Wurde eine Online-Anwendung mit den im Abschnitt 2.5.1 erläuterten Schablonen konfiguriert, kann ein Abgleich mit einem LDAP-Verzeichnisdienst erfolgen. Dazu muss das Symbol in der MOA-ID-Proxy-Anwendungsübersicht (siehe Abb. 2.14) verwendet werden. Der Abgleich wird augenblicklich durchgeführt und mit einer Erfolgs- bzw. Misserfolgsmeldung abgeschlossen. Anmerkung: Bei einem Abgleich mit einer LDAP-Datenquelle werden Änderungen im LDAP vom Usermanagement übernommen und repliziert. Sowohl positive als auch negative Änderungen werden dabei vom LDAP-Server auf das Usermanagement übertragen. 2.5.3 Benutzer importieren Grundsätzlich kann der Import von Benutzern auf zwei Arten erfolgen. Zum einen kann wie bereits im vorherigen Abschnitt ausgeführt, ein LDAP-Abgleich stattfinden, andererseits ist es auch möglich einen Import aus einer bereits bestehenden MOA-ID-Proxy XML- Konfigurationsdatei vorzunehmen. Der Importvorgang gliedert sich in zwei Schritte. Zunächst muss das Ziel des Imports ausgewählt werden. Als Ziel werden alle registrierten Online-Applikationen angeboten (siehe Abb. 2.20). Im zweiten Schritt erfolgt die Auswahl der Quelle, wobei zwischen dem Import aus einer MOA-ID-Proxy XML-Konfigurationsdatei und einem LDAP-Import gewählt werden kann. 26
Abb. 2.20: Auswahl der Importgrundlagen Wurde einer Online-Anwendung kein LDAP-Zugang zugewiesen dann bleibt die Auswahl auf die MOA-ID-Proxy XML-Konfigurationsdatei beschränkt. Import aus einer MOA-ID-Proxy XML-Konfigurationsdatei Der Import aus einer bestehenden XML-Konfigurationsdatei ermöglicht den Import bestehender Datenbestände, die nicht über einen LDAP-Verzeichnisdienst erreichbar sind. Eine XML-Konfigurationsdatei sieht wie folgt aus: <?xml version="1.0" encoding="utf-8"?> <MOAIdentities xmlns="http://reference.egovernment.gv.at/namespace/moa/20020822#/xmllpr20030814" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:fn="http://www.w3.org/2004/07/xpath-functions" xmlns:xs="http://www.w3.org/2001/xmlschema"> <!-- Eintrag aller Benutzer mit Berechtigung --> <!-- Die Daten müssen in der Schreibweise wie in der Personenbindung (= Schreibweise des ZMRs) eingegeben werden --> <Mapping> <Identity> <NamedIdentity SurName="Max" GivenName="Muster" BirthDate="1950-01- 01">1</NamedIdentity> </Identity> <Parameters UN="max.muster" PW="" Param1="MusterparameterMuster"/> </Mapping> <Mapping> <Identity> <NamedIdentity SurName="Peter" GivenName="Müller" BirthDate="1970-01- 01">1</NamedIdentity> </Identity> <Parameters UN="peter.mueller" PW="" Param1="MusterparameterMeier"/> </Mapping> </MOAIdentities> 27
Abb. 2.21 zeigt die Statusmeldung eines erfolgreich durchgeführten Imports. Abb. 2.21: Import aus einer bestehenden MOA-ID-Proxy-Konfiguration Import aus einem LDAP-Verzeichnis Bei Auswahl von LDAP als Importquelle wird zunächst der der Online-Anwendung zugeordnete LDAP-Server mit dem Distinguished Name (DN) und dem angewandten Filter sowie der Anzahl derzeitiger Übereinstimmungen in einem Überblicksfenster dargestellt (Abb. 2.22). Zur einfachen Identifikation des Zugangs wird dessen Bezeichner in der (blauen) Tabellenkopfzeile angezeigt. Der Importvorgang wird durch Klick auf den Button "Importieren" gestartet. Abb. 2.22: Import aus einem LDAP-Verzeichnisdienst 2.6 Single-Sign-On über den MOA-ID-Proxy Der MOA-ID-Proxy ermöglicht die einfache Anbindung einer bestehenden Online-Applikation an den Authentisierungs-Mechanismus eines MOA-ID-Moduls. Durch ein transparentes Proxying wird die Online-Applikation vor nicht authentisierten Zugriffen geschützt. Die Authentisierung kann abhängig von der jeweiligen Online-Anwendung auf zweierlei Arten erfolgen: stateful: Das MOA-ID-Modul nimmt eine einmalige Authentisierung an der Online- Applikation vor. stateless: Die Login-Parameter werden bei jedem Zugriff auf die Online-Applikation übergeben. 28
Um eine Online-Anwendung als identifizierter Benutzer zu starten, muss diese über eine MOA-ID-Authentisierung aufgerufen werden. Die folgende Tabelle beschreibt die zur Erläuterung der erforderlichen URL verwendeten Parameter. Parameter Beispielwert Beschreibung %BEREICH% EGIZ Bereichskennzeichnung zur bpk-ableitung %PUBLICURLPREFIX% https://konfuzius.iaik.tug raz.at/ Eindeutige Identifikation einer Online- Anwendung für den MOA-ID-Proxy. %MOA-ID_HOST% konfuzius.iaik.tugraz.at Rechner, auf dem der MOA-ID-Proxy läuft. %RELATIVE_URL% exchange/ Relative URL für die Online-Anwendung. Der Aufruf erfolgt über eine URL der Form: z.b. https://%moa-id_host%/moa-id-auth/startauthentication? Target=%BEREICH%&OA=%PUBLICURLPREFIX%%RELATIVE_URL% https://konfuzius.iaik.tugraz.at/moa-id-auth/startauthentication? Target=EGIZ&OA=https://konfuzius.iaik.tugraz.at/exchange/ Ablauf der Zugangsprüfung Zunächst authentifiziert sich der Anwender über einen im Trusted Viewer seiner lokalen Bürgerkartenumgebung angezeigten Antrag, den er mit seiner Bürgerkarte signiert. Um dann Zugang zu einer Online-Anmeldung zu erhalten sind zahlreiche Prüfungen erforderlich. Schlägt eine der Prüfungen fehl, wird dem Anwender stets folgende Fehlermeldung präsentiert (Abb. 2.23). Abb. 2.23: Verweigerung des Zugangs zu einer Online-Applikation Abb. 2.24 zeigt anschaulich die Abfolge der erforderlichen Prüfprozesse. Grün dargestellt sind Prozesse, die die jeweilige Online-Anwendung betreffen, blaue Elemente kennzeichnen durch Bürgerkarten authentifizierte Personen und rote Elemente beschreiben die Bindung von Personen an Anwendungen (in diesem Dokument werden diese als "Benutzer" bezeichnet). 29
Abb. 2.24: Ablauf der Zugangsprüfung einer MOA-ID-Proxy-Anwendung 30
Die folgende Aufzählung beschreibt kurz die einzelnen Prüfprozesse (anlehnend an Abb. 2.24). 1.) Zunächst wird das PublicURLPräfix aus der aufrufenden URL mit den eingetragenen Online-Applikationen verglichen, um eine entsprechende Anwendung zu finden. 2.) Im nächsten Schritt wird über die bpk des Anwenders nach einer passenden Zugangskonfiguration gesucht. a.) Wurde eine Konfiguration gefunden, wird überprüft ob diese mit einer Person verknüpft ist oder ob die Identifikation ausschließlich über das bpk erfolgt. Anmerkung: Abschnitt 2.5.2 erläutert die Möglichkeit der Existenz von Personen ohne namentliche Registrierung, die ausschließlich über das errechnete bpk identifiziert werden. Besteht eine Verknüpfung zwischen einem bpk und einem Benutzer dann wird nun die entsprechende Benutzer-ID (uid) ermittelt. Schließlich wird noch geprüft ob das Konto der Person derzeit "aktiv" oder "inaktiv" ist. b.) Anmerkung: Bitte zunächst 3.) und 4.) lesen. Wurde auch für das Duplikat keine Zugangskonfiguration gefunden wird zunächst nach weiteren Online-Applikationen mit identischem PublicURLPräfix gesucht. (Um Gruppenbildungen zu ermöglichen, können unterschiedliche Online- Applikationen identische PublicURLPräfixe besitzen.) c.) Konnte keine (einem bpk entsprechende) Zugangskonfiguration gefunden werden, wird zunächst geprüft, ob die Anwendungskonfiguration eine Anmeldung ohne (w)bpk erlaubt. Ist eine Anmeldung ohne bpk erlaubt, wird nun versucht, das entsprechende Benutzerkonto auf eine alternative Weise zu ermitteln. Hierzu dienen die Daten (Vorname, Zuname und Geburtsdatum) aus der Personenbindung des anzumeldenden Benutzers. Es wird nun versucht, ein Benutzerkonto mit entsprechenden Daten zu finden. Wurde ein Benutzer gefunden, wird nun überprüft ob dieser derzeit "aktiv" oder "inaktiv" gesetzt ist. Schließlich erfolgt dann wieder eine Suche nach einer entsprechenden Zugangskonfiguration (diesmal basierend auf der Benutzer-ID). Analog zu b.) muss auch hier unterschieden werden, ob die Zugangsdaten für einen LDAP-Eintrag oder für ein manuell erstelltes Duplikat gesucht werden. Sollte die Suche nach einer Zugangskonfiguration im Fall eines Duplikats fehlschlagen, dann wird erneut wie in 1.) nach weiteren Anwendungen mit gleichem PublicURLPräfix gesucht. Schließlich muss noch berücksichtigt werden, ob auch die benutzerspezifische Konfiguration ein Login ohne (w)bpk gestattet (unabhängig davon ob die Anwendungskonfiguration dies erlaubt). 3.) Im dritten Schritt wird untersucht, ob die gewünschte Online-Anwendung derzeit "aktiv" oder "inaktiv" ist. In inaktivem Zustand ist es keinem Benutzer erlaubt, die Anwendung zu verwenden. 4.) Nun wird geprüft ob das jeweilige Benutzerkonto als gelöscht markiert ist. Anmerkung: Ein Benutzerkonto kann beispielsweise durch einen LDAP-Abgleich gelöscht werden. Gleichzeitig kann jedoch ein manuell erstelltes Duplikat des Kontos existieren (siehe Editieren eines Benutzerzugangs, Seite 5). Aus diesem Grund wird zunächst nochmals nach einer passenden Zugangskonfiguration wie in 2.) erläutert gesucht diesmal jedoch für das Duplikat. 5.) Hier erfolgt die Prüfung ob der Benutzerzugang derzeit "aktiv" oder "inaktiv" gesetzt ist. 31
6.) Der Benutzer ist berechtigt, die Online-Applikation zu verwenden. Nun wird der Loginzeitpunkt des Benutzers für die entsprechende Online-Applikation vermerkt. 7.) An dieser Stelle wird der aktuelle Loginzeitpunkt als letzter Loginversuch (unabhängig von der verwendeten Online-Anwendung) im Personen-Kontext eingetragen. 8.) Schließlich werden nun die dem Benutzer zugehörigen Logindaten übergeben. 32
Deployment 3 Deployment Die vorliegende Anwendung gliedert sich in zwei Teile. Der erste Teil erläutert die erforderliche Konfiguration für den MOA-ID-Proxy, der zweite Teil beschäftigt sich mit der Einrichtung der Benutzerverwaltung. Da beide Teile getrennt voneinander arbeiten (die Benutzerverwaltung könnte in einem geschützten Bereich laufen) wurden zwei getrennte Servlet-Engines (Apache Tomcat v5.0.28) verwendet, die bereits in der Auslieferung enthalten sind. Die nachfolgenden Parameter dienen als Platzhalter für die Installationsverzeichnisse der beiden Tomcat Instanzen bzw. als Platzhalter für den Hostrechner der Web-Anwendung. Parameter Name Beispielwert Beschreibung %MOA-ID-PROXY% d:\tomcat5.0.28-moaidproxy Installationsverzeichnis der Apache Tomcat Instanz, die den MOA-ID-Proxy enthält. %UMGMT% d:\tomcat5.0.28-umgmt Installationsverzeichnis der Apache Tomcat Instanz, die die Benutzerverwaltung beinhaltet. %HOSTRECHNER% test0815.iaik.tugraz.at Kennzeichnet den vollen Namen des Host- Rechners der Web-Anwendung. 3.1 Systemanforderungen Es gelten folgende Anforderungen an die Installationsplattform bzw. an die Clientkomponenten (die angegebenen Versionen entsprechen der getesteten Umgebung): 3.1.1 Server-Komponenten Da die Auslieferung bereits die erforderlichen Servlet-Container (Apache Tomcat v5.0.28) enthält, beschränkt sich die einzige serverseitige Anforderung auf: Java 2 Plattform v1.4.2 oder neuer (inkl. Unlimited Strength Jurisdiction Policy Files 3 & eine JCE-Implementierung 4 ) SQL-kompatible Datenbank z.b. MySQL v4.1.18 Hinweis: MySQL 5.x wird ausdrücklich nicht empfohlen, da dieses zu Schwierigkeiten im Zusammenhang mit dem verwendeten Hibernate Framework (siehe Abschnitt 3.2.1) führen kann. 3.1.2 Client-Komponenten Clientseitig muss abgesehen von einem Web-Browser eine lokale Bürgerkartenumgebung installiert sein, die die Version 1.2 der Security-Layer Spezifikation unterstützt. Die frei zur Verfügung stehende BKU Software des Bundes kann von folgender Seite bezogen werden: http://www.cio.gv.at/identity/bku/ 3 4 z.b. http://java.sun.com/j2se/1.4.2/download.html z.b. http://jce.iaik.at/ 33
Deployment 3.2 Abhängigkeiten Von den in 3.1 erläuterten Systemanforderungen abgesehen sind zusätzlich folgende Voraussetzungen zu erfüllen: 3.2.1 Server-Komponenten MOA-ID-Proxy: Der HTTP-Connector dieses Anwendungsteils läuft auf Port 80, der SSL- Connector auf Port 443. Es muss sichergestellt werden, dass keine andere Anwendung diese Ports im Serverbetrieb verwendet. User-Management: Das User-Management arbeitet auf den Ports 8080 (HTTP-Connector) und 8443 (SSL-Connector). Auch hier muss sichergestellt werden, dass keine andere Anwendung diese Ports im Serverbetrieb verwendet. Datenbank: Das Zugangsmanagement mit LDAP-Einbindung verwendet das Open-Source- Framework "Hibernate 5 " zusammen mit einer SQL-kompatiblen Datenbank. Hierbei ist zu beachten, dass die Datenbank verfügbar und Hibernate richtig konfiguriert (siehe Abschnitt 3.5.1.1) sind. Hinweis: An dieser Stelle sei darauf hingewiesen, dass beide Tomcat-Installationen auf dieselbe Hibernate-Konfigurationsdatei im classes-verzeichnis der Benutzerverwaltung, %UMGMT%/webapps/moa-id-proxy-umgmt/WEB-INF/classes/hibernate.cfg.xml zurückgreifen. 3.2.2 Client-Komponenten Bürgerkartenumgebung: Der Client muss sicherstellen, dass die Bürgerkartenumgebung einwandfrei funktioniert und dass eine eventuell vorhandene Firewall eingehende Verbindungen auf dem definierten Port (definiert über die Konfiguration der BKU-Auswahl in der Datei %UMGMT%/webapps/moa-id-proxy-umgmt/auswahl/xmldata.xml sowie über die Konfiguration der Bürgerkartenumgebung) zulässt. 3.3 Installation Die Installation der Web-Anwendung beschränkt sich auf das Auspacken der beiden Servlet- Container (MOA-ID-Proxy und Benutzerverwaltung) und auf das Ausführen eines Grundkonfigurations-Dialogs. Ob die beiden Servlet-Engines über ein Shell-Skript oder als Service gestartet werden spielt keine Rolle. Wesentlich ist die Anpassung der Umgebungsvariablen an das jeweilige System (siehe Abschnitt 3.4.1.1 und Abschnitt 3.5.1.1). 3.3.1 Initialisierung der Web-Anwendung Bevor die Web-Anwendung genutzt werden kann, muss zunächst eine Initialisierung erfolgen. Dazu wird der URL, mit der normalerweise die Benutzerverwaltung gestartet wird, ein Parameter "admin=true" hinzugefügt: http://%hostrechner%:8080/moa-id-proxy-umgmt/ ProxyUserChooser.do?action=show_proxyusers&admin=true 5 http://www.hibernate.org/ 34
Deployment Dies führt zu einer modifizierten Variante des bereits bekannten Login-Formulars (siehe nachfolgende Abbildung) mit dem sich der SuperUser mit Benutzernamen und Passwort anmelden kann. Der Benutzername lautet "root" und ist unveränderbar. Das Passwort des SuperUseres wird über die Datei su.properties des WEB-INF Verzeichnisses festgelegt und lautet in der Auslieferungsversion "1234". Hinweis: Dieses Passwort sollte aus Sicherheitsgründen im Zuge der Installation auf ein sicheres Passwort geändert werden. Abb. 3.1: Modifizierte Variante des Login-Dialogs Der Initialisierungs-Dialog erlaubt verschiedene Grundeinstellungen wie öffentliche Adresse, diverse MOA-ID-Einstellungen, einen MOA-ID-Test, das Verwalten von Organisationseinheiten sowie eine Initialisierung der anwendungsspezifischen Datenbanktabellen. Das Vorbereiten der Datenbanktabellen kann im Bedarfsfall auch manuell über ein SQL-Script vorgenommen werden. Hinweis: Die für diese Anwendung erstellte Datenbank lautet "proxyumgmt". 35
Deployment Abb. 3.2: Initialisierungsdialog für den Superuser "root" Initialisiert man die Datenbank über das Grundeinstellungs-Formular, dann wird für jede Organisationseinheit ein Administrator angelegt. Diese erhalten jeweils den Benutzernamen "admin" und das Passwort "1234". Damit wir der erstmalige Start der Benutzerverwaltung, über den auf Seite 34 dargestellten Link, ermöglicht. Hinweis: Das automatisch erstellte Passwort sollte aus Sicherheitsgründen ehestmöglich auf ein sicheres Passwort geändert werden. Innerhalb der Benutzerverwaltung können dann weitere Administratoren auf herkömmliche Weise erstellt werden (siehe Abschnitt 2.3.4), die sich dann in weiterer Folge wie vorgesehen mit ihrer Bürgerkarte anmelden. Um eine gute Übersichtlichkeit zu gewährleisten wird die Konfiguration des MOA-ID-Proxy und des Benutzermanagements im folgenden getrennt erläutert. 3.4 MOA-ID-Proxy 3.4.1 Konfiguration Zunächst folgt eine Beschreibung der Parameter, die unbedingt vor Inbetriebnahme der Anwendung angepasst werden müssen, danach folgt eine Erläuterung weiterer Anpassungsmöglichkeiten, die jedoch nicht unbedingt bei einem ersten Testlauf geändert werden müssen. 36