Embed Size (px)
Citation preview
Bundesministerium für öffentliche Leistung und Sport
Chief Information Office Austria IKT-Stabsstelle des Bundes
Konvention
MOA ID 1.0
Spezifikation
MOA ID 2002-10-08 Öffentlicher Entwurf
Bezeichnung Spezifikation Module für Online Applikationen - ID
Kurzbezeichnung MOA ID
Version 1.0
Datum 2002-10-08
Dokumentenklasse Konvention
Dokumentenstadium Entwurf öffentlich
Kurzbeschreibung Dieses Dokument spezifiziert ein Servermodul für die weitere Umsetzung der e-Government-Strategien.
Das Basismodul ID dient zur sicheren Identifikation und Authentifikation von Benutzern mittels Bürgerkarte. Dabei wird die digitale Signatur zum sicheren Beweis der Authentizität verwendet.
Das Design sieht vor, dass Online-Applikationen die Identifikation und Authentifikation an MOA ID auslagern können.
Mit dem vorliegenden Dokument wird eine weitere Vereinheitlichung des e-Governments sowie eine Vereinfachung der Umsetzung von modernen Online-Applikationen angestrebt.
Autoren Chief Information Office, Stabsstelle IKT-Strategie des Bundes, Bundesministerium für öffentliche Leistung und Sport
Email: [email protected]
Bundesministerium für Finanzen
Email: [email protected]
Arbeitsgruppe ARGE Spezifikation MOA
2002-10-0 MOA ID 1.0 Seite 2/29
Inhaltsverzeichnis 1 Einleitung .........................................................................................................5 2 Anwendungsfälle ................................................................................................6 3 Überblick ..........................................................................................................7
4 Allgemeine Anforderungen ................................................................................. 10 4.1 Unterstützte Plattformen ............................................................................... 10 4.2 TLS Authentisierung ..................................................................................... 10 4.3 Skalierbarkeit und Verfügbarkeit..................................................................... 10 4.4 Namespace................................................................................................. 10
5 Authentisierungskomponente ............................................................................. 11 5.1 Schnittstelle zur verweisenden Webseite.......................................................... 11 5.2 Schnittstelle zur Bürgerkarte.......................................................................... 11
5.2.1 Information bezüglich Wurzelzertifikate....................................................... 11 5.2.2 Abfrage der Personenbindung.................................................................... 12
5.2.3 Signieren des AUTH-Block ........................................................................ 12 5.3 Schnittstelle zur nachfolgenden Applikation ...................................................... 13 5.4 AUTH-Block ................................................................................................ 14
5.4.1 <saml:AttributeStatement>...................................................................... 14 5.4.2 <saml:Subject> ..................................................................................... 14
5.4.3 <saml:NameIdentifier> ........................................................................... 14 5.4.4 <saml:Attribute>.................................................................................... 15 5.4.5 <ds:Signature>...................................................................................... 15
5.5 Anmeldedaten ............................................................................................. 15 5.5.1 <saml:AttributeStatement>...................................................................... 16
5.5.2 <saml:Subject> ..................................................................................... 16 5.5.3 <saml:NameIdentifier> ........................................................................... 16 5.5.4 <saml:SubjectConfirmation> .................................................................... 16 5.5.5 <saml:Attribute>.................................................................................... 17
5.6 Konfiguration .............................................................................................. 18
5.7 Funktionsbeschreibung ................................................................................. 19 5.7.1 Überprüfung der Signatur der Personenbindung............................................ 19 5.7.2 Überprüfung des signierten AUTH-Blocks ..................................................... 19
6 Proxykomponente ............................................................................................ 20 6.1 Schnittstelle zum Aufbau des Requests an die Online-Applikation ......................... 20
6.2 Schnittstelle zur Online-Applikation ................................................................. 20 6.2.1 Typisches Setup für stateless Online-Applikationen ....................................... 20 6.2.2 Typisches Setup für stateful Online-Applikationen ......................................... 21
2002-10-0 MOA ID 1.0 Seite 3/29
6.3 Schnittstelle zum Browser des Benutzers ......................................................... 21 6.4 Proxy-Funktion............................................................................................ 21 6.5 Konfiguration .............................................................................................. 21
6.5.1 Konfiguration in der Proxykomponente........................................................ 21 6.5.2 Konfiguration der Online-Applikation .......................................................... 22
7 Definition der Schnittstelle zwischen Authentisierungskomponente und nachfolgenden Applikation ...................................................................................................... 25
7.1 SOAP ......................................................................................................... 25 7.1.1 Beispiele für SOAP Messages ..................................................................... 25
7.2 API............................................................................................................ 25
7.2.1 Interface IdentificationService................................................................... 26 8 Referenzen...................................................................................................... 27 9 Anhang – Nicht-Spezifizierte Funktionalität ........................................................... 29
2002-10-0 MOA ID 1.0 Seite 4/29
Dokumenten Information 1
Versionen 2
Version Datum Beschreibung Autor
1.0 8.10.2002 Version 1.0 BMF/CIO
3
© Diese Spezifikation wird von BMöLS (Bundesministerium für öffentliche Leistung und Sport) 4 und BMF (Bundesministerium für Finanzen) zur Verfügung gestellt. Die Verwendung ohne 5 Modifikation ist unter Bezugnahme auf diese Copyright-Notiz zulässig. 6
7
2002-10-0 MOA ID 1.0 Seite 5/29
1 Einleitung 8
Die vorliegende Spezifikation umfasst das Modul Identifikation von MOA (MOA-ID). 9
Zielsetzung dieses Dokuments ist das Modul so zu spezifizieren, dass eine Implementierung in 10 Phase 2 durchgeführt werden kann. Stellt sich in Phase 2 heraus, dass Ergänzungen sinnvoll 11 sind, so können diese während dieser Phase 2 durchgeführt werden. 12
2002-10-0 MOA ID 1.0 Seite 6/29
2 Anwendungsfälle 13
Die primäre Funktion von MOA-ID ist Anwendungen zu unterstützen einer HTTP-Session eine 14 VPK bzw. andere benutzerspezifische Daten sicher zuordnen zu können. 15
[UC BRZ] beschreibt die Anwendungsfälle aus Sicht der Online-Applikationen, die MOA-ID 16 abdecken muss. 17
Die Anwendungsfälle, die MOA abdecken muss sind in der folgenden Liste zusammengefasst: 18
• Authentisierung eines Benutzers (Bürger oder Behördenmitarbeiter) mittels 19 Bürgerkarte und Security-Layer 20
• Konfiguration von MOA-ID 21
2002-10-0 MOA ID 1.0 Seite 7/29
3 Überblick 22
23
24
MOA-ID besteht aus zwei Modulen, der Authentisierungskomponente und der 25 Proxykomponente, die mit dem Browser des Benutzers und Online-Applikationen Schnittstellen 26 aufweisen. Mit dem Security-Layer des Benutzers wird sowohl über den Browser als auch 27 direkt kommuniziert. 28
Die Authentisierungskomponente führt die eigentliche Authentisierung des Benutzers durch 29 und übergibt der Proxykomponente die Anmeldedaten. Die Proxykomponente übernimmt die 30 Anmeldedaten von der Authentisierungskomponente, führt die Anmeldung an der Online 31 Applikation durch und schleust in der Folge Daten an die Online-Applikation und Daten an den 32 Benutzer durch. Diese beiden Komponenten können auf unterschiedlichen Rechnern oder auf 33 dem gleichen Rechner eingesetzt werden. 34
Die folgende Tabelle beschreibt einen typischen An- und Abmeldevorgang in mehreren 35 Schritten (die Nummerierung der Schritte entspricht den Nummern in der oben gezeigten 36 Grafik): 37
Schritt Beschreibung
1. Der Benutzer verbindet sich zu einem Web-Portal, über das die verfügbaren Online-Applikationen (OA) erreichbar sind. Jeder Link zu einer OA verweist auf die Authentisierungskomponente mit zwei Parameter: • URL der tatsächlich zu verwendeten Applikation:
z.B. https://app1.gv.at/Beispiel • Geschäftsbereich: als String kodiert
2. Der Benutzer verbindet sich über HTTPS mit der Authentisierungskomponente, die die Authentisierung des Benutzers durchführt:
2002-10-0 MOA ID 1.0 Seite 8/29
2.1. Die Authentisierungskomponente erzeugt eine HTML-Seite zum Auslesen der Personen-Bindung, mit folgenden Inhalten:
• <FORM> mit Security-Layer <InfoboxReadRequest>-Kommando zum Auslesen der Personenbindung
Diese HTML-Seite wird an den Browser geschickt.
2.2. Der Browser schickt das Kommando per HTTP POST an den Security-Layer. Der Security-Layer
• liest die Personenbindung
• sendet die Personenbindung über die angegebene DataURL (siehe [SecLayer1.1]) an die Authentisierungskomponente zurück.
2.3. Die Authentisierungskomponente sendet, als Antwort auf die Personenbindung, eine XML Antwortseite, die direkt das Kommando zum Signieren des von der Authentisierungskomponente generierten AUTH-Blocks enthält.
2.4. Der Request wird vom Security-Layer verarbeitet (Siehe [SecLayer1.1-Bindung] Abschnitt 3.3.2 Punkt 5b). Die signierten Daten werden direkt and die DataURL zurückgesendet.
2.5. Die Authentisierungskomponente überprüft den signierten AUTH-Block und legt für den Benutzer die Anmeldedaten (siehe Abschnitt 5.5) an.
2.6. Ist der obige Authentisierungsvorgang erfolgreich, dann wird eine Redirect-Seite mit einem SAML-Artifact (siehe Abschnitt 5.3) erstellt und zum Browser gesendet.
3. Der Browser führt das Redirect zur angegebenen URL (Proxykomponente von MOA-ID) durch. Als Parameter wird das eindeutige SAML-Artifact übergeben, mit dem die nachfolgende Applikation die Anmeldedaten von der Authentisierungskomponente abfragen kann.
4.
5.
Die nachfolgende Applikation (Proxykomponente) verwendet dieses eindeutige SAML-Artifact, um die Anmeldedaten via SOAP von der Authentisierungskompo-nente zu erhalten. Danach werden die Anmeldedaten in der Authentisierungskomponente gelöscht.
6. Die Proxykomponente liest eine Konfigurationsdatei die beschreibt, wie die Anmeldedaten an die nachfolgende Applikation übergeben werden müssen, und meldet den Benutzer bei der Applikation an.
7. In der Folge werden die Antworten der (stateless) OA an den Benutzer weitergeleitet und die Anfragen des Benutzers an die OA weitergeleitet.
38
Im Falle einer neu entwickelten Online-Applikation kann die Funktionalität und die Schnitt-39 stellen der Proxykomponente von der Online-Applikation übernommen werden. 40
2002-10-0 MOA ID 1.0 Seite 9/29
41
42
Im folgenden wird die Proxykomponente und die neu entwickelte Online-Applikation als 43 nachfolgende Applikation bezeichnet. 44
2002-10-0 MOA ID 1.0 Seite 10/29
4 Allgemeine Anforderungen 45
4.1 Unterstützte Plattformen 46
Es muss Java Runtime Environment ab Version 1.3 unterstützt werden. 47
4.2 TLS Authentisierung 48
Sämtliche Schnittstellen zwischen den Komponenten und Applikationen können mittels TLS 49 [TLS] authentisiert werden: 50
51
Schnittstelle TLS Authentisierung Beschreibung
Browser - Authentisierungskomponente
Server verpflichtend
Browser – nachfolgende Applikation
Server verpflichtend
Authentisierungskomponente – MOA Signaturprüfung
Server, Client konfigurierbar
nachfolgende Applikation - Authentisierungskomponente
Server, Client konfigurierbar
Proxykomponente – Online-Applikation
Server, Client konfigurierbar
52
4.3 Skalierbarkeit und Verfügbarkeit 53
MOA-ID muss skalierbar und auf einen 7 * 24h Betrieb ausgelegt sein. 54
4.4 Namespace 55
Alle in dieser Spezifikation definierten XML-Elemente sind dem Namespace 56 http://reference.e-government.gv.at/namespace/moa/20020822# zugeordnet. 57
2002-10-0 MOA ID 1.0 Seite 11/29
5 Authentisierungskomponente 58
Die Funktionsweise der Authentisierungskomponente orientiert sich an dem in [SAML-Binding] 59 im Abschnitt 4.1.1 („Browser/Artifact Profile of SAML“) beschriebenen Vorgang, erweitert durch 60 die Erstellung des vom Benutzer signierten AUTH-Blocks mit dem Security-Layer 61 [SecLayer1.1]. 62
5.1 Schnittstelle zur verweisenden Webseite 63
Die Authentisierungskomponente wird immer durch eine andere (verweisende) Webseite 64 aufgerufen. Diese Webseite kann z.B. Teil eines Portals sein. 65
Der Aufruf der Authentisierungskomponente durch die verweisende Webseite (aufrufende 66 Applikation) erfolgt durch das Aufrufen einer von der Authentisierungskomponente 67 bereitgestellten URL durch den Browser des Benutzers. Der HTTP-Request hat die Form: 68
GET https://<moa-id-server-und-pfad>? 69 TARGET=<geschäftsbereich>&OA=<oaurl>&CSS=<css-url> 70
Wobei: 71
• <moa-id-server-und-pfad> angibt, welche URL auf der Authentisierungskomponente 72 für die Generierung der HTML-Seite zur Abfrage der Bürgerkarte verwendet wird.. 73
• TARGET=<geschäftsbereich> (siehe [GB], [GB-BK]) angibt, für welches Verfahren der 74 Benutzer authentisiert werden soll. 75
• OA=<oaurl> mittels URL angibt, an welche Seite in der nachfolgenden Applikation der 76 Benutzer nach erfolgreicher Authentisierung weitergeleitet werden muss. Die URL 77 (bzw. ein eindeutiger Teil davon) dient außerdem als Schlüssel für die Auswahl der 78 applikationsspezifischen Konfiguration in der Authentisierungskomponente (siehe 79 Abschnitt 5.6 Konfiguration). 80
• CSS=<css-url> angibt, welches Stylesheet verwendet werden muss, um die Seite mit 81 der Bürgerkarten-Abfrage anzuzeigen. 82
Die Weiterleitung an die nachfolgende Applikation erfolgt durch einen HTTP-Redirect (Status 83 Code 302). 84
5.2 Schnittstelle zur Bürgerkarte 85
5.2.1 Information bezüglich Wurzelzertifikate 86
Für die Sicherheit des Identifikationsmoduls ist es wesentlich, dass der Benutzer zuverlässig 87 die Authentizität der Authentisierungskomponente überprüfen kann. Diese Authentizität wird 88 durch die Verwendung des TLS-Protokolls sichergestellt. Da TLS-Implementierung in gängigen 89 Web-Browsern viele Wurzelzertifikate als vertrauenswürdige vorinstalliert haben, ist es 90 notwendig, dass der Benutzer die Richtigkeit der verwendeten Serverzertifikate manuell 91 überprüft. Der folgende Ablauf soll sicherstellen, dass der Benutzer diese Überprüfung 92 durchführt bzw. bewusst auf diese Überprüfung verzichtet. 93
Bevor die Personenbindung ausgelesen wird, bekommt der Benutzer eine Möglichkeit (mittels 94 Info-Button) eine signierte Informationsseite von der Authentisierungskomponente zu laden, 95 welche automatisch im Secure-Viewer des Security-Layers sicher angezeigt wird. Diese 96 Informationsseite beinhaltet eine Beschreibung, wie der Benutzer die Authentizität des Servers 97 mittels TLS überprüfen kann, und ist von der Authentisierungskomponente signiert. Die 98 Signatur und der Zertifikatspfad zum Wurzelzertifikat sind vom Benutzer zu überprüfen. 99
2002-10-0 MOA ID 1.0 Seite 12/29
5.2.2 Abfrage der Personenbindung 100
Diese Schnittstelle dient zum Abfragen der Personenbindung vom Security-Layer (siehe 101 Abschnitt 3 Überblick, Schritt 2.1). 102
Die Authentisierungskomponente erzeugt eine HTML-Seite die zumindest das folgende <LINK>-103 , <FORM>- und <SCRIPT>-Element enthält: 104
<LINK rel="stylesheet" type="text/css" href="<css-url>"> 105 106 <FORM name="getIdentityLinkForm" 107 action=http://localhost:3495/http-security-layer-request 108 method="POST"> 109 <INPUT type="hidden" name="XMLRequest"/> 110 <INPUT type="hidden" name="DataURL" 111 value=<generateSignAuthBlockRequestServletID>? 112 TARGET=<geschäftsbereich>?CSS=<css-url>/> 113 <INPUT type="submit" value="Auslesen der Personenbindung"/> 114 </FORM> 115 116 <A href='http://<Infopage>'> Wichtige Information zu Zertifikaten</A> 117 118
<css-url> ist die in Abschnitt 5.1 Schnittstelle zur verweisenden Webseite beschriebene URL. 119
Das Feld XMLRequest muss folgenden Wert beinhalten: 120
<InfoboxReadRequest 121 xmlns="http://www.buergerkarte.at/namespaces/securitylayer/20020225#"> 122 <InfoboxIdentifier> 123 IdentityLink 124 </InfoboxIdentifier> 125 <BinaryFileParameters/> 126 </InfoboxReadRequest> 127 128
Das Feld DataURL enthält eine URL, welche einen eindeutigen, für jeden Auslesevorgang 129 unterschiedlichen Identifier beinhaltet. Diese URL verweist auf ein Servlet, welches die 130 Personenbindung entgegennimmt und in Folge eine Antwort darauf erzeugt (Beschreibung 131 siehe Abschnitt 5.2.3). 132
5.2.3 Signieren des AUTH-Block 133
Das im Abschnitt 5.2.2 Abfrage der Personenbindung über die DataURL referenzierte Servlet 134 nimmt die Personenbindung entgegen. 135
Ist der <InfoboxReadRequest> erfolgreich, so erzeugt das Servlet die XML-Antwortseite mit 136 dem Befehl zum Signieren des AUTH-Blocks (siehe Abschnitt 5.4). Ist der 137 <InfoboxReadRequest> nicht erfolgreich wird eine HTML-Seite mit einer Fehlerbeschreibung 138 erzeugt und der Authentisierungsvorgang abgebrochen. Die erzeugte XML- bzw. HTML-Seite 139 wird an den Security-Layer retourniert, der je nach Content-Type der Antwort entsprechend 140 reagiert. (siehe [SecLayer1.1-Bindung] Abschnitt 3.3.2 Punkt 5) 141
Das Servlet hat die Parameter: 142
• geschäftsbereich 143
• css-url 144
• Personenbindung 145
Folgende Schnittstelle definiert die XML-Seite, die dazu dient den AUTH-Block mit dem 146 Security-Layer zu signieren (siehe Abschnitt 3 Überblick, Schritt 2.3). 147
XML-Antwortseite zum Signieren des AUTH-Blocks: 148
2002-10-0 MOA ID 1.0 Seite 13/29
<CreateXMLSignatureRequest 149 xmlns="http://www.buergerkarte.at/namespaces/securitylayer/20020831#"> 150 <KeyboxIdentifier>CertifiedKeypair</KeyboxIdentifier> 151 <DataObjectInfo Structure="enveloping"> 152 <DataObject> 153 <XMLContent> 154 [der in Abschnitt 5.4 beschriebene AUTH-Block] 155 </XMLContent> 156 </DataObject> 157 <TransformsInfo> 158 [mögliche Transformationen] 159 </TransformsInfo> 160 </DataObjectInfo> 161 <SignatureInfo> 162 [Spezifikation wo die Signatur eingebettet werden soll] 163 </SignatureInfo> 164 </CreateXMLSignatureRequest> 165 166
<TransformsInfo> enthält die Transformationen, die angewendet werden können, um die 167 XML-Struktur des AUTH-Blocks in ein für den Benutzer verständliches Format zu konvertieren, 168 das im Viewer des Security-Layers angezeigt werden kann. Es müssen sämtliche in Abschnitt 169 5.4 AUTH-Block spezifizierten Informationen dem Benutzer angezeigt werden. Diese 170 Transformationen müssen für alle Security-Layer-Implementierungen, die unterstützt werden, 171 konfiguriert werden können. Alle diese Transformationen müssen dem Security-Layer zur 172 Verfügung gestellt werden, sodass dieser die geeignete Transformation auswählen kann. 173
Ist die Erstellung bzw. Prüfung der Signatur nicht erfolgreich wird eine HTML-Seite mit einer 174 Fehlerbeschreibung erzeugt und der Authentisierungsvorgang abgebrochen. Die erzeugte 175 HTML-Seite wird an den Browser retourniert. 176
Ist die Erstellung und Prüfung der Signatur erfolgreich, wird entsprechend der SAML 177 Spezifikation ein Redirect, welches das SAMLartefact (siehe Abschnitt 5.3) enthält, vom Server 178 über die Security-Layer-Implementierung an den Browser retourniert. 179
Als DataURL dürfen nur URLs spezifiziert werden, die die Authentisierungskomponente 180 referenzieren. 181
5.3 Schnittstelle zur nachfolgenden Applikation 182
Die nachfolgende Applikation wird durch den HTTP-Redirect von der 183 Authentisierungskomponente aufgerufen, und stellt die Authentisierung an der Applikation 184 selbst sicher. Der HTTP-Request, mit dem die nachfolgende Applikation aufgerufen wird, hat 185 die Form: 186
GET https://<applikation-server-und-pfad>? 187 TARGET=<geschäftsbereich>&SAMLart=<SAML artifact> 188
Wobei: 189
• <applikation-server-und-pfad> die URL angibt, an der die nachfolgende Applikation 190 aufgerufen werden kann, um den Benutzer zu authentisieren. Sie ist identisch mit dem 191 Wert des beim Aufruf der Authentisierungskomponente übergebenen Parameters OA. 192
• TARGET=<geschäftsbereich> den Geschäftsbereich angibt, für den der Benutzer 193 authentisiert werden soll. 194
• SAMLart=<SAML artifact> das SAML-Artifact übergibt, das während des 195 Authentisierungsvorganges mit der Authentisierungskomponente erzeugt wurde, und 196 anhand dessen die nachfolgende Applikation die Identität des Benutzers verifizieren 197 kann. Die Codierung des SAML-Artifact ist in [SAML-Binding], Abschnitt 4.1.1.8 198 beschrieben. 199
Die nachfolgende Applikation muss mit Hilfe des SAML-Artifact einen SOAP-Request an die 200 Authentisierungskomponente zusammenstellen, wie in [SAML-Binding], Abschnitte 3 und 201
2002-10-0 MOA ID 1.0 Seite 14/29
4.1.1.6 beschrieben. Bei erfolgreicher Rückmeldung der SOAP-Response, wie in Abschnitt 202 4.1.1.6 in [SAML-Binding] beschrieben, ist der Benutzer an der nachfolgenden Applikation 203 angemeldet. 204
5.4 AUTH-Block 205
Der AUTH-Block ist eine Datenstruktur, die von der Authentisierungskomponente und vom 206 Security-Layer mittels eines XSLT Stylesheets aufgebaut wird, und enthält folgende 207 Informationen: 208
• Vorname, Nachname aus Personenbindung 209
• URL der Authentisierungskomponente 210
• URL und Geschäftsbereich der nachfolgenden Applikation 211
• Aktuelle Zeit 212
Die Personenbindung ist nicht im AUTH-Block enthalten weil: 213
• die ZMR-Zahl nicht immer gespeichert werden darf 214
• die Daten der Personenbindung (öffentliche Schlüssel, ZMR Zahl) für den Benutzer 215 wenig aussagekräftig sind und daher eine Anzeige im Secure Viewer des Security-Layer 216 nicht sinnvoll ist 217
• die Daten der Personenbindung würden drei mal zwischen Security-Layer und 218 Authentisierungskomponente übertragen werden 219
Der AUTH-Block wird als SAML-Assertion [SAML-Assertions] dargestellt und vom Benutzer 220 signiert. 221
Das <saml:Assertion>-Element muss folgende verpflichtende Attribute enthalten: 222
Name Beschreibung
MajorVersion Muss den Wert 1 haben
MinorVersion Muss den Wert 0 haben
AssertionID Die Assertion-ID wird in der Folge nicht verwendet und kann daher auf einen beliebigen Wert gesetzt werden.
Issuer Der Vorname und Nachname des Benutzers durch ein Leerzeichen getrennt (der Vorname wird aus dem <GivenName>-Element, der Nachname aus dem <FamilyName>-Element der Personenbindung entnommen.
IssueInstant Zeitpunkt der Erstellung der Assertion
223
Das Element enthält weiters genau ein <saml:AttributeStatement>-Element und genau ein 224 <ds:Signature>-Element. 225
5.4.1 <saml:AttributeStatement> 226
Das <saml:AttributeStatement>-Element enthält genau ein <saml:Subject>-Element und 227 ein <saml:Attribute>-Elemente. 228
5.4.2 <saml:Subject> 229
<saml:Subject> enthält ein <saml:NameIdentifier> als Inhalt. 230
5.4.3 <saml:NameIdentifier> 231
Enthält die URL der Authentisierungskomponente als Inhalt. 232
2002-10-0 MOA ID 1.0 Seite 15/29
5.4.4 <saml:Attribute> 233
<saml:Attribute> kommt zweimal Mal vor um den Geschäftsbereich und die URL der 234 nachfolgenden Applikation darzustellen. 235
Jedes <saml:Attribute> enthält genau ein <saml:AttributeValue>. 236
5.4.4.1 Geschäftsbereich 237
<saml:Attribute> für den Geschäftsbereich hat folgende Attribute: 238
Name Beschreibung
AttributeName Geschäftsbereich
AttributeNamespace http://reference.e-government.gv.at/namespace/moa/20020822#
239
<saml:Attribute> für den Geschäftsbereich enthält genau ein <saml:AttributeValue> mit 240 dem Geschäftsbereich als xs:token. Der Geschäftsbereich wurde vorher als Parameter dem 241 Servlet übergeben. 242
5.4.4.2 URL der nachfolgenden Applikation 243
<saml:Attribute> hat folgende Attribute: 244
Name Beschreibung
AttributeName OA
AttributeNamespace http://reference.e-government.gv.at/namespace/moa/20020822#
245
<saml:Attribute> für die URL der nachfolgenden Applikation enthält genau ein 246 <saml:AttributeValue> mit der <oaurl> als xs:anyURI. Die URL wurde vorher als 247 Parameter dem Servlet übergeben. 248
5.4.5 <ds:Signature> 249
Die XML Signatur der <saml:Assertion> wird gemäß Security-Layer Version 1.1 250 [SecLayer1.1] erstellt. 251
Die Signatur enthält ein <dsig:Reference> Element, das wie folgt auszuführen ist: 252
<dsig:Reference URI=""> 253 <dsig:Transforms> 254 <dsig:Transform 255 Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> 256 [XSLT Transformationen] 257 </dsig:Transforms> 258 <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 259 <dsig:DigestValue> ..... </dsig:DigestValue> 260 </dsig:Reference> 261 262
Weiters enthält die Signatur ein <ds:KeyInfo> Element, welches ausreichend Information 263 enthalten muss, dass eine automatische Validierung der Signatur möglich ist. Jedenfalls muss 264 das X509 Signaturzertifikat eingebunden werden. 265
5.5 Anmeldedaten 266
Die Anmeldedaten werden in Form einer SAML-Assertion dargestellt, die, basierend auf dem 267
2002-10-0 MOA ID 1.0 Seite 16/29
signierten AUTH-Blocks und der vorher übersendeten zugehörigen Personenbindung, von der 268 Authentisierungskomponente der nachfolgenden Applikation zur Verfügung gestellt wird. Die 269 SAML-Assertion wird nicht signiert und enthält folgende Informationen: 270
• VPK 271
• signierter AUTH-Block (konfigurierbar) 272
• signierte Personenbindung 273 (konfigurierbar: keine Personenbindung, Personenbindung mit ZMR, Personenbindung 274 ohne ZMR) 275
• PersonData Struktur (konfigurierbar: mit oder ohne ZMR) 276
• Zertifikatstype (qualifiziertes Zertifikat oder einfaches Zertifikat) 277
• Information zur Behörde (optional) 278
Der Aufbau der SAML-Assertion für die Anmeldedaten erfolgt analog zum Aufbau des AUTH-279 Blocks (Abschnitt 5.4) 280
Das <saml:Assertion>-Element muss folgende verpflichtende Attribute enthalten: 281
Name Beschreibung
MajorVersion muss den Wert 1 haben
MinorVersion muss den Wert 0 haben
AssertionID Die Assertion-ID wird in der Folge nicht verwendet und kann daher auf einen eindeutigen Wert gesetzt werden.
Issuer URL der Authentisierungskomponente
IssueInstant Zeitpunkt der Erstellung der Assertion
282
Das Element enthält weiters genau ein <saml:AttributeStatement>-Element. 283
5.5.1 <saml:AttributeStatement> 284
Das <saml:AttributeStatement>-Element enthält genau ein <saml:Subject>-Element und 285 mehrere <saml:Attribute>-Elemente. 286
5.5.2 <saml:Subject> 287
<saml:Subject> enthält ein <saml:NameIdentifier> Element. 288
5.5.3 <saml:NameIdentifier> 289
Das Element muss folgendes Attribut enthalten: 290
Name Beschreibung
NameQualifier Beschreibt die Domäne des Namens und muss den String http://reference.e-government.gv.at/names/vpk/20020221# enthalten.
291
Als Inhalt enthält <saml:NameIdentifier> die VPK in Base64 kodierter Darstellung. 292
5.5.4 <saml:SubjectConfirmation> 293
Ist konfiguriert, dass AUTH-Block und/oder Personenbindung mitgegeben werden sollen, 294 werden diese im Element <saml:SubjectConfirmation> eingebunden. 295
2002-10-0 MOA ID 1.0 Seite 17/29
Als <saml:ConfirmationMethod> wird 296 http://reference.e-government.gv.at/names/moa/20020822#cm benutzt. 297
<saml:SubjectConfirmationData> enthält den AUTH-Block und/oder die Personenbindung (in 298 dieser Reihenfolge). Die ZMR-Zahl der Personenbindung wird je nach Konfiguration 299 ausgeblendet oder mitgegeben. 300
5.5.5 <saml:Attribute> 301
<saml:Attribute> kommt mehrmals vor um die oben erwähnten Informationen darzustellen: 302
Jedes <saml:Attribute> enthält genau ein <saml:AttributeValue>. 303
5.5.5.1 PersonData 304
Das Attribut für die Personendaten ist immer vorhanden und enthält abhängig von der 305 Konfiguration die ZMR-Zahl (siehe Abschnitt 5.6). 306
<saml:Attribute> für PersonData hat folgende Attribute: 307
Name Beschreibung
AttributeName PersonData
AttributeNamespace http://reference.e-government.gv.at/namespace/ persondata/20020228#
308
<saml:AttributeValue> enthält genau die PersonData-Struktur (identisch zu der in der 309 Personenbindung strukturiert). Diese PersonData-Struktur enthält: Vorname, Nachname, 310 Geburtsdatum, ZMR-Zahl (optional). 311
5.5.5.2 Zertifikatstyp 312
Dieses Attribut beschreibt den Typ des Zertifikats, mit dessen zugehörigen privaten Schlüssel 313 der AUTH-Block vom Benutzer signiert wurde. <saml:Attribute> für den Zertifikatstyp hat 314 folgende Attribute: 315
Name Beschreibung
AttributeName isQualifiedCertificate
AttributeNamespace http://reference.e-government.gv.at/namespace/moa/20020822#
316
<saml:Attribute> für den Zertifikatstyp enthält genau ein <saml:AttributeValue> mit 317 folgendem Inhalt: 318
true wenn das Zertifikat ein qualifiziertes Zertifikat ist
false wenn das Zertifikat ein einfaches Zertifikat ist
319
5.5.5.3 Behördenzertifikat 320
Dieses Attribut beschreibt ob bei der Signatur des AUTH-Block ein Behördenzertifikat 321 verwendet wurde. Ein Behördenzertifikat ist ein Zertifikat mit der Erweiterung 322 Behördeneigenschaft (siehe [OID]). 323
Ein <saml:Attribute> für die Information ob ein Behördenzertifikat vorliegt ist nur dann in 324 den Anmeldedaten vorhanden, wenn zur Signaturerstellung ein Behördenzertifikat verwendet 325 wurde. 326
2002-10-0 MOA ID 1.0 Seite 18/29
Das <saml:Attribute> hat folgende Attribute: 327
Name Beschreibung
AttributeName isPublicAuthority
AttributeNamespace urn:oid:1.2.40.0.10.1.1.1 (siehe [RFC3061])
328
Das <saml:Attribute> für die Information ob ein Behördenzertifikat vorliegt enthält genau ein 329 <saml:AttributeValue> mit folgendem Inhalt: 330
True wenn das Zertifikat ein Behördenzertifikat ist, aber kein Behördenkennzeichen im Zertifikat verfügbar ist
Behördenbezeichnung wenn das Zertifikat ein Behördenzertifikat ist und ein Behördenkennzeichen im Zertifikat verfügbar ist
331
5.6 Konfiguration 332
Folgende Daten müssen für die Kommunikation mit allen zu unterstützenden Security-Layer 333 Implementierungen konfiguriert werden können: 334
• Transformationen für unterschiedliche Datenformate für die sichere Anzeige des AUTH-335 Blocks. 336
Folgende Daten müssen für die Kommunikation mit MOA-Signaturprüfung konfigurierbar sein: 337
• Konfiguration ob die Kommunikation mit MOA-Signaturprüfung via SOAP- oder via API-338 Aufrufe erfolgen soll. 339
• Angabe, ob die Schnittstelle zur MOA-Signaturprüfung mit TLS-Client- und/oder TLS-340 Server-Authentisierung geschützt werden muss. 341
o verwendetes TLS-Client-Zertifikat der Authentisierungskomponente 342
o akzeptierte TLS-Server-Zertifikate der MOA-Signaturprüfung 343
o vertrauenswürdige Wurzelzertifikate für akzeptierte TLS-Server-Zertifikate der 344 MOA-Signaturprüfung 345
• TrustProfileID und VerifyTransformsInfoID für die Überprüfung der Signatur der 346 Personenbindung 347
• TrustProfileID und VerifyTransformsInfoID für die Überprüfung der Signatur des 348 AUTH-Blocks 349
Folgende Daten müssen für jede nachfolgende Applikation in der Authentisierungskomponente 350 konfigurierbar sein: 351
• Angabe, ob die ZMR-Zahl in der Personenbindung und in der PersonData-Struktur an 352 die nachfolgende Applikation übergeben wird oder nicht 353
• Angabe, ob der AUTH-Block an die nachfolgende Applikation übergeben wird oder nicht. 354
• Angabe, ob die Personenbindung an die nachfolgende Applikation übergeben wird oder 355 nicht. 356
• Angabe, ob die Schnittstelle zur nachfolgenden Applikation mit TLS-Client- und/oder 357 TLS-Server-Authentisierung geschützt werden muss. 358
o verwendetes TLS-Server-Zertifikat 359
o akzeptierte TLS-Client-Zertifikate der nachfolgenden Applikation 360
o vertrauenswürdige Wurzelzertifikate für akzeptierte TLS-Client-Zertifikate der 361 nachfolgenden Applikation 362
2002-10-0 MOA ID 1.0 Seite 19/29
Mehrere nachfolgende Applikationen müssen innerhalb derselben 363 Authentisierungskomponente konfiguriert werden können. Die im Aufruf übergebene URL 364 der nachfolgenden Applikation (siehe Abschnitt 5.1 Schnittstelle zur verweisenden 365 Webseite) wird zur Auswahl der Konfiguration herangezogen. Ein eindeutiges Präfix der URL 366 der nachfolgenden Applikation muss deshalb als Schlüssel verwendet werden. Die URL muss 367 zumindest aus https:// und einem gültigen Domänen-Namen bestehen. 368
5.7 Funktionsbeschreibung 369
5.7.1 Überprüfung der Signatur der Personenbindung 370
Die Überprüfung der Signatur der Personenbindung erfolgt gemäß der Spezifikation für die 371 Personenbindung [PersBind]. Die Überprüfung wird mittels des Kommandos 372 <VerifyXMLSignatureRequest> des MOA-Modul für Signatur-Prüfung mit folgenden 373 verpflichtenden Eingangs-Parametern durchgeführt: 374
<VerifySignatureInfo> enthält die signierte Personenbindung
<SignatureManifestCheckParams> Das Attribut ReturnReferenceInputData muss auf false gesetzt sein
<TrustProfileID> Eine Referenz auf ein Profil von Wurzelzertifikaten
375
Anschließend wird überprüft ob die Personenbindung mit einem für die Personenbindung 376 zugelassenem Zertifikat signiert wurde. 377
5.7.2 Überprüfung des signierten AUTH-Blocks 378
Die Überprüfung der Signatur wird mittels des Kommandos <VerifyXMLSignatureRequest> 379 des MOA-Modul für Signatur-Prüfung mit folgenden verpflichtenden Eingangs-Parametern 380 durchgeführt: 381
<VerifySignatureInfo> enthält den signierten AUTH-Block
<SignatureManifestCheckParams> Das Attribut ReturnReferenceInputData muss auf true gesetzt sein.
<ReturnHashInputData> muss enthalten sein
<TrustProfileID> Eine Referenz auf ein Profil von Wurzelzertifikaten
382
Der AUTH-Block muss mit einem privaten Schlüssel des Benutzers signiert sein, dessen 383 korrespondierender öffentliche Schlüssel Teil der Personenbindung ist. 384
2002-10-0 MOA ID 1.0 Seite 20/29
6 Proxykomponente 385
Die Proxykomponente ermöglicht eine einfache Anbindung bestehender Online-Applikationen 386 an den Authentisierungs-Mechanismus des MOA Identifikationsmoduls, indem es: 387
• die SAML-Struktur von der Authentisierungskomponente anfordert, um die Identität des 388 Benutzers zu sichern 389
• eine einmalige Authentisierung an der Online-Applikation vornimmt („stateful“ Online-390 Applikation) oder die Login-Parameter bei jedem Zugriff auf die Online-Applikation 391 übergibt („stateless“ Online-Applikation). 392
• die Online-Applikation durch transparentes Proxying vor nicht authentisierten Zugriffen 393 schützt. 394
6.1 Schnittstelle zum Aufbau des Requests an die Online-395
Applikation 396
Zum Aufbau des Requests an die Online-Applikation muss innerhalb der Proxykomponente eine 397 Klasse aufgerufen werden, die folgendes Interface implementiert. Die implementierende Klasse 398 muss in der Proxykomponente global konfiguriert werden können. Die Proxykomponente muss 399 eine Default-Implementierung bereitstellen, die die im Abschnitt 6.5 Konfiguration 400 beschriebenen Konfigurationsmöglichkeiten abdeckt. 401
public interface ConnectionBuilder { 402 /** 403 * Build an URLConnection object which can be used to send a request to the 404 * remote web application (the ‘online application’). 405 * 406 * @param request The incoming request which shall be proxied. 407 * @param destinationUrl The destination URL for the outgoing request. 408 * @return An URLConnection to query the remote web application. 409 */ 410 public URLConnection buildRequest(HttpServletRequest request, 411 String destinationUrl); 412 } 413 414
6.2 Schnittstelle zur Online-Applikation 415
Online-Applikationen werden unterschieden in stateless und stateful Online-Applikationen. 416
Stateless Online-Applikationen verlieren alle Benutzerinformation, wenn die Verbindung 417 abgebaut wird (typischerweise am Ende eines HTTP-Requests). Es ist also notwendig, 418 Benutzerinformatin (z.B. VPK) bei jedem Request mitzugeben. 419
Stateful Online-Applikationen behalten die Benutzerinformation auch wenn die Verbindung 420 abgebaut wird. Üblicherweise werden für stateful Online-Applikationen Cookies eingesetzt. 421 Benutzerinformation ist also nur beim Session-Aufbau notwendig. 422
Aus Sicht der Proxykomponente sind stateful Online-Applikationen eine Untermenge (ein 423 Spezialfall) von stateless Online-Applikationen. Damit ist das Session-Handling der Online-424 Applikation (Timeout, etc.) für die Proxykomponente transparent. 425
6.2.1 Typisches Setup für stateless Online-Applikationen 426
Bei stateless Online-Applikationen muss jeder HTTP-Request und die dazugehörige Antwort der 427 Online-Applikation durch die Proxykomponente gehen. Um performance-kritisches URL-428 Rewriting zu vermeiden, muss folgende Lösung verwendet werden: 429
• Der DNS-Eintrag der Online-Applikation verweist auf die Proxykomponente 430
2002-10-0 MOA ID 1.0 Seite 21/29
• Die Proxykomponente kennt zu jedem DNS-Eintrag die wirkliche Adresse der Online-431 Applikation 432
• Die Online-Applikation ist mittels Virtual Hosting so konfiguriert, dass sie Requests, die 433 auf den nach außen sichtbaren Domänen-Namen der Online-Applikation lauten, 434 entgegennimmt 435
6.2.2 Typisches Setup für stateful Online-Applikationen 436
• Die Proxykomponente und die Online-Applikation haben unterschiedliche DNS-Namen, 437 wobei einer der Namen eine Subdomain der anderen ist. 438
• Der erste Zugriff nach dem Authentisierungsvorgang erfolgt auf eine „Login-URL“, deren 439 DNS-Name auf die Proxykomponente auflöst. Die Proxykomponente leitet wie im Fall 440 einer stateless Online-Applikation den Request an die Online-Applikation weiter (die 441 Online-Applikation muss also auch per Virtual Hosting diese URL auflösen können). 442
• Das Login-Script der Online-Applikation prüft, ob der Request von der 443 Proxykomponente kommt. Wenn ja, baut sie die Session auf (z.B. durch Setzen eines 444 Cookies seitens der Online-Applikation im Browser des Benutzers, das für die Domäne 445 der Online-Applikation gültig ist). Enstprechendes Firewall-Setup vorausgesetzt genügt 446 ein einfaches Prüfen der IP-Adresse. 447
• Von diesem Zeitpunkt an gehen alle Requests an der Proxykomponente vorbei direkt an 448 die Online-Appliktion, da der Benutzer an eine entsprechende Session gebunden ist. 449
• Um das Problem des Timeouts bzw. des Logout zu umgehen, besitzt die 450 Proxykomponente ein sehr kurzes Timeout (Sekunden bzw. Minutenbereich). Das 451 Session-Management obliegt ganz der Online-Appliktion. 452
6.3 Schnittstelle zum Browser des Benutzers 453
Die Proxykomponente verfügt über eine eigene HTTP-Session mit dem Benutzer, in der 454 folgende Informationen server-seitig hinterlegt werden: 455
• Die Anmeldedaten des Benutzers 456
6.4 Proxy-Funktion 457
Die Proxykomponente muss bei stateless Online-Applikationen als transparenter Proxy zur 458 Online-Applikation fungieren: 459
• Alle Requests zur Online-Applikation müssen von der Proxykomponente auf ihre 460 Berechtigung geprüft werden: ein direkter Zugriff ohne vorherige Verwendung der 461 Authentisierungskomponente darf nicht möglich sein. 462
• Alle Requests müssen mit allen Parametern zur Online-Applikation weitergeleitet 463 werden. Ausnahme: die in der Konfiguration der Online-Applikation angegebenen Login-464 Parameter müssen gefiltert werden. Im Falle einer stateless Online-Applikation müssen 465 die Login-Parameter bei jedem Request mitgegeben werden. 466
• Die von der Online-Applikation generierte Antwort muss unverändert an den Benutzer 467 zurückgegeben werden. 468
6.5 Konfiguration 469
6.5.1 Konfiguration in der Proxykomponente 470
Für die Proxykomponente muss folgende Konfiguration durchgeführt werden können: 471
• Angabe des HTTP-Session-Timeout des Benutzers in der Proxykomponente. Nach einem 472 Ablauf der Session ist der Benutzer nicht mehr an der Proxykomponente authentisiert. 473
2002-10-0 MOA ID 1.0 Seite 22/29
Alle server-seitig in der Session gespeicherten Benutzerdaten müssen gelöscht werden. 474
• Angabe der Klasse, die das LoginParameterResolver Interface implementiert 475 (optional) 476
Folgende Daten müssen für die Kommunikation mit der Authentisierungskomponente 477 konfigurierbar sein: 478
• Konfiguration ob die Kommunikation mit der Authentisierungskomponente via SOAP- 479 oder via API-Aufrufe erfolgen soll. 480
• Angabe, ob die Schnittstelle zur Authentisierungskomponente mit TLS-Client und/oder 481 TLS-Server-Authentisierung geschützt werden muss. 482
o verwendetes TLS-Client-Zertifikat 483
o akzeptierte TLS-Server-Zertifikate der Authentisierungskomponente 484
o vertrauenswürdige Wurzelzertifikate für akzeptierte TLS-Server-Zertifikate der 485 Authentisierungskomponente 486
In der Proxykomponente müssen je Online-Applikation folgende Konfigurationsmöglichkeiten 487 gegeben sein: 488
• Eine optionale URL der Konfigurationsdatei für die Online-Applikation (siehe nächster 489 Abschnitt). Falls die URL nicht angegeben ist, wird implizit folgende URL angenommen: 490 http://<oa-domain>/moaconfig.xml, wobei <oa-domain> die nach außen sichtbare 491 Domäne der Online-Applikation angibt. 492
• Das Mapping des nach außen sichtbaren Domänen-Namens (<oa-domain>) auf die 493 wirkliche Domäne der Online-Applikation. 494
• Angabe, ob die Schnittstelle zur Online-Applikation mit TLS-Client und/oder TLS-Server-495 Authentisierung geschützt werden muss. 496
o verwendetes TLS-Client-Zertifikat 497
o akzeptierte TLS-Server-Zertifikate der Online-Applikation 498
o vertrauenswürdige Wurzelzertifikate für akzeptierte TLS-Server-Zertifikate der 499 Online-Applikation 500
Ein eindeutiges Präfix der URL der Online-Applikation muss deshalb als Schlüssel verwendet 501 werden. Die URL muss zumindest aus https:// und einem gültigen Domänen-Namen 502 bestehen. 503
6.5.2 Konfiguration der Online-Applikation 504
Die Konfigurationsdatei beschreibt die Art und Weise, wie die Proxykomponente die Anmeldung 505 an der Online-Applikation durchführt. Die Lage der Konfigurationsdatei wird in der 506 Konfiguration der Proxykomponente als URL hinterlegt. Die Konfigurationsdatei soll 507 standardmäßig vom Web-Server der nachfolgenden Applikation geladen werden. 508
Die Konfigurationsdatei ist eine XML-Datei, deren Format in [MOA-ID Config Schema] 509 beschrieben ist, und die folgende Element enthält: 510
Name Beschreibung
login-type Gibt an, ob die Online-Applikation ein einmaliges Login erwartet (stateful), oder ob die Login-Parameter bei jedem Request mitgegeben werden müssen (stateless). Im Fall einer stateful Online-Applikation werden die in der HTTP-Session der Proxykomponente gespeicherten Anmeldedaten nur für den Aufruf des Login-Scripts verwendet. Unmittelbar nach dem Aufruf müssen sie gelöscht werden.
param-auth Konfiguriert die Übergabe der Authentisierungs-Parameter an die Online-Applikation mittels URL-Parametern.
2002-10-0 MOA ID 1.0 Seite 23/29
basic-auth Konfiguriert die Übergabe der Authentisierungs-Parameter an die Online-Appliktion mittels HTTP Basic Authentication.
header-auth Konfiguriert die Übergabe der Authentisierungs-Parameter an die Online-Applikation in HTTP Request Headern.
6.5.2.1 Login mittels URL-Parameter 511
Das Element <param-auth> enthält eine Aufzählung von <parameter> Elementen, die folgende 512 Attribute besitzen: 513
Name Beschreibung
Name Beschre ibt den Namen des Parameters und ist ein frei zu wählender String.
Value Beschreibt den Inhalt des Parameters und kann einen der durch MOAAuthDataType beschriebenen Werte annehmen.
514
Anhand der <parameter>-Elemente wird der Request für den Login-Vorgang (für stateful 515 Online-Applikationen) folgendermaßen zusammengestellt: 516
GET https://<login-url>?<p1.name=p1.resolvedValue>&<p2.name=p2.resolvedValue>... 517
Die <login-url> ergibt sich aus dem Parameter OA des ursprünglichen Requests an die 518 Authentisierungskomponente (siehe 5.1 Schnittstelle zur verweisenden Webseite). Der Wert 519 resolvedValue wird in der Proxykomponente je nach Wert des Platzhalters eingesetzt. 520
6.5.2.2 Login mittels Basic Authentication 521
Das Element <basic-auth> enthält folgende 2 Elemente, die die UserId und das Passwort 522 spezifizieren und für eine Basic Authentication analog [HTTP-Auth] angeben: 523
Name Beschreibung
Userid Die UserId des zu authentisierenden Benutzers; kann einen der durch MOAAuthDataType beschriebenen Werte annehmen.
Password Das Passwort des zu authentisierenden Benutzers; kann einen der durch MOAAuthDataType beschriebenen Werte annehmen.
Aus diesen Angaben müssen je nach Wert der Platzhalter die entsprechenden HTTP-Header für 524 die Basic Authentication erstellt und in den HTTP-Request an die Online-Applikation eingefügt 525 werden. 526
6.5.2.3 Login mittels HTTP Request Header 527
Das Element <header-auth> enthält eine Aufzählung von <header> Elementen, die folgende 528 Attribute besitzen: 529
Name Beschreibung
Name Beschreibt den Namen des Headers und ist ein frei zu wählender String.
Value Beschreibt den Inhalt des Headers und kann einen der durch MOAAuthDataType beschriebenen Werte annehmen.
Die Header werden folgendermaßen in den Request an die Online-Applikation eingefügt: 530
<h1.name>:<h1.resolvedValue> 531
<h2.name>:<h2.resolvedValue> 532
... 533
Der Wert resolvedValue wird in der Proxykomponente je nach Wert des Platzhalters 534 eingesetzt. Etwaige Header aus dem ursprünglichen Request an die Proxykomponente, die den 535
2002-10-0 MOA ID 1.0 Seite 24/29
selben Namen haben, müssen überschrieben werden. 536
6.5.2.4 MOAAuthDataType 537
Der Typ MOAAuthDataType dient an vielen Stellen der in diesem Abschnitt beschriebenen 538 Konfiguration als Platzhalter für Anmeldedaten des Benutzers. Im Zuge des Anmeldevorgangs 539 an der Online-Applikation müssen diese Platzhalter durch die entsprechenden Anmeldedaten 540 des Benutzers ersetzt werden. Folgende Platzhalter sind definiert: 541
• MOAGivenName: der Vorname des Benutzers, wie in der PB enthalten 542
• MOAFamilyName: der Nachname des Benutzers, wie in der PB enthalten 543
• MOADateOfBirth: das Geburtsdatum des Benutzers, wie in der PB enthalten 544
• MOAVPK: die VPK des Benutzers, wie von der Authentisierungskomponente 545
• MOAPublicAuthority: wird durch true ersetzt, falls es sich um einen Benutzer einer 546 Behörde handelt, andernfalls wird false gesetzt 547
• MOABKZ: das Behördenkennzeichen (nur sinnvoll, wenn MOAPublicAuthority den Wert 548 true ergibt) 549
• MOAQualifiedCertificate: wird durch true ersetzt, falls das Zertifikat des Benutzers 550 qualifiziert ist, andernfalls wird false gesetzt 551
• MOAZMRZahl: die ZMR-Zahl des Benutzers; diese ist nur dann verfügbar, wenn die 552 Online-Applikation die ZMR-Zahl bekommen darf (und daher in der Personenbindung 553 enthalten ist). 554
• MOAIPAddress: die IP-Adresse des Client des Benutzers 555
2002-10-0 MOA ID 1.0 Seite 25/29
7 Definition der Schnittstelle zwischen Authentisie-556
rungskomponente und nachfolgenden Applikation 557
Über eine echte Client/Server-Schnittstelle verfügt nur die Authentisierungskomponente. 558 Deren spezifizierte Funktionalität (die Abfrage der Identität) kann sowohl über SOAP (für 559 Aufrufe über das Netzwerk) als auch über API Aufrufe verwendet werden. 560
7.1 SOAP 561
Im Dokument [SAML-Binding], Abschnitt 3, ist die Bindung von SAML-Anfragen an SOAP 562 beschrieben. Dieses Binding muss zur Anfrage an die Authentisierungskomponente verwendet 563 werden. 564
[MOA-ID WSDL] beschreibt die MOA-Schnittstelle bei Verwendung als Web-Service mit SOAP 565 als Transportprotokoll. Aus dem WSDL-Dokument können mit geeigneten Tools Client-Stub- 566 und Server-Tie-Objekte generiert werden. 567
Die SOAP Spezifikation basiert auf SOAP Version 1.1 [SOAP], die WSDL Spezifikation auf WSDL 568 Version 1.1 [WSDL]. 569
Das Dokument folgt dem hierarchischen Aufbau von WSDL-Dokumenten (siehe [WSDL] 570 Abschnitt 1). 571
7.1.1 Beispiele für SOAP Messages 572
Beispiele für SOAP Requests und Response Messages zur Abfrage der SAML-Struktur sind 573 ebenfalls in [SAML-Binding], Abschnitt 3, beschrieben. 574
7.1.1.1 Response im Fehlerfall: 575
<SOAP-ENV:Envelope 576 xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/“ 577 SOAP-ENV:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/“> 578 <SOAP-ENV:Body> 579 <SOAP-ENV:Fault> 580 <faultcode>SOAP-ENV :Server</faultcode> 581 <faultstring>Server Error</faultstring> 582 <detail> 583 <moa:ErrorResponse 584 xmlns:moa=“http://reference.e-government.gv.at/namespace/moa/20020822#“> 585 <ErrorCode>2000</ErrorCode> 586 <Info>Fehler im MOA Modul</Info> 587 </moa:ErrorResponse> 588 </detail> 589 </SOAP-ENV:Fault> 590 </SOAP-ENV:Body> 591 </SOAP-ENV:Envelope> 592 593
7.2 API 594
Die in [MOA-ID WSDL] definierten Aufrufe sind in geeigneten Java Interfaces modelliert. Die 595 Art der Modellierung orientiert sich an der im Package javax.xml.soap definierten Interfaces 596 ohne diese jedoch direkt zu referenzieren. 597
Die Server-seitige Schnittstelle ist durch das Interface IdentificationService definiert. 598
Die Definitionen der weiteren verwendeten Interfaces sind in [MOA-ID API] dokumentiert. 599
2002-10-0 MOA ID 1.0 Seite 26/29
7.2.1 Interface IdentificationService 600
package at.gv.egovernment.moa; 601 602 /** 603 * Interface providing functions for querying identification data. 604 */ 605 public interface IdentificationService { 606 /** 607 * Get the identification data. 608 */ 609 public GetIdentificationDataResponse 610 getIdentificationData(GetIdentificationDataRequest request) 611 throws MOAException; 612 } 613 614
2002-10-0 MOA ID 1.0 Seite 27/29
8 Referenzen 615
Referenz Titel Verfasser Datum
[MOA-Auftrag] Projekt Module für Online Applikationen (MOA) –Design- und Spezifikationsphase –Auftragsbeschreibung
BMF 05.07.2002
[UC BRZ] Anwendungsfälle Spezifikation, Version 4.1 BRZ 03.09.2002
[SecLayer1.1] Schnittstellenspezifikation Security-Layer Version 1.1; http://www.buergerkarte.at/konzept/ securitylayer/spezifikation/20020831/
CIO 31.08.2002
[SecLayer1.1-Bindung]
Bindung des Schnittstellenprotokolls des Security-Layers für das Konzept Bürgerkarte an Transportprotokolle, Version 1.1; http://www.buergerkarte.at/konzept/ securitylayer/spezifikation/20020831/
CIO 31.08.2002
[PersBind] XML Definition der Personenbindung, Version 1.1; http://www.buergerkarte.at/konzept/ personenbindung/spezifikation/20020506
CIO 06.05.2002
[OID] Object Identifier und Einsatz in X.509 Zertifikaten, Version 1.1
CIO 06.08.2002
[GB] e-Government Geschäftsbereiche, Version 1.0; http://reference.e-government.gv.at/uploads/ media/gb-1-0-20020524.pdf
24.05.2002
[GB-BK] e-Government verwaltungsinterne Geschäftsbereiche - Spezifikation für den Datenschutz und die verwaltungsbereich-spezifisch abgeleitete Personenkennzeichnung, Version 1.0; http://reference.e-government.gv.at/uploads/ media/gb-bk-1-0-20020524_02.pdf
24.05.2002
[MOA-ID Config Schema]
Datei „MOA ID Config.xsd“ ARGE 06.08.2002
[MOA-ID WSDL]
Datei „MOA ID.wsdl ARGE 14.08.2002
[MOA-ID API] Java Package at.gv.egovernment.moa ARGE 23.08.2002
[HTTP-Auth] HTTP Authentication: Basic and Digest Access Authentication, IETF RFC 2069
IETF 06.1999
[SAML-Assertions]
Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML), Committee Specification 01; http://www.oasis-open.org/committees/ security/docs/cs-sstc-core-01.pdf
OASIS 31.05.2002
[SAML-Binding]
Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML), Committee Specification 01; http://www.oasis-open.org/ committees/ security/cs-sstc-bindings-01.pdf
OASIS 31.05.2002
[TLS] The TLS Protocol V.1.0, IETF RFC 2046 IETF 01.1999
2002-10-0 MOA ID 1.0 Seite 28/29
[RFC3061] A URN Namespace of Object Identifiers; IETF RFC 3061; http://www.ietf.org/rfc/rfc3061.txt
IETF 02.2001
[SOAP] Simple Object Access Protocol (SOAP) V.1.1 W3C 08.05.2000
[WSDL] Web Services Description Language (WSDL) V.1.1
W3C 15.03.2001
[XMLDSig] XML-Signature Syntax and Processing; http://www.w3.org/TR/xmldsig-core/
W3C 12.02.2002
616
2002-10-0 MOA ID 1.0 Seite 29/29
9 Anhang – Nicht-Spezifizierte Funktionalität 617
Dieser Abschnitt beschreibt welche Funktionalität, die in [MOA-Auftrag] gefordert wird, dzt. 618 nicht spezifiziert wurde. 619
Ad 3. Vertraulichkeitsstufe I muss nicht unterstützt werden 620
Ad 5. Es wird nicht der AUTH-Block sondern die Anmeldedaten an nachfolgende Applikationen 621 weitergegeben – diese Weitergabe muss nicht bestätigt (signiert) erfolgen 622
Ad 7. Die Identifizierung muss nur mittels des AUTH-Blocks und des Security-Layers erfolgen 623
Ad 8. wird als Anforderung gestrichen 624
Ad 9. wird als Anforderung gestrichen 625
