From 05fbf84d2f1af1e9920b4bde23ae3a730cf96b35 Mon Sep 17 00:00:00 2001 From: Thomas Lenz Date: Tue, 4 Mar 2014 15:56:59 +0100 Subject: Handbook protocoll update --- id/server/doc/handbook/config/config.html | 4 +- id/server/doc/handbook/protocol/Assertion.xml | 81 +++ id/server/doc/handbook/protocol/AuthRequest.xml | 38 ++ id/server/doc/handbook/protocol/idp_metadata.xml | 116 ++++ .../handbook/protocol/openIDconnect_sequenz.png | Bin 22117 -> 121367 bytes id/server/doc/handbook/protocol/protocol.html | 650 ++++++++++++++++++++- .../handbook/protocol/serviceprovider_metadata.xml | 95 +++ id/server/doc/handbook/spec/MOA-SPSS-2.0.0.wsdl | 128 ++++ id/server/doc/handbook/spec/MOA-SPSS-2.0.0.xsd | 572 ++++++++++++++++++ .../doc/htmlTemplates/template_onlineBKU.html | 37 ++ 10 files changed, 1709 insertions(+), 12 deletions(-) create mode 100644 id/server/doc/handbook/protocol/Assertion.xml create mode 100644 id/server/doc/handbook/protocol/AuthRequest.xml create mode 100644 id/server/doc/handbook/protocol/idp_metadata.xml create mode 100644 id/server/doc/handbook/protocol/serviceprovider_metadata.xml create mode 100644 id/server/doc/handbook/spec/MOA-SPSS-2.0.0.wsdl create mode 100644 id/server/doc/handbook/spec/MOA-SPSS-2.0.0.xsd create mode 100644 id/server/doc/htmlTemplates/template_onlineBKU.html diff --git a/id/server/doc/handbook/config/config.html b/id/server/doc/handbook/config/config.html index 52b894fe4..48ca18305 100644 --- a/id/server/doc/handbook/config/config.html +++ b/id/server/doc/handbook/config/config.html @@ -527,7 +527,6 @@ https://<host>:<port>/moa-id-configuration/secure/usermanagementInit
  • Online Applikation anlegen: Ein Benutzer ohne Admin-Rechte kann neue Online-Applikationen anlegen. Die Funktionen „Online-Applikation aktivieren“ (siehe Kapitel 3.2: ) steht jedoch nicht zur Verfügung. Somit muss die Online-Applikation von einem Benutzer mit Admin-Rechten aktiv geschalten werden.
  • Benutzerverwaltung: Ein Benutzer ohne Admin-Rechte kann keine neuen Benutzer erstellen. Dieser kann jedoch seinen Benutzeraccount bearbeiten und gegeben falls löschen. Beim Löschen eines Benutzeraccounts werden Online-Applikationen die von diesem erstellt wurden jedoch nicht automatisch gelöscht.
    • -

     

    2.2 MOA-ID-Auth

    Dieser Abschnitt behandelt die Basiskonfiguration des Modules MOA-ID-Auth. Der erste Teilabschnitt behandelt die Bekanntmachung der Konfigurationsdatei mittels einer System Property und der zweite Teilabschnitt beschreibt die einzelnen Konfigurationsparameter im Detail. Eine Konfiguration die als Ausgangspunkt für die individuelle Konfiguration verwendet werden kann finden Sie hier.

    2.2.1 Bekanntmachung der Konfigurationsdatei

    @@ -1563,7 +1562,8 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der http://demo.egiz.gv.at/demologin-pvp2-sso/metadata/demoportal-pvp2-sso.mdxml     - URL unter der die MOA-ID-Auth Instanz die Metadaten der Online-Applikation beziehen kann. Diese Metadaten müssen durch die Online-Applikation signiert sein. Für den Fall das die Metadaten über https abgeholt werden, muss ja jeweilige Serverzertifikat zur Zertifikatsprüfung im TrustStore der MOA-ID-Auth Instanz hinterlegt sein. +

    URL unter der die MOA-ID-Auth Instanz die Metadaten der Online-Applikation beziehen kann. Diese Metadaten müssen durch die Online-Applikation signiert sein. Für den Fall das die Metadaten über https abgeholt werden, muss ja jeweilige Serverzertifikat zur Zertifikatsprüfung im TrustStore der MOA-ID-Auth Instanz hinterlegt sein.

    +

    Hinweis: Metadaten können nur über http oder https abgeholt werden.

    Infos zum Zertifikat diff --git a/id/server/doc/handbook/protocol/Assertion.xml b/id/server/doc/handbook/protocol/Assertion.xml new file mode 100644 index 000000000..6be5c7384 --- /dev/null +++ b/id/server/doc/handbook/protocol/Assertion.xml @@ -0,0 +1,81 @@ + + + https://demo.egiz.gv.at/demoportal_moaid-2.0 + + + + + + + + + + + + + kvUKbjEOo7lVsclpkgHFkkbJ5bErwG/bu6KzGoJzLZs= + + + bNS+LN4YNeqKR05F+Y9YbRkPEJ87rhEK+Prk3pEnMBZT8VKWwP/ki4TdrupkFX3YjJvINXk2NFJxcB5GEbHxJjnpF8+K4gH2cPRyzDdS72mlO70mKg9Aa2chP/35c9kyGaHfzrw7Y4MzKjrkXfl76ekdL8UzHFYVFE4oUwtJXvrsg78RZNcy4aCuUvzsJbYwfriAjT7Cp93F5aum6oJ6kXk8XSHmh+yVzFSzYL+WkbIV+x7OOXVnoAWSY5d3tPGlr2LhjTf53q0pn+cggJ6jPfAVmwuxJTwe2C7xPlkylsQkswORMwXovGr+KqrcOpimxgeukvlJD+7YUHsi8uJMvg== + + + + xRE83dJy1dj+KVBp5Syo91fjGeG1MmJDSuTZ5MwdDzvIZrbK3YPh0jbJz4lOSrw9urRacavZX4m2 +XAKfSRxaowP3GqTh3Ew4WJE7yXEnWiic7bUz8uMIr020bsvqHCvY48+oPARbz/cEOf5NgMBWqo9E +nibdIyU5+AmfFzDaMwNocJEANoXrjLTpduCHvT0Qt/wH+7rVdgjX1djMrBhyMWs7GQyIBRfuf58m +8kdcoiMSm9AWA4d4GzXch+bi1QRzj+Ib80DeWdcXP3Hc6pcyp/+L+hya2jZ9NMS8yup6xuoAeh7w +6JNpfE9QnO3/CPrDZTtmjPK2OIRkhgn4Yi+iBQ== + AQAB + + + + + + + + + https://demo.egiz.gv.at/demoportal_moaid-2.0 + + QVGm48cqcM4UcyhDTNGYmVdrIoY= + + + + + + + https://demo.egiz.gv.at/demoportal_demologin/ + + + + + http://www.stork.gov.eu/1.0/citizenQAALevel/4 + + + + + 2.1 + + + Mustermann + + + Max + + + 1940-01-01 + + + BF:QVGm48cqcM4UcyhDTNGYmVdrIoY= + + + 4 + + + AT + + + urn:publicid:gv.at:cdid+BF + + + + diff --git a/id/server/doc/handbook/protocol/AuthRequest.xml b/id/server/doc/handbook/protocol/AuthRequest.xml new file mode 100644 index 000000000..9a5c5f481 --- /dev/null +++ b/id/server/doc/handbook/protocol/AuthRequest.xml @@ -0,0 +1,38 @@ + + + https://demo.egiz.gv.at/demoportal_demologin/ + + + + + + + + + + + 6azvvz1bk4wlcEoCEq3DgwYE/FU= + + + J+en/LY0okRfEW9KEX4sj6TydwHFrtY4PbS1wDvdpAr9v6qY4+PvKHIhfTY/D/DBMJq/bVMJj+y+LgXzyHbLitqEvJkgYeFBrfFLu/6I7zuqucHbip4YAd63Vrg6f5buxrY0S4uJniRGtEhkZDcGJ0Y9Bu3obWXMk7oK/tHtsrvejd27bQOzdZv1ESWiBorlTVPzkfvS13jNsIyeWOuQ/Zv0FKn9RenqvbIVWnG3xKiSEcKT4VaosDdvZX35wxEYh3Rk84ZySDdp502vCvpOjSkc64s6ZiqZcmwwpSNb3+uMwvUNF+gH7mAYs1FXit9/UaGyL30qXgEc+TUZd2o/iA== + + + + nEPzKMh3TovnfBnTyv+TMYFsGep8Uil7iNbfVyfLoBfqRdeGDOk4es2qWkgB6az+kM/9Js2H06m4 +pjEY7/RIjd0lMWqgi8eqdjilMmbFQykkYYQhlZbvi8KqoBcCKzj5N3GY4qh8A5qN4y85Q3sZj23T +iiIY1rphE+ZTOHCm6CKeRso9jj409YHP1xAXfPvtIYx2TA1uuagxOmL75OC/hr7gcUm0tmuKiSeq ++TO4VZw2Q7K7YESZ1WkiBoG2i4cHdcBFKnVrGNtyxl6UkjWxXRJSU9aNLs5QxsE6iFwCvFoIO+IU +cVWxfFHqOGbRtAcRUb4fk+KFHE2o1DLmfwZaUQ== + AQAB + + + + + + https://demo.egiz.gv.at/demoportal_demologin/ + + + + http://www.stork.gov.eu/1.0/citizenQAALevel/4 + + diff --git a/id/server/doc/handbook/protocol/idp_metadata.xml b/id/server/doc/handbook/protocol/idp_metadata.xml new file mode 100644 index 000000000..ff8a2cdf1 --- /dev/null +++ b/id/server/doc/handbook/protocol/idp_metadata.xml @@ -0,0 +1,116 @@ + + + + + + + + + + + + + TDy0AH/6p/9B1XhpoisAD3Rwx3fzQt75+tD+rvmA1ro= + + + QC+UmPuj/8cmpjyDtprXMz7bEZ3a5bJQT4QgJ3bkZ5sHfNR5u3NvYLdZbWwrzKiruDPdItYghTnXIv3fULBjR8j/51nOjgHQPzk8oz9MeJVFtH99AxLYwkYRk2bl1ZiPc5gZJOoyf0uF5nO+F9oJFV0CD91QVEBAKmnlGpED4s53EVojKFrXxbQUNEmNrHXq0o+iIIZnKUb+PDDjqr/IZoDmTYswsld7tv5+PZT6MyQADVHYfuU6DjY98vFCAFeBDyw7BY8dplFuUzqzvQ2AEF3vY+1lF2Xet6in9pjly3OZq+9greFkpcTZoyIBql+jS6qjf5WD51CjTm76xWQsRg== + + + + + + + + xRE83dJy1dj+KVBp5Syo91fjGeG1MmJDSuTZ5MwdDzvIZrbK3YPh0jbJz4lOSrw9urRacavZX4m2 +XAKfSRxaowP3GqTh3Ew4WJE7yXEnWiic7bUz8uMIr020bsvqHCvY48+oPARbz/cEOf5NgMBWqo9E +nibdIyU5+AmfFzDaMwNocJEANoXrjLTpduCHvT0Qt/wH+7rVdgjX1djMrBhyMWs7GQyIBRfuf58m +8kdcoiMSm9AWA4d4GzXch+bi1QRzj+Ib80DeWdcXP3Hc6pcyp/+L+hya2jZ9NMS8yup6xuoAeh7w +6JNpfE9QnO3/CPrDZTtmjPK2OIRkhgn4Yi+iBQ== + AQAB + + + + MIIEFTCCAv2gAwIBAgIJAI/HXXgQpJtFMA0GCSqGSIb3DQEBCwUAMGQxCzAJBgNVBAYTAkFUMRMw +EQYDVQQIEwpTb21lLVN0YXRlMQ0wCwYDVQQHEwRHcmF6MQ0wCwYDVQQKEwRFR0laMSIwIAYDVQQD +ExlNT0EtSUQgSURQIChUZXN0LVZlcnNpb24pMB4XDTE0MDEyMTA4NDAxOFoXDTE1MDEyMTA4NDAx +OFowZDELMAkGA1UEBhMCQVQxEzARBgNVBAgTClNvbWUtU3RhdGUxDTALBgNVBAcTBEdyYXoxDTAL +BgNVBAoTBEVHSVoxIjAgBgNVBAMTGU1PQS1JRCBJRFAgKFRlc3QtVmVyc2lvbikwggEiMA0GCSqG +SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFETzd0nLV2P4pUGnlLKj3V+MZ4bUyYkNK5NnkzB0PO8hm +tsrdg+HSNsnPiU5KvD26tFpxq9lfibZcAp9JHFqjA/capOHcTDhYkTvJcSdaKJzttTPy4wivTbRu +y+ocK9jjz6g8BFvP9wQ5/k2AwFaqj0SeJt0jJTn4CZ8XMNozA2hwkQA2heuMtOl24Ie9PRC3/Af7 +utV2CNfV2MysGHIxazsZDIgFF+5/nybyR1yiIxKb0BYDh3gbNdyH5uLVBHOP4hvzQN5Z1xc/cdzq +lzKn/4v6HJraNn00xLzK6nrG6gB6HvDok2l8T1Cc7f8I+sNlO2aM8rY4hGSGCfhiL6IFAgMBAAGj +gckwgcYwHQYDVR0OBBYEFKG3LzuPtAGCXUPTw3fo9dtsS9wWMIGWBgNVHSMEgY4wgYuAFKG3LzuP +tAGCXUPTw3fo9dtsS9wWoWikZjBkMQswCQYDVQQGEwJBVDETMBEGA1UECBMKU29tZS1TdGF0ZTEN +MAsGA1UEBxMER3JhejENMAsGA1UEChMERUdJWjEiMCAGA1UEAxMZTU9BLUlEIElEUCAoVGVzdC1W +ZXJzaW9uKYIJAI/HXXgQpJtFMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAME3wzEi +UAcF2pCDtMMJzX4IDhSkWNuvWtSMMy8Vgtcc2t570teIKh+qNKQWZyX3QFVE6ovDABg3ZUhn780l +G4/t6aMOUEeGg4udl7l0QRBRbdd+9oc0Aw5dQqku02AQ6wQd695PLj+F0GeA7cdef90aLPu6Rwa5 +z5BiKpReJZoul3NpjQXz7A1IslZOlIhEDcFUlBSn/+QfLOeNDKurvPT0OzUGSGfrv0AoniNHc/fz +lfyRmgFbzAVHedU5cIxcE0yHtEKFjFSVwtGng9rTJpoOoY4pvGvAHlw6GEgO+HwFukPDtnvY8vi/ +cfmNJhb06H+6mmHz929Bk4HuHoQj8X8= + + + + urn:oasis:names:tc:SAML:2.0:nameid-format:persistent + urn:oasis:names:tc:SAML:2.0:nameid-format:transient + urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + EGIZ + E-Government Innovationszentrum + http://www.egiz.gv.at + + + E-Government Innovationszentrum + Lenz + Thomas + thomas.lenz@egiz.gv.at + + + diff --git a/id/server/doc/handbook/protocol/openIDconnect_sequenz.png b/id/server/doc/handbook/protocol/openIDconnect_sequenz.png index 47b8f2784..2faff33ed 100644 Binary files a/id/server/doc/handbook/protocol/openIDconnect_sequenz.png and b/id/server/doc/handbook/protocol/openIDconnect_sequenz.png differ diff --git a/id/server/doc/handbook/protocol/protocol.html b/id/server/doc/handbook/protocol/protocol.html index bd6893af0..f75888f22 100644 --- a/id/server/doc/handbook/protocol/protocol.html +++ b/id/server/doc/handbook/protocol/protocol.html @@ -32,10 +32,447 @@

    Dieses Kapitel behandelt jene Authentifizierungsprotokolle die vom Modul MOA-ID-Auth unterstützt werden. Wobei die Verwendung der Protokolle PVP 2.1 oder OpenID Connect empfohlen wird. Das Protokoll SAML 1, welches bis zur MOA-ID Version 1.5.1 verwendet wurde, wird jedoch ab der Version 2.0 nur mehr aus Kompatibilitätsgründen angeboten und nicht mehr aktiv weiterentwickelt.

    +

    1.1 Übersicht der Zugangspunkte

    +

    In diesem Abschnitt sind die Zugangspunkte der vom Modul MOA-ID-Auth unterstützten Protokolle kurz zusammengefasst. Eine detailierte Beschreibung der einzelnen Protokolle finden Sie in den anschließenden Unterkapiteln.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ProtokollRequesttypURL
    PVP 2.1Metadatenhttps://<host>:<port>/moa-id-auth/pvp2/metadata

    PVP 2.1

    		Authentifizierungsrequest
    + POST Binding    		https://<host>:<port>/moa-id-auth/pvp2/post

    PVP 2.1

    		Authentifizierungsrequest
    +Redirect Binding    		https://<host>:<port>/moa-id-auth/pvp2/redirect
    OpenID ConnectAuthentifizierungsrequest
    + (AuthCode-Request)    		https://<host>:<port>/moa-id-auth/oauth2/auth
    OpenID Connect

    AccessToken-Request

    		https://<host>:<port>/moa-id-auth/oauth2/token
    SAML 1Authentifizierungsrequest

    https://<host>:<port>/moa-id-auth/StartAuthentication

    SAML 1

    GetAuthenticationData

    https://<host>:<port>/moa-id-auth/services/GetAuthenticationData

    +

    http://<host>:<port>/moa-id-auth/services/GetAuthenticationData

    +

    1.2 Übersicht der möglichen Attribute

    +

    Die nachfolgende Tabelle beinhaltet eine Liste aller Attribute die vom Modul MOA-ID-Auth an die Online-Applikation zurückgeliefert werden können, sofern diese nach der Authentifizierung zur Verfügung stehen. Alle Namen beziehen sich auf den Attributnamen im jeweiligen Protokoll. Detailinformationen zu den einzelnen Attributen finden Sie in der PVP 2.1 Spezifikation der der STORK Spezifikation.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ProtokolleBeschreibung
    PVP 2.1OpenID ConnectSAML 1
    NameProfil
    urn:oid:1.2.40.0.10.2.1.1.149BPKeID 

    Bereichsspezifisches Personenkennzeichen (bPK / wbPK)

    +

    Hinweis: Der Syntax für dieses Attribut ist bPK-value := (BEREICH ":" bPK) wobei unter Bereich der öffentliche Bereich (Target) der Online-Applikation oder die Stammzahl des Auftraggebers bei Anwendungs-verantwortlichen aus der Privatwirtschaft angegeben wird.

    urn:oid:2.5.4.42

    		given_nameprofile Vorname

    urn:oid:1.2.40.0.10.2.1.1.261.20

    		family_nameprofile Familienname
    urn:oid:1.2.40.0.10.2.1.1.55birthdateprofile Geburtsdatum im Format JJJJ-MM-TT
    urn:oid:1.2.40.0.10.2.1.1.261.64EID-CCS-URLeID URL auf die Bürgerkartenumgebung die für die Authentifizierung verwendet wurde. Im Falle einer Anmeldung mittels STORK steht dieses Attribut NICHT zur Verfügung.
    urn:oid:1.2.40.0.10.2.1.1.261.94EID-CITIZEN-QAA-LEVELeID Authentifizierungslevel des Bürgers
    urn:oid:1.2.40.0.10.2.1.1.261.32EID-ISSUING-NATIONeID Landescode gem. ISO-3166 ALPHA-2
    urn:oid:1.2.40.0.10.2.1.1.261.34EID-SECTOR-FOR-IDENTIFIEReID Bereich für den die bPK / wbPK berechnet wurde.
    urn:oid:1.2.40.0.10.2.1.1.261.62EID-AUTH-BLOCKeID Base64 kodierte Signatur die während des Authentifizierungsdaten vom Benutzer erzeugt wurde.
    urn:oid:1.2.40.0.10.2.1.1.261.66EID-SIGNER-CERTIFICATEeID Base64 kodiertes Zertifikat, dass für die Anmeldung verwendet wurde.
    urn:oid:1.2.40.0.10.2.1.1.261.36EID-SOURCE-PINeID_gov 

    Stammzahl der natürlichen Person

    +

    Hinweis: Dieses Attribut steht nur zur Verfügung wenn die Online-Applikation alle Anforderungen an eine Applikation aus dem öffentlichen Bereich erfüllt.

    urn:oid: 1.2.40.0.10.2.1.1.261.104EID-SOURCE-PIN-TYPEeID_gov 

    Bereich der Stammzahl, wobei aktuell nur ein Bereich existiert.

    +

    Hinweis: Dieses Attribut steht nur zur Verfügung wenn die Online-Applikation alle Anforderungen an eine Applikation aus dem öffentlichen Bereich erfüllt.

    urn:oid:1.2.40.0.10.2.1.1.261.38EID-IDENTITY-LINKeID_gov 

    Gesamte Personenbindung in BASE64 kodiert.

    +

    Hinweis: Im Falle einer privatwirtschaftlichen Applikation ist die Stammzahl durch die wbPK ersetzt.

    urn:oid:1.2.40.0.10.2.1.1.261.68MANDATE-TYPEmandate Bezeichnung des verwendeten Vollmachten-Profils.
    urn:oid:1.2.40.0.10.2.1.1.261.102MANDATOR-NATURAL-PERSON-SOURCE-PIN-TYPEmandate Bereich der Stammzahl der vertretenen natürlichen Person, wobei aktuell nur ein Bereich existiert.
    urn:oid:1.2.40.0.10.2.1.1.261.70MANDATOR-NATURAL-PERSON-SOURCE-PINmandate Stammzahl der natürlichen Person, für die Vollmachts- bzw. Vertretungsbe-fugnisse ausgeübt werden.
    urn:oid:1.2.40.0.10.2.1.1.261.76MANDATOR-LEGAL-PERSON-SOURCE-PIN-TYPEmandate Gibt an, um welche Art der Stammzahl einer vertretenen juristischen Person es sich handelt.
    urn:oid:1.2.40.0.10.2.1.1.261.100MANDATOR-LEGAL-PERSON-SOURCE-PINmandate Stammzahl der juristischen Person, für die Vollmachts- bzw. Vertretungsbe-fugnisse ausgeübt werden.
    urn:oid:1.2.40.0.10.2.1.1.261.98MANDATOR-NATURAL-PERSON-BPKmandate Bereichsspezifisches Personenkennzeichen des Vollmachtgebers
    urn:oid:1.2.40.0.10.2.1.1.261.78MANDATOR-NATURAL-PERSON-GIVEN-NAMEmandate Vorname(n) der natürlichen Person, die die Vollmacht erteilt hat, bzw. die vertreten wird.
    urn:oid:1.2.40.0.10.2.1.1.261.80MANDATOR-NATURAL-PERSON-FAMILY-NAMEmandate Nachname der Person, die die Vollmacht erteilt hat, bzw. die vertreten wird.
    urn:oid:1.2.40.0.10.2.1.1.261.82MANDATOR-NATURAL-PERSON-BIRTHDATEmandate Geburtsdatum der Person, die die Vollmacht erteilt hat, bzw. die vertreten wird im Format JJJJ-MM-TT
    urn:oid:1.2.40.0.10.2.1.1.261.84MANDATOR-LEGAL-PERSON-FULL-NAMEmandate Name der juristischen Person bzw. Personenmehrheit gemäß zugrundelie-gendem Register.
    urn:oid:1.2.40.0.10.2.1.1.261.86MANDATE-PROF-REP-OIDmandate Object Identifiern (OID) zur Kennzeichnung von berufsmäßigen ParteienvertreterInnen bzw. OrganwalterInnen.
    urn:oid:1.2.40.0.10.2.1.1.261.88MANDATE-PROF-REP-DESCRIPTIONmandate Textuelle Beschreibung der Eigenschaft als berufsmäßiger ParteienvertreterIn.
    urn:oid:1.2.40.0.10.2.1.1.261.90MANDATE-REFERENCE-VALUEmandate Die im Rahmen einer elektronischen Vollmachtserstellung generierte Transaktionsnummer.
    urn:oid:1.2.40.0.10.2.1.1.261.92MANDATE-FULL-MANDATEmandate Base64 kodierte Vollmacht im XML Format gemäß Vollmachten-Spezifikation.
    urn:oid:1.2.40.0.10.2.1.1.261.96EID-STORK-TOKENstork Beinhaltet die komplette Response Message eines STORK Providers im Base64-Format.
    http://www.stork.gov.eu/1.0/
    + inheritedFamilyName    		inheritedFamilyNamestork 

    Vererbter Familienname

    + Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.
    http://www.stork.gov.eu/1.0/
    + adoptedFamilyName    		adoptedFamilyNamestork 

    Angenommener Familienname

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + gender    		genderstork 

    Geschlecht

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + countryCodeOfBirth    		countryCodeOfBirthstork 

    Geburtsland

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + nationalityCode    		nationalityCodestork 

    Nationalität

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + maritalStatus    		maritalStatusstork 

    Familienstand

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + textResidenceAddress    		textResidenceAddressstork 

    Wohnadresse in Textform

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + canonicalResidenceAddress    		canonicalResidenceAddressstork 

    Anerkannte Wohnadresse

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + title    		titlestork 

    Titel

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + residencePermit    		residencePermitstork 

    Aufenthaltsbewilligung

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + pseudonym    		pseudonymstork 

    Pseudonym

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + age    		agestork 

    Alter

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + isAgeOver    		isAgeOverstork 

    Mindestalter erreicht

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    http://www.stork.gov.eu/1.0/
    + fiscalNumber    		fiscalNumberstork 

    Steuernummer

    +

    Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

    +

     

    2 PVP 2.1

    - - +

    Die PVP 2.1 Implementierung des Modules MOA-ID-Auth bezieht sich auf das S-Profil der PVP 2 Spezifikation. Das S - Profil von PVP 2 verwendet SAML WebSSO für die Authentifizierung von Benutzern mit Webbrowser. Dadurch wird die direkte Kommunikation des Browsers mit der Anwendung ermöglicht, was in Anwendungsfällen notwendig ist, wo Anwendungen nicht kompatibel mit dem Reverse - Proxy - Verfahren sind, datenschutzrechtliche Probleme bestehen oder SAML WebSSO als Industriestandard unterstützt werden soll.

    +

    Bevor PVP 2.1 als Authentifizierungsprotokoll verwendet werden kann muss das Modul MOA-ID-Auth entsprechend konfiguriert werden. Detailinformationen zur Konfiguration finden Sie hier.

    +

    2.1 Ablauf einer Anmeldung mittels PVP 2.1

    +

    Die nachfolgende Abbildung zeigt das Sequenzdiagramm eines Anmeldevorgangs mittels PVP 2.1 und des Modules MOA-ID-Auth als Identityprovider. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung oder die Vollmachten-Auswahl betreffen bewusst nicht berücksichtigt.

    +

     

    +

    2.2 Metadaten

    +

    Das Modul MOA-ID-Auth stellt für Service-Provider (Online-Applikationen) Metadaten bereit welche alle PVP 2.1 spezifischen Informationen der MOA-ID-Auth Instanz beinhalten. Diese Metadaten werden durch das Modul MOA-ID-Auth signiert, wodurch Service Provider die Authentizität der Metadaten verifizieren können. Ein Beispiel für Metadaten von MOA-ID-Auth finden sie hier. Die aktuellen Metadaten zu Ihrer MOA-ID-Auth Instanz können unter folgender URL abgerufen werden.

    +
    http://<host>:<port>/moa-id-auth/pvp2/metadata
+
    +

    bzw.

    +
    +https://<host>:<port>/moa-id-auth/pvp2/metadata
+
    +

    Wollen Sie für Ihre Online-Applikation PVP 2.1 als Authentifizierungsprotokoll nutzen müssen für jede Online-Applikation Metadaten erstellt und durch den Service Provider signiert werden. Zusätzlich muss die URL auf die Metadaten und das entsprechende Signaturzertifikat zur Prüfung der Signatur in der online-applikationsspezifischen PVP 2.1 Konfiguration von MOA-ID-Auth hinterlegt sein. Ein Beispiel für online-applikationsspezifische Metadaten finden Sie hier.

    +

    Die nachfolgenden Anforderungen an die online-applikationsspezifischen Metadaten .

    + +

    Zusätzlich unterstützt das Modul MOA-ID-Auth auch die Verschlüsselung PVP 2.1 Assertion mit einem vom Service-Provider definierten Zertifikat. Um diese Funktion zu nutzen muss in den Metadaten ein zweites XML Element md:EntitiesDescriptor/md:EntityDescriptormd:SPSSODescriptor/md:KeyDescriptor mit dem Attribut use="encryption" vorhanden sein (siehe Beispiel). In diesem Fall verwendet das Modul MOA-ID-Auth, dass in diesem Element hinterlegte Zertifikat zur Verschlüsselung der PVP 2.1 Assertion.

    +

    Hinweis: Fehlt im XML Element md:EntitiesDescriptor/md:EntityDescriptormd:SPSSODescriptor/md:KeyDescriptor das Attribut use wird das in diesem Element hinterlegte Zertifikat sowohl zur Prüfung der Signatur des Authentifizierungsrequest als auch zur Verschlüsselung der PVP 2.1 Assertion verwendet.

    +

    2.3 Zugangspunkte

    +

    Für die Kommunikation zwischen Service Provider und dem Modul MOA-ID-Auth stellt MOA-ID-Auth aktuell zwei PVP 2.1 spezifische Zugangspunkte zur Verfügung. Detailinformationen zu den beiden Zugangspunkten (Bindings) entnehmen finden Sie in der SAML2 Spezifikation.

    + +
    https://<host>:<port>/moa-id-auth/pvp2/post
    + +
    https://<host>:<port>/moa-id-auth/pvp2/redirect
    +

    Hinweis: Die Zugangspunkte können auch direkt aus den von MOA-ID-Auth generierten Metadaten entnommen werden.

    +

    2.3.1 Authentifizierungsrequest

    +

    Der Authentifizierungsrequest wird vom Service Provider erstellt und an das Modul MOA-ID-Auth übermittelt. Zur Übertragung, muss je nach verwendetem Binding, einer der beiden Zugangspunkte und die entsprechende Kodierung der Parameter verwendet werden.

    +

    Folgende Minimalanforderungen an den Authentifizierungsrequest müssen erfüllt sein.

    + +

    Einen Beispielrequest finden Sie hier.

    +

    Hinweis: Detailinformationen finden Sie im Abschnitt Spezifikationen in der PVP 2.1 Spezifikation und der SAML2 Spezifikation.

    +

    2.3.2 Authentifizierungsresponse

    +

    Nach erfolgreicher Authentifizierung antwortet das Modul MOA-ID-Auth mit einer PVP 2.1 Assertion. Zur Übertragung der Assertion erfolgt an das in den Metadaten der Online-Applikation angegebene AssertionConsumerService (siehe Metadaten).

    3 OpenID Connect

    OpenID Connect ist ein Authentifizierungsprotkoll welches auf dem OAuth 2.0 Protokoll aufbaut. Dieses Protokoll erlaubt Online-Applikationen die Identifizierung und Authentifizierung von Benutzern, mit Hilfe des Modules MOA-ID-Auth. Der Vorteil von OpenID Connect im Vergleich zu auf SAML basierten Protkollen (PVP 2.1, SAML 1) ist der einfachere Aufbau der einzelnen Protokollnachrichten. Zusätzlich existieren einige frei Verfügbare Bibliotheken für unterschiedliche Programmiersprachen, welche OpenID Connect implementieren.

    Bevor OpenID Connect in Kombination mit dem Modul MOA-ID-Auth verwendet werden kann muss das Modul MOA-ID-Auth konfiguriert werden. Detailinformationen zur Allgemeinen Konfiguration und zur online-applikationsspezifischen Konfiguration finden Sie im jeweiligen Abschnitt des Kapitels Konfiguration. TODO!

    @@ -44,13 +481,40 @@

    3.1 Ablauf einer Anmeldung mittels OpenID Connect

    Die nachfolgende Abbildung zeigt das Sequenzdiagramm eines Anmeldevorgangs mittels OpenID Connect und des Modules MOA-ID-Auth als Identityprovider. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung oder die Vollmachten-Auswahl betreffen bewusst nicht berücksichtigt.

    -

    TODO:

    - +

    Sequenzdiagramm OpenID Connect

    +
      +
    1. Der Benutzer verbindet sich zu einem Web-Portal (Service Provider) über das die Online-Applikation erreichtbar ist. Nach der Betätigung eines Login-Buttons wird der Anmeldevorgang ausgelöst.
      2. +
    2. Der Service Provider generiert den AuchCode Request und sendet diesen über den Browser an das Modul MOA-ID-Auth.
      3. +
    3. MOA-ID-Auth validiert den AuthCode Request.
      4. +
    4. MOA-ID-Auth leitet die BenutzerIn oder den Benutzer zur Bürgerkartenauswahl +
        +
      1. Die BenutzerIn oder der Benutzer Authentifiziert sich mit der gewählten Methode.
        2. +
      +
      5. +
    5. Nach erfolgreicher Authentifizierung erzeugt MOA-ID-Auth die AuthCode Response. +
        +
      1. Die AuthCode Response wird mittels Redirect an den Service Provider retourniert.
        2. +
      +
      6. +
    6. Der Service Provider validiert die AuthCode Response.
      7. +
    7. Der Service Provider generiert den AccessToken Request und sendet diesen an MOA-ID-Auth zum Abholen der Benutzerdaten.
      8. +
    8. MOA-ID-Auth validiert den AccessToken Request
      9. +
    9. MOA-ID-Auth generiert die AccessToken Response +
        +
      1. Retournierung der AccessToken Response an den Service Provider
        2. +
      +
      10. +
    10. Validieren der AccessToken Response +
        +
      1. Wird die Validierung gültig abgeschlossen kann die BenutzerIn oder der Benutzer am Service Provider angemeldet werden.
        2. +
      +
      11. +

    3.2 Zugangspunkte

    Zur Verwendung von OpenID Connect stellt das Modul MOA-ID-Auth zwei Zugangspunkte zur Kommunikation mit der Online-Applikation zur Verfügung. Diese Zugangspunkte bezeichnen die URLs unter welchen das Modul MOA-ID-Auth die entsprechenden OpenID Connect Nachrichten entgegennimmt.

    3.3 Beschreibung der Nachrichten

    @@ -58,18 +522,184 @@

    3.2.1 AuthCode Request

    Der AuthCode Request ist die Authentifizierungsanfrage einer Online-Applikation für eine BenutzerIn oder einen Benutzer. -Folgende Parameter müssen oder können mit dem AuthCode-Request mitgesendet werden, wobei für die Übertragung der Parameter sowohl http GET als auch http POST verwendet werden kann.

    - - +Folgende Parameter müssen mit dem AuthCode-Request mitgesendet werden, wobei für die Übertragung der Parameter sowohl http GET als auch http POST verwendet werden kann.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameBeispielwertBeschreibung
    client_idhttps://demo.egiz.gv.at/demoportal-openID_demoIst der eindeutige Identifikatior für die Online-Applikation. Dieser MUSS mit dem Identifikatior aus der Konfiguration identisch sein.
    response_typecode

    Rückgabewert des AuthCode Requests.

    + Hinweis: Dieser Wert MUSS "code" sein.
    redirect_urihttps://demo.egiz.gv.at/demoportal-openID_demo/securearea.actionDie Callback-URI der Online-Applikation zu welcher die Callbacks der OAuth 2.0 Request gesendet werden. Dieser MUSS mit der Redirct URL aus der Konfiguration identisch sein.
    state1425782214234Ein von der Online-Applikation generierter Wert welcher in beiden Requests (AuthCode und Token) gleich sein muss (ein CSRF Token)
    scopeopenID profile eID

    Definiert welche Authentifizierungsinformationen an die Online-Applikation zurückgeliefert werden.

    +

    Mögliche Werte sind: openId, profile, eID, eID_gov, mandate, stork wobei die Werte mittels Leerzeichen kombiniert werden können. Der Wert openID muss immer angegeben werden. Der Inhalt der einzelnen Profile, mit Ausnahme des Profiles openID, kann aus der Übersicht der möglichen Attribute entnommen werden.

    +
      +
    • openID: +
        +
      • bpk --> Bereichsspezifisches Kennzeichen (bPK / wbPK)
        • +
      • iss --> Public URP Prefix der MOA-ID Instanz
        • +
      • exp --> Zeitliche Gültigkeit
        • +
      • iat --> Ausstellungszeitpunkt
        • +
      • auth_time --> Authentifizierungszeitpunkt
        • +
      +
      • +
    +

     

    +

    Nachfolgend ein Beispiel für einen OpenID Connect Authentifizierungsrequest an das Modul MOA-ID-Auth.

    +
    <form method="get" action="https://demo.egiz.gv.at/demoportal_moaid-2.0/oauth2/auth">
+  <input type="hidden" value="code" name="response_type">
+  <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo" name="client_id">
+  <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action" name="redirect_uri">
+  <input type="hidden" value="profile eID eID_gov mandate" name="scope"> 
+  <input type="hidden" value="1152547590" name="state">
+  <input type="submit" value="OpenID Connect login">
+</form>

    3.2.2 AuthCode Response

    - +

    Das Ergebnis des AuthCode Requests wird an die redirect_uri der Online-Applikation gesendet. Die nachfolgenden Parameter werden dabei übergeben.

    + + + + + + + + + + + + + + + + +
    NameBeispielwertBeschreibung
    state1425782214234Der von der Online-Applikation generierte und im AuthCode Request übergebene CSRF Token.
    code4/P7q7W91a-oMsCeLvIaQm6bTrgtp7

    Ein vom Modul MOA-ID-Auth generierter Wert, welcher beim Abholen des AccessTokens (AccessToken Request) wieder an MOA-ID-Auth übergeben werden muss.

    +

     

    +

    Nochfolgend ein Beispiel für eine AuthCode Response.

    +
    https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action?state=1425782214234&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7

    3.2.3 AccessToken Request

    +

    Mit dem AccessToken Request können vom Service Provider der Online-Applikation die Anmeldedaten an der MOA-ID-Auth Instanz abgeholt werden. Für die Abholung müssen folgende Parameter mit dem AccessToken Request an MOA-ID-Auth übertragen werden, wobei für die Übertragung der Parameter sowohl http GET als auch http POST verwendet werden kann.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameBeispielwertBeschreibung
    grant_typeauthorization_codeDieser MUSS den Wert „authorization_code“ besitzen.
    code4/P7q7W91a-oMsCeLvIaQm6bTrgtp7

    Dieser Parameter wird in der AuthCode Response an die Online-Applikation (Service Provider) übertragen und muss in diesem Request wieder übermittelt werden.

    redirect_urihttps://demo.egiz.gv.at/demoportal-openID_demo/securearea.actionDie Callback-URI der Online-Applikation zu welcher die Callbacks der OAuth 2.0 Request gesendet werden. Dieser MUSS mit der Redirct URL aus der Konfiguration identisch sein.
    client_idhttps://demo.egiz.gv.at/demoportal-openID_demoIst der eindeutige Identifikatior für die Online-Applikation. Dieser MUSS mit dem Identifikatior aus der Konfiguration identisch sein.
    client_secret0adf1ec7-c2a6-4fd3-897c-456d0fb7b5ccDas Client Password der Online-Applikation. Dieses MUSS mit dem Client Password aus der Konfiguration identisch sein.
    +

     

    +

    Nachfolgend ein Beispiel für einen AccessToken Request

    +
    <form method="POST" action="https://demo.egiz.gv.at/demoportal_moaid-2.0/oauth2/token">
+  <input type="hidden" value="authorization_code" name="grant_type">
+  <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo" name="client_id">
+  <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action" name="redirect_uri">
+  <input type="hidden" value="0adf1ec7-c2a6-4fd3-897c-456d0fb7b5cc" name="client_secret"> 
+  <input type="hidden" value="4/P7q7W91a-oMsCeLvIaQm6bTrgtp7" name="code">
+</form>

    3.2.4 AccessToken Response

    +

    Die AccessToken Response beinhaltet ein signiertes JSON-Token welches alle angeforderten (Parameter scope im AuthCode Request) und vorhandenen Authentifizierungsdaten beinhaltet. Dieses JSON-Token ist mit einer JSON Web Signatur von MOA-ID-Auth signiert, wobei die Signatur alle angeforderten Daten einschließt. Details zur Konfiguration des Signatur Zertifikats finden Sie hier.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameBeispielwertBeschreibung
    access_tokenSlAV32hkKG

    Ein AccessToken welches für eine anschließende Kommunikation mit MOA-ID-Auth verwendet werden kann.

    +

    Hinweis: Diese Funktion wird jedoch aktuell nicht unterstützt.

    token_typeBearer

    OpenID Connect spezifischer Parameter (Details entnehmen Sie bitte der OpenID Connect Spezifikation)

    expires_in3600Gültigkeitszeitraum der Response (TODO)
    scopeopenID profile eIDDie im AuthCode Request angeforderten Profile.
    id_tokeneyJhbGciOiJSU.....Dieses Element beinhaltet die eigentlichen Authentifizierungsdaten und ist durch eine JSON Web Signatur signiert.

     

    +

    Nachfolgend ein Beispiel für einen AccessToken Response

    +
    {
+	"access_token": "SlAV32hkKG",
+  "token_type": "Bearer",
+  "expires_in": 3600,
+  "scope": "openid eID"
+  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
+               yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
+               NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
+               fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
+               AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
+               Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
+               NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
+               QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
+               K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
+               XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
+}

    3 SAML 1

    diff --git a/id/server/doc/handbook/protocol/serviceprovider_metadata.xml b/id/server/doc/handbook/protocol/serviceprovider_metadata.xml new file mode 100644 index 000000000..15e26469c --- /dev/null +++ b/id/server/doc/handbook/protocol/serviceprovider_metadata.xml @@ -0,0 +1,95 @@ + + + + + + + + + + + + + xLFVU7fH3+IC84vAuSZTP7+oeGk= + + + d1GD51DilpbwQdL9BONrhQS9zeydpWw8r/DKp/k5nLDQ6Tpw+OQgqYWvsMcnMgrltJa/4Q326fEf6HdFbLfrHSij8Nfx8i2idJ9JUwpj1R2GE0eo+8NXvJ/1H9Nf0pPjZ35MXQ9bC2fN/HnPalRaJSd9gCk/hW/KtB0r4qODkppz0hHplIKs7kqDnzd7ZT7golGI801N6DwzJ3jW8U26OOhzXtCbTsDdZE5gvA34kH5EDaa9RMx2JIPqBjzvDAE7oylKg2VcQdpJ1xLEi3zOF2kvgTLi6+CLHbQDc1JKcWJ10FC9yATT7poHJOgjoZ8Vt5QZJ12PKJ1NnopwcsvJ4g== + + + + + + + MIIDhTCCAm2gAwIBAgIEUflpdjANBgkqhkiG9w0BAQsFADBzMRAwDgYDVQQGEwdVbmtub3duMRAw +DgYDVQQIEwdVbmtub3duMRAwDgYDVQQHEwdVbmtub3duMRAwDgYDVQQKEwdVbmtub3duMRAwDgYD +VQQLEwdVbmtub3duMRcwFQYDVQQDEw5QVlAgU2FtcGxlIElEUDAeFw0xMzA1MDIwODE5MDlaFw0x +MzA3MzEwODE5MDlaMHMxEDAOBgNVBAYTB1Vua25vd24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNV +BAcTB1Vua25vd24xEDAOBgNVBAoTB1Vua25vd24xEDAOBgNVBAsTB1Vua25vd24xFzAVBgNVBAMT +DlBWUCBTYW1wbGUgSURQMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmWrWy07+hO2V +oMeOHpizN3qU2cL2e3EkzAkowmG+OpsR3UpI0dvolRuzaxDPUeANfE913KPempsT3cOKGS5IIBmx +PgZM1H7EcEPVS2PYimMr1HztBMJMGAdFVFeVFsgdYP4cbwPUs03/E6kVmN7/C+vMyRPMD7i83YL8 +/IHChymZ5aJTsRXUpM0TjQQPBQbnnHVWzjcUJ9z9KataS/KpUUM8iSWk73u/gWOs3vbQLoro80xj +LsSdXyJ9dVTCTwCpdP5UJPlsNLg1F7AU+OHwem76rezI0JJZhHUMg6v1xWzh8XycI6CizpD6RmkM +XfICbFD8TR5zcNBieH/yNQeAEwIDAQABoyEwHzAdBgNVHQ4EFgQUoLaHuWuxRrEh37oIQ0GzfDpy +h4MwDQYJKoZIhvcNAQELBQADggEBAAaAJVSji/OMCUZtSSIYM37go1+JLSamSkkftbkKmMWGBeKj +i9ndilpFY/Fbslt+lUueOyd5VawWPYorQBksyJH7glmQexMzEbwqPR8t+++Dq5+mj/XjXrYHlPej +FvCMy5kElxXczIQZmsutGtamreyAMpFMa3T2pU5tuVNwSbe754dOztaX6E92IGZtApKIHm/uLU75 +JQkTWhP9I3DaNX593VYPkeAoYxzaX1ElE2HFs4ELRzMXa0joTaGLyZ6LdLcK1bR3um9OywHWeiab +xtSAML1SoKfTcmzWCpb0yFhfOUKXyw+SikBAkiQruMK8PcboY9VFrKUSzKHBvnDC4U4= + + + + + + + MIIELTCCAxWgAwIBAgIJALF/kMqjWCxQMA0GCSqGSIb3DQEBCwUAMGwxCzAJBgNVBAYTAkFUMRMw +EQYDVQQIEwpTb21lLVN0YXRlMQ0wCwYDVQQHEwRHcmF6MQ0wCwYDVQQKEwRFR0laMSowKAYDVQQD +EyFNT0EtSUQtQ29uZmlndXJhdGlvbiAoRW5jcnlwdGlvbikwHhcNMTQwMTIxMDkzMDIzWhcNMTUw +MTIxMDkzMDIzWjBsMQswCQYDVQQGEwJBVDETMBEGA1UECBMKU29tZS1TdGF0ZTENMAsGA1UEBxME +R3JhejENMAsGA1UEChMERUdJWjEqMCgGA1UEAxMhTU9BLUlELUNvbmZpZ3VyYXRpb24gKEVuY3J5 +cHRpb24pMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr+5eXUViI2d/KLqfej29BNeD +DiDzhWlpAViPconGsEDHrXFNeSd3DTuJKH6x06wrpGfvtTh91ThId0R0hthS82aaKTlW1SgX/Rps +5VlmiNXQty8/UrrnqAsIO65jbsy41EXTDVrnDbg5WmK2xsowk7d4jUE4cdk3VKu07Kzg9ZiQHz8V +WMmGGPIXVs87+wgjq68tvo3+Nk5fcKPyV4ff2oc5/muxjavGdAIDJV2E/dDHwM3fbNFXk5OAse2V +8/vmHCm0bzVOP+V5vNxp1r8myZ914WYFt0WJL4/oyyrerGK6gqGdkLcGfMutaJvBxV+hNIMGLWMc +6LjCWVARIXvHyQIDAQABo4HRMIHOMB0GA1UdDgQWBBR9aJK1JouIYwcn2ycQUsPv4Q8BaDCBngYD +VR0jBIGWMIGTgBR9aJK1JouIYwcn2ycQUsPv4Q8BaKFwpG4wbDELMAkGA1UEBhMCQVQxEzARBgNV +BAgTClNvbWUtU3RhdGUxDTALBgNVBAcTBEdyYXoxDTALBgNVBAoTBEVHSVoxKjAoBgNVBAMTIU1P +QS1JRC1Db25maWd1cmF0aW9uIChFbmNyeXB0aW9uKYIJALF/kMqjWCxQMAwGA1UdEwQFMAMBAf8w +DQYJKoZIhvcNAQELBQADggEBAFSMmGNTAhDfoadFz0SrMDLjrPGIGjanbijLTOEURZYJiB4sQxa8 +3H6FNy1zvfzmPnrdbFr15w/6KgF9YP/0/JMUalrhm1JKWBY4TqJcG2BumAUcLSdsHOsezRi5E14s +WF2sNRa8C0LkfMfCW/wBCLXPn68XhQW7MuGgpEVrRenXQ3hwSykNiKq4vfn8tg+1hKwlrM3pbQQw +7YmXUm9TnHmkvJfZJEgSiFiLUjc1HxUFNl23PGjKJ1GxDerS7pBHG23KkVZTacuKM/MjVfFeFQJ4 +8JcRJUO0HuM6O1v/1sumtq/4wrKYo5I5LZPRuEKGNFme9hi/1BQT9bK9roZlxH0= + + + + urn:oasis:names:tc:SAML:2.0:nameid-format:persistent + urn:oasis:names:tc:SAML:2.0:nameid-format:transient + urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified + + + Default Service + + + + + + + + + + + + + + + + + + + + + + + diff --git a/id/server/doc/handbook/spec/MOA-SPSS-2.0.0.wsdl b/id/server/doc/handbook/spec/MOA-SPSS-2.0.0.wsdl new file mode 100644 index 000000000..4f9deee38 --- /dev/null +++ b/id/server/doc/handbook/spec/MOA-SPSS-2.0.0.wsdl @@ -0,0 +1,128 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/id/server/doc/handbook/spec/MOA-SPSS-2.0.0.xsd b/id/server/doc/handbook/spec/MOA-SPSS-2.0.0.xsd new file mode 100644 index 000000000..73d145ecf --- /dev/null +++ b/id/server/doc/handbook/spec/MOA-SPSS-2.0.0.xsd @@ -0,0 +1,572 @@ + + + + + + + + + + + + + + + + + + + + Ermöglichung der Stapelsignatur durch wiederholte Angabe dieses Elements + + + + + + + + + + + + + + + + + + + + + + Kardinalität 1..oo erlaubt die Antwort auf eine Stapelsignatur-Anfrage + + + + Resultat, falls die Signaturerstellung erfolgreich war + + + + + + + + + + + + + + + + + + + + Ermöglichung der Stapelsignatur durch wiederholte Angabe dieses Elements + + + + + + + + + + + + + + + + + + + Auswahl: Entweder explizite Angabe des Signaturorts sowie ggf. sinnvoller Supplements im Zshg. mit der Signaturumgebung, oder Verweis auf ein benanntes Profil + + + + + + + + + + + + + + + + + + Kardinalität 1..oo erlaubt die Antwort auf eine Stapelsignatur-Anfrage + + + + Resultat, falls die Signaturerstellung erfolgreich war + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + mit diesem Profil wird eine Menge von vertrauenswürdigen Wurzelzertifikaten spezifiziert + + + + + + + + + + + only ds:X509Data and RetrievalMethod is supported; QualifiedCertificate is included as X509Data/any;publicAuthority is included as X509Data/any; SecureSignatureCreationDevice is included as X509Data/any, IssuingCountry is included as X509Data/any + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Pro dsig:Reference-Element in der zu überprüfenden XML-Signatur muss hier ein ReferenceInfo-Element erscheinen. Die Reihenfolge der einzelnen ReferenceInfo Elemente entspricht jener der dsig:Reference Elemente in der XML-Signatur. + + + + + + + + + + mit diesem Profil wird eine Menge von vertrauenswürdigen Wurzelzertifikaten spezifiziert + + + + + + + + + + + only ds:X509Data and ds:RetrievalMethod is supported; QualifiedCertificate is included as X509Data/any; PublicAuthority is included as X509Data/any; SecureSignatureCreationDevice is included as X509Data/any, IssuingCountry is included as X509Data/any + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Auswahl: Entweder explizite Angabe EINER Transformationskette inklusive ggf. sinnvoller Supplements oder Verweis auf ein benanntes Profil + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Resultat, falls die Signaturerstellung gescheitert ist + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Ein oder mehrere Transformationswege können von der Applikation an MOA mitgeteilt werden. Die zu prüfende Signatur hat zumindest einem dieser Transformationswege zu entsprechen. Die Angabe kann explizit oder als Profilbezeichner erfolgen. + + + + + Profilbezeichner für einen Transformationsweg + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Die Angabe des Transformationsparameters (explizit oder als Hashwert) kann unterlassen werden, wenn die Applikation von der Unveränderlichkeit des Inhalts der in "Transformationsparamter", Attribut "URI" angegebenen URI ausgehen kann. + + + + Der Transformationsparameter explizit angegeben. + + + + + Der Hashwert des Transformationsparameters. + + + + + + + + + + + + + + + + + + + + + + Explizite Angabe des Transformationswegs + + + + + + + Alle impliziten Transformationsparameter, die zum Durchlaufen der oben angeführten Transformationskette bekannt sein müssen, müssen hier angeführt werden. Das Attribut "URI" bezeichnet den Transformationsparameter in exakt jener Weise, wie er in der zu überprüfenden Signatur gebraucht wird. + + + + + + + + + + + + + + + + diff --git a/id/server/doc/htmlTemplates/template_onlineBKU.html b/id/server/doc/htmlTemplates/template_onlineBKU.html new file mode 100644 index 000000000..52abf83fb --- /dev/null +++ b/id/server/doc/htmlTemplates/template_onlineBKU.html @@ -0,0 +1,37 @@ + + + + + + + + +
    + Falls Sie nicht automatisch weitergeleitet werden klicken Sie bitte hier: + + + + + + + + + + + + +
    + +
    + + +
    +
    +
    + + -- cgit v1.2.3