Dokumentation. Identifikation über SMS und Sprache

Transkript

1 Dokumentation Telefon: ++43 (316) Fax: ++43 (316) Inffeldgasse 16a / 8010 Graz / Austria Identifikation über SMS und Sprache Version 1.0, 14. Jänner 2008 DI Thomas Knall thomas.knall@egiz.gv.at Zusammenfassung: Die zunehmende private und berufliche Mobilität der Bürger bedingt ein Überdenken der bisherigen Zugänge zu Behörden-Verfahren. Vielen BürgerInnen ist es aus verschiedensten Gründen nicht möglich, E-Government über herkömmliche Kanäle (PC, Browser, Internetzugang, Bürgerkartenumgebung) zu nutzen. Diesen BürgerInnen steht mit diesem Prototyp ein alternativer Zugang zu Behörden-Verfahren über einen identifizierten Sprachkanal zu Verfügung. Es wird hier die Anwendung dokumentiert. Es werden dabei sowohl die Benutzung (Anwendungsbeschreibung) als auch die Installation beschrieben (Deployment und Auslieferung). Inhaltsverzeichnis: Abbildungsverzeichnis... 2 Revision History Einleitung Schlüsselwörter Geschlechtsspezifische Bezeichnungen Motivation 4 2 Kurzbeschreibung Technische Grundlagen Systembeschreibung Prozessbeschreibung Offene Punkte Voraussetzungen zur Nutzung der Anwendung 15 3 Anwendungsbeschreibung Registrierung mit Bürgerkarte Registrierung in einer Behörde Identifizierung und Vertretung 23 4 Deployment Systemanforderungen Installation Konfiguration 30 5 Auslieferung Struktur 36 Referenzen Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz

2 Abbildungsverzeichnis Abbildungsverzeichnis Abb. 2.1: Trennung von Front-Office und Back-Office... 6 Abb. 2.2: Systemüberblick... 6 Abb. 2.3: Registrierung in der Behörde... 9 Abb. 2.4: Registrierung mit Bürgerkarte...11 Abb. 2.5: Aufbau eines identifizierten Sprachkanals...13 Abb. 2.6: Aufbau eines identifizierten Sprachkanals inkl. Vertretung durch Organwalter...14 Abb. 3.1: Front-Office zur Registrierung mit Bürgerkarte...17 Abb. 3.2: Authentisierung mit Bürgerkarte...17 Abb. 3.3: Signatur der Anmeldedaten...18 Abb. 3.4: Registrierungsformular nach Bürgerkarten-Authentisierung...18 Abb. 3.5: Erfolgreiche Konto-Registrierung...19 Abb. 3.6: Freischaltung eines Kontos mit einer TAN...20 Abb. 3.7: Konto erfolgreich freigeschaltet Abb. 3.8: Back-Office für Sachbearbeiter/Organwalter...21 Abb. 3.9: Registrierung eines Zugangs durch einen Sachbearbeiter...22 Abb. 3.10: Eintragen der standardisierten Vollmacht...23 Abb. 3.11: Rückfrage bei der Aktualisierung der Infobox "Mandates" Abb. 3.12: Die standardisierte Vollmacht wurde erfolgreich eingetragen Abb. 3.13: Auswahl der Pseudo-Vollmacht bei trustdesk Basic...24 Abb. 3.14: MOA-ID-Login am Beispiel "Ausstellung von Geburtsurkunden"...25 Abb. 3.15: Eingabe des Benutzernamens und des Passworts der BürgerIn...26 Abb. 3.16: Eingabe der übermittelten TAN...27 Abb. 3.17: Signatur der Anmeldedaten in der Rolle als Vertreter...27 Abb. 3.18: Stellvertretung am Beispiel "Ausstellung von Geburtsurkunden"

3 Revision History Revision History Version Datum Autor(en) T. Knall erster Entwurf T. Knall T. Knall Offene Punkte Kurzbeschreibung, Anwendungsbeschreibung, Deployment T. Knall finale Überarbeitung 3

4 Einleitung 1 Einleitung 1.1 Schlüsselwörter Dieses Dokument verwendet die Schlüsselwörter MUSS, DARF NICHT, ERFORDERLICH, SOLLTE, SOLLTE NICHT, EMPFOHLEN, DARF und OPTIONAL zur Kategorisierung der Anforderungen. Diese Schlüsselwörter sind analog zu ihren englischsprachigen Entsprechungen MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY und OPTIONAL zu handhaben, deren Interpretation in [ KEYWORDS ] festgelegt ist. 1.2 Geschlechtsspezifische Bezeichnungen Alle Personenbezeichnungen, die in diesem Dokument in der männlichen Form verwendet werden, gelten sinngemäß auch für die weibliche Form. 1.3 Motivation E-Government gewährleistet den Bürgern einen komfortablen Zugang zu Dienstleistungen der Behörden. Dieser Zugang kann generell von allen Bürgern genutzt werden sofern diesen entsprechende Infrastruktur (PC, Browser, Internetzugang, Bürgerkartenumgebung sowie ggf. Kartenleser) zu Verfügung steht. Auch wenn diese Voraussetzungen vielfach bereits gegeben sind 1 gibt es dennoch eine große Anzahl an Personen, die mit den neuen Medien nicht vertraut sind bzw. denen die notwendigen Kenntnisse fehlen um mit den neuen Technologien umgehen zu können. Um nun auch diesen Personenkreis in den Genuss der Vorteile des E-Governments kommen zu lassen, müssen anlehnend an die in 1 Abs. 1 E-GovG [ E-GovG ] festgelegte "grundsätzliche Wahlfreiheit zwischen Kommunikationsarten für Anbringen" alternative Kommunikationskanäle auf deren Eignung untersucht und gegebenenfalls zu Verfügung gestellt werden. Um sämtliche potentielle technische Hürden bei der Nutzung eines E-Government- Verfahrens auszuschließen, müssten Verfahren auch über ein Telefongespräch zwischen Bürger und Sachbearbeiter abgewickelt werden können. Als einzige Voraussetzung ist in diesem Fall der Besitz eines (SMS-fähigen) Telefons anzusehen über das die Identifikation des Bürgers durchgeführt werden kann. Der hier erläuterte Prototyp setzt ein Konzept eines identifizierten Sprachkanals zwischen Bürger und Sachbearbeiter, basierend auf Identifikation nach dem Konzept Bürgerkarte, um. 1 Laut einer Studie der Statistik Austria besitzen 70,7% aller Haushalte einen Computer sowie 59,6% einen Internetzugang zum Befragungszeitpunkt Februar und März 2007 ([ IKT2007 ]). 4

5 Kurzbeschreibung 2 Kurzbeschreibung In Abstimmung auf die Zielgruppe von identifizierten Sprachkanälen Bürger ohne Zugang zu neuen Technologien wie Internet oder Bürgerkarte sollen beliebige Verfahren unter Zuhilfenahme eines (SMS-fähigen) Telefons sowie mit Hilfe eines Sachbearbeiters bzw. Organwalters durchgeführt werden können. Durch die Fokussierung der Kommunikation auf einen Sprachkanal entfallen sämtliche eventuell anderweitig vorhandene technischen Hürden. Ein Sprachkanal kann demnach als "Fallback"-Variante zu bislang üblichen E-Government-Zugängen betrachtet werden. Bislang war die Abwicklung von Verfahren über Telefon bzw. Handy mangels eindeutiger Identifikation des Anrufers nicht durchführbar. Mittels eines identifizierten Sprachkanals kann der Sachbearbeiter in der Rolle eines Organwalters im Namen des Betroffenen agieren, diesen gezielt nach erforderlichen Informationen fragen und ihm damit die Durchführung eines kompletten E-Government-Prozess abnehmen. Berücksichtigt werden muss allerdings, dass die Identifikation einer BürgerIn über Telefon nicht die gleiche Qualität wie eine echte Bürgerkarten-Authentifizierung aufweist. Der Prototyp sollte demnach nicht bei kritischen Anwendungen wie z.b. Strafregisterbescheinigungen eingesetzt werden. 2.1 Technische Grundlagen Damit ein Sachbearbeiter einen kompletten E-Government-Prozess für einen identifizierten Anrufer erledigen darf muss der Sachbearbeiter als Organwalter agieren dürfen. Dadurch eröffnet sich die Möglichkeit den identifizierten Sprachkanal an MOA-ID im Kompatibilitätsmodus für Organwalter zu koppeln MOA-ID für Organwalter und berufsmäßige Parteienvertreter MOA-ID im Kompatibilitätsmodus bietet die Infrastruktur die erforderlich ist, um eine Stellvertretung durch einen Organwalter bzw. berufsmäßigen Parteienvertreter technisch umzusetzen (siehe [ MOA-ID-KM ]). MOA-ID fordert unter Kenntnis der entsprechenden personenbezogenen Daten zur eindeutigen Identifikation des Betroffenen beim Stammzahlenregister-Gateway eine temporäre Vollmacht für den Organwalter an. Diese Vollmacht wird an die Applikation weitergereicht und danach von MOA-ID wieder verworfen. Auf diesem Weg kann der Organwalter E-Government Verfahren in Vertretung des Betroffenen durchführen Stammzahlenregister Gateway Das Stammzahlenregister-Gateway (siehe [ SZRGW-SPEC ]) ist eine zentrale Applikation die Behördenanwendungen den Zugang zum Stammzahlenregister ermöglicht. Derzeit unterstützt das Gateway ausschließlich jene Funktionen die für den MOA-ID Kompatibilitätsmodus benötigt werden. MOA-ID benutzt das Gateway um temporäre Vollmachten erstellen zu lassen. Das Gateway nutzt die von MOA-ID übermittelten Daten zur Identifikation eines Betroffenen, um dessen Stammzahl beim Stammzahlenregister zu ermitteln. Die Identifikationsdaten fließen dann zusammen mit den Identifikationsdaten des Organwalters in eine Pseudo-Vollmacht ein. Diese wird vom Gateway signiert und an MOA-ID retourniert. 5

6 Kurzbeschreibung 2.2 Systembeschreibung Bei dem hier dokumentierten Prototyp erfolgte eine Trennung der Front-Office-Komponente von der Back-Office-Komponente. Dadurch kann die Back-Office-Komponente in einem geschützten Bereich (z.b. Intranet) betrieben werden, während das Front-Office innerhalb einer DMZ eingerichtet werden kann (siehe Abb. 2.1). Auf diesem Weg kann das Back-Office vor unberechtigten Zugriffen geschützt werden. Abb. 2.1: Trennung von Front-Office und Back-Office Der Prototyp setzt sich aus verschiedenen serverseitigen Komponenten zusammen (Abb. 2.2). Diese Komponenten umfassen die Benutzerschnittstellen für SachbearbeiterIn bzw. Organwalter sowie für die BürgerIn, die Applikation, bestehend aus Front-Office und Back-Office, eine Datenbank und eine mit einem Plugin versehene MOA-ID-Installation. Darüber hinaus benötigt der Demonstrator einige externe Elemente, wie Stammzahlenregister, Stammzahlenregister-Gateway und SMS-Gateway. Abb. 2.2: Systemüberblick 6

7 Kurzbeschreibung Benutzerschnittstellen UI Bürgerin: UI Organwalter: Die BürgerIn kann über das Front-Office nach Authentifizierung mit Bürgerkarte selbst ein Benutzerkonto für identifizierte Sprachkanäle registrieren. Das Front-Office erlaubt weiters die Aktivierung neu erstellter Benutzerkonten durch Eingabe eines per SMS übermittelten Transaktionscodes. Diese Benutzerschnittstelle wurde im Rahmen eines MOA-ID-Plugins realisiert. Diese Schnittstelle umfasst die Eingabe von Benutzernamen/Passwort sowie eines per SMS übermittelten Transaktionscodes. Die eingegeben Daten werden vom Plugin ausgewertet und entsprechend aufbereitet an MOA-ID übergeben. UI SachbearbeiterIn/Organwalter: Das Back-Office kann von Sachbearbeitern eingesetzt werden um Benutzerkonten ohne Authentifizierung des Vertretenen zu registrieren. Hierbei muss organisatorisch sichergestellt werden, dass die Daten des Vertretenen authentisch sind (z.b. mittels Personalausweis, Meldebestätigung,...). Ebenso wie beim Front-Office können auch hier Benutzerkonten aktiviert werden. Organwalter haben weiters die Möglichkeit eine spezielle Pseudo- Vollmacht in ihre Bürgerkartenumgebung eintragen zu lassen mit der identifizierte Sprachkanäle aufgebaut werden können Applikation Die Applikation setzt sich unter anderem aus folgenden Komponenten zusammen: Front-Office: Back-Office: Apache Struts 2 : Hibernate 3 : Das Front-Office umfasst die Registrierung von Benutzerkonten durch die BürgerIn nach Authentifizierung mittels Bürgerkarte. Das Back-Office umfasst die Registrierung von Benutzerkonten ohne Authentifizierung, sowie das Speichern der Pseudo-Vollmacht in die Bürgerkartenumgebung des Organwalters. Struts ist ein Open-Source-Framework, das für die Präsentationsschicht und die Steuerungsschicht des Front- und Back-Office eingesetzt wird. Es dient hauptsächlich zur Trennung von Darstellung, Geschäftslogik und Datenmodell. Hierbei handelt es sich um ein Persistenz-Framework, das den Zustand von Objekten in einer relationalen Datenbank speichern kann, wobei die eigentliche Datenbankausprägung transparent gehalten wird. JConfig 4 : JConfig ist eine Bibliothek, die das Verwalten von Anwendungskonfigurationen erleichtert. Es wird hier in einer modifizierten Form eingesetzt. MOA-ID-Auth 5 : MOA-ID-Auth ist die Authentifizierungskomponente von MOA-ID. Diese wird verwendet, um BürgerInnen über ihre Bürgerkarte zu authentifizieren. Darüber hinaus wurde diese Komponente um ein Plugin erweitert, mit dem identifizierte Sprachkanäle aufgebaut werden können

8 Kurzbeschreibung SZR-Client 6 : Diese Komponente erlaubt den Zugriff auf das Stammzahlenregister des Bundesministerium für Inneres. Durch Abfrage des Stammzahlenregisters mit eingegebenen Personendaten können diese indirekt auf Gültigkeit gegenüber dem ZMR geprüft werden Datenbank Als Datenbank wird für den Prototypen eine MySQL-Datenbank eingesetzt. Durch das verwendete Persistenz-Framework Hibernate ist es jedoch jederzeit möglich, die Datenbankausprägung gegen eine andere (z.b. Oracle) auszutauschen Serverseitige Infrastruktur Zusätzlich finden folgende unabhängige Komponenten Verwendung: SMS-Gateway: Zum Nachweis des Besitzes des Telefons mit der bei der Registrierung angegebenen Telefonnummer werden Transaktionscodes generiert, die via SMS an das Telefon versandt werden. Als Gateway zum Versenden von SMS- Nachrichten dient das HTTP-XML-SMS-Gateway von "sms.at mobile internet services" (siehe [ SMS.AT ]). Stammzahlenregister: Das Stammzahlenregister 7 ist als Front-End zum Zentralen Melderegister zu betrachten das im Großen und Ganzen für die Berechnung von Stammzahlen zuständig ist. Stammzahlenregister-Gateway: Das Stammzahlenregister-Gateway ([ SZRGW-SPEC ]) ist eine zentrale Applikation, die behördlichen MOA-ID Installationen den Zugang zum SZR auf einfache Art und Weise ermöglicht. 2.3 Prozessbeschreibung Dieser Abschnitt definiert die dem Prototypen zugrundegelegten Prozesse. Diese gliedern sich in zwei Registrierungsprozesse sowie den Prozess des Aufbaus eines identifizierten Sprachkanals Registrierung in einer Behörde Dieser Prozess umfasst die Schritte (siehe Abb. 2.3) für die Registrierung eines Kontos ohne Bürgerkarte (siehe auch Abschnitt 3.2). 1. Die BürgerIn begibt sich in eine Behörde, füllt einen papierbasierten Antrag aus und weist sich gegenüber einem Sachbearbeiter mit Personalausweis und ggf. auch Meldebestätigung aus. 2. Ein Sachbearbeiter prüft die angegebenen Daten gegen Personalausweis und Meldezettel. Die Antragsdaten werden dann vom Sachbearbeiter im Back-Office in das dortige elektronische Registrierungsformular übertragen. 3. Die eingegeben Daten werden gegenüber dem ZMR geprüft. Dies verhindert Tippfehler des Sachbearbeiters. Tippfehler werden entweder direkt vom Sachbearbeiter korrigiert, andere, nicht feststellbare Fehler führen zur Zurückweisung der Registrierung. 4. Die eingegeben Daten werden gespeichert. 5. Sogleich wird ein Aktivierungscode generiert der an die im Antrag angegebene Telefonnummer als SMS übermittelt wird

9 Kurzbeschreibung 6. Die BürgerIn empfängt den Aktivierungscode auf ihrem Mobiltelefon. 7. Die BürgerIn teilt dem Sachbearbeiter den Aktivierungscode mit. Sollte die BürgerIn ihr Mobiltelefon nicht dabei haben oder verzögert sich die Zustellung der SMS aus unbestimmten Gründen, hat die Antragstellerin auch zu einem späteren Zeitpunkt über das Front-Office die Möglichkeit, das Konto freizuschalten. Notfalls kann dies auch telefonisch erfolgen. 8. Der Sachbearbeiter gibt den Aktivierungscode ein. 9. Der Registrierungscode wird überprüft. 10. War die Prüfung erfolgreich, dann ist das Konto nun aktiviert. Registrierung (Papierantrag) ZMR via SZR Registrierungsstelle/ Behörde BürgerIn 2 Übertragung der Daten vom Papier durch einen Sachbearbeiter 1 Antragsformular am Papier ausfüllen (ZMR- Daten, uid, pw...) 3 ZMR-Daten OK? N Fehler Fehler mitteilen Y 4 Registrierungsdaten speichern 5 Aktivierungscode generieren und per SMS versenden SMS 6 Aktivierungscode erhalten 7 Aktivierungscode dem Sachbearbeiter mitteilen Aktivierungscode eingeben 8 N 9 Aktivierungscode OK? 10 Y Konto ist aktiviert Abb. 2.3: Registrierung in der Behörde 9

10 Kurzbeschreibung Registrierung mit Bürgerkarte Dieser Prozess umfasst die Schritte (siehe Abb. 2.4) für die Registrierung eines Kontos mit Bürgerkarte (siehe auch Abschnitt 3.1). 1. Die BürgerIn startet das Front-Office durch Eingabe einer URL. Dort identifiziert und authentifiziert sie sich mittels Bürgerkarte. 2. Das elektronische Antragsformular wird ausgefüllt (inhaltlich identisch mit dem papierbasierten Formular). 3. Die eingegeben Daten werden zunächst auf Plausibilität geprüft. 4. Sind die Antragsdaten nicht plausibel (Konto wurde bereits registriert, fehlende Angaben etc...) wird eine entsprechende Fehlermeldung gezeigt und die BürgerIn wird gebeten die Eingabe zu korrigieren. 5. Sind die Antragsdaten erfolgreich geprüft worden, werden die Personendaten über eine Stammzahlenregister-Anfrage gegenüber dem Zentralen Melderegister geprüft. 6. Sollte die Prüfung gegenüber ZMR negativ verlaufen, wird eine entsprechende Meldung angezeigt und die BürgerIn gebeten die Antragsdaten zu korrigieren. 7. Die Registrierungsdaten werden gespeichert. 8. Es wird nun ein Aktivierungscode generiert und via SMS an die BürgerIn gesandt. 9. Die BürgerIn erhält den Aktivierungscode und gibt diesen in das entsprechende Aktivierungsformular ein. 10. Der Aktivierungscode wird überprüft und ggf. eine Fehlermeldung angezeigt. 11. War der Aktivierungscode gültig, wird das Konto aktiviert. 10

11 Kurzbeschreibung Registrierung (Antrag mit Bürgerkarte) ZMR via SZR Registrierungsstelle/ Behörde BürgerIn 1 Identifikation und Authentifikation mit Bürgerkarte 3 Antragsdaten prüfen 2 elektronisches Antragsformular ausfüllen (ZMR-Daten, uid, pw...) 5 4 Antragsdaten plausibel N Fehler anzeigen ZMR-Daten prüfen Y 6 Prüfung ok? N Fehler Fehler anzeigen Y 7 Registrierungsdaten speichern 8 Aktivierungscode generieren und per SMS versenden SMS 9 Aktivierungscode erhalten Aktivierungscode eingeben 10 Aktivierungscode OK? N Fehler anzeigen Y Konto ist aktiviert 11 Abb. 2.4: Registrierung mit Bürgerkarte 11

12 Kurzbeschreibung Aufbau eines identifizierten Sprachkanals Dieser Prozess umfasst die Schritte (siehe Abb. 2.5) für den Aufbau eines identifizierten Sprachkanals (siehe auch Abschnitt 3.3.2). 1. Die BürgerIn meldet sich telefonisch bei einer Behörde und äußert den Wunsch ein Verfahren telefonisch abzuwickeln. 2. Ein Organwalter wählt eine speziell für identifizierte Sprachkanäle vorbereitete Vollmacht aus seiner Bürgerkartenumgebung und startet die gewünschte E-Government-Anwendung. 3. Die Authentifizierungskomponente der Anwendung (MOA-ID) erkennt die Pseudo- Vollmacht und bietet ein Formular zur Eingabe von Benutzername und Passwort sowie eines Einmalcodes (TAN) an. 4. Der Organwalter bittet die BürgerIn um Mitteilung ihres Benutzernamens und ihres Passworts. 5. Die BürgerIn teilt dem Organwalter ihren Benutzernamen und das Passwort mit. 6. Nun wird der Benutzername, das Passwort sowie die Aktivierung des Kontos überprüft. Sind Benutzername/Passwort fehlerhaft oder wurde das Konto nicht aktiviert wird dies dem Organwalter mitgeteilt, der die BürgerIn informiert woraufhin die Identifizierung abgebrochen wird oder die Daten ggf. korrigiert werden. 7. Es wird eine TAN an die BürgerIn versandt. 8. Die BürgerIn teilt dem Organwalter die TAN mit. 9. Die TAN wird vom Organwalter in das Formular eingegeben und vom Prototypen überprüft. Stimmt die TAN nicht mit der an die BürgerIn übermittelten TAN überein, wird dies angezeigt. Der Organwalter weist die BürgerIn auf die falsche TAN hin und korrigiert ggf. die Eingabe. 10. Nachdem die übermittelten Daten überprüft wurden gilt die BürgerIn als identifiziert. 11. Der Organwalter wird von MOA-ID zur Signatur seiner Daten und der des Vertretenen aufgefordert. Die Signatur ist ein Sicherheitsmerkmal um Batch-Abfragen am SZR- Gateway zu verhindern. Gleichzeitig wird über das Signaturzertifikat des Organwalters die Eigenschaft "Organwalter" (Organwalter-OID) überprüft. 12. Das SZR-Gateway holt sich aus dem Stammzahlenregister die Stammzahl des Vertretenen und erstellt eine temporäre Vollmacht. 13. Der Organwalter wird an die entsprechende Anwendung weitergeleitet und kann diese als Vertretung der BürgerIn durchführen. 12

13 Kurzbeschreibung Aufbau eines identifizierten Sprachkanals Anwendung Organwalter BürgerIn 3 MOA-ID erkennt Vollmacht und verlangt uid/pw 2 Organwalter wählt Pseudovollmacht und startet Anwendung 1 BürgerIn meldet sich bei Behörde 4 Organwalter verlangt uid/pw 5 BürgerIn gibt uid/ pw bekannt Eingabe von uid/ pw uid/pw uid/pw gültig, Konto aktiviert? 6 N BürgerIn auf Fehler hinweisen Identifizierung abgebrochen 7 Y TAN an BürgerIn senden TAN 8 TAN dem Organwalter mitteilen 9 Eingabe der TAN TAN TAN gültig? N BürgerIn auf Fehler hinweisen Identifizierung abgebrochen Y 10 BürgerIn ist identifiziert, Organwalter zur Signatur auffordern 11 Signatur der Anmeldedaten zur Vertretung 12 SZR-Gateway erstellt temporäre Vollmacht Weiterleitung des Organwalters an gewünschte Anwendung 13 Durchführung der Anwendung in Vertretung der BürgerIn Abb. 2.5: Aufbau eines identifizierten Sprachkanals 13

14 Kurzbeschreibung Die nachfolgende Abb. 2.6 dient zur Verdeutlichung des in Abb. 2.5 skizzierten Prozesses. Abb. 2.6: Aufbau eines identifizierten Sprachkanals inkl. Vertretung durch Organwalter 2.4 Offene Punkte Die Umsetzung des Prozesses der Registrierung eines Kontos nach Authentifizierung mit Bürgerkarte (Abschnitt 2.3.2) nutzt derzeit nicht die Möglichkeit, BürgerInnen über ihr Bereichsspezifisches Personenkennzeichen eindeutig zu identifizieren. Dies würde die Angabe einer Adresse im Falle einer Nichteindeutigkeit der Angaben "Vorname(n)", "Familienname" und "Geburtsdatum" ("Datenzwillinge") überflüssig machen. Gleichzeitig würde damit auch ein möglicher Angriffspfad eines Datenzwillings, der nicht seine Adresse sondern jene seines Zwillings angibt, unterbunden werden. Die MOA-ID-Plugin-Schnittstelle sowie das Stammzahlenregister-Gateway sehen in den aktuell verfügbaren Versionen leider keine Weitergabe eines Bereichsspezifischen Personenkennzeichens vor weshalb dieses vorerst nicht durch diesen Prototypen verwendet werden kann. Sollte der Prototyp produktiv eingesetzt werden sind folgende drei Möglichkeiten für den Prozess "Registrierung mit Bürgerkarte" gegeben. Möglichkeit #1: Erweiterung des Stammzahlenregister-Gateways um die Möglichkeit, Bereichsspezifische Personenkennzeichen entgegenzunehmen. Erweiterung des Plugin-Interfaces von MOA-ID um die Möglichkeit, Bereichsspezifische Personenkennzeichen entgegenzunehmen. Möglichkeit #2: Versenden eines RSa-Briefs für Datenzwillinge mit einem Freischaltcode um die angegebene Adresse auf diese Weise zu verifizieren. Freischalten eines Benutzerkontos erst nach Eingabe dieses Freischaltcodes. Nachteil: Es ist schwer argumentierbar warum zusätzlich zur eindeutigen Identifizierung über Bürgerkarte noch ein RSa-Brief versandt werden muss. 14

15 Kurzbeschreibung Möglichkeit #3: Ablehnung einer Konto-Registrierung im Falle von Datenzwillingen sowie Verweis auf die Registrierungsmöglichkeit ohne Bürgerkarte (durch persönliches Erscheinen in einer Behörde). Nachteil: Benachteiligung der Gruppe der "Datenzwillinge" (davon gibt es etwa 400 in Österreich). In Anbetracht der Nachteile der Varianten 2 und 3 erscheint der erste Lösungsansatz am sinnvollsten. 2.5 Voraussetzungen zur Nutzung der Anwendung Für die Nutzung der Anwendung bestehen clientseitig folgende Voraussetzungen: Web-Browser, beispielsweise Mozilla Firefox 2.0.x 8 SMS-fähiges Mobiltelefon Sofern die BürgerIn das Konto für identifizierte Sprachkanäle nicht durch persönliches Erscheinen in einer Behörde registrieren lassen möchte, sondern den Weg über eine Bürgerkarten-Authentifizierung gehen möchte bestehen zusätzlich folgende Voraussetzungen: PC/SC-fähiges Kartenlesegerät Bürgerkarten-Software Die Kommunikation mit der Bürgerkarte muss mit einer der Security-Layer- Spezifikation [ SL122 ] entsprechenden Bürgerkartensoftware erfolgen z.b. ITSolution TrustDesk Basic, Version

16 Anwendungsbeschreibung 3 Anwendungsbeschreibung Die nachfolgende Anwendungsbeschreibung gliedert sich in drei Teile. Der erste Teil beschreibt die Registrierung eines Kontos für identifizierte Sprachkanäle über eine Bürgerkarten-Authentifikation (Abschnitt 3.1), der zweite Teil zeigt die Registrierung ohne Bürgerkarte in einer Behörde (Abschnitt 3.2) und der dritte Teil erläutert den Vorgang der Identifizierung über einen Sprachkanal sowie die Vertretung durch einen Organwalter (Abschnitt 3.3). Der Anwendungsbeschreibung wird folgende Terminologie bzw. folgende Parameter zu Grunde gelegt: Parameter Name Beschreibung Beispiel %SERVERURL% URL über die der Server, auf dem die Anwendung läuft, extern erreichbar ist 3.1 Registrierung mit Bürgerkarte Die Möglichkeit der Registrierung eines Kontos mit Bürgerkarte wurde geschaffen um BürgerInnen eine Alternative zum persönlichen Erscheinen bei der Behörde bieten zu können. Voraussetzung für diese Möglichkeit ist dann allerdings der Besitz einer Bürgerkarte sowie die entsprechende Hard- und Software (siehe auch Abschnitt 2.5). Zunächst ruft die BürgerIn das Front-Office über die URL %SERVERURL%/ivc, beispielsweise auf. Das Front-Office (siehe Abb. 3.1) ermöglicht neben der Anmeldung eines Kontos (Klick auf den Link "Konto mit Bürgerkarte anmelden") auch die Freischaltung eines soeben angemeldeten Kontos durch Eingabe eines Freischalt-TANs (Klick auf "Konto mit TAN freischalten"). 16

17 Anwendungsbeschreibung Abb. 3.1: Front-Office zur Registrierung mit Bürgerkarte Die BürgerIn wird zur Authentisierung weitergeleitet (siehe Abb. 3.2). Das Bürgerkarten- Symbol zeigt ob die Bürgerkartenumgebung bereit ist. Sollte die Bürgerkartenumgebung noch nicht gestartet sein, muss dies nun erfolgen. Abb. 3.2: Authentisierung mit Bürgerkarte 17

18 Anwendungsbeschreibung Nach Klick auf "Authentisierung starten" wird die BürgerIn zur Signatur der Anmeldedaten aufgefordert (siehe Abb. 3.3). Es muss nun die 6-stellige Signatur PIN eingegeben werden. Abb. 3.3: Signatur der Anmeldedaten Nach erfolgreicher Authentisierung erscheint das Anmeldeformular (Abb. 3.4) bei dem Vorname(n), Familienname sowie das Geburtsdatum bereits vorab ausgefüllt sind. Abb. 3.4: Registrierungsformular nach Bürgerkarten-Authentisierung 18

19 Anwendungsbeschreibung Die BürgerIn muss nun einen Benutzernamen sowie ein Passwort (das zweimal eingegeben werden muss) wählen. Sollte der Benutzername bereits vergeben sein, wird die BürgerIn darauf hingewiesen. In diesem Fall muss ein neuer Benutzername gewählt werden. Nun muss noch die Telefonnummer eines SMS-fähigen Telefons angegeben werden. Nach Klick auf "Benutzer registrieren" werden zunächst die personenspezifischen Daten über eine SZR-Abfrage überprüft. Sollte Vorname(n), Familienname sowie Geburtsdatum nicht ausreichend sein um eine BürgerIn eindeutig zu identifizieren ("Datenzwilling") so müssen zusätzlich Adressdaten (jedoch nicht zwingenderweise alle Felder) angegeben werden. Hinweis: Sämtliche eingegebenen Daten müssen mit den Daten mit denen die BürgerIn im ZMR registriert ist übereinstimmen. Dies kann bei dem Feld "Gemeinde" problematisch sein, da hier nicht immer der exakte Gemeindename eingetragen ist (z.b. "Graz,04.Bez.:Lend" anstatt "Graz"). Gegebenfalls ist das Feld "Gemeinde" leer zu lassen. Konnte ein Konto erfolgreich registriert werden erscheint folgende Meldung (Abb. 3.5). Abb. 3.5: Erfolgreiche Konto-Registrierung 19

20 Anwendungsbeschreibung Das Benutzerkonto ist vorerst inaktiv, da zunächst die angegebene Telefonnummer durch Versand einer TAN überprüft werden muss. Aus diesem Grund wird der BürgerIn eine SMS übermittelt, die die TAN enthält. Nach Klick auf "OK" gelangt die BürgerIn zum Eingabeformular für diese TAN (Abb. 3.6). Abb. 3.6: Freischaltung eines Kontos mit einer TAN Nach (richtiger) Eingabe der TAN und Klick auf "Konto freischalten" gilt das Konto als freigeschaltet (siehe Abb. 3.7). Abb. 3.7: Konto erfolgreich freigeschaltet. 20

21 Anwendungsbeschreibung 3.2 Registrierung in einer Behörde Besitzt eine BürgerIn keine Bürgerkarte oder möchte sie die Möglichkeit der Registrierung eines Kontos mit der Bürgerkarte nicht nützen, dann muss sie persönlich bei der Behörde erscheinen und sich mittels Personalausweis bzw. ggf. Meldebestätigung ausweisen. Der Sachbearbeiter wird dann das Konto über das Back-Office (siehe Abb. 3.8) erstellen. Das Back-Office wird über eine URL aufgerufen, die idealerweise nur über das Intranet erreichbar ist. beispielsweise aufgerufen. Die URL zum Back-Office muss entsprechend abgesichert werden. Das Back- Office des Prototyps ist derzeit via Basic-Authentication (Benutzername/Passwort) folgendermaßen abgesichert: Benutzername: ivc Passwort: ivc Das Back-Office (siehe Abb. 3.8) bietet folgende Möglichkeiten: Anmeldung eines Kontos durch einen Sachbearbeiter (Klick auf Link "Konto anmelden") Freischaltung eines Kontos durch Eingabe eines Freischalt-TANs (Klick auf "Konto mit TAN freischalten") Schreiben der standardisierten Pseudo-Vollmacht auf die Bürgerkarte des Organwalters Abb. 3.8: Back-Office für Sachbearbeiter/Organwalter 21

22 Anwendungsbeschreibung Nachdem sich die BürgerIn ausgewiesen hat, kann der Sachbearbeiter ein Konto einrichten. Dazu füllt er das in Abb. 3.9 gezeigte Formular aus. Um Fehleingaben zu vermeiden werden die eingegebenen Personendaten mittels Stammzahlenregister-Abfrage verifiziert. Konnten die Daten nicht eindeutig einer Person zugeordnet werden, wird der Sachbearbeiter darauf hingewiesen worauf dieser nach Rücksprache mit der BürgerIn Korrekturen vornehmen kann. Abb. 3.9: Registrierung eines Zugangs durch einen Sachbearbeiter Nach Absenden des Formulars ("Benutzer registrieren") wird ein Benutzerkonto erstellt und der BürgerIn eine SMS mit einem Aktivierungscode übermittelt um die angegebene Telefonnummer zu verifizieren. Der Sachbearbeiter gelangt automatisch zum Aktivierungsformular (siehe auch Abb. 3.6) in das er den Aktivierungscode eingibt, den ihm die BürgerIn nach Erhalt nennen muss. Wurde der Aktivierungscode nicht gleich empfangen oder hat die BürgerIn ihr Mobiltelefon nicht zu Hand, kann sie das Konto selbst zu einem späteren Zeitpunkt aktivieren oder dies notfalls auch telefonisch mit Hilfe des Sachbearbeiters durchführen. 22

23 Anwendungsbeschreibung 3.3 Identifizierung und Vertretung Bevor ein Organwalter BürgerInnen über einen identifizierten Sprachkanal vertreten kann, muss er einmalig eine spezielle Pseudo-Vollmacht auf seiner Bürgerkarte bzw. in der Bürgerkartenumgebung speichern. Über diese Vollmacht erkennt MOA-ID, dass ein identifizierter Sprachkanal aufgebaut werden soll und startet das entsprechend konfigurierte MOA-ID-Plugin (siehe auch Abschnitt 4.3.3) Eintragen der standardisierten Vollmacht in der Bürgerkartenumgebung Das Eintragen der standardisierten Vollmacht in die Bürgerkartenumgebung kann der Organwalter über das Back-Office erledigen. Nach Klick auf den entsprechenden Link auf der Startseite des Back-Office wird die in Abb dargestellte Seite gezeigt. Das Bürgerkarten-Symbol zeigt an ob die Bürgerkartenumgebung bereit ist. Gegebenenfalls muss an dieser Stelle die Bürgerkartenumgebung gestartet werden. Weiters ist darauf zu achten, dass die Bürgerkarte für den Organwalter eingelegt ist. Abb. 3.10: Eintragen der standardisierten Vollmacht Nach Klick auf "Vollmacht eintragen" wird die Pseudo-Vollmacht "IdentifiedVoiceChannel" unter "Mandates" in die Bürgerkartenumgebung gespeichert. Gegebenenfalls ist die Aktualisierung der Infobox "Mandates" noch zu bestätigen (Abb. 3.11). Abb. 3.11: Rückfrage bei der Aktualisierung der Infobox "Mandates". 23

24 Anwendungsbeschreibung Wurde die Vollmacht erfolgreich eingetragen erscheint folgende Meldung (Abb. 3.12). Abb. 3.12: Die standardisierte Vollmacht wurde erfolgreich eingetragen Aufbau eines identifizierten Sprachkanals Möchte eine BürgerIn über einen Sprachkanal ein Verfahren anstoßen, meldet sie sich zunächst telefonisch bei einem Sachbearbeiter. Um einen identifizierten Sprachkanal aufbauen zu können, muss sich die BürgerIn zum einen zuvor registriert haben (Abschnitt 3.1 bzw. 3.2) zum anderen muss der Sachbearbeiter als Organwalter agieren können (d.h. eine entsprechende OID in seinem Zertifikat auf der Bürgerkarte besitzen). Der Organwalter wählt zunächst die Pseudo-Vollmacht innerhalb seiner Bürgerkartenumgebung (siehe Abb. 3.13: Auswahl der Pseudo-Vollmacht), entweder durch Festlegung eines Profils oder durch Aktivierung von "Auswahl bei Anfrage". Abb. 3.13: Auswahl der Pseudo-Vollmacht bei trustdesk Basic 24

25 Anwendungsbeschreibung Nun nennt die BürgerIn das anzustoßende Verfahren. Der Organwalter startet nun die gewünschte Anwendung und startet dort ein MOA-ID-Login. Üblicherweise geschieht dies durch Auswahl der "Chipkarte" als Ausprägung der Bürgerkarte (siehe Abb. 3.14) bzw. bei neueren Anwendungen, die die A1-Signatur aus Bürgerkartenausprägung nicht mehr unterstützen, durch Klick auf "Authentisierung starten". Abb. 3.14: MOA-ID-Login am Beispiel "Ausstellung von Geburtsurkunden" 25

26 Anwendungsbeschreibung Neben der Personenbindung des Organwalters wird auch die Pseudo-Vollmacht an MOA-ID übermittelt. MOA-ID erkennt diese Vollmacht und leitet den Aufbau eines identifizierten Sprachkanals ein. Dazu wird dem Organwalter folgendes Formular präsentiert (Abb. 3.15). Abb. 3.15: Eingabe des Benutzernamens und des Passworts der BürgerIn Die BürgerIn nennt dem Organwalter ihren Benutzernamen und ihr Passwort. Nachdem dieser die Daten eingegeben werden diese verifiziert. Stimmen diese mit den Daten eines registrierten Benutzers überein wird eine TAN generiert und der BürgerIn an die bei der Registrierung angegebene Telefonnummer per SMS übermittelt. 26

27 Anwendungsbeschreibung Die BürgerIn teilt dem Organwalter nun die TAN mit, woraufhin dieser die Identifizierung der BürgerIn durch Eingabe der TAN in das Formular abschließt (Abb. 3.16). Ab diesem Zeitpunkt kann die BürgerIn als identifiziert betrachtet werden. Abb. 3.16: Eingabe der übermittelten TAN Nun wird der Organwalter zur Signatur der Anmeldedaten in der Rolle als Vertreter aufgefordert (Abb. 3.17). Abb. 3.17: Signatur der Anmeldedaten in der Rolle als Vertreter 27

28 Anwendungsbeschreibung Die Signatur wird schließlich an das Stammzahlenregister-Gateway übermittelt, das damit unter anderem die Organwaltereigenschaft des Sachbearbeiters verifizieren kann. Das Gateway erstellt nun eine temporäre Vollmacht für MOA-ID im Kompatibilitätsmodus. MOA-ID leitet nun den Organwalter im Namen der BürgerIn an die gewünschte Anwendung weiter (siehe z.b. Abb am Beispiel der Anwendung "Ausstellung von Geburtsurkunden"). Abb. 3.18: Stellvertretung am Beispiel "Ausstellung von Geburtsurkunden" 28

29 Deployment 4 Deployment Der Dokumentation des Deployments werden folgende Parameter zu Grunde gelegt: Parameter Name Beschreibung Beispiel %CATALINA_BASE% Pfad zum Servlet-Container C:\Programme\tomcat ivc 4.1 Systemanforderungen Es gelten folgende Anforderungen an die Installationsplattform bzw. an die Clientkomponenten (die angegebenen Versionen entsprechen der getesteten Umgebung): Server-Komponenten J2SE Java Runtime Environment (JRE) v1.5.x 10 Apache Tomcat v Relationale Datenbank, z.b. MySQL Client-Komponenten siehe Abschnitt 2.5, "Voraussetzungen zur Nutzung der Anwendung" 4.2 Installation Hinweis: Die Installationsbeschreibung geht davon aus, dass die beiliegende MOA-ID- Distribution verwendet wird und dass ein gemeinsamer Servlet-Container (Apache Tomcat) für Back-Office/Front-Office und MOA-ID-AUTH Verwendung findet. Die Installation des Prototypen setzt sich aus fünf Schritten zusammen: Deployment des Back-Office Das Deployment beschränkt sich auf das Kopieren des Web-Archivs für die Komponente Back-Office (ivc-backend.war) in das Tomcat-Webapps-Verzeichnis %CATALINA_BASE%\webapps. Deployment des Front-Office Das Deployment beschränkt sich auf das Kopieren des Web-Archivs für das Front- Office (ivc.war) in das Tomcat-Webapps-Verzeichnis %CATALINA_BASE%\webapps. Deployment von MOA-ID-AUTH mit dem Plugin für den identifizierten Sprachkanal Die Komponente MOA-ID-AUTH wird installiert, indem das Web-Archiv (moaidivc.war) in das Tomcat-Webapps-Verzeichnis %CATALINA_BASE%\webapps kopiert wird. Konfiguration von MOA-ID-AUTH (siehe Abschnitt 4.3) Konfiguration der Web-Anwendung (siehe Abschnitt 4.3) Hinweis: Front-Office und Back-Office besitzen eine gemeinsame Konfiguration

30 Deployment 4.3 Konfiguration Die Konfiguration des Prototypen gliedert sich in drei Teile: Konfiguration des Servlet-Containers Apache Tomcat Konfiguration des Front-Office bzw. des Back-Office Konfiguration von MOA-ID Sämtliche für die Konfiguration aller Komponenten erforderlichen Konfigurationsdateien befinden sich im Verzeichnis %CATALINA_BASE%/conf Apache Tomcat Die Konfiguration des Servlet-Containers erfolgt über die Datei %CATALINA_BASE%/conf/server.xml. Die Beispielkonfiguration umfasst zusätzlich noch die Datei %CATALINA_BASE%/conf/tomcat-users.xml in der Benutzername und Passwort zur Absicherung des Back-Office eingetragen sind. Die Absicherung des Back- Office kann auch durch einen vorgeschalteten Web-Server erfolgen, der den externen Zugang nur auf das Front-Office und auf MOA-ID-AUTH zulässt. Weitere Informationen entnehmen Sie bitte der Dokumentation des Servlet-Containers [ TOMCAT-DOC ] bzw. der Dokumentation Ihres Web-Servers. Sollte MOA-ID so konfiguriert sein, dass es Templates über SSL von der Web-Anwendung lädt (siehe Abschnitt 4.3.3), dann muss über die Java-System-Properties javax.net.ssl.* ein Trust-Store angegeben werden. Folgende System-Properties sollten beim Servlet-Container gesetzt werden. System-Property file.encoding moa.id.configuration moa.spss.server.configuration ivc.configuration javax.net.ssl.truststore javax.net.ssl.truststorepassword javax.net.ssl.truststoretype Beschreibung Sollte auf UTF-8 gesetzt werden. Enthält den Pfad zur Konfiguration der Authentifizierungskomponente MOA-ID-AUTH. Sollte auf %CATALINA_BASE%/conf/moa-id/moaidconfig.xml gesetzt werden. Enthält den Pfad zur Konfiguration der internen MOA-SPSS-Komponente. Sollte auf %CATALINA_BASE%/conf/moaspss/SampleMOASPSSConfiguration.xml gesetzt werden. Enthält den Pfad zur Konfiguration des Front- Office/Back-Office. Sollte auf %CATALINA_BASE%/conf/ivc/ application_config.xml gesetzt werden. Enthält den Pfad zum Trust-Store des Servlet- Containers. Enthält das Passwort des Trust-Stores des Servlet- Containers. Enthält den Typ (z.b. JKS) des Trust-Stores. 30

31 Deployment Front-Office/Back-Office Die Konfiguration des Front- und des Back-Office befindet sich im Ordner %CATALINA_BASE%/conf/ivc. Die Konfigurationsdatei application_config.xml umfasst sämtliche Einstellungen für die Web-Anwendung. Wie aus dem folgenden Listing zu entnehmen ist, wurde die Konfiguration in einzelne Kategorien eingeteilt. Gelb markierte Einträge müssen vor Inbetriebnahme des Prototypen angepasst werden. <properties> <category name="error"> <mailto>replace_with_admin- </mailto> </category> <category name="moa"> <category name="id-auth"> <connection.url> <connection.internal.url> </connection.internal.url> <!-- <keystore.uri>replace_with_keystore_uri</keystore.uri> <keystore.type>replace_with_keystore_type</keystore.type> <keystore.password>replace_with_keystore_password</keystore.password> <key.password>replace_with_key_password</key.password> <truststore.uri>replace_with_truststore_uri</truststore.uri> <truststore.type>replace_with_truststore_type</truststore.type> <truststore.password>replace_with_truststore_password</truststore.password> --> </category> </category> <category name="hibernate"> <hibernate.connection.driver_class>com.mysql.jdbc.driver</hibernate.connection.driver_class> <hibernate.connection.url> jdbc:mysql://replace_with_db-host/replace_with_db-name </hibernate.connection.url> <hibernate.connection.username>replace_with_username</hibernate.connection.username> <hibernate.connection.password>replace_with_password</hibernate.connection.password> <hibernate.dialect>org.hibernate.dialect.mysqldialect</hibernate.dialect> </category> <category name="sms.at"> <account.login>replace_with_sms.at-username</account.login> <account.type> </account.type> <account.pass>replace_with_sms.at-password</account.pass> <sms.text> Ihr Code für den authentifizierten Sprachkanal: ${tan}\nsollten Sie diese SMS unerwünscht erhalten haben, wenden Sie sich bitte an REPLACE_WITH_ADMIN- . </sms.text> </category> <category name="tan"> <!-- <tan.handler>at.gv.egiz.ivc.tan.logtanhandler</tan.handler> --> <tan.handler>at.gv.egiz.ivc.tan.smsattanhandler</tan.handler> <tan.digits>5</tan.digits> </category> 31

32 Deployment <category name="szr"> <pvp.file>${catalina.base}/conf/ivc/szr/pvp.1_8.xml</pvp.file> <pvp.version>1.8</pvp.version> <keystore.location>replace_with_keystore.jks</keystore.location> <keystore.password>replace_with_keystore_password</keystore.password> <truststore.location>replace_with_truststore.jks</truststore.location> <service.url> soapv2%23pvp1?dest=stammzahlenregister2&opzone=test </service.url> <truststore.password>replace_with_truststore_password</truststore.password> </category> <category name="internal"> <allow.multiple.accounts>false</allow.multiple.accounts> </category> </properties> Kategorie "error" Schlüssel mailto Beschreibung -Adresse, die dem Anwender auf einer Fehlerseite zusammen mit der Fehlermeldung als Kontakt-Adresse angezeigt wird. Fehlerseiten werden nur bei abnormem Anwendungsverhalten oder intern aufgetretenen Fehlern angezeigt. Kategorie "moa" mit Unterkategorie "id-auth" Diese Kategorie bzw. Unterkategorie enthält Einstellung die die Authentifizierungskomponente MOA-ID-AUTH betreffen. Schlüssel connection.url Beschreibung connection.internal.url keystore.uri keystore.type keystore.password key.password truststore.uri truststore.type truststore.password Enthält die URL über die der Browser auf MOA-ID-AUTH weitergeleitet wird. Diese URL muss von extern erreichbar sein. Enthält die URL über die die Web-Anwendung intern auf MOA- ID zugreifen kann (Abholen der SAML-Assertion). Diese URL sollte eine HTTP-URL sein und sollte extern nicht erreichbar sein. Hinweis: Werden die nachfolgenden Schlüssel konfiguriert kann auf Konfiguration dieses Schlüssels verzichtet werden. Angabe des Keystores für eine SSL-Verbindung zwischen Web- Anwendung und MOA-ID. Der Typ des verwendeten Keystores (z.b. JKS) Das Passwort des Keystores. Sollte der Keystore-Typ JKS verwendet werden, können einzelne Schlüssel zusätzlich durch Passwort gesichert sein. Grundsätzlich sollte für die Schlüssel das gleiche Passwort wie für den Keystore verwendet werden. Angabe eines Truststores für die SSL-Verbindung. Angabe des Typs des Truststores. Angabe des Passworts des Truststores. 32

33 Deployment Kategorie "hibernate" Diese Kategorie umfasst die Konfiguration der Datenbank. Schlüssel hibernate.connection.driver_class hibernate.connection.url hibernate.connection.username hibernate.connection.password hibernate.dialect Kategorie "sms.at" Beschreibung Angabe der Treiber-Klasse für Hibernate. Wird MySQL verwendet sollte der Eintrag com.mysql.jdbc.driver lauten. Hinweis: Kommt eine andere Datenbank zum Einsatz muss die angegebene Treiber-Klasse über eine datenbankspezifische Bibliothek zu Verfügung gestellt werden (analog zum MySQL-Connector). Die Verbindungs-URL zur Datenbank. z.b. jdbc:mysql://localhost:3306/ivc Der Benutzername zum Zugriff auf die Datenbank. Das Passwort zum Zugriff auf die Datenbank. Der Hibernate-spezifische Datenbank-Dialekt. Kommt MySQL zum Einsatz sollte der Eintrag org.hibernate.dialect.mysqldialect lauten. Der Prototyp verwendet ein Konto bei sms.at ([ SMS.AT ]) um die TANs als SMS zu versenden. Dieser Account entspricht keinem Standard-Konto und muss explizit bei sms.at angefordert werden. Schlüssel account.login account.pass account.type sms.text Kategorie "tan" Beschreibung Der Login-Name für sms.at. Das Passwort Der Login-Typ. Dieser Wert sollte auf gesetzt sein. Der Text der zu versendenden SMS. Hinweis: Der Platzhalter ${tan} wird durch die jeweilige TAN ersetzt; Zeilenumbrüche können durch \n realisiert werden. Diese Kategorie umfasst die Festlegung eines Handlers für TANs. Ein solcher Handler generiert TANs und versendet sie. Ein TAN-Handler muss das Interface at.gv.egiz.ivc.tan.tanhandler implementieren. Schlüssel Beschreibung tan.handler TAN-Handler, der SMS generiert und versendet. Im Test-Betrieb kann der Handler at.gv.egiz.ivc.tan.logtanhandler (TANs scheinen nur in der LOG-Datei auf) verwendet werden. Für den Produktiveinsatz ist at.gv.egiz.ivc.tan.smsattanhandler vorgesehen. tan.digits Anzahl der Stellen der generierten TANs. Hinweis: Diese Einstellung wird bei den beiden vorgegebenen Handlern verwendet. Wird ein eigener Handler implementiert, sollte diese Einstellung auch berücksichtigt werden. 33

34 Deployment Kategorie "szr" In dieser Kategorie kann der Zugang zum Stammzahlenregister (SZR) konfiguriert werden. Schlüssel pvp.file Beschreibung Angabe des Pfades zum Security-Token, das zum Zugriff auf das SZR erforderlich ist. In der Beispielkonfiguration ist der Pfad ${catalina.base}/conf/ivc/szr/pvp.1_8.xml voreingestellt. Das Security-Token muss jedoch noch entsprechend konfiguriert werden. pvp.version zu Grunde liegende Version, voreingestellt mit 1.8 keystore.location keystore.password truststore.location service.url truststore.password Pfad zum Keystore, der für die SSL-Client-Authentifizierung zum SZR erforderlich ist. Passwort des Keystores. Pfad zum Truststore, der für die SSL-Verbindung zum SZR erforderlich ist. Service-URL zum SZR. Derzeit ist das Test-Portal konfiguriert: pvp1?dest=stammzahlenregister2&opzone=test Passwort des Truststores. Um das Stammzahlenregister verwenden zu können ist zusätzlich noch ein Security-Token (Datei pvp.1_8.xml) erforderlich. Dieses Token enthält Authentifizierungs-Informationen, wie UserId, OrganisationsId etc. und muss vor Nutzung des Prototyps entsprechend konfiguriert werden. Weitere Informationen entnehmen Sie bitte der technischen Dokumentation zum Stammzahlenregister [ SZR ]. Kategorie "internal" Diese Kategorie beinhaltet interne Einstellungen für den Prototypen. Schlüssel allow.multiple.accounts MOA-ID Beschreibung Hiermit kann konfiguriert werden ob es möglich ist, mehrere Konten für eine Person anzumelden (true) oder ob über bpk der Person sichergestellt wird, dass nur ein Konto angemeldet wird (false). Die MOA-ID-Konfigurationsdatei moaid-config.xml befindet sich im Ordner %CATALINA_BASE%/conf/moa-id. Die dem Deliverable beigelegte Beispiel-Konfiguration entspricht im Großen und Ganzen der Default-MOA-ID-Konfiguration. Aus diesem Grund enthält das folgende Listing nur die davon abweichenden Einträge, wobei die zu konfigurierenden Einträge hervorgehoben sind:... <Infobox Identifier="Mandates" required="false" providestammzahl="true" provideidentitylink="true"> <FriendlyName>Vollmachten</FriendlyName> <ParepSpecificParameters> <CompatibilityMode>true</CompatibilityMode> <EnableInfoboxValidator>false</EnableInfoboxValidator> <PartyRepresentation> <InputProcessor template="/resources/templates/pareptemplate.html"> at.gv.egovernment.moa.id.auth.validator.parep.parepinputprocessorimpl </InputProcessor> <AlwaysShowForm>true</AlwaysShowForm> 34

35 Deployment <ConnectionParameter URL=" <ClientKeyStore password="replace_with_client-keystore-password"> REPLACE_WITH_CLIENT-KEYSTORE </ClientKeyStore> </ConnectionParameter> <!-- Notare --> <PartyRepresentative oid=" " representphysicalparty="true" representcorporateparty="true" representationtext="berufsmäßige(r) Parteienvertreter(in) mit Notariatseigenschaft"/> <!-- Rechtsanwaelte --> <PartyRepresentative oid=" " representphysicalparty="true" representcorporateparty="true" representationtext="berufsmäßige(r) Parteienvertreter(in) mit Rechtsanwaltseigenschaft"/> <!-- Organwalter --> <PartyRepresentative oid=" " representphysicalparty="true" representcorporateparty="false" representationtext="organwalter"/> <PartyRepresentative oid=" identifiedvoicechannel" representphysicalparty="true" representcorporateparty="false" representationtext="parteienvertreter(in) über einen identifizierten Sprachkanal"> <InputProcessor template="/templates/identifiedvoicechannelpareptemplate.html"> at.gv.egiz.ivc.moa.id.auth.identifiedvoicechannelparepinputprocessorimpl </InputProcessor> </PartyRepresentative> </PartyRepresentation> </ParepSpecificParameters> </Infobox>... <!-- Identifizierter Sprachkanal --> <OnlineApplication type="publicservice" publicurlprefix=" <AuthComponent providestammzahl="true" provideauthblock="false" provideidentitylink="true" providecertificate="false"> <Templates> <Template URL=" </Templates> </AuthComponent> </OnlineApplication>... Grundsätzlich müssen zwei Kategorien konfiguriert werden: Die Verbindungsparameter zum Stammzahlenregistergateway (bestehend aus URL zum SZR-Gateway, Client-Keystore und Client-Keystore-Passwort) sowie die applikationsspezifischen MOA-ID-Parameter für das Front-Office. Weitere Informationen zur Konfiguration von MOA-ID-Online-Anwendungen entnehmen Sie bitte dem MOA-ID-Handbuch [ MOA-ID-HB ]. 35