& & Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 Projektbezeichnung Prototyp Interoperable Servicekonten Dokumentname Überblick über den Lösungsvorschlag Projektleiter Herr Kirschenbauer (StMFLH) Version 0.2 Erstellt am 05.10.2016 Zuletzt geändert Anton Kronseder, 05.10.2016 Bearbeitungszustand In Bearbeitung Dokumentablage https://www.interoperable-servicekonten.de/p/x/LoBv Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 2 Änderungsverzeichnis Nr. 1 Datum 01.09.2016 V Kapitel 0.1 Alle Beschreibung Initiale Erstellung Autor Zustand Anton Nicht Kronseder, veröffentlicht Robert Reiner 2 05.10.2016 0.2 Alle Klarstellung: IdP-Proxy nur als zentrale Anton In Instanz nicht erlaubt Kronseder, Bearbeitung Klarstellung zu Vertrauenszonen Klarstellung der Abläufe Robert Reiner (Vertrauenszonen) Klarstellung der Kommunikationswege im Dipol Vereinfachte Grafik für Dipoleigenschaft, Text angepasst Klarstellung: VD tritt nicht als SP auf (Proxy-Alternative) Konkretisierung von SAML-Proxy zu SAML-IdP-Proxy Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 3 Dieses Dokument beschreibt in einem kurzen Überblick die gewählte Lösung und grenzt sie gegenüber alternativen Lösungen ab. Diese Hintergrundinformation ist für das Verständnis der Integration von Servicekonten für die Teilnehmer relevant. Die in diesem Dokument beinhalteten Spezifikationen und Definitionen stellen eine Diskussionsgrundlage für die Teilnehmer am fachlichen Prototypen und dem BSI dar. Der Hinweis, dass jede Aussage oder Forderung ungeachtet der Formulierung stets nur ein Vorschlag ist erfolgt aus Gründen der Lesbarkeit nur jeweils zu Beginn eines Tour-Dokuments. In Teilen der Dokumentation, beispielsweise welche Attribute in der Föderation übermittelt werden und wie diese aufgebaut sein sollen, werden lediglich Vorschläge unterbreitet, da es sich hier um nicht technische, sondern um fachliche Spezifikationen handelt. Die fachlichen Spezifikationen sollen von den Teilnehmern am fachlichen Prototypen erarbeitet und mit dem BSI abgestimmt werden. Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 4 Inhaltsverzeichnis 1 Realisierung...............................................................................................6 1.1 Zusammenfassung ............................................................................................................ 6 1.2 Hintergrund....................................................................................................................... 7 1.3 Servicekonten als Schlüssel .............................................................................................. 7 1.4 Vertrauenszonen .............................................................................................................. 8 1.5 Servicekonto ist ein Dipol ............................................................................................... 10 1.6 Informationen zur Anbindung ........................................................................................ 11 2 Alternativen ............................................................................................ 12 2.1 Alternative Standards ..................................................................................................... 12 2.2 SAML-IdP-Proxies ............................................................................................................ 12 2.3 Discovery-Service ............................................................................................................ 14 3 Literaturverweise .................................................................................... 16 4 Glossar .................................................................................................... 17 Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 5 1 Realisierung Ein Überblick über die Implementierung der Integration von interoperablen Servicekonten. 1.1 Zusammenfassung Dieses Dokument beschreibt, wie Servicekonten unterschiedlicher Anbieter innerhalb der Föderation miteinander kommunizieren. Es wird gezeigt, dass Verwaltungsdienste nur mit ihrem eigenen Servicekonto interagieren. Die Interoperabilität ist damit ausschließlich auf den Servicekonten definiert. Abbildung: Schematische Darstellung eines Servicekontos mit seinen Schnittstellen und den Metadaten Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 6 1.2 Hintergrund Im Fokus steht die Interoperabilität und die Fähigkeit der Föderationsmitglieder ihre Innovationskraft in die Föderation einzubringen. Aus diesem Grund wird die Schnittstelle der Verwaltungsdienste bei der Interoperabilität der Servicekonten nicht berücksichtigt. Auf diese Weise steht es den einzelnen Föderationsteilnehmern frei, wie sie ihre Verwaltungsdienste an ihre Servicekonten anbinden. Der Verwaltungsdienst selbst spricht dabei zu keinem Zeitpunkt mit dem fremden Servicekonto. Um an der Föderation teilzunehmen, müssen die Teilnehmer ihre Verwaltungsdienste dadurch nicht anpassen. Dies schützt die getätigten Investitionen der Teilnehmer und führt zu keinem Aufwand für eine Anpassung aller Verwaltungsdienste. Dies ist vorteilhaft, da die Zahl der Servicekonten überschaubar ist und - so die Identitätsfeststellung durch wenige Server in den Bundesländern erfolgt - konstant bleibt, die Zahl der Verwaltungsdienste aber sehr groß ist und voraussichtlich stark wächst. Die Aufgabe von Servicekonten der Föderation ist - im ersten Schritt - lediglich, Nutzer zu identifizieren. Dazu gehören die Authentifizierung und die Zuordnung der zur Identitätsfeststellung zugehörigen Personenattributen. Möchte ein Nutzer einen Verwaltungsdienst eines Bundeslandes nutzen, kann er das Servicekonto eines anderen Bundeslandes zur Authentifizierung verwenden. 1.3 Servicekonten als Schlüssel Der Lösungsansatz erlaubt es Nutzern ein von ihnen gewähltes Servicekonto als Schlüssel für ihre Authentifizierung durch ein fremdes Servicekonto zu verwenden. Abbildung: Schematisches, vereinfachtes Schaubild Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 7 Das Schaubild zeigt nicht die tatsächlichen Kommunikationswege, sondern visualisiert nur das Prinzip ein Servicekonto als Schlüssel für ein anderes Servicekonto zu verwenden. Ein Servicekonto dient - ähnlich wie bei einem SAML-IdP-Proxy - sowohl als IdP als auch als SP. Die Lösung kommt im Gegensatz zu einem Proxy-Ansatz ohne zentralem Proxy aus, der alle Informationen mitlesen muss. Damit realisiert dieser Ansatz eine Ende-zu-Ende Verschlüsselung der personenbezogenen Daten des Benutzers zwischen den Servicekonten. Durch die Begrenzung der Kommunikation auf die Servicekonten, ist die Zahl der auszutauschenden Zertifikate für die Kommunikationsstrecken aber begrenzt und einfach zu verwalten. 1.4 Vertrauenszonen Der Anbieter eines Verwaltungsdiensts muss die Daten des Nutzers, der diesen Verwaltungsdienst nutzt, entgegennehmen. Der Anbieter eines Verwaltungsdiensts muss auch die Authentifizierung des Nutzers vornehmen oder vornehmen lassen, um entscheiden zu können, ob der Nutzer zu der Nutzung des Diensts berechtigt ist. Wenn der Anbieter diese Authentifizierung durch einen Drittens, außerhalb der eigenen, übergreifenden Vertrauenszone, vornehmen lässt, muss er die Nutzerinformationen mit der Zustimmung des Nutzers an diesen Dritten übertragen. Die Authentifizierungsantwort enthält ebenfalls Daten des Nutzers und darf nur mit dessen Zustimmung von der außerhalb der übergreifenden Vertrauenszone liegenden Authentifizierungsstelle an den Verwaltungsdienst (direkt oder indirekt) übertragen werden. Stimmt der Nutzer einer der beiden Übertragungen nicht zu, kann der Verwaltungsdienst nicht genutzt werden. Die folgende Grafik zeigt an welchen Stellen die Daten des Nutzers auftreten. Innerhalb der Konten können die Daten des Nutzers im Klartext vorliegen. Die Föderation schreibt vor, dass die Daten über die grün markierten Kommunikationswege verschlüsselt übertragen werden müssen. Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 8 Abbildung: Vertrauenszonen in der Föderation Die Servicekonten und Verwaltungsdienste des Teilnehmers bilden eine Vertrauenszone. In diese Vertrauenszone können weitere Servicekonten und Verwaltungsdienste aufgenommen werden. Jede Vertrauenszone definiert ein Servicekonto, das diese Vertrauenszone vertritt und in der Föderation auftritt. Zwischen diesem Servicekonto und den Servicekonten der andern Föderationsmitglieder werden die Informationen verschlüsselt übersendet. Kein Dritter kann diese Informationen mitlesen. Die Vertrauenszone eines Teilnehmers muss nicht homogen sein. Es ist möglich, dass die Vertrauenszone in weitere kleinere Vertrauenszonen unterteilt wird. Innerhalb der Vertrauenszone eines Teilnehmers kann es mehrere Servicekonten geben, die in einer durch den Teilnehmer definierten Weise miteinander kommunizieren. Die konkrete Ausgestaltung Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 9 der Vertrauenszone obliegt somit dem Teilnehmer. Aus Sicht der Föderation ist die Vertrauenszone des Teilnehmers eine Blackbox mit einem ausgezeichneten Servicekonto. Dieses Konzept ist analog zu einem Portal, das seinen Nutzern verschiedene Dienste anbietet. Dem Nutzer muss dargelegt werden, wer seine Daten entgegen nimmt und was diese Stelle mit diesen Daten tun darf. Ob die Stelle für die Erbringung dieser Dienstleistung einen oder mehrere Server in unterschiedlichen Rechenzentren benötigt, ist für die Betrachtung der Sicherheit nicht relevant, solange der Betreiber die Daten vor den Zugriffen Dritter schützt. Die tatsächliche Ausgestaltung der Kommunikation innerhalb einer Vertrauenszone obliegt dem Teilnehmer und seinen Anforderungen an den Schutz der Daten. Es ist also wichtig, dass der Nutzer informiert wird, welche Stellen die von ihm übertragenen Daten mitlesen können und was diese Stellen mit diesen Daten tun dürfen. Die Verantwortlichen der Vertrauenszonen müssen sicherstellen, dass die Beteiligten der Vertrauenszone die Daten nur gemäß der durch den Nutzer erteilten Zustimmung verwenden. Generell ist es anzustreben, dass die Informationen von Nutzern von möglichst wenig Beteiligten gelesen werden können. Die Vertrauenszone definiert die Beteiligten und macht es so für die Nutzer transparent, wie die Daten des Nutzers verwendet werden. Das Konzept für interoperable Servicekonten schreibt nicht vor, wie die Vertrauenszonen technisch oder organisatorisch intern ausgestaltet werden. Diese Freiheitsgrade können von den Föderationsteilnehmern genutzt werden, um eigene Lösungen zu entwickeln, die beispielsweise auch den spezifischen organisatorischen Rahmenbedingungen gerecht werden. 1.5 Servicekonto ist ein Dipol Servicekonten werden über die Security Assertion Markup Language (SAML) an die Föderation angebunden. Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 10 Für die Integration eines Servicekontos ist es wichtig zu verstehen, dass aus Sicht der Interoperabilität das Servicekonto ein Dipol mit den beiden Polen Identity-Provider (IdP) und Service-Provider (SP) ist. Abbildung: Schematische Darstellung eines Servicekontos als Dipol Die Abbildung zeigt vereinfacht die Dipoleigenschaften von Servicekonten. Es werden nicht alle Kommunikationswege aufgezeigt, sondern nur schematisch die Dipoleigenschaft. Die beiden Kommunikationswege (a) und (b) sind voneinander unabhängig. In beiden Fällen wird beschrieben, wie die Anmeldung an einem fremden Servicekonto erfolgt. Im dem Anwendungsfall (a) meldet sich der Nutzer für die Nutzung eines Verwaltungsdiensts 1 mit Servicekonto 2 an. Im Anwendungsfall (b) meldet sich der Nutzer für die Nutzung eines Verwaltungsdiensts 2 mit Servicekonto 1 an. 1.6 Informationen zur Anbindung Damit Föderationsteilnehmer ihr Servicekonto in die Föderation integrieren können, sind folgende Schritte durchzuführen: 1. Anmeldung als Teilnehmer (außerhalb dieser Spezifikation) 2. Bereitstellung von Metadaten zum eigenen Servicekonto 3. Integration der Metadaten der anderen Föderationsteilnehmer (über automatische Anmeldung) Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 11 2 Alternativen Eine kurze Diskussion der möglichen Alternativlösungen. Zu dem gewählten Ansatz wurden verschiedene alternative Lösungsstrategien betrachtet. Hier eine kurze Darlegung, warum diese Alternativen nicht gewählt wurden. 2.1 Alternative Standards Offene Standards sind für das E-Government wichtig, um den Teilnehmern der Föderation freie Hand bei der Wahl ihrer Technologien zu geben. Das E-Government beginnt nicht auf der grünen Wiese. Viele Teilnehmer haben bereits Servicekonten, die mit möglichst geringem Aufwand angebunden werden müssen. Zudem bieten offene Standards die Möglichkeit, Technologien zu einem späteren Zeitpunkt zu wechseln. Dies ist wichtig, da Technologieanbieter Geschäftsstrategien ändern können und dadurch Produkte vom Markt genommen oder zu ungünstigeren Konditionen angeboten werden. Die Verwendung von SAML als offenen Standard für die Anbindung von Servicekonten wurde durch den Auftraggeber vorgegeben. Eine naheliegende Alternative von OpenID Connect stand daher nicht zur Wahl. Generell könnte aber in Zukunft die Föderation auch über den OpenID Connect Standard aufgebaut bzw. erweitert werden, falls die ersten Servicekonten diesen Standard implementieren. Dies hätte dann zum gegebenen Zeitpunkt eine weitere Untersuchung zur Folge. 2.2 SAML-IdP-Proxies SAML-IdP-Proxies werden in vielen E-Govenment-Lösungen weltweit für interoperable Identifizierung von Nutzern (Studenten, Mitarbeitern und Bürgern) verwendet. Diese Lösung skaliert gut und ist durch viele Umsetzungen erprobt. Diese Lösung wurde beispielsweise auf europäischer Ebene für STORK gewählt (siehe auch http://www.esens.eu/content/eidasconnector | PDF). Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 12 SAML unterscheidet Identity-Provider (IdPs) und Service-Provider (SPs). Damit zwei Server miteinander kommunizieren können, müssen sie für die Verschlüsselung und das Signieren der übertragenen Informationen die Zertifikate des Kommunikationspartners kennen. Diese Zertifikate müssen vor Beginn der Kommunikation ausgetauscht werden. Bei einer großen Zahl von Kommunikationspartnern ist der Austausch der Zertifikate nicht trivial. Jeder Kommunikationspartner muss die Zertifikate aller potentiellen Gegenstellen kennen und bei Aktualisierung entsprechend informiert werden. SAML-IdP-Proxies umgehen dieses Problem durch die Hierarchisierung. Jeder IdP-Proxy muss so nur die Zertifikate seiner unmittelbaren Kommunikationspartner kennen: Alle untergeordneten Knoten und einen übergeordneten Knoten. In einer SAML-IdP-Proxy-Architektur, begeben sich die Teilnehmer der Föderation in eine besondere Vertrauensstellung. Personenbezogenen Informationen liegen auf den Servern der Teilnehmer kurzzeitig auch unverschlüsselt vor. Durch die IdP-Proxy-Architektur werden die Knoten mit einem zentralen Wurzelknoten in einer Baumstruktur angeordnet. Über diesen Wurzelknoten laufen alle Informationen und könnten technisch dort mitgelesen und ausgewertet werden. Die Verwaltungsdienste sind in diesem Lösungsvorschlag nicht enthalten, treten also nicht als SAML-SPs auf. Daher treten sie auch nur intern mit ihrem Servicekonto in Verbindung, sind also kein Teil einer IdP-SP-Kommunikation der interoperablen Servicekonten. Daher sind keine vermittelnden Proxies notwendig. Die Kommunikation erfolgt ausschließlich direkt zwischen dem SP des anfragenden und dem IdP des antwortenden Servicekontos. Aus diesem Grund sind auch hier keine Proxies notwendig. Der IdP-Proxy-Standard weist bei den Produkten unterschiedlicher Anbieter unterschiedliche Auslegungen auf. Die Interpretation von SAML-IdP-Proxy-Requests (SAML-Authn-Requests, die die unter 3.4.1.5 in der Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 angegebenen Restriktionen erfüllen) ist gegenüber Nicht-ProxyAuthn-Requests nicht immer einheitlich. Demzufolge ist die Interoperabilität bei der Verwendung von SAML-IdP-Proxies gegenwärtig schlechter als bei SAML-Kommunikation ohne Verwendung eines SAML-IdP-Proxies. Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 13 Der Auftraggeber hat die Vorgabe gemacht, zentrale SAML-IdP-Proxies nicht zu verwenden. Die Verwendung von SAML-IdP-Proxies durch die Föderationsteilnehmer ist hierbei natürlich nicht beschränkt. Jeder Teilnehmer kann für die Anbindung seines Servicekontos eine für ihn passende Strategie wählen und daher auch einen Proxy verwenden. Gefordert ist lediglich, dass der durch die Interoperabilität definierte Schnittstelle entsprochen wird. 2.3 Discovery-Service Um die Möglichkeit des Mitlesens aller Informationen im zentralen Wurzel-IdP-Proxy zu verhindern, wurde ursprünglich auch eine Lösung mit Discovery-Service angedacht. Auftraggeber und Auftragnehmer planten diesen Ansatz weiter zu untersuchen. Bei diesem Ansatz ist die Lösungsstrategie, dass ein Servicekonto die Informationen für die Kommunikation mit einem anderen Servicekonto von einem zentralen Discovery-Service erhält. Hierbei handelt es sich also um einen Metadata-Discovery-Service. Metadata- gegenüber IdP-Discovery Grundsätzlich muss zwischen einem Discovery-Service für Metadaten und einen DiscoveryService für IdPs unterschieden werden. Ein IdP-Discovery-Service hat lediglich die Aufgabe, den zu einem Benutzer passenden IdP automatisch oder per Rückfrage zu ermitteln. Ein Metadata-Discovery-Service ermittelt die Verbindungsdaten für eine sichere Kommunikation zwischen SAML-Entities. Grundsätzlich unterscheiden wir zwischen einem dynamischen und einem statischen Metadata-Service. Bei dem dynamischen Metadata-Discovery werden die Verbindungsdaten für eine sichere Kommunikation zwischen Servicekonten zur Zeit der Nutzeranfrage ermittelt. Bei einem statischen Metadata-Service werden die Daten über einen definierten Kanal außerhalb des SAML-Standards ausgetauscht. Für einen dynamischen Metadata-Discovery-Ansatz gab es zum Zeitpunkt der Erstellung dieses Prototypen noch keinen offenen oder Industriestandard. Aufgrund des Zeitplans war eine umfassende Betrachtung des Themas nicht möglich. Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 14 Der SAML-Standard für Metadata definiert das Nachrichtenformat und sieht drei statische Möglichkeiten vor, die standardisierten Deskriptoren abzurufen: 1. Austausch über DNS 2. Austausch über einen Standard-URL (ein sogenannter well-known URL) 3. Out-of-Band (also außerhalb des Standards) Die ersten beiden Möglichkeiten implizieren, dass jeder Teilnehmer seine Daten selbst auf seinen Servern dezentral zur Föderation publiziert. Das bedeutet dann aber auch, dass jeder Teilnehmer bei jedem anderen Teilnehmer die aktuellen Daten abrufen muss. Bei 16 Teilnehmern müsste jeder Teilnehmer also zur Ermittlung aller Verbindungsinformationen 15 verschiedene Server innerhalb der Föderation anfragen. Zur Erleichterung der Ermittlung der aktuellen Metadaten haben wir uns für den Prototypen daher für einen zentralen Ansatz entschieden. Die Metadaten werden auf einem zentralen Server von den Teilnehmern der Phase 2 über einen Webschnittstelle eingespielt und können über dieselbe Schnittstelle automatisiert bezogen werden. Dieser Austausch findet bei der Integration eines Servicekontos in die Föderation statt. Die Deskriptoren werden dabei vom Metadata-Server validiert, um frühestmöglich etwaige Konfigurationsprobleme zu lokalisieren. Die Föderation muss definieren in welchen Abständen die Teilnehmer die Konfigurationen auf dem zentralen Metadata-Server überprüfen müssen. Alternativ kann auch gefordert werden, dass bei einem Kommunikationsproblem, die Metadaten erneut abgeglichen werden müssen. Derzeit sind diese Eckpunkte noch nicht definiert. Gerade im Testbetrieb können Teilnehmer ihre Zugangsdaten häufiger ändern wollen. Wir empfehlen daher in der Phase 2 die Daten regelmäßig abzugleichen und bei Problemen die Daten zu überprüfen. Im Rahmen einer weiteren Untersuchung könnte das Thema des dynamischen MetadataDiscovery-Service jedoch von Interesse sein. Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 15 3 Literaturverweise Weitere Informationen zum Thema Interoperable Servicekonten finden Sie in den folgenden Dokumenten. Name Kurzbeschreibung Version Tour für neue Eine geführte Tour durch die Dokumentation für neue Föderationsmitglieder Föderationsmitglieder. Überblick über die Liste der Anwendungsfälle, die für die Spezifikation des Anwendungsfälle Lösungsvorschlags betrachtet werden. Beschreibung der SAML- Dokumentation der SAML-Metadaten für die an der Metadaten Föderation teilnehmenden IdPs und SPs. Beschreibung der Dokumentation der Kommunikationsschnittstellen Schnittstellen außerhalb der SAML-Metadaten. API-Dokumentation Informationen zur Nutzung des APIs. 0.1 Kurzanleitung für Liste von Kurzanleitungen, die Aufgaben der 0.1 Föderationsteilnehmer Föderationsteilnehmer beschreiben. Glossar Beschreibung der zentralen Begriffe im Kontext von 0.1 0.2 0.2 0.2 0.1 interoperablen Servicekonten der Föderation. Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 16 4 Glossar Die in diesem Dokument verwendeten Begriffe aus der Domäne Interoperable Servicekonten werden in einem separaten Glossar erklärt. In diesem Glossar werden alle Begriffe der Domäne aufgelistet. Prototyp Interoperable Servicekonten Überblick über den Lösungsvorschlag V 0.2 vom 05.10.2016 17
© Copyright 2024 ExpyDoc
