MOA ID-Administration

- - -

- Module für Online-Applikationen -

- -

-Projekt moa -

-
- - - - - - - -

MOA-ID

- übersicht

- Basis-Installation

- Konfiguration

- Optionale
Komponenten

-
-

- Zurück

-

-

-Konfiguration
von MOA-ID -

-Konfigurationsdatei -

-Parameter-übersicht
-ConnectionParameter
-AuthComponent
-  BKUSelection
-  SecurityLayer
-  MOA-SP
-  IdentityLinkSigners
-  VerifyInfoboxes
-ProxyComponent
-OnlineApplication
-  AuthComponent
-  ProxyComponent
-ChainingModes
-TrustedCACertificates
-GenericConfiguration
-
-Konfiguration
der Online-Applikation
-
-Parameter-übersicht
-LoginType
-ParamAuth
-  ParamAuth/Parameter
-BasicAuth
-HeaderAuth
-  HeaderAuth/Header
-
-Konfiguration
von MOA-SP
-
-VerifyTransformsInfoProfile
-TrustProfile
-Certstore
-
-änderung der Konfig.
während des Betriebs
- -
-

- -

Konfiguration von MOA ID v.1.4

Die Konfiguration von MOA ID wird mittels einer XML-basierten - Konfigurationsdatei, die dem Schema - MOA-ID-Configuration-1.4.xsd - entspricht, durchgeführt. -

Der Ort der Konfigurationsdatei wird im Abschnitt Deployment - der Web-Applikation in Tomcat beschrieben. -

Die folgenden Abschnitte erläutern das Format der Konfigurationsdatei. - MOA-ID-Configuration.xml - zeigt ein Beispiel für eine umfassende Konfigurationsdatei.

Enthält die Konfigurationsdatei relative Pfadangaben, werden - diese relativ zum Verzeichnis, in dem sich die MOA-ID Konfigurationsdatei - befindet, interpretiert.
-

ConnectionParameter
- Das Element ConnectionParameter enthält Parameter, - die MOA-ID für den Aufbau von Verbindungen zu anderen Komponenten - benötigt. Dieses Element tritt mehrfach in der Konfigurationsdatei - auf und wird daher vorab detailliert beschrieben.
-
- Das Attribut URL enthält die URL der Komponente zu - der die Verbindung aufgebaut werden soll. Wird das Schema https - verwendet, können die Kind-Elemente AcceptedServerCertificates - und ClientKeyStore angegeben werden. Wird das Schema http - verwendet müssen keine Kind-Elemente angegeben werden bzw. - werden diese nicht ausgewertet. Andere Schemas werden nicht unterstützt. -
-
- Wird die Verbindung über TLS aufgebaut und erfordert der TLS-Server - eine Client-Authentisierung mittels Zertifikate, dann muss das Kind-Element - ClientKeyStore spezifiziert werden. Im Element ClientKeyStore - wird der Filename des PKCS#12-Keys (relativ zur MOA-ID Konfigurationsdatei) - angegeben. Diesem Keystore wird der private Schlüssel für - die TLS-Client-Authentisierung entnommen. Das Passwort zum Lesen - des privaten Schlüssels wird im Attribut ClientKeyStore/@password - konfiguriert.
- Aufgrund der Tatsache, dass starke Verschlüsselung eine Voraussetzung - für MOA-ID darstellt, werden clientseitig nur die folgenden - Cipher Suites unterstützt:
-

SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_3DES_EDE_CBC_SHA

- Im Kind-Element AcceptedServerCertificates kann ein Verzeichnisname - (relativ zur MOA-ID Konfigurationsdatei) angegeben werden, in dem - die akzeptierten Zertifikate der TLS-Verbindung hinterlegt sind. In - diesem Verzeichnis werden nur Serverzertifikate abgelegt. Fehlt dieser - Parameter wird lediglich überprüft ob ein Zertifikatspfad - zu den im Element <TrustedCACertificates> angegebenen - Zertifikaten erstellt werden kann. Falls dies nicht möglich ist, - kommt es zu einem Fehlerfall. -

AuthComponent
- AuthComponent enthält Parameter, die nur die MOA-ID - Authentisierungskomponente betreffen. Das Element ist optional - und muss nicht verwendet werden, wenn auf dem Server keine MOA-ID - Authentisierungskomponente installiert wird.
-
- Das Element AuthComponent hat fünf Kind-Elemente: -

BKUSelection (optional)
SecurityLayer
MOA-SP
IdentityLinkSigners
VerifyInfoboxes (optional ab Version 1.4)

AuthComponent/BKUSelection
- Das optionale Element BKUSelection enthält Parameter - zur Nutzung eines Auswahldienstes für eine Bürgerkartenumgebung - (BKU). Wird das Element nicht angegeben, dann wird die lokale - Bürgerkartenumgebung auf http://localhost:3495/http-security-layer-request - verwendet.
-
- Das Attribut BKUSelectionAlternative gibt an welche - Alternative zur BKU-Auswahl verwendet werden soll. MOA-ID unterstützt - die Werte HTMLComplete (vollständige HTML-Auswahl) - und HTMLSelect (HTML-Code für Auswahl) ["Auswahl - von Bürgerkartenumge-bungen", Arno Hollosi].
-
- Das Kind-Element ConnectionParameter spezifiziert die - Verbindung zum Auswahldienst (siehe ConnectionParameter), - jedoch kann das Kind-Element ClientKeyStore nicht angegeben - werden.

AuthComponent/Templates
- Das optionale Element Templates kann genau einmal vorkommen, um - das Aussehen der Seiten "Auswahl der Bürgerkartenumgebung" sowie - "Anmeldung mit Bürgerkarte" anzupassen. Die hier - spezifizierten (globalen) Templates haben Priorität gegenüber Templates, - die in der aufrufenden URL (vgl. Aufruf von MOA-ID-AUTH) - übergeben werden, haben jedoch Nachrang gegenüber in - der Konfigurationsdatei für eine Online-Applikation individuell definierte (lokale) - Templates (siehe - OnlineApplication/AuthComponent/Templates). - Das heißt, sind in der Konfigurationsddatei für eine Online-Applikation lokale - Templates definiert (Element OnlineApplication/AuthComponent/Templates), so werden - die als global spezifizierten Templates (AuthComponent/Templates) für diese - OnlineApplikation ignoriert, jedoch für alle anderen Online-Applikationen - verwendet. Templates in der aufrufenden URL werden demnach nur mehr dann - herangezogen, wenn in der Konfigurationsdatei weder globale (für alle - Online-Applikationen gültig) noch lokale (Templates je Online-Applikation) - spezifiziert sind.
- Das Templates-Element hat die zwei Kindelemente - BKUSelectionTemplate und Template. Jedes dieser - beiden Elemente kann genau einmal vorkommen oder fehlen. - Das Kindelement BKUSelectionTemplate spezifiziert ein Template - zur Gestaltung der Seite "Auswahl der Bürgerkartenumgebung", - während das Kindelement Template die Seite - "Anmeldung mit Bürgerkarte" referenziert. - Beide Elemente haben genau ein Attribut namens URL, - das die Lage des Templates im Form einer URL beschreibt. - Relative Pfadangaben werden dabei relativ zum Verzeichnis, in dem sich die - MOA-ID Konfigurationsdatei befindet, interpretiert.
- Im folgenden Beispiel werden zwei Templates im Verzeichnis - CATALINA_HOME/conf/moa-id/templates referenziert: -
-

-<Templates>
-  <BKUSelectionTemplate URL="templates/SampleBKUSelectionTemplate.html"/>
-  <Template URL="templates/SampleTemplate.html"/>
-</Templates>

- -
- Richtlinien zur Struktur der beiden Templates können der - MOA-ID-Spezifikation bzw. dem Abschnitt - Aufruf von MOA-ID-AUTH - dieses Handbuches entnommen werden. - -

AuthComponent/SecurityLayer
- Das Element SecurityLayer enthält Parameter - zur Nutzung des Security-Layers.
-
- Das Kind-Element TransformsInfo spezifiziert eine - Transformation, die für die Erstellung der Signatur des - AUTH-Blocks als Parameter in den CreateXMLSignatureRequest - des Security-Layers integriert werden muss. Mehrere unterschiedliche - Implementierungen des Security-Layer können durch die - Angabe mehrerer TransformsInfo-Elemente unterstützt - werden.
-
- Das Attribut TransformsInfo/@filename verweist auf - eine Datei, die das globale Element TransformsInfo - vom Typ TransformsInfo enthält. Die Angabe erfolgt - relativ zur MOA-ID Konfigurationsdatei. Das Encoding dieser - Datei muss UTF-8 sein.
-
- Beispiel für - eine TransformsInfo-Datei

AuthComponent/MOA-SP
- Das Element MOA-SP enthält Parameter zur Nutzung - von MOA-SP. MOA-SP wird für die überprüfung - der Signatur der Personenbindung und des AUTH-Blocks verwendet. -
-
- Wird das Kind-Element ConnectionParameter angegeben, - dann wird MOA-SP über das Webservice angesprochen.

Wird das Kind-Element ConnectionParameter - nicht angegeben so wird eine MOA-ID beiligende Version von - MOA-SP direkt über das Java-API angesprochen. In diesem - Fall muss das System-Property auf die verwendete Konfigurationsdatei - von MOA-SP gesetzt werden. Eine beispielhafte MOA-SP Konfigurationsdatei - ist in $MOA_ID_INST_AUTH/conf/moa-spss/SampleMOASPSSConfiguration.xml - enthalten.

Hinweis: MOA-SP muss entsprechend konfiguriert - werden - siehe hierzu Abschnitt Konfiguration - von MOA-SP. Alle Details zur Konfiguration von MOA-SP - finden sie in der Distribution von MOA-SP/SS beiligenden - Dokumentation im Abschnitt 'Konfiguration'.
-
- Das Kind-Element VerifyIdentityLink/TrustProfileID - spezifiziert eine TrustProfileID, die für den VerifyXMLSignatureRequest - zur Überprüfung der Signatur der Personenbindung - verwendet werden muss. Diese TrustProfileID muss beim - verwendeten MOA-SP Modul konfiguriert sein.
-
- Die Kind-Elemente VerifyAuthBlock/TrustProfileID - und VerifyAuthBlock/VerifyTransformsInfoProfileID - spezifizieren eine TrustProfileID und eine ID für - ein Transformationsprofil, die für den VerifyXMLSignatureRequest - zur überprüfung der Signatur des Auth-Blocks - verwendet werden müssen. Diese TrustProfileID muss - beim verwendeten MOA-SP Modul konfiguriert sein.

AuthComponent/IdentityLinkSigners -
- Dieses Element gibt an von welchen Signatoren die Signatur - des IdentityLink erstellt werden musste damit der IdentityLink - akzeptiert wird. Für jeden Signator muss der X509SubjectName - nach RFC 2253 spezifiziert werden.
-
- Beispiel -

- Anmerkung: Ab Version 1.4 ist dieses Element nicht mehr verpflichtend notwendig, da die - Berechtigung von Zertifikaten zum Signieren von Personenbindungen ab Februar - 2007 über die Zertifikatseigenschaft "Eigenschaft zur Ausstellung von Personenbindungen" - (OID: 1.2.40.0.10.1.7.1) geprüft wird. - Der Namens-Check des alten Zertifikats wird fix in MOA-ID integriert, sodass das - IdentityLinkSigners-Element in der Konfiguration überflüssig wird. - -
-

AuthComponent/VerifyInfoboxes -
- Ab Version 1.4 bietet MOA-ID die Möglichkeit einer erweiterten Infobox-Validierung, - das heißt, es können neben der Personenbindung auch weitere ausgelesene Infoboxen - validiert werden. Die für die Validierung der Infoboxen notwendigen Parameter - können über die Konfigurationsdatei durch das VerifyInfoboxes - Element sowohl global als auch - lokal - je Online-Applikation gesetzt werden. MOA-ID übergibt diese Parameter der - Applikation, die für die Verifikation des Inhaltes der jeweilgen von der BKU - übermittelten Infobox verantwortlich ist. Im Folgenden wird eine derartige - Applikation als Prüfapplikation bezeichnet. -
- Das Verifyinfoboxes Element ist optional und kann fehlen, - wenn keine Infoboxen außer der der Personenbindung validiert werden müssen. -
- Das VerifyInfoboxes-Element hat folgende Kind-Elemente: -

DefaultTrustProfile: Dieses optionale - Element kann nur einmal vorkommen und spezifiziert ein Trust-Profil, das - von einer Prüfapplikation zur Validierung einer Infobox - herangezogen werden kann, wenn für diese Infobox kein eigenes - Trust-Profil gesetzt wurde. Es hat genau ein - Kindelement namens TrustProfileID, das die ID eines in MOA-SP - konfigurierten Trust-Profiles enthält. -
- Anmerkung: Das Trust-Profil für die - Personenbindung darf nicht - zur Validierung anderer Infoboxen verwendet werden. Das Trust-Profil für - die Bürgerkarte soll nur dann zur Validierung - anderer Infoboxen verwendet werden, wenn die zur Verifikation der Zertifikate benötigten - Wurzelzertifikate bereits im entsprechenden Trust-Store enthalten sind. (vgl. - MOA-ID Spezifikation, Abschnitt 4.6). -
Infobox: Dieses Element kann beliebig oft vorkommen - und kapselt die Parameter, die für die Validierung einer Infobox an die - jeweilige Prüfapplikation übergeben werden. -
- Das Infobox-Element hat folgende Attribute: -
- Identifier: Dieses Attribut muss vorhanden sein und gibt - den Namen der Infobox an. Er muss dabei exakt dem Bezeichner - der jeweiligen zu validierenden Infobox aus der BKU entsprechen, also - zum Beispiel Mandates für die Vollmachten-Infobox oder - EHSPToken für die GDAToken-Infobox. -
  -
- required: Dieses Attribut vom Typ - boolean bestimmt, ob MOA-ID den Inhalt der entsprechenden Infobox - für die Anmeldung zwingend benötigt. Ist es auf true - gesetzt, und wird der entsprechende Infobox-Inhalt nicht von der BKU - übermittelt, so bricht MOA-ID den Anmeldevorgang mit einer Fehlermeldung - ab. -
  - Fehlt dieses Attribut, so wird als Defaultwert false gesetzt. -
  -
- provideStammzahl: Dieses Attribut vom Typ - boolean bestimmt, ob die Prüfapplikation die Stammzahl aus der - Personenbindung erhalten darf. Fehlt dieses Attribut, so wird als Defaultwert - false gesetzt. -
  - Anmerkung: Das Attribut steht in keinem Zusammenhang zum gleichnamigen - Attribut OnlineApplication/AuthComponent/@provideStammzahl, - das angibt ob die Stammzahl an die Online-Applikation weitergegeben werden darf. -
- provideIdentityLink: Dieses Attribut vom Typ - boolean bestimmt, ob die Prüfapplikation die Personenbindung erhalten - soll. Hat es den Wert true, so wird ein Klone des Wurzel-Elements der Personenbindung - an die Prüfapplikation übergeben, wobei zu beachten ist, dass die - darin enthaltene Stammzahl auf einen leeren String gesetzt wird, falls das - Attribut provideStammzahl auf false - gesetzt ist. - Fehlt das provideIdentityLink-Attribut, so wird als Defaultwert false gesetzt. -
  - Anmerkung 1: Das Attribut steht in keinem Zusammenhang zum gleichnamigen - Attribut OnlineApplication/AuthComponent/@provideIdentityLink, - das angibt ob die Online-Applikation die Personenbindung erhalten - soll. -
  - Anmerkung 2: Der Prüfapplikation werden defaultmäßig der Vorname, - der Familienname, das Geburtsdatum, der Typ der Stammzahl, die Stammzahl - (konfigurierbar) und die öffentlichen Schlüssel aus der Personenbindung - übergeben. Das Attribut provideIdentityLink sollte deshalb - wirklich nur dann auf true gesetzt werden, wenn von der - Prüfapplikation noch andere Daten aus der Personenbindung benötigt - werden. -
- Das Infobox-Element hat folgende Kind-Elemente: -
- FriendlyName: Das Element ist optional und - enthält einen Namen, der von MOA-ID zur Anzeige von, die jeweilige Infobox - betreffende, Fehlermeldungen im Browser verwendet wird. Im Regelfall wird man - hier den deutschen Namen der Infobox setzen, also z.B. Vollmachten - oder Stellvertretungen für die Mandates-Infobox oder - GDAToken für die EHSPToken-Infobox. -
  - Fehlt dieses Element, so wird für Fehlermeldungen der Wert des - Identifier-Attributes verwendet. -
- TrustProfileID: Das Element ist optional und - bezeichnet ein in MOA-SP konfiguriertes Trust-Profil, das von MOA-ID - für die Validierung der Infobox verwendet wird. - Dabei ist wieder zu beachten, dass das Trust-Profil für die - Personenbindung nicht - zur Validierung anderer Infoboxen verwendet werden darf, und das Trust-Profil für - die Bürgerkarte nur dann zur Validierung - anderer Infoboxen verwendet werden soll, wenn die zur Verifikation der - Zertifikate benötigten Wurzelzertifikate bereits im entsprechenden - Trust-Store enthalten sind. (vgl. MOA-ID Spezifikation, Abschnitt 4.6). -
  Fehlt dieses Element, so wird das - Default-Trust-Profil - verwendet. Ist dieses auch nicht konfiguriert, so wird für die - Validierung der entsprechenden Infobox keine Zertifikatsprüfung - notwendig sein. -
- ValidatorClass: Das Element ist optional - und bezeichnet den Namen der Klasse (voller Package-Name), die von MOA-ID - zur Validierung der Infobox geladen werden soll. Fehlt dieses Element, - so wird MOA-ID versuchen, eine Default-Klasse zu laden, deren Namen aus - dem Identifier-Attribut der Infobox abgeleitet - wird (vgl. MOA-ID-Spezifikation, Abschnitt 4.7.2.3, - Zuordnung eines InfoboxReadResponse zu einer implementierenden Klasse). -
  - Anmerkung: Im Regelfall wird dieses Element fehlen, da bei der - Entwicklung einer Infobox-Prüfapplikation der Default-Klassennamen - verwendet werden sollte. Nur wenn es verschiedene Prüfapplikationen - für eine Infobox gibt, wird man das ValidatorClass - verwenden, um eine andere als die Default-Applikation zu laden. -
- SchemaLocations: Das Element ist optional - und referenziert XML-Schemas, die von der Prüfapplikation zum - validierenden Parsen von Infoboxen verwendet werden können. Das - Element hat beliebig viele Schema-Kindelemente, dessen Attribute - namespace und schemaLocation jeweils die Namespace-URI - und den Ort (URI) des entsprechenden Schemas bezeichnen. Relative URIs im - schemaLocation-Attribut sind dabei relativ zum Verzeichnis der - MOA-ID-Konfigurationsdatei zu interpretieren. -
  - Beispiel: -
  -
```
-    <SchemaLocations>
-      <Schema namespace="http://ns1.ns1" schemaLocation="schemas/ns1.xsd"/>
-      <Schema namespace="http://ns2.ns2" schemaLocation="schemas/ns2.xsd"/>
-    </SchemaLocations>
-                              
```
  - Weitere Möglichkeiten zur Übergabe von XML-Schemas an die - Prüfapplikation können in der MOA-ID-Spezifikation im - Abschnitt 4.7.2, Erweiterte Infoboxüberprüfung, nachgelesen werden. -
- ApplicationSpecificParameters: - Das Element ist optional und nimmt Infobox-kontext-spezifische Parameter - auf. -
  - Da MOA-ID die zusätzlichen zur Personenbindung abgefragten Infoboxen - (bzw. deren Inhalte) nicht a priori kennt, ist es unmöglich vorherzusehen, - welche Parameter eine Prüfapplikation zum Validieren einer Infobox - benötigt. Die Konfiguration sieht daher das Element - ApplicationSpecificParameters vor, um einer bestimmten - Prüfapplikation kontext spezifische Parameter zu übermitteln. - Dieses Element wird vollständig an die Prüfapplikation - weitergegeben, und es obliegt der Prüfapplikation die Kindelemente - des ApplicationSpecificParameters-Element zu extrahieren und zu - interpretieren. -
  - Beispiel: -
  -
```
-    <ApplicationSpecificParameters>
-      <Parameter1>content1</Parameter1>
-      <Parameter2>content2</Parameter2>
-      <Parameter3>
-        <Parameter3a>content3a</Parameter3a>
-        <Parameter3b>content3b</Parameter3b>
-      </Parameter3>
-    </ApplicationSpecificParameters>
-                              
```
  -
-

-
- Eine Beispielkonfiguration finden sie am Ende das Abschnitts - OnlineApplication/AuthComponent/VerifyInfoboxes. -
-
-

- -

ProxyComponent
- ProxyComponent enthält Parameter, die - nur die MOA-ID Proxykomponente betreffen. Das Element - ist optional und muss nicht verwendet werden, wenn auf - dem Server keine MOA-ID Proxykomponente installiert - wird.
-
- Das Element ProxyComponent hat nur das Kind-Element - AuthComponent, das die Verbindung zur Authentisierungs-komponente - beschreibt.
-
- Baut die Proxykomponente die Verbindung zur Authentisierungs-komponente - über ein Webservice auf, dann muss das Element - ConnectionParameter spezifiziert werden.
-
- Baut die Proxykomponente die Verbindung zur Authentisierungs-komponente - über das API auf, dann wird das Element ConnectionParameter - nicht spezifiziert.

OnlineApplication
- Für jede Online-Applikation, die über MOA-ID - authentisiert wird, gibt es ein Element OnlineApplication. - Die Parameter betreffen teils die MOA-ID Authentisierungskomponente, - teils die MOA-ID Proxykomponente, teils beide.
-
- Das ab Version 1.3 optionale Attribut OnlineApplication/@type - spezifiziert den Typ der OnlineApplikation und kann - die Werte publicService für eine Applikation - aus dem öffentlichen Bereich und businessService - für eine Anwendung aus dem privatwirtschaftlichen Bereich annehmen. - Ab Version 1.4 kann im Modus businessService ein zusätzliches - logisches Attribut OnlineApplication/@calculateHPI angegeben werden. - Dadurch wird im Falle von calculateHPI="true" im privatwirtschaftlichen - Bereich zur Identifikation der Health Professional Identifier HPI anstatt des wbPKs (siehe - - OnlineApplication/AuthComponent/IdentificationNumber) berechnet - und zur Anmeldung weiterverwendet. - Ist dieses Attribut nicht gesetzt, so wird der Typ publicService - vorausgesetzt.
-
- Das Attribut OnlineApplication/@publicURLPrefix - entspricht dem URL-Präfix der nach außen - sichtbaren Domäne der Online-Applikation, welcher - von der MOA-ID Proxykomponente durch den URL-Präfix - der wirklichen Domäne (Attribut OnlineApplication/ProxyComponent/ConnectionParameter/@URL) - ersetzt wird. Es dient als Schlüssel zum Auffinden - der Konfigurationsparameter zur Online-Applikation. -

Das Attribut OnlineApplication/@keyBoxIdentifier - gibt das Schlüsselpaar an, welches von der Bürgerkartenumgebung - zum Signieren des Auth Blocks verwendet wird. Mögliche - Werte: CertifiedKeypair sowieSecureSignatureKeypair. -
- Das Element OnlineApplication hat optional - zwei Kind-Elemente: AuthComponent und ProxyComponent. -

OnlineApplication/AuthComponent -
- Das Element OnlineApplication/AuthComponent - muss verwendet werden wenn auf dem Server die Authentisierungskomponente - installiert wird. Es enthält Parameter, die - das Verhalten der Authentisierungskomponente bezüglich - der Online-Applikation konfiguriert.
-
- Das optionale Attribut slVersion definiert die Version des - verwendeten SecurityLayer und damit den Namespace aller - Requests, die von MOA-ID an die Bürgerkartenumgebung - geschickt werden. Dieses Attribut kann entweder den Wert 1.1 - oder 1.2 annehmen. Fehlt das Attribut, so wird als - Defaultwert 1.1 gesetzt. -
Wurde als Typ der Online-Applikation - der Wert businessService (vgl. Attribut OnlineApplication/@type) - spezifiziert, so wird das Attribut slVersion ignoriert - und immer der Wert 1.2 verwendet, da die für - Applikationen aus dem privatwirtschaftlichen Bereich notwendige - Berechnung des wirtschaftsbereichsspezifischen Personenkennzeichens - (wbPK) erst ab SecurityLayer Version 1.2 möglich ist. -

- Das Attribut provideStammzahl bestimmt, - ob die Stammzahl in den Anmeldedaten aufscheint - oder ob der Wert ausgeblendet (d.h. auf den Leerstring gesetzt) - wird. Die Attribute provideAUTHBlock und - provideIdentityLink steuern, ob die - Anmeldedaten den Auth-Block bzw. die Personenbindung enthalten. - Ab Version 1.3 kann das Attribut provideCertificate - verwendet werden, um das Signatorzertifikat in die - Anmeldedaten aufzunehmen. - Alle Attribute sind optional und haben den Default-Wert - false. -
- Anmerkung: Das Attribut provideStammzahl steht in keinem - Zusammenhang zum gleichnamigen Attribut - VerifyInfoboxes/@provideStammzahl, - das angibt ob die Stammzahl an eine Prüfapplikation weitergegeben - werden darf. - Anmerkung: Das Attribut provideIdentityLink steht in keinem - Zusammenhang zum gleichnamigen Attribut - VerifyInfoboxes/@provideIdentityLink, - das angibt ob die Personenbindung an eine Prüfapplikation - weitergegeben werden soll. -
-
-

OnlineApplication/AuthComponent/IdentificationNumber -
- Das wirtschaftsbereichsspezifische Personenkennzeichen (wbPK) - wird aus der auf der Bürgerkarte gespeicherten Stammzahl des Bürgers - und der Stammzahl des Wirtschaftsunternehmens berechnet. - Laut E-Governmentgesetz - darf die Errechnung eines wbPK aus der Stammzahl nicht beim Auftraggeber eines - privaten Bereichs durchgeführt werden (vgl. E-GovGesetz §12(1).4), und muss deshalb - an die Bürgerkartenumgebung ausgelagert werden. - Das OnlineApplication/AuthComponent/IdentificationNumber Element - wird nun verwendet, um die Stammzahl des Wirtschaftsunternehmens zu spezifizieren, - welche in weiterer Folge von MOA-ID an die Bürgerkartenumgebung übergeben - wird.
Dieses Element muss bei privatwirtschaftlichen Applikationen - vorhanden sein und wird ignoriert, falls es im Kontext von Anwendungen aus - dem öffentlichen Bereich verwendet wird.
- Das Element hat genau eines der folgenden möglichen Kindelemente - aus dem PersonData - Namespace, die als einzigen Inhalt die jeweilige Stammzahl des Unternehmens enthalten: -

- Das Element pr:Firmenbuchnummer enthält als einzigen Inhalt - die Firmenbuchnummer des Unternehmens. -
- Das Element pr:Vereinsnummer enthält als einzigen Inhalt - die Vereinsregisternummer des Unternehmens. -
- Das Element pr:ERJPZahl enthält als einzigen Inhalt eine - Zahl aus dem Ergänzungsregister für nicht-natürliche Personen (CorporateBody). -
- Das Element pr:ZMRzahl enthält als einzigen Inhalt eine - Stammzahl einer natürlichen in Österreich meldepflichtigen Person. -

- - Die Stammzahl ist jeweils ohne Präfix anzugeben, also wird zum Beispiel - die Firmenbuchnummer FN468924i folgendermaßen definiert: -

- <pr:Firmenbuchnummer>468924i</pr:Firmenbuchnummer> -

- Leerzeichen werden ignoriert und im Falle einer Firmenbuchnummer werden - führende Nullen gelöscht und Bindestriche aus der Nummer entfernt. -

- Beispiele:
-

- 468924 i wird zu 468924i
- 00468924 wird zu 468924i
- 468924-i wird zu 468924i
-

- Alternativ zu den oben angeführten Elementen aus dem - PersonData - Namespace kann auch das Element AnyNumber verwendet werden, um - Stammzahlen zu spezifizieren, die nicht einer der vier oben aufgelisteten - Kategorien zugeordnet werden können. -

- Das Element AnyNumber hat genau ein Attribut namens Identifier, - das das Präfix der jeweiligen Stammzahl entält. Der Inhalt des - Elements AnyNumber ist die Stammzahl selbst, wobei die selben Regeln - wie oben gelten. -

- Die Firmenbuchnummer aus obigem Beispiel könnte man nun beispielsweise mit Hilfe das Elements - AnyNumber auch folgendermaßen definieren: -

- <AnyNumber Identifier="FN">468924i</AnyNumber> -

- Es sei aber nochmals daraufhingewiesen, dass für Stammzahlen der - Kategorien Firmenbuchnummer, Vereinsnummer, - ERJPZahl und ZMRzahl die vordefinierten Elemente aus - dem PersonData - Namespace verwendet werden sollen. Das Element AnyNumber wurde hauptsächlich in - das Schema aufgenommen, um offen für mögliche Erweiterungen zu sein. -

OnlineApplication/AuthComponent/Templates -
- Dieses Kindelement kann genau einmal vorkommen und entspricht in seiner Struktur dem - Element AuthComponent/Templates. - Es kann verwendet werden, um Templates zur Gestaltung der Seiten - "Auswahl der Bürgerkartenumgebung" sowie - "Anmeldung mit Bürgerkarte" individuell für - eine Online-Applikation zu definieren. Die hier definierten Templates haben - Priorität gegenüber globalen Templates und Templates, die - in der aufrufenden URL übergeben werden. -

- -

OnlineApplication/AuthComponent/TransformsInfo -
- Dieses Kindelement kann mehrfach vorkommen und entspricht in seiner Struktur - dem Element AuthComponent/SecurityLayer/TransformsInfo. - Das Element kann verwendet werden, um für unterschiedliche - Online-Applikationen unterschiedliche Transformationen zu spezifizieren. - Alle über dieses Element definierten Transformationen haben - Vorrang gegenüber die durch AuthComponent/SecurityLayer/TransformsInfo - angegebenen Transformationen. Das heißt, ist für eine - Online-Applikation das Kindelement AuthComponent/TransformsInfo - vorhanden, so wird für diese Applikation die durch dieses Element - spezifizierte Transformation verwendet (das Element kann natürlich - mehrfach vorkommen, wodurch mehrere Transformationen bezeichnet werden). - Für alle Applkikationen, die kein Kindelement vom Typ - AuthComponent/TransformsInfo enthalten, werden die unter - AuthComponent/SecurityLayer/TransformsInfo spezifizierten - "Default-Transformationen" verwendet.
- Dabei ist zu beachten, dass für jede definierte Transformation - ein entsprechendes MOA-SP/VerifyAuthBlock/VerifyTransformsInfoProfileID - Element vorhanden sein muss.

OnlineApplication/AuthComponent/VerifyInfoboxes -
- Dieses optionale Element entspricht dem VerifyInfoboxes-Element - aus der globalen AUTH-Komponente und überschreibt teilweise die - dort gesetzten Werte für die jeweilige Infobox pro Online-Applikation. - Dabei gelten die folgenden Regeln: -
- Ist nur das globale VerifyInfoboxes-Element - vorhanden, so gelten die dort definierten Parameter für alle - Online-Applikationen. Ist kein globales Element vorhanden, so kann - MOA-ID für alle Online-Applikation, in deren AUTH-Komponente - ein VerifyInfoboxes-Element enthalten ist, die darin - definierten Infoboxen überprüfen. Für - Online-Applikationen, in deren AUTH-Komponente kein - VerifyInfoboxes-Element gesetzt ist, kann demnach keine - andere Infobox als die der Personenbindung validiert werden. -
- Sind sowohl global (MOA-IDConfiguration/AuthComponent/VerifyInfoboxes) - als auch lokal (OnlineApplication/AuthComponent/VerifyInfoboxes) - in den Online-Applikationen Infobox-Validatoren konfiguriert, so verarbeitet - MOA-ID die darin enthaltenen Parameter wie folgt: -

DefaultTrustProfile: Ein lokal - definiertes Default-Trust-Profil hat sowohl Vorrang gegenüber einem - global gesetzten Default-Trust-Profil - als auch gegenüber einem global gesetzen - infobox-spezifischen Trustprofil. Ist - beispielsweise im globalen VerifyInfoboxes-Element zwar kein - Default-Trust-Profil, aber für die Infobox A ein eigenes Trust-Profil - definiert, so wird ein lokal definiertes Default-Trust-Profil dem global - für die Infobox A gesetzten Trust-Profil vorgezogen. -
Infobox: MOA-ID kann die Vereinigung aus den - global und lokal konfigurierten Infoboxen für eine Online-Applikation - validieren. Sind beispielsweise global Prüfapplikationen - für die Infoboxen mit den Bezeichnern - (Infobox/@Identifier-Attribut) A - und B konfiguriert, und lokal für die Online-Applikation - OA1 die Infoboxen B, C und D, so - kann MOA-ID für die Online-Applikation OA1 die - Infoboxen A, B, C und D validieren. - Für die Infobox A werden dabei die Parameter aus der - globalen Konfiguration verwendet und für die Infoboxen - C und D die lokalen Parameter. Für die Infobox - B sind sowohl globale als auch lokale Parameter vorhanden, - die von MOA-ID wie folgt interpretiert werden: -
- Attribute: - Die Attribute required, - provideStammzahl und - provideIdentityLink überschreiben - die global gesetzten Werte. Dabei ist zu beachten, das ein Fehlen dieser - Attribute bedeutet, dass ihnen über das Schema der Defaultwert - false zugewiesen wird. Ist also beispielsweise für die - Infobox mit dem Bezeichner B das required-Attribut - global auf true gesetzt (<Infobox Identifier="B" required="true">) - und fehlt dieses Attribut lokal in der Online-Applikation OA1 - (<Infobox Identifier="B">), so hat das required-Attribut - für die Infobox B den Wert false. -
  - Die Attribute required, - provideStammzahl und - provideIdentityLink müssen also - für Infoboxen, die sowohl global als auch lokal konfiguriert sind, - in jeder lokalen Konfiguration neu gesetzt werden, wenn ihnen der Wert - true zugwiesen werden sollen. -
- Kind-Elemente: -
  - FriendlyName: - Ein lokal gesetzter FriendlyName wird einem global - gesetzten vorgezogen. Ist sowohl lokal als auch global kein - FriendlyName definiert, so wird das - Identifier-Attribut als FriendlyName - verwendet. -
    -
  - TrustProfileID: - Ein lokal definiertes Trust-Profil wird einem lokal definierten - Default-Trust-Profil vorgezogen. Sind lokal sowohl kein - Default-Trust-Profil als auch kein infobox-spezifisches Trust-Profil - definiert, so wird das global gesetzte infobox-spezifisches Trust-Profil - verwendet. Fehlt auch dieses, so wird das globale Default-Trust-Profil - selektiert. Ist weder lokal als auch lokal ein Trust-Profil - definiert, so wird für für die Validierung dieser - Infobox kein Trust-Profil benötigt. -
  - ValidatorClass: - Eine lokal gesetzte Validator-Klasse wird einer global gesetzten - vorgezogen. Ist sowohl lokal als auch global für eine Infobox - keine Validator-Klasse konfiguriert, so wird die Default-Klasse - geladen (siehe ValidatorClass). -
  - SchemaLocations: - Lokal definierte Schemas werden global definierten vorgezogen. - Sind lokal keine Schemas konfiguriert, so werden die globalen verwendet, - so sie vorhanden sind. -
  - - ApplicationSpecificParameters: - Lokal definierte applikationsspezifische Paramter werden global - definierten vorgezogen. Sind lokal keine derartigen Paramter - konfiguriert, so werden die globalen verwendet, so sie vorhanden - sind. -
  -
-

-
- Beispiel: In der Konfigurationsdatei - - SampleMOAIDVerifyInfoboxesConfiguration.xml sind global - (MOA-IDConfiguration/AuthComponent/VerifyInfoboxes) - Prüfapplikationen für die beiden Infoboxen mit den Bezeichnern - InfoboxA und InfoboxB konfiguriert. - InfoboxA demonstriert in diesem Beispiel die minimale Konfiguration - einer Prüfapplikation - es ist nur der Identifier angegeben. MOA-ID - wird in diesem Fall versuchen, die Default-Validatorklasse - at.gv.egovernment.moa.id.auth.validator.infoboxa.InfoboxAValidator - zu laden (siehe dazu auch MOA-ID-Spezifikation, Abschnitt 4.7.2.3, - Zuordnung eines InfoboxReadResponse zu einer implementierenden Klasse). - Da ein Default-Trust-Profil (GlobalVIDefaultTrust) konfiguriert ist, - wird MOA-ID dieses Profil zur Verifikation von Zertifikaten heranziehen. - Da kein FriendlyName gesetzt ist, wird das Identifier Attibut - (InfoboxA) als FriendlyName verwendet. Weitere Parameter - sind für die Verifikation dieser Infobox nicht erforderlich. -
- Die Prüfapplikation für die InfoboxB setzt nahezu alle - möglichen Paramter mit Ausnahme der Validator-Klasse. MOA-ID wird - zur Verifikation dieser Infobox also auch die dafür zustädige Default-Klasse - (at.gv.egovernment.moa.id.auth.validator.infoboxb.InfoboxBValidator) - laden, und alle konfigurierten Parameter an diese Klasse übergeben. -
- In die Konfigurationsdatei sind drei Online-Applikationen mit den - public URL-Prefixen https://OA1/, https://OA2/ und - https://OA3/ eingetragen. - Online-Applikation OA1 konfiguriert Prüfapplikationen für - die drei Infoboxen InfoboxB, InfoboxC und - InfoboxD. Das heißt, MOA-ID kann für die Online-Applikation - OA1 insgesamt vier Infoboxen überprüfen: die - Paramter für die Infobox InfoboxA werden - von der entsprechenden global konfigurierten Prüapplikation - übernommen. Die Infoboxen InfoboxC und - InfoboxD sind nur lokal gesetzt. Für InfoboxB - übernimmt MOA-ID die applikationsspezifischen Parameter aus der - entsprechenden global konfigurierten Infobox und überschreibt - alle weiteren Parameter mit den lokalen Werten. Als Trust-Profil wird - das lokale Deafult-Trust-Profil (LocalOA1DefaultTrust) genommen - - dieses hat Vorrang gegenüber den global gesetzten Profilen. Weiters - ist zu beachten, dass die Attribute provideStammzahl und - provideIdentityLink lokal nicht gesetzt sind, und daher den - Deafult-Wert false einnehmen. -
- Das VerifyInfoboxes-Element in der AUTH-Komponente der zweiten - Online-Applikation (OA2) spezifiziert keine anderen Prüfapplikationen - als die global definierten, überschreibt aber für beide Infoboxen - teilweise die global gesetzten Parameter. InfoboxA verwendet - ein lokal definiertes Trust-Profil (LocalInfoboxOA2ATrust), - InfoboxB übernimmt - alle globalen Parameter, setzt aber für die Attribute required, - provideStammzahl und provideIdentityLink jeweils den - Defaultwert false. -
- Die dritte Online-Applikation OA3 enthält in Ihrer AUTH-Komponente - kein VerifyInfoboxes-Element. MOA-ID übernimmt daher für - diese Online-Applikation die global konfigurierten Infobox-Prüapplikationen - (InfoboxA und InfoboxB) mit allen Paramertern genauso wie - sie dort gesetzt sind. Zu beachten ist hier, dass das in der AUTH-Komponente - auf true gesetzte Attribut proviedStammzahl die - Online-Applikation und nicht die Prüapplikation - betrifft. -
-

OnlineApplication/ProxyComponent -
- Das Element OnlineApplication/ProxyComponent - muss verwendet werden wenn auf dem Server die - Proxykomponente installiert wird.
-
- Das optionale Attribut configFileURL - verweist auf eine Konfigurationsdatei die dem Schema - MOA-ID-Configuration-1.4.xsd - entspricht mit Dokument-Element Configuration. - Die Angabe erfolgt relativ zur verwendeten MOA-ID - Konfigurationsdatei. Beispiel für das Element - configFileURL: "oa/SampleOAConfiguration.xml".
- Defaultmäßig wird versucht die Datei - von der betreffenden OnlineApplikation unter dem - Wert: http://<realURLPrefix>/MOAConfig.xml - zu laden.
- (<realURLPrefix> entspricht dem - Wert von OnlineApplication/ProxyComponent/ConnectionParameter/@URL) -
-
- Das optionale Attribut sessionTimeOut - legt das Timeout einer Benutzersession in der - Proxykomponente in Sekunden fest.
- Default-Wert: 3600
-
- Im optionalen Attribut loginParameterResolverImpl - kann der Klassenname eines zu verwendenden LoginParameterResolver - angegeben werden, welcher die Defaultimplementierung - ersetzt.
-

Im optionalen Attribut loginParameterResolverConfiguration -kann ein Configurationsstring für die - Initialisierung der betreffenden loginParameterResolverImpl - angegeben werden.
-
- Im optionalen Attribut connectionBuilderImpl - kann der Klassenname eines zu verwendenden ConnectionBuilder - angegeben werden, welcher die Defaultimplementierung - ersetzt.
-
- Im Kind-Element ConnectionParameter ist - konfiguriert, wie MOA-ID-PROXY zur Online-Applikation - verbindet.

ChainingModes
- Das Element ChainingModes definiert, - ob bei der Zertifikatspfad-überprüfung - das Kettenmodell ("chaining") oder - das Modell nach PKIX RFC 3280 ("pkix") - verwendet werden soll.
-
- Das Attribut systemDefaultMode spezifiziert - das Modell, das im Standardfall verwendet werden - soll.
-
- Mit dem Kind-Element TrustAnchor kann - für jeden Trust Anchor ein abweichendes - Modell spezifiziert werden. Ein Trust Anchor - ist ein Zertifikat, das in TrustedCACertificates - spezifiziert ist. Ein Trust Anchor wird durch - den Typ <dsig:X509IssuerSerialType> - spezifiziert. Das für diesen Trust Anchor - gültige Modell wird durch das Attribut - mode spezifiziert.
-
- Gültige Werte für die Attribute systemDefaultMode - und mode sind "chaining" und - "pkix".
-
- Beispiel -

TrustedCACertificates
- Das Element TrustedCACertificates - enthält das Verzeichnis (relativ zur - MOA-ID Konfigurationsdatei), das jene Zertifikate - enthält, die als vertrauenswürdig - betrachtet werden. Im Zuge der Überprüfung - der TLS-Serverzertifikate wird die Zertifikatspfaderstellung - an einem dieser Zertifikate beendet.

GenericConfiguration
- Das Element GenericConfiguration - ermöglicht das Setzen von Namen-Werte - Paaren mittels der Attribute name - und value. Die folgende Liste spezifiziert -

gültige Werte für das name-Attribut, -
eine Beschreibung
gültige Werte für das value-Attribut - und (falls vorhanden)
den Default-Wert für das value-Attribut. -

- - - - - - - -

name: DirectoryCertStoreParameters.RootDir
Gibt den Pfadnamen zu einem - Verzeichnis an, das als Zertifikatsspeicher - im Zuge der TLS-Server-Zertifikatsüberprüfung - verwendet wird. - - value: - Gültige Werte: Name eines gültigen - Verzeichnisses (relativ zur MOA-ID Konfigurationsdatei) - Dieser Parameter muss angegeben werden. -

- - - - - - - -

name: AuthenticationSession.TimeOut
Gibt die Zeitspanne in - Sekunden vom Beginn der Authentisierung - bis zum Anlegen der Anmeldedaten an. - Wird die Angegebene Zeitspanne überschritten - wird der Anmeldevorgang abgebrochen. - - - value: - Gültige Werte: positive Ganzzahlen - - Default-Wert: 120

- - - - - - - -

name: AuthenticationData.TimeOut
Gibt die Zeitspanne in - Sekunden an, für die die Anmeldedaten - in der Authentisierungskomponente zum - Abholen durch die Proxykomponente oder - eine nachfolgende Applikation bereitstehen. - Nach Ablauf dieser Zeitspanne werden - die Anmeldedaten gelöscht. - - value: - Gültige Werte: positive Ganzzahlen - Default-Wert: 600

- - - - - - - -

name: TrustManager.RevocationChecking
Für die TLS-Server-Authentisierung - dürfen nur Server-Zertifikate verwendet - werden, die eine CRLDP-Extension enthalten - (andernfalls kann von MOA-ID keine CRL-überprüfung - durchgeführt werden). - Soll das RevocationChecking generell - ausgeschaltet werden, ist dieses Attribut - anzugeben und auf "false" zu setzen. - - - value: - Gültige Werte: true, false - Default-Wert: true

- - - - - - - -

name: FrontendServlets.EnableHTTPConnection

Standardmäßig können - die beiden Servlets "StartAuthentication" - und "SelectBKU" welche das - User-Frontend darstellen, aus Sicherheitsgründen, - nur über das Schema HTTPS aufgerufen - werden.

Wenn die beiden Servlets jedoch auch - Verbindungen nach dem Schema HTTP - entgegennehmen sollen, so kann mittels - dem Attribut "EnableHTTPServletConnection" - erlaubt werden.

Hinweis: Sicher und sinnvoll ist - das Erlauben der HTTP Verbindung nur - dann, wenn ein Vorgeschalteter Webserver - das HTTPS handling übernimmt, - und eine Verbindung zu den Servlets - nur über diesen Webserver möglich - ist.

- value:
- Gültige Werte: true, false
- Default-Wert: false

- - - - - - - -

name: - FrontendServlets.DataURLPrefix

Standardmäßig wird als - DataURL Prefix das URL Präfix - unter dem die MOA-ID Servlets erreichbar - sind verwendet. Im Falle das sich - der MOA-ID Server hinter einer Firewall - befindet und die Requests von einem - vorgelagertem Webserver weitergereicht - werden, kann mit FrontendServlets.DataURLPrefix - ein alternatives URL Präfix angegeben - werden. In diesem Fall muss der Webserver - so konfiguriert sein, dass er Request - auf diese URLs an den MOA-ID Server - weiterleitet.

- value:
- Gültige Werte: URLs nach dem Schema - 'http://' und 'https://'
- Default-Wert: kein Default-Wert
- Beispiel: <GenericConfiguration name="FrontendServlets.DataURLPrefix" - value="https://<your_webserver>/moa-id-auth/"/>

- - - - -

- - -

-

- - - -

-

-

Konfiguration der Online-Applikation

-Die Konfiguration der OA beschreibt die Art und Weise, wie die Proxykomponente die Anmeldung an der Online-Applikation -durchführt. -

-Der Name der Konfigurationsdatei wird in der Konfiguration von MOA-ID als Wert des Attributs -configFileURL des Elements MOA-IDConfiguration/OnlineApplication/ProxyComponent hinterlegt. -
Ist dieses Attribut nicht gesetzt, dann wird die Datei von http://<realURLPrefix>/MOAConfig.xml geladen, -wobei <realURLPrefix> dem Konfigurationswert OnlineApplication/ProxyComponent/ConnectionParameter/@URL entspricht. -

-Die Konfigurationsdatei ist eine XML-Datei, die dem Schema -MOA-ID-Configuration-1.4.xsd mit dem Wurzelelement -Configuration entspricht. -

- -

-LoginType
-Das Element LoginType 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 werden sie gelöscht. -
-Default-Wert: stateful -

- -

-ParamAuth
-Konfiguriert die übergabe der Authentisierungs-Parameter an die Online-Applikation mittels URL-Parametern. Das Element -kann ein oder mehrere Kind-Elemente <Parameter> beinhalten. -

- -

-ParamAuth/Parameter
-Das Element <Paramter> enthält die Attribute Name und Value. -

-Das Attribut Name beschreibt den Namen des Parameters und ist ein frei zu wählender String. -

-Das Attribut Value beschreibt den Inhalt des Parameters und kann einen der durch MOAAuthDataType beschriebenen -Werte annehmen. Gültige Werte von MOAAuthDataType sind: -

MOAGivenName - der Vorname des Benutzers, wie in der Personenbindung enthalten -
MOAFamilyName - der Nachname des Benutzers, wie in der Personenbindung enthalten -
MOADateOfBirth - das Geburtsdatum des Benutzers, wie in der Personenbindung enthalten -
MOABPK - die bereichsspezifische Personenkennzeichnung des Benutzers, wie von der -Authentisierungskomponente berechnet -
MOAWBPK - das wirtschaftsbereichsspezifische Personenkennzeichen des Benutzers, wie von der -Bügerkartenumgebung berechnet -
MOAPublicAuthority - wird durch true ersetzt, falls der Benutzer mit einem Zertifikat signierte, -welches eine Behördenerweiterung beinhaltet. Andernfalls wird false gesetzt -
MOABKZ - das Behördenkennzeichen (nur sinnvoll, wenn MOAPublicAuthority den Wert true -ergibt) -
MOAQualifiedCertificate - wird durch true ersetzt, falls das Zertifikat des Benutzers -qualifiziert ist, andernfalls wird false gesetzt -
MOAStammzahl - die Stammzahl des Benutzers; diese ist nur dann verfügbar, wenn die Online-Applikation -die Stammzahl bekommen darf (und daher in der Personenbindung enthalten ist) -
MOAIPAddress - IP-Adresse des Client des Benutzers. -

- -Anhand der <Parameter>-Elemente wird der Request für den Login-Vorgang (für stateful Online-Applikationen) -folgendermaßen zusammenge-stellt:
-

-GET https://<login-url>? - <p1.name=p1.resolvedValue>& - <p2.name=p2.resolvedValue>... -

-Die <login-url> ergibt sich aus dem Parameter OA des Aufrufs von MOA-ID-AUTH, -zusammen mit der Konfiguration von OnlineApplication/@publicURLPrefix und von OnlineApplication/ProxyComponent/ConnectionParameter/@URL. -
Der Wert resolvedValue wird in MOA-ID-PROXY je nach Wert des Platzhalters eingesetzt. -

-BasicAuth
-Das Element BasicAuth konfiguriert die übergabe der Authentisierungs-Parameter an die Online-Appliktion -mittels HTTP Basic Authentication. Es enthält zwei Kind-Elemente. -

-Das Element UserID gibt die UserId des zu authentisierenden Benutzers an und kann einen der durch -MOAAuthDataType beschriebenen Werte annehmen. -

-Das Element Password gibt das Passwort des zu authentisierenden Benutzers an und kann einen der durch -MOAAuthDataType beschriebenen Werte annehmen. -

- -

-HeaderAuth
-Das Element HeaderAuth konfiguriert die übergabe der Authentisierungs-Parameter an die Online-Applikation -in HTTP Request Headern. Das Element kann ein oder mehrere Kind-Elemente <Header> beinhalten. -

- -

-HeaderAuth/Header
-Das Element <Header> enthält die Attribute Name und Value. -

-Das Attribut Name beschreibt den Namen des Header und ist ein frei zu wählender String. -

-Das Attribut Value beschreibt den Inhalt des Header und kann einen der durch MOAAuthDataType -beschriebenen Werte annehmen. -

-Die Header werden folgendermaßen in den Request an die Online-Applikation eingefügt: -

-<h1.name>:<h1.resolvedValue>
-<h2.name>:<h2.resolvedValue>
-...
-

-Der Wert resolvedValue wird in der Proxykomponente je nach Wert des Platzhalters eingesetzt. -Etwaige Header aus dem ursprünglichen Request an die Proxykomponente, die denselben Namen haben, müssen -überschrieben werden. -

- - -

- - - -

-

-

Konfiguration von MOA-SP

- -

MOA-ID überprüft die Signaturen der Personenbindung und - des AUTH-Blocks mit dem VerifyXMLSignatureRequest von - MOA-SP. Dazu muss MOA-SP wie unten beschreiben konfiguriert werden. -
-
- VerifyTransformsInfoProfile
- Der Request zum überprüfen der Signatur des AUTH-Blocks - verwendet ein vordefiniertes VerifyTransformsInfoProfile. Die - im Request verwendete Profil-ID wird in der MOA-ID Konfigurationsdatei - im Element /MOA-IDConfiguration/ AuthComponent/MOA-SP/VerifyAuthBlock/ - VerifyTransformsInfoProfileID definiert. Entsprechend muss - am MOA-SP Server ein VerifyTransformsInfoProfile mit gleichlautender - ID definiert werden. Die Profiledefinition selbst ist in der Auslieferung - von MOA-ID in $MOA_ID_INST_AUTH/conf/moa-spss/profiles/MOAIDTransformAuthBlock.xml - enthalten. Diese Profildefinition muss unverändert übernommen - werden.

- -

-TrustProfile
-Die Requests zur überprüfung der Signatur verwenden vordefinierte TrustProfile. -Die im Request verwendete Profil-IDs werden in der MOA-ID Konfigurationsdatei -in den Elementen /MOA-IDConfiguration/AuthComponent/MOA-SP/VerifyIdentityLink/ TrustProfileID und -/MOA-IDConfiguration/AuthComponent/MOA-SP/VerifyAuthBlock/TrustProfileID definiert. Diese beiden Elemente -können unterschiedliche oder identische TrustProfileIDs enthalten. -Am MOA-SP Server müssen TrustProfile mit gleichlautender ID definiert werden. -Die Auslieferung von MOA-ID enthält das Verzeichnis $MOA_ID_INST_AUTH/conf/moa-spss/trustprofiles/MOAIDBuergerkarteRoot, -das als TrustProfile verwendet werden kann. Weitere Zertifikate können als vertrauenswürdig hinzugefügt werden. -

- -

-Certstore
-Zum Aufbau eines Zertifikatspfades können benötigte Zertifikate aus einem Zertifikatsspeicher verwendet werden. -Die Auslieferung von MOA-ID enthält das Verzeichnis $MOA_ID_INST_AUTH/conf/moa-spss/certstore, das als initialer -Zertifikatsspeicher verwendet werden kann. -

- -

-Hinweis: Mit dem Wechsel auf Version 1.3 verwendet MOA SP/SS ein neues Format für die XML-Konfigurationsdatei. -Für die Konvertierung einer älteren Konfigurationsdatei auf das neue Format steht Ihnen ein Tool -zur Verfügung. Details dazu finden sie in der der Distribution von MOA-SP/SS beiligenden -Dokumentation im Kapitel 'Konfiguration', Abschnitt 1.2.1.
- -

- - -

- - - -

-

-

Änderung der Konfiguration während des Betriebs

-Der Inhalt dieser Konfiguration, bzw. jene Teile, auf die indirekt verwiesen wird, können während des laufenden -Betriebes des MOA-Servers geändert werden. Der Server selbst wird durch den Aufruf einer URL -(im Applikationskontext von MOA ID) dazu veranlasst, die geänderte Konfiguration neu einzulesen. -Im Falle einer fehlerhaften neuen Konfiguration wird die ursprüngliche Konfiguration beibehalten. -

- - -

-

- - - - - - -

-
- - -