für das eGovernment
|
Open Interfaces für das eGovernment |
|
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.1.0 |
| 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. |
Die Schnittstellenspezifikation 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. Das folgende Blockbild zeigt die prinzipielle Struktur der Bürgerkarten-Umgebung. 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 Bürgerkarten-Umgebung 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 Bürgerkarten-Umgebung MÜSSEN die Umgebungs-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, ebenso wie die TLS und HTTPS Bindung (die Anforderung ergibt sich aus den Default-Werten für die Ports). Die Internet Assigned Numbers Authority (IANA) hat für den Security-Layer zwei Ports reserviert [port-numbers] (siehe Default-Werte in den Abschnitten 2.2, 3.2, 4.2 und 5.2).
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.
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.
Bezeichner und Parameter der Bindung werden im Befehl
GetPropertiesResponse des
Security-Layer verwendet.
Der Bezeichner dieser Bindung ist "TCP/IP".
Parameter der Bindung: keine
CITIZENCARD.Security-Layer.TCPIP.HOST (default: 127.0.0.1)CITIZENCARD.Security-Layer.TCPIP.PORT (default: 3495)Keine weitere Kodierung. Die XML-Kommandos werden 1:1 in der Verbindung übertragen.
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 keinen ausreichenden Schutz bietet. Aus diesem Grund wird EMPFOHLEN, dass diese Bindung nur Verbindungen zulässt, die vom lokalen Rechner (127.0.0.1) kommen.
Es wird EMPFOHLEN, dass die Bürgerkarten-Umgebung den Endanwender über mögliche Risiken der TCP/IP-Bindung informiert (z.B. Help-Text während Abfrage eines PINs für einen Infobox- oder Signatur-Request).
Die HTTP-Bindung bietet Webbrowsern und anderen Web-fähigen Applikationen die Möglichkeit direkt - ohne weitere aktive Komponenten - auf die Funktionen der Bürgerkarten-Umgebung zuzugreifen. Dazu ist eine entsprechende Kodierung als HTTP-Request erforderlich.
Bezeichner und Parameter der Bindung werden im Befehl
GetPropertiesResponse des
Security-Layer verwendet.
Der Bezeichner dieser Bindung ist "HTTP".
Parameter der Bindung: keine
CITIZENCARD.Security-Layer.HTTP.HOST (default: 127.0.0.1)CITIZENCARD.Security-Layer.HTTP.PORT (default: 3495)Anmerkung zur Terminologie: die HTTP-Bindung arbeitet mit HTML Formularfeldern. Speziell ausgezeichnete Formularfelder, die Parameter zur Steuerung des Ablaufes enthalten, werden im folgenden als Formular-Parameter bezeichnet. Felder die zur Weiterreichung von Daten (ausgehend von der Applikation über die Bürgerkarten-Umgebung) zum Server dienen werden als Weitergabe-Felder bezeichnet. Alle anderen Formularfelder werden als weitere Felder bzw. weitere Formularfelder bezeichnet.
Die Applikation übermittelt der Bürgerkarten-Umgebung bei der HTTP-Bindung ein HTML-Formular, das folgende Formularfelder enthält:
XMLRequest (MUSS enthalten sein) - enthält
den Security-Layer XML-RequestRedirectURL (optional) - zur asynchronen Umleitung
der ApplikationDataURL (optional) - Ziel-URL an die das Ergebnis
(die XML-Response) geschickt werden soll. Der
Empfangsserver kann wie in Schritt 5 des Ablaufs beschrieben, verschiedene
Antworten auf den HTTP-POST-Request schicken, die die weitere Abarbeitung
beeinflussen.StylesheetURL (optional) - ein Stylesheet zum
Transformieren des Ergebnisses für eine
Anzeige bei der ApplikationDiese Felder werden als Formularparameter bezeichnet, da sie der Ablaufsteuerung dienen. Das HTML-Formular kann zusätzlich Weitergabe-Felder bzw. weitere Formularfelder enthalten.
Alle HTML-Formularfelder können von einem Security-Layer Befehl aus referenziert werden. Siehe dazu Abschnitt 3.5.
RedirectURL angegeben schickt die Bürgerkarten-Umgebung
als Antwort einen HTTP-Redirect (HTTP Code: 302 oder 303)
und schließt die Browser-Verbindung.XMLRequest Formular-Parameter und
bearbeitet den Request.DataURL angegeben schickt die Bürgerkarten-Umgebung
die XML-Response entsprechend
Kapitel 3.4.2 kodiert mittels HTTP-POST an diese URL. Die Antwort des Servers beeinflusst den Ablauf
wie folgt: <ok/>"
(in exakt dieser Schreibweise): die Verarbeitung setzt
in Schritt 6 fort.XMLRequest
zugewiesen. Die anderen Formular-Parameter bleiben unberührt. Die Verarbeitung
setzt in Schritt 4 fort.XMLRequest
zugewiesen. Die DataURL wird für die folgende Verarbeitung
auf die im Location HTTP-Header enthaltene URL gesetzt. Die
anderen Formular-Parameter (StylesheetURL, RedirectURL
und Weitergabefelder) bleiben unberührt. Die Verarbeitung setzt in
Schritt 4 fort.StylesheetURL angegeben liest die Bürgerkarten-Umgebung
einen XSL-Stylesheet von der angegebenen Adresse und transformiert damit die
XML-Response. Das Transformationsergebnis hat vom Typ text/html zu sein.RedirectURL angegeben schickt die Bürgerkarten-Umgebung
eine (eventuell transformierte) XML-Response in der Browser-Verbindung
und schließt die Browser-VerbindungAnmerkung: Ist eine RedirectURL
angegeben, wird im Schritt 3 die Browser-Verbindung beendet. Sollte also im
Schritt 5 die Notwendigkeit entstehen (z.B. Fall e), Daten an die Browser-Verbindung
weiterzuleiten, kann dieses nicht stattfinden. In diesem Fall, sollte die Bürgerkarten-Umgebung
eine entsprechenden Fehlermeldung ausgeben.
Aus dem beschriebenen Ablauf ergeben sich sinnvolle und nicht sinnvolle Kombinationen der Formularparamter. Die folgende Tabelle gibt eine Übersicht und erläutert kurz die Auswirkung:
| RedirectURL | DataURL | StylesheetURL | Sinnhaftigkeit | Auswirkung |
|---|---|---|---|---|
| - | - | - | Beschränkt sinnvoll | XML-Response wird direkt an aufrufende Applikation geschickt. Nur für Auswertung durch Programme oder Scripts geeignet. Für Endanwender nicht geeignet, da sie mit XML als Klartext konfrontiert werden. |
| - | - | X | Sinnvoll | XML-Response wird nach HTML transformiert und an aufrufende Applikation geschickt. |
| - | X | - | Sinnvoll |
Sinnvoll. XML-Response wird an DataURL geschickt. DataURL sollte entsprechende Antwort für Applikation (z.B. Browser) zurückliefern (Fall 5e). Ansonsten (Fall 5a, der im wesentlichen der Spezifikation 1.0 entspricht), nur beschränkt sinnvoll. XML-Response wird an DataURL und an aufrufende Applikation geschickt. Nur für Programme und Scripts geeignet, da Antwort an Applikation XML als Klartext enthält. |
| - | X | X | Sinnvoll |
Resultat wird an DataURL geschickt, aufrufende Applikation erhält HTML-transformiertes Resultat: entspricht einer synchronen Benutzerführung. Nur sinnvoll, in den Fällen 5a, 5b, 5c. In den Fällen 5d, 5e, 5f ist die Angabe der StylesheetURL nutzlos. |
| X | - | - / X | Nicht sinnvoll | Applikation wird umgeleitet, aber Resultat (XML-Response) kann von niemandem in Empfang genommen werden. |
| X | X | - | Sinnvoll | Applikation erhält sofort einen Redirect, Resultat wird an DataURL geschickt: entspricht einer asynchronen Benutzerführung. |
| X | X | X | Nicht sinnvoll | StylesheetURL ist nutzlos. Stattdessen vorhergehenden Fall verwenden. |
Die HTTP-Requests
der Applikation an die Bürgerkarten-Umgebung werden entsprechend
[RFC2616] HTTP kodiert. Der Request kann wahlweise als HTTP-GET oder HTTP-POST erfolgen;
es MÜSSEN
beide Varianten von der Bürgerkarten-Umgebung unterstützt werden.
(Anmerkung: manche Webclients unterstützen nur eine limitierte Größe
der HTTP-GET Requests). Die Anfrage kann als application/x-www-form-urlencoded
oder als multipart/form-data kodiert werden. Beide Formate MÜSSEN
unterstützt werden.
Die HTTP-Anfrage
MUSS an die URL "/http-security-layer-request"
erfolgen. (Über die URL können zukünftig
verschiedene Requesttypen unterschieden werden). Bei einem Request an
eine unbekannte URL ist eine HTTP-404 Fehlermeldung zurückzuliefern .
Folgende Formularfelder können angegeben werden:
XMLRequestRedirectURLDataURLStylesheetURLAndere Formularfelder im HTTP-Request werden nicht ausgewertet.
Alle Formularfelder des eingehenden HTTP-Requests können vom Security-Layer Befehl aus referenziert werden (siehe Abschnitt 3.5).
Die Response der Bürgerkarten-Umgebung an die DataURL in Schritt 5 ist HTTP-POST kodiert. Sie enthält folgende Formularfelder:
ResponseType: wird immer auf den Wert "HTTP-Security-Layer-RESPONSE"
gesetzt. (Kann in späteren Versionen zur Unterscheidung herangezogen
werden).XMLResponse: enthält die XML-Struktur der
Security-Layer XML-Response.application/x-www-form-urlencoded
vs. multipart/form-data), da zum Beispiel Felder für File-Uploads
nur als multipart/form-data kodiert werden können.Für Zugriffe auf die DataURL und die StylesheetURL
MÜSSEN HTTP und HTTPS als Protokolle
unterstützt werden.
Im Kontext der HTTP-Bindung ist es möglich Formular-Felder, die im HTTP-Request übergeben werden vom Security-Layer Befehl aus zu referenzieren. Dabei können nicht nur die oben definierten Formular-Parameter referenziert werden, sondern beliebige Formularfelder. Mögliche Anwendungsfälle sind das Referenzieren bei den Signaturbefehlen Create(XML|CMS)SignatureRequest und Verify(XML|CMS)SignatureRequest.
URI-Protokoll: formdata
Analog zu Abschnitt "Signatur nach XMLDSig / Anfrage / Ergänzungsobjekte"
der Schnittstellenspezifikation, werden Referenzen, die als Protokoll "formdata"
haben, mit dem übergebenen Inhalt (hier der Inhalt des entsprechenden Formularfelds)
aufgelöst.
Beispiel:
HTML-Formular: <input name="summary" value="Eine kurze Zusammenfassung."
Referenz-URI:
formdata:summaryAuflösen der Referenz ergibt "Eine kurze Zusammenfassung."
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 DataURL unterschieden werden, was je nach Anwendungsfall ausreichen kann, im Allgemeinen jedoch nicht ausreichend Schutz bietet. Aus diesem Grund wird EMPFOHLEN, dass diese Bindung nur Verbindungen zulässt, die vom lokalen Rechner (127.0.0.1) kommen, und dem Benutzer die Möglichkeit zu bieten, selbst zu entscheiden, ob Daten an eine bestimmte DataURL gesendet werden sollen.
Ist die DataURL gesetzt und verwendet das HTTPS-Protokoll(1), kann das Server-Zertifikat der Gegenstelle ausgewertet werden. Dies ist eine verläßliche Methode zur Authentifikation der Gegenstelle. Da das Resultat eines XML-Requests an diese URL gepostet wird, findet eine Authentifikation des Empfängers, nicht aber des Absenders des Requests statt. In der Praxis bietet daher diese Methode ähnlich hohen Schutz vor ungewollter Dateneinsicht und/oder anderen Attacken wie die HTTPS-Bindung (siehe Abschnitt 5). Ein Rechte-Management basierend auf DataURLs erscheint als eine sinnvolle und benutzerfreundliche Sicherheitsmaßnahme.
(1) Auch eine gegebenenfalls gesetzte StylesheetURL sollte in diesem Fall vom gleichen Server originieren. Anderenfalls könnte über den von der StylesheetURL referenzierten Stylesheet (stammt potentiell von einem bösartigen Server) Daten ausgespäht werden.
Die hier angeführten Beispiele sollen lediglich einen Eindruck der Befehle und der Kodierung vermitteln. Sie erheben keinen Anspruch auf Vollständigkeit (zum Beispiel wird die Verwendung eines HTTP-GET Requests nicht demonstriert).
|
POST /http-security-layer-request HTTP/1.1 |
| Request der Applikation als application/x-www-form-urlencoded (Punkt 2 des Ablaufs) |
|
POST /http-security-layer-request HTTP/1.1 |
| Request der Applikation mit Weitergabe-Feldern als multipart/form-data kodiert (Punkt 2 des Ablaufs) |
| HTTP/1.1 302
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: 503 ResponseType=HTTP-Security-Layer-RESPONSE&XMLResponse=%3C%3Fxml+version%3D %221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A%3Csl%3AInfoboxReadResponse+xm lns%3Asl%3D%22http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuritylaye r%2F20020225%23%22%3E%0D%0A%3Csl%3ABinaryFileData%3E%3Csl%3AXMLContent%3E% 0D%0A%3CDocumentText%3EInhalt+einer+einer+Infobox%3C%2FDocumentText%3E%0D% 0A%3C%2Fsl%3AXMLContent%3E%3C%2Fsl%3ABinaryFileData%3E%0D%0A%3C%2Fsl%3AInf oboxReadResponse%3E%0D%0A&ProgramCode_=123%3A667%2Fkx9 |
| Response an DataURL inklusive Weitergabefeld (Punkt 5 des Ablaufs) |
|
HTTP/1.1 200 OK |
| Antwort des Servers auf HTTP-POST auf DataURL (Punkt 5 des Ablaufs) |
|
HTTP/1.1 200 OK |
| Response an Applikation (Punkt 6 des Ablaufs) |
Aus dem beschriebenen Ablauf, der Kodierung und der möglichen Referenzierung von Feldern ergeben sich beispielhaft untenstehende Anwendungsfälle. Mit "v1.0" werden die Möglichkeiten der Spezifikation Version 1.0 des Security-Layer markiert. Mit "v1.1" werden die Möglichkeiten der Spezifikation Version 1.1 des Security-Layer markiert. Generell ist die Version 1.1 vollständig rückwärtskompatibel mit Version 1.0, wenn im Schritt 5 des Ablaufs eine "<ok/>"-Antwort von Serverseite erfolgt (Fall 5a). Alle "v1.0" Fälle gelten also auch für Version 1.1 der Spezifikation.
Die hier beschriebenen Lösungen sind als mögliche Anwendungsszenarien zu verstehen. Für einige der Fälle gibt es auch hier nicht angeführte Alternativen.
Die Eingabefelder des HTML-Formulars werden serverseitig oder clientseitig (JavaScript) in einen XML-Request kodiert. Das so erzeugte Formular wird durch den Anwender an die Bürgerkarten-Umgebung gepostet.
Ab v1.0 (= Fall 5a): DataURL und entweder RedirectURL oder StylesheetURL sind gesetzt. Die Signaturdaten werden automatisch an den Server gesandt. Eventuelle Programmparameter (zum Beispiel Session-ID) können in die DataURL kodiert werden (...?para1=value1¶2=value2...). Der Anwender erhält eine HTML Antwort.
Ab v1.1: Nur Setzen der DataURL, Server sendet Antwort an Anwender (Fall 5e). Eventuelle Programmparameter können in Weitergabe-Feldern enthalten sein.
Ab v1.1: Die Daten-Files werden in Weitergabe-Feldern (Name endet mit '_') im Formular aufgenommen. Die DataURL wird gesetzt. Die Bürgerkarten-Umgebung leitet die Felder entsprechend an den Server weiter. Die Felder (und damit die Files) können auch zum Beispiel in eine Signatur miteinbezogen werden (siehe Abschnitt 3.5). Die Antwort kommt entweder vom Server (Fall 5e), oder alternativ durch Setzen der StylesheetURL oder RedirectURL.
Es wird ein InfoboxReadRequest an die Bürgerkarten-Umgebung abgesetzt. Die Infobox enthält die notwendigen Daten.
Ab v1.0: DataURL und StylesheetURL sind gesetzt. Der Inhalt der Infobox wird an die DataURL gepostet, der vom Server stammende Stylesheet erzeugt ein passendes Formular.
Ab v1.1: nur DataURL setzen. Server bindet Daten in Formular ein und liefert fertiges Formular an Bürgerkarten-Umgebung (Fall 5e).
Ab v1.0: Aufteilen in zwei Arbeitsschritte. Die einzelnen Arbeitsschritte können wie in obigen Fällen ausgeführt werden. Eine gewisse Automatisierung des Ablaufes ist durch Einsatz von Javascript auf der Client-Seite möglich.
Ab v1.1: Befehlskaskadierung: Die Formularfelder, die die eigentlichen Anwender-Eingabedaten enthalten, werden alle als Weitergabe-Felder markiert. Als erster Befehl wird vom Anwender ein InfoboxReadRequest zum Auslesen der Personenbindung abgesetzt. Resultat wird per DataURL an Server gesendet. Dieser empfängt Personenbindung und wertet die Weitergabe-Felder, die die Anwender-Eingabedaten enthalten, aus. Aus diesen Weitergabe-Feldern wird ein entsprechender CreateSignatureRequest erzeugt. Dieser wird als Antwort in die DataURL-Verbindung an die Bürgerkarten-Umgebung geschickt (Fälle 5b, 5c, 5d - 5c erscheint am sinnvollsten). Die Bürgerkarten-Umgebung arbeitet daraufhin den empfangenen Signatur-Befehl ab und sendet das Resultat an die neue DataURL (Fall 5c). Dort kann der Server die Antwort entsprechend auswerten und eine passende Antwort erzeugen (5e). Alternativ kann die Antwort (und damit die Benutzerführung) durch Setzen der StylesheetURL bzw. RedirectURL erfolgen.
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.
Bezeichner und Parameter der Bindung werden im Befehl
GetPropertiesResponse des
Security-Layer verwendet.
Der Bezeichner dieser Bindung ist "TLS".
Parameter der Bindung: keine
CITIZENCARD.Security-Layer.TLS.HOST (default: 127.0.0.1)CITIZENCARD.Security-Layer.TLS.PORT (default: 3496)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.
Keine weitere Kodierung. Die XML-Kommandos werden 1:1 in der Verbindung übertragen.
Die TLS-Bindung bietet Authentifizierung der anfragenden Applikation und der Bürgerkarten-Umgebung, 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 Bürgerkarten-Umgebung 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.
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 Bürgerkarten-Umgebung 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.
Bezeichner und Parameter der Bindung werden im Befehl
GetPropertiesResponse des
Security-Layer verwendet.
Der Bezeichner dieser Bindung ist "HTTPS".
Parameter der Bindung: keine
CITIZENCARD.Security-Layer.HTTPS.HOST (default: 127.0.0.1)CITIZENCARD.Security-Layer.HTTPS.PORT (default: 3496)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.
Wie in Abschnitt 3.4 der HTTP-Bindung, mit dem Unterschied,
/https-security-layer-request"
gesendet wirdResponseType auf
den Wert "HTTPS-Security-Layer-RESPONSE" gesetzt wirdDie HTTPS-Bindung bietet wie die TLS-Bindung Authentifizierung der anfragenden Applikation und der Bürgerkarten-Umgebung, 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 Bürgerkarten-Umgebung 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.