Logo BMÖLS Open Interfaces
für das eGovernment
Logo A-SIT

Security-Layer für das Konzept Bürgerkarte

Bindung an Transportprotokolle


Dokumenteninformation

Bezeichnung Bindung des Schnittstellenprotokolls des Security-Layers für das Konzept Bürgerkarte an Transportprotokolle
Kurzbezeichnung Transportprotokolle Security-Layer
Version 1.0.3
Datum 31. 08. 2002
Dokumentklasse Konvention
Dokumentstadium Öffentlicher Entwurf
Kurzbeschreibung Die Schnittstellenspezifikation Security-Layer definiert die Struktur der XML-Kommandos und die notwendige Funktionalität der Kommandos. Dieses Dokument beschreibt, wie diese XML-Kommandos in eine Reihe von Transportprotokollen eingebunden werden können.
Autoren Arno Hollosi (arno.hollosi@cio.gv.at)
Gregor Karlinger (gregor.karlinger@cio.gv.at)
Arbeitsgruppe BMÖLS, CIO des Bundes, Operative Unit
© Diese Spezifikation wird von A-SIT und dem BMÖLS zur Verfügung gestellt. Die Verwendung ohne Modifikation ist unter Bezugnahme auf diese Copyright-Notiz zulässig. Eine Erweiterung der Spezifikation ist erlaubt, jedoch muss dies eindeutig gekennzeichnet sein, und es muss die erweiterte Spezifikation frei zur Verfügung gestellt werden.

Inhalt

  1. Einleitung
  2. TCP/IP - Bindung
    1. Bezeichner und Parameter
    2. Environment-Variablen
    3. Ablauf
    4. Kodierung
    5. Anmerkungen
  3. HTTP - Bindung
    1. Bezeichner und Parameter
    2. Environment-Variablen
    3. Ablauf
    4. Kodierung
    5. Anmerkungen
    6. Beispiele
  4. SSL/TLS - Bindung
    1. Bezeichner und Parameter
    2. Environment-Variablen
    3. Ablauf
    4. Kodierung
    5. Anmerkungen
  5. HTTPS - Bindung
    1. Bezeichner und Parameter
    2. Environment-Variablen
    3. Ablauf
    4. Kodierung
    5. Anmerkungen
  6. Referenzen
  7. Historie

1. Einleitung

Die Kernspezifikation des Security-Layer definiert die Struktur der XML-Kommandos und die notwendige Funktionalität der Kommandos. Dieses Dokument beschreibt, wie diese XML-Kommandos in bestimmte Transportprotokolle eingebunden werden können. Das Blockbild unten zeigt die prinzipielle Struktur der Security-Kapsel. Die XML-Kommandos werden über verschiedene Module an Transportprotokolle gebunden, im Bild z.B. an TCP/IP und HTTP. Die Module sorgen für die notwendige Umsetzung und Kodierung - die funktionalen Module der Security-Kapsel arbeiten nur mit den definierten XML-Kommandos und sind gegenüber dem Transport und den Eigenschaften des verwendeten Protokolls ignorant.

Die Adresse der Bindungen ist im Allgemeinen durch den verwendeten Internet-Socket bestimmt. Die Socket-Adresse besteht aus zwei Teilen: IP-Adresse und Portnummer. Für jede Bindung wird eine Default-IP-Adresse (bzw. DNS-Name) sowie eine Default-Portnummer spezifiziert. Um möglichst flexibel zu sein, kann von den Standard-Default-Adressen durch entsprechende Angabe von lokalen Environment-Variablen am Rechner abgewichen werden. Implementation der Security-Kapsel müssen die Environment-Variablen auf die Werte für ihre Bindungen setzen, selbst wenn diese deckungsgleich mit den Standardvorgaben sind.

Sofern Bindungen über die Art der übertragenen Daten unterschieden werden können, ist es möglich, dass Bindungen denselben Port benützen. Im besonderen wird darauf hingewiesen, dass sich die TCP/IP-Bindung und die HTTP-Bindung eine Adresse teilen können müssen, sowie die TLS und HTTPS Bindung. Die Internet Assigned Numbers Authority (IANA) hat für den Security-Layer zwei Ports reserviert [port-numbers].

Für Informationen, welche der in diesem Dokument beschriebenen Bindungen von einer Implementation verpflichtend zur Verfügung gestellt werden müssen, um dem Konzept Bürgerkarte zu genügen, siehe das Dokument Minimalanforderungen Security-Layer.

2. TCP/IP - Bindung

Die TCP/IP-Bindung ist eine 1:1 Umsetzung der Security-Layer-Kommandos. Es wird eine übliche TCP/IP-Verbindung über Sockets benutzt. Die definierten Kommandos werden ohne weitere Kodierung oder Umsetzung/Einbettung in der Verbindung übertragen.

2.1. Bezeichner und Parameter

Bezeichner und Parameter der Bindung werden im GetPorpertiesResponse übergeben.

Der Bezeichner dieser Bindung ist "TCP/IP".

Parameter der Bindung: keine

2.2. Environment-Variablen

2.3. Ablauf

  1. Die Security-Kapsel öffnet das Service am angegebenen Port und wartet auf eingehende Verbindungen
  2. Eine Applikation liest die Environmentvariablen aus (bzw. benützt die Default-Werte) und öffnet eine Verbindung zur angegebenen Adresse
  3. Die Applikation überträgt den XML-Request
  4. Die Security-Kapsel arbeitet den Request ab und schickt eine Response.
  5. Die Security-Kapsel schließt die Verbindung.

2.4. Kodierung

Keine weitere Kodierung. Die XML-Kommandos werden 1:1 in der Verbindung übertragen.

2.5. Anmerkungen

Die TCP/IP-Bindung bietet weder Authentifizierung der anfragenden Applikation, noch bietet sie Vertraulichkeit (Verschlüsselung) der Kommunikation. Applikationen können ausschließlich über die IP-Adresse unterschieden werden, was jedoch nicht ausreichend Schutz bietet. Aus diesem Grund wird stark empfohlen, dass diese Bindung nur Verbindung zulässt die vom lokalen Rechner (127.0.0.1) kommen.

3. HTTP - Bindung

Die HTTP-Bindung bietet Webbrowsern und anderen Web-fähigen Applikationen die Möglichkeit direkt - ohne weitere aktive Komponenten - auf die Funktionen der Security-Kapsel zuzugreifen. Dazu ist eine entsprechende Kodierung als HTTP-Request erforderlich.

3.1. Bezeichner und Parameter

Bezeichner und Parameter der Bindung werden im GetPorpertiesResponse übergeben.

Der Bezeichner dieser Bindung ist "HTTP".

Parameter der Bindung: keine

3.2. Environment-Variablen

3.3. Ablauf

  1. Die Security-Kapsel öffnet das Service am angegebenen Port und wartet auf eingehende Verbindungen
  2. Eine Applikation liest die Environmentvariablen aus (bzw. benützt die Default-Werte) und setzt einen entsprechenden HTTP-POST bzw. HTTP-GET kodierten Request zur angegebenen Adresse ab
  3. Ist eine Redirect-URL angegeben schickt die Security-Kapsel als Antwort einen HTTP-Redirect (HTTP Code: 303) und schließt die Verbindung
  4. Die Security-Kapsel bearbeitet den Request
  5. Ist eine Data-URL angegeben schickt die Security-Kapsel die Response als HTTP-POST kodiert an die angegebene URL. Sendet der Server einen HTTP-Code 200 als Antwort setzt die Verarbeitung fort. Antwortet der Server mit einer Fehlermeldung (z.B. HTTP-Code 404) gibt die Security-Kapsel eine entsprechende Fehlermeldung aus und bricht die Verarbeitung ab.
  6. Ist eine Stylesheet-URL angegeben liest die Security-Kapsel einen XSL-Stylesheet von der angegebenen Adresse und transformiert damit die Response der Kapsel
  7. Ist keine Redirect-URL angegeben schickt die Security-Kapsel eine HTTP kodierte (und eventuell transformierte) Response in der Verbindung und schließt die Verbindung

3.4. Kodierung

Die XML-Requests werden entsprechend [RFC2616] HTTP kodiert. Damit entspricht die Kodierung dem Fall der HTML-Form Daten (application/x-www-form-urlencoded). Der Request kann wahlweise als HTTP-GET oder HTTP-POST erfolgen. (Anmerkung: manche Webclients unterstützen nur eine limitierte Grösse der HTTP-GET Requests).

Der Request hat an die URL "/http-security-layer-request" zu erfolgen. (Über die URL können zukünftig verschiedene Requesttypen unterschieden werden). Bei einem Request einer unbekannten URL ist entsprechend eine HTTP-404 Meldung auszugeben.

Folgende Felder werden angegeben:

XMLRequest: (zwingend)
enthält den Security-Layer XML-Request.
RedirectURL: (optional)
enthält eine URL, die die Security-Kapsel als Antwort auf den Request in einem HTTP 303-Redirect schicken soll (Schritt 3 des Ablaufes). Dies dient dem Zweck, dass Webbrowser wieder auf eine Seite gelenkt werden können, die von der Applikation kontrolliert wird.
DataURL: (optional)
enthält eine URL, an die die Security-Kapsel die XML-Antwort in Form eines HTTP-POST schicken soll. Der Empfangsserver schickt im Falle der fehlerfreien Übernahme der Daten eine "HTTP 200 OK" Antwort. Im Fehlerfall entsprechend dem Fehler einen anderen HTTP-Fehlerkode. Als Protokolle sind verpflichtend HTTP und HTTPS zu unterstützen.
StylesheetURL: (optional)
enthält eine URL, von der die Security-Kapsel einen XSL-Stylesheet liest. Mit diesem Stylesheet wird die XML-Antwort der Security-Kapsel transformiert (Schritt 6 des Ablaufs) und an den Browser zurückgeschickt (Schritt 7). Das Transformationsergebnis hat vom Typ "text/html" zu sein.

Die Response der Security-Kapsel an die Data-URL in Schritt 5 ist ebenfalls HTTP-POST kodiert. Sie enthält die Felder ResponseType und XMLResponse. ResponseType wird auf den Wert "HTTP-Security-Layer-RESPONSE" gesetzt.

3.5. Anmerkungen

Die HTTP-Bindung bietet weder Authentifizierung der anfragenden Applikation, noch bietet sie Vertraulichkeit (Verschlüsselung) der Kommunikation. Applikationen können über die IP-Adresse und die Daten-URL unterschieden werden, was je nach Anwendungsfall ausreichen kann, im Allgemeinen jedoch nicht ausreichend Schutz bietet. Aus diesem Grund wird stark empfohlen, dass diese Bindung nur Verbindung zulässt die vom lokalen Rechner (127.0.0.1) kommen und die Nutzern die Möglichkeit der Beschränkung (bzw. Bestätigung) der Senden von Daten an eine externe Data-URL bietet.

Verpflichtend zu unterstützende Protokolle für Kommunikation mit der Data-URL und der Stylesheet-URL sind HTTP und HTTPS.

3.6 Beispiele

POST /http-security-layer-request HTTP/1.1
Host: localhost:20012
Content-type: application/x-www-form-urlencoded
Content-Length: 322

XMLRequest=%3C%
3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22
%3F%3E%0D%0A%3CInfoboxReadRequest%3E%0D%0A%3CInfoboxIde
ntifier%
3EInfobox1%3C%2FInfoboxIde
ntifier%3E%0D%0A%3C%2FInfoboxReadRequ
est%3E%0D%0A%0D%0A&RedirectURL=http%3A%2F%2Fredirect.me.to%2Fpa
usenfueller.html&DataURL
=http%3A%2F%2Fpost.data.here%2Freaddata
.script

Request der Applikation (Punkt 2 des Ablaufs)

 

HTTP/1.1 303 See other
Server: Security-Kapsel/FastProtoType/1.0
Date: Fri, 13 Nov 2001 07:28:23 GMT
Connection: close
Location: http://redirect.me.to/pausenfueller.html
Content-Length: 127
Content-Type: text/html

<HTML><BODY>Please go to
<A HREF="http://redirect.me.to/pausenfueller.html">Pausenfueller</A>.
</BODY></HTML>
Redirect an Applikation (Punkt 3 des Ablaufs)

 

POST /readdata.script HTTP/1.1
Host: post.data.here
Content-type: application/x-www-form-urlencoded
Content-Length: 236

ResponseType=HTTP-Security-Layer-RESPONSE&XMLResponse=%3C%3Fxml+v
ersion%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A%3CInfoboxRe
adResponse%3E%0D%0A%3CInfoboxData%3EInfoboxInhalt+der+Box1%3C%2FI
nfoboxData%3E%0D%0A%3C%2FInfoboxReadResponse%3E%0D%0A
Response an Data-URL (Punkt 5 des Ablaufs)

 

HTTP/1.1 200 OK
Server: Security-Kapsel/FastProtoType/1.0
Date: Fri, 13 Nov 2001 07:28:24 GMT
Connection: close
Content-Length: 127
Content-Type: text/xml

<?xml version="1.0" encoding="UTF-8"?>
<InfoboxReadResponse>
<InfoboxData>Infobox-Inhalt der Box1</InfoboxData>
</InfoboxReadResponse>
Response an Applikation (Punkt 6 des Ablaufs)

4. SSL/TLS-Bindung

Die TLS-Bindung ist eine 1:1 Umsetzung der Security-Layer-Kommandos. Es wird eine übliche TLS-Verbindung [TLS] über Sockets benutzt. Die definierten Kommandos werden ohne weitere Kodierung oder Umsetzung/Einbettung in der Verbindung übertragen.

Die TLS-Bindung entspricht von Ablauf und Aufbau her der TCP/IP-Bindung, mit dem Unterschied, dass das zugrundeliegende Transportprotokoll TLS ist.

4.1. Bezeichner und Parameter

Bezeichner und Parameter der Bindung werden im GetPorpertiesResponse übergeben.

Der Bezeichner dieser Bindung ist "TLS".

Parameter der Bindung: keine

4.2. Environment-Variablen

4.3. Ablauf

Wie in Abschnitt 2.3 der TCP/IP-Bindung, mit dem Unterschied, dass im Punkt 2 beim Aufbau der Verbindung zusätzlich entsprechend TLS ein Handshake und eine Verschlüsselung des Kanales stattfindet.

4.4. Kodierung

Keine weitere Kodierung. Die XML-Kommandos werden 1:1 in der Verbindung übertragen.

4.5. Anmerkungen

Die TLS-Bindung bietet Authentifizierung der anfragenden Applikation und der Security-Kapsel, sowie Vertraulichkeit (Verschlüsselung) der Kommunikation. Damit entspricht diese Bindung erhöhten Sicherheitsanforderungen und bietet ausreichend Schutz um auch Kommunikation über ungesicherte Netzwerke zu gewährleisten.

Die Security-Kapsel kann auch auf Basis der Zertifikate der Applikationen entsprechende Zugriffsrechte vergeben und damit dem Benützer gegenüber für erhöhten Komfort, sowie Unterstützung bei der Sicherheitskonfiguration sorgen.

5. HTTPS-Bindung

Die HTTPS-Bindung bietet wie die HTTP-Bindung Webbrowsern und anderen Web-fähigen Applikationen die Möglichkeit direkt - ohne weitere aktive Komponenten - auf die Funktionen der Security-Kapsel zuzugreifen. Dazu ist eine entsprechende Kodierung als HTTP-Request erforderlich.

Die HTTPS-Bindung entspricht der HTTP-Bindung mit dem Unterschied, dass das zugrundeliegende Protokoll HTTPS [HTTPS] (HTTP mit SSL/TLS [TLS]) ist.

5.1. Bezeichner und Parameter

Bezeichner und Parameter der Bindung werden im GetPorpertiesResponse übergeben.

Der Bezeichner dieser Bindung ist "HTTPS".

Parameter der Bindung: keine

5.2. Environment-Variablen

5.3. Ablauf

Wie in Abschnitt 3.3 der HTTP-Bindung, mit dem Unterschied, dass im Punkt 2 beim Aufbau der Verbindung zusätzlich entsprechend TLS ein Handshake und eine Verschlüsselung des Kanales stattfindet.

5.4. Kodierung

Wie in Abschnitt 3.4 der HTTP-Bindung, mit dem Unterschied,

5.5. Anmerkungen

Die HTTPS-Bindung bietet wie die TLS-Bindung Authentifizierung der anfragenden Applikation und der Security-Kapsel, sowie Vertraulichkeit (Verschlüsselung) der Kommunikation. Damit entspricht diese Bindung erhöhten Sicherheitsanforderungen und bietet ausreichend Schutz um auch Kommunikation über ungesicherte Netzwerke zu gewährleisten.

Die Security-Kapsel kann auch auf Basis der Zertifikate der Applikationen entsprechende Zugriffsrechte vergeben und damit dem Benützer gegenüber für erhöhten Komfort, sowie Unterstützung bei der Sicherheitskonfiguration sorgen.

6. Referenzen

HTTP 1.1
Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1, Juni 1999
http://www.ietf.org/rfc/rfc2616.txt
HTTPS
E. Rescorla: RFC 2818: HTTP over TLS, Mai 2000
http://www.ietf.org/rfc/rfc2818.txt
TLS
T. Dierks, C. Allen: RFC 2246: The Transport Layer Security (TLS) Protocol, Version 1.0, Januar 1999
http://www.ietf.org/rfc/rfc2246.txt
IANA - Port numbers
Internet Assigned Numbers Authority: Port Numbers
http://www.iana.org/assignments/port-numbers

7. Historie

Version 1.0.3 vom 31.08.2002

Version 1.0.2 vom 24.04.2002

Version 1.0.1 vom 18.03.2002