Bericht. egov: IAM Infrastruktur Vision. E-Government ffo Vorhaben B Januar 2010, Projekt-Nr

Größe: px
Ab Seite anzeigen:

Download "Bericht. egov: IAM Infrastruktur Vision. E-Government ffo Vorhaben B2.06. 9. Januar 2010, Projekt-Nr. 12.564.00.00"

Transkript

1 Bericht egov: IAM Infrastruktur Vision E-Government ffo Vorhaben B Januar 2010, Projekt-Nr Januar 2010, Projekt-Nr

2 Dokumentinformationen Titel: Projektnummer: Datum: Datei: Anzahl Seiten: Geprüft durch Koreferent bzw. Projektbegleiter: egov: IAM-Pilotinfrastruktur <Versanddatum> D:\Documents\_10_proj\projekte\12_564_eCH_IAM_Anforderungen_Architektur\Berichte\zA WK_Dok_100118_IAM_eGov.doc 48 exkl. Beilagen Version Datum Wichtigste Änderungen Verantwortlich V Erstellung Dokumentstruktur Gabriel Müller V Überarbeitung Dokumentstruktur Adrian Marti V Erster Entwurf Markus A. Meier V Einarbeiten Feedback AWK Markus A. Meier V Einarbeiten Feedback Kernteam egov (H. Häni, D. Wunderli, E. Meyer, C. Dolf, C. Mattmann, M. Zweiacker Markus A. Meier V Einarbeiten Feedback nach WS Markus A. Meier V Mehr Feedback Markus A. Meier V Einarbeiten letzte Feedbackrunde, Input vom SEC Workshop Markus A. Meier V Qualitätssicherung AWK Markus A. Meier V Endgültige Version AWK einarbeiten letzter Feedback Markus A. Meier AWK Group AG Dieser Bericht ist vertraulich und nur für den Auftraggeber bestimmt. Diesem steht das Recht zu, die Arbeitsergebnisse von AWK für den vereinbarten Zweck zu verwenden. Eine über den Auftrag hinausgehende Verwendung ist nicht zulässig. AWK Group AG Leutschenbachstrasse 45 CH-8050 Zürich Tel Fax /48

3 Abkürzungen und Begriffe Abkürzung IAM PIN SSO KPI Beschreibung Identity Access Management Persönliche Identifikationsnummer Single Sign-On Key Performance Indicator Referenzierte Dokumente Titel Autor / Herausgeber Datum Link / Datei [1] ech Referenzmodell IAM Whitepaper No.: IAM [2] ech-0107 IAM Design Prinzipien [3] Technische Spezifikation N. Haenni, M. Itin, V. Kulhavy, H. Rüger, C. Winteregg 23. April 2007 SEAC: W. Müller, H. Häni Mitglieder der Arbeitsgruppen - Spezifikation und Funktionsnachweis / Arbeitsgruppe, c/o SECO option=com_docman&task =doc_download&gid=9 90&lang=de nthosting.ch/gast/doku mente%20projekt%20stabi 3IKT/_Specific ation_1%200_deen.pdf 3/48

4 Inhaltsverzeichnis 1. Zusammenfassung Bezug zur Motivation Begriffe im und um IAM Identifikator Identität Subjekt Ressource Digitales Zertifikat Namensraum - Domäne Attribute Claim, Claimset Security Token Service STS, Relying Party RP Claim Assertion Service, Claim Assertion Infrastructure, Identity Provider, Service Provider im Umfeld IAM - Identity und Access Management Register Vertrauensbeziehung (Trust) Vision egov IAM Domänen Adapter-Service Authentifizierung Name Mapping Registrierung der Identität Access Control Mapping Verwaltung und Verteilung der Identität Prinzipien, Anforderungen, Standards Prinzipien Anforderungen Vorgaben und Standards Prozesse im IAM Umfeld Legislative Identifikation /48

5 Administration Autorisierung Executive Verwaltung Verteilung Authentisierung Authentifizierung Access Control Audit Technische Architektur Technisches Referenz-Modell IT-Architektur IAM System-Topologie IAM Architekturbausteine Identitäten Informationen über Zugangs-Rechte, Privilegien und Rollen Identitäts-Speicherung Subjekte und Ressourcen Provisionierung Typische Anwendungsfälle Benutzer schaut seine Einwohnerregister-Daten an Prozesse und Operationen im egov IAM Adapter-Service Überprüfung eines Dokuments von Notar X durch Benutzer Y Benutzer (Bürger) wird Mitarbeiter bei einer kantonalen Verwaltung E-Banking eines Kunden mit einer Ein Landwirt greift mit einer Suisse-ID auf ein Teilnehmersystem (z.b. Kantonssystem) zu Benutzer kauft bei einem Versandhaus ein /48

6 Interface Interface Interface Interface 1. Zusammenfassung Dieses Dokument beschreibt die Vision einer möglichen IAM-Architektur im Rahmen des egov Vorhabens ffo B2.06 des Katalogs priorisierter Vorhaben. Sie ist in Abbildung 1 dargestellt: Behörden trust egov IAM Infrastruktur Schweiz 2 Suisse CSP ID CA 1 Benutzende Register CSP Infrastruktur IdP CAS 3 2 trust CSP Certification Provider IdP Identity Provider CAS Claim Assertion Service 2 Firmen trust Abbildung 1: egov IAM Architektur Eine IAM Infrastruktur dient üblicherweise zur Verwaltung von Ressourcen und deren Identitäten sowie der Verwaltung der Eigenschaften und Berechtigungen innerhalb einer Firma oder innerhalb einer Organisation. Die egov IAM Architektur ist ein IAM Ansatz für föderalistische Organisationen. Der Ansatz basiert darauf, dass auf Ressourcen Zugreifende, wie Benutzer oder beteiligte Ressourcen, ein digitales Zertifikat von einer anerkannten Zertifizierungsstelle (Certification Authority CA) besitzen, welches vom Certification Provider (CSP) ausgegeben wurde. Ebenfalls wird angenommen, dass zwischen unterschiedlichen Ressourcen ein genau definiertes Vertrauensverhältnis (Trust) definiert ist. Es wird dabei vom folgenden Ablauf ausgegangen (siehe Abbildung 1 oben): 1) Benutzende registrieren sich bei der Registrierungsstelle 1 (z.b. ) und erhalten ein digitales Zertifikat (z.b. auf einer Smartcard) 2) Benutzende verwenden z.b. einen bestimmten Behördenservice. Sie authentisieren sich stark mit Hilfe des Authentifizierungszertifikats. 1 Streng genommen wird zwischen der Registrierungsstelle (Registration Authority) und der Zertifizierungsstelle (Certification Authority), der Ausgabestelle der Zertifikate, unterschieden. 6/48

7 3) Die Identität der Benutzenden wird beim Identityprovider IdP verifiziert. Allfällige zusätzliche erforderliche Angaben zu den Benutzenden werden beim CAS (Claim Assertion Service) des CSP unter Zustimmung der Benutzenden nachgefragt. Diese Vision versucht die egov IAM Architektur auf einer hohen Abstraktionsebene ohne technische Details zu erklären. Der Fokus liegt auf dem Verständnis der Abläufe und Zusammenhänge. Das Dokument ist wie folgt gegliedert: Motivation zur Einstimmung (Kapitel 2) Einleitung mit Definition der wichtigsten Begriffe (Kapitel 3) Vision (Kapitel 4) Prinzipien, Anforderungen, Standards (Kapitel 5) Prozesse im IAM Umfeld, aufgeteilt nach Legislative und Executive (Kapitel 6) Technische Architektur (Vertiefung der Vision Kapitel 7) Typische Anwendungsfälle (Kapitel 8) 1.1. Bezug zur Dieses Dokument bezieht sich stark auf die Aktivitäten um und zur. Viele der Beispiele verwenden konkret den Ansatz mit dem vorgesehenen Träger (siehe nebenstehende symbolische Abbildung) mit dem Authentifizierungsoder Signierungszertifikat. Nebst den allgemeinen Begriffen, welche im Kapitel 3 zum Thema IAM eingeführt werden, sind im gleichen Kapitel auch die speziellen Begriffe im Umfeld zu finden. Es ist jedoch wichtig zu verstehen, dass der Scope dieses Dokuments sich nicht auf die beschränkt. Die darin beschriebenen Prinzipien sind allgemein und gelten deshalb für ein breiteres Umfeld. 7/48

8 Interface 2. Motivation Zur Einstimmung ein einfacher möglicher Anwendungsfall für die Verwendung der bei einer Behörde, z.b. das Ausstellen einer bestimmten Bescheinigung für einen Bürger der Gemeinde X. Weitere Anwendungsfälle befinden sich im Kapitel 8. Vorbedingungen: Benutzer hat Gemeinde X hat Trust-Beziehung mit der egov IAM Infrastruktur Schweiz Der folgende stark vereinfachte Anwendungsfall zeigt die einzelnen dafür notwendigen Schritte: Bürger 2 1 Internet Adapter-Service 9 5 Legislative Identifikation Administration Autorisierung Exekutive Authentifizierung Name Mapping Registrierung Access Control Mapping Verteilung 4 Identifizierung 6 3 Gemeindportal 7 8 Verzeichnis Bürger Gemeinde X Service Y egov IAM Infrastruktur Schweiz CSP ID CA CSP Infrastruktur IdP CAS trust Abbildung 2: Bürger verwendet Service Y der Gemeinde X 1) Bürger verwendet seine an seinem Notebook 2) Er ruft das Gemeindeportal der Gemeinde X auf 3) Weil er einen geschützten Service Y verwenden will, muss er sich identifizieren 2. Dies kann durch seine erfolgen. 4) Die Authentifizierung erfolgt mit Hilfe seiner (über den Adapter- Service, Details dazu siehe Kapitel 4.1). 2 Stark authentifizieren 8/48

9 5) Seine wird verifiziert 6) Die (externer Name) wird auf den internen Namen, welcher im Bürgerverzeichnis steht, gemappt (Details siehe unter Anmerkungen weiter unten). 7) Der Bürger ist identifiziert 8) Es erfolgt der Serviceaufruf 9) Das gewünschte Resultat wird dem Bürger zurückgeschickt. Anmerkungen: Folgende Schritte sind in diesem Anwendungsfall nicht explizit gezeigt: Eingabe Pin: Es wird davon ausgegangen, dass der Pin für die Freigabe des Zertifikats auf dem Datenträger verwendet werden muss. Name Mapping: Auf Grund der beschränkten Attribute, welche auf einer zu einem Benutzer gespeichert sind, könnte es erforderlich sein vom Benutzer zusätzliche Angaben zu verlangen um ihn eindeutig identifizieren zu können. Dieser Schritt wird in diesem Beispiel nicht gezeigt. In diesem Dokument wird jedoch weiter hinten darauf eingegangen, z.b. bei der Erklärung von Claims im Kapitel 3.8 oder im Anwendungsfall im Kapitel 8.7 9/48

10 3. Begriffe im und um IAM Im IAM Umfeld werden viele Begriffe in unterschiedlicher Auslegung verwendet. Es ist deshalb wichtig, zuerst ein gemeinsames Verständnis dafür zu schaffen. In diesem Dokument werden deutschsprachige Begriffe aus dem Glossary des ech IAM- Referenzmodells sowie aus dem Umfeld verwendet. Zum Teil werden die englischsprachigen Begriffe verwendet, da diese auch in unserem Umfeld weit verbreitet und bekannt sind. Einige Begriffe werden mit Hilfe von Beispielen und Zeichnungen illustriert und vertieft. Die Begriffe werden nicht nach alphabetischer Reihenfolge sondern nach logischem Aufbau des Dokuments sowie dem Zusammenhang unter den Begriffen selbst eingeführt Identifikator Identifikator Ein Identifikator ist eine Zeichenkette, welche ein Subjekt oder eine Ressource innerhalb eines Namensraumes eindeutig bezeichnet. Der eindeutige Identifikator eines Subjektes oder einer Ressource ist oft ein nicht selbsterklärender Name und kann beliebig komplex sein. Dieser Identifikator kann auch in einem digitalen Zertifikat enthalten sein. Der Identifikator soll nur dazu dienen, ein Subjekt eindeutig und unmissverständlich zu identifizieren. Anmerkung: Der Identifikator im Umfeld ist die eindeutige Nummer in der Form Identität Identität Eine Identität hat einen Identifikator (eindeutigen Namen), meist zusammen mit einer Menge von zusätzlichen Attributen, welche innerhalb eines Namensraumes eindeutig einem Subjekt zugewiesen werden kann. Ein Subjekt kann mehrere Identitäten haben. 10/48

11 3.3. Subjekt Subjekt Ein Subjekt ist eine Entität, die auf eine elektronische Ressource zugreift oder zugreifen möchte. Es kann sich um eine natürliche oder juristische Person oder auch um eine Maschine handeln Ressource Ressource Eine Ressource ist eine Anwendung, ein Service, eine Funktion, ein Prozess oder Daten, auf welche ein Subjekt zugreifen möchte Digitales Zertifikat Digitales Zertifikat Ein digitales Zertifikat besteht aus digitalen Daten, mit welchen ein Subjekt oder eine Ressource eindeutig identifiziert werden kann (Ermittlung des Eigentümers des Zertifikats). Dazu enthält das Zertifikat üblicherweise: Den Namen des Ausstellers Informationen zu den Regeln und Verfahren unter denen das Zertifikat ausgegeben wurde Informationen zur Gültigkeitsdauer des Zertifikates Den öffentlichen Schlüssel, zu dem das Zertifikat Angaben macht Den Namen (oder eine andere eindeutige Bezeichnung) des Eigentümers des öffentlichen Schlüssels (engl. subject) des Subjektes Weitere Informationen zum Eigentümer des öffentlichen Schlüssels Angaben zum zulässigen Anwendungs- und Geltungsbereich des öffentlichen Schlüssels. Eine digitale Signatur, mittels welcher die Echtheit der Angaben im Zertifikat überprüft werden kann. Anmerkungen: In diesem Dokument wird fortan nur von Zertifikat gesprochen. Gemeint ist immer ein digitales Zertifikat Der Name des Subjektes (der Identifikator) ist nicht automatisch gleichzusetzen mit seinem Zertifikat! 11/48

12 3.6. Namensraum - Domäne Die Eindeutigkeit eines Namens ist generell an einen bestimmten Rahmen gebunden, d.h. abhängig von seinem Kontext. Man spricht vom Namensraum oder im IAM Umfeld von Domäne: Domäne Die Domäne stellt einen Namensraum dar. Innerhalb dieses Namensraums sind Identitäten eindeutig, d.h. es gibt nicht mehrere Identitäten für die gleiche Ressource. Wir alle sind vertraut mit dem Internetnamensraum und verwenden die Punktnotation zum Aufruf einer bestimmten Ressource, z.b. der Homepage Noch vor dem Internet waren wir vertraut mit dem Namensraum von Prozessen in einem Betriebssystem oder dem Namensraum des Dateisystems. Namensräume, d.h. Domänen, sind im IAM Umfeld von grösster Wichtigkeit, da jede IAM-Umgebung nur eine endliche Anzahl von Subjekten und Ressourcen verwaltet. Unter den verschiedenen Domänen können Vertrauensbeziehungen aufgebaut werden (Trust Relations), um eine Domänen-übergreifende Verwendung der Identitäten zu ermöglichen. Anmerkung zur Eindeutigkeit: Das ech Referenzmodell definiert, dass eine Person (Subjekt) mehrere Identitäten haben kann. Innerhalb eines Namensraums erlaubt eine Ressource immer nur eine eindeutige Identität. Um diese Mehrdeutigkeit zu beherrschen braucht es also ein Identitäts-Mapping von externen Identitäten zu Identitäten innerhalb des Namensraums. Dieses Identitäts-Mapping könnte man als eine Art indirekten Adressierung bezeichnen (siehe Abbildung 3): Namensraum X Ext-ID A1 Ext-ID A3 Ext-ID C2 Name Ressource A Ext-ID A1 Ext-ID A2 Ext-ID A3 Name Ressource B Ext-ID B1 Ext-ID B2 Ext-ID B3 Name Ressource C Ext-ID C1 Ext-ID C2 Ext-ID C3 Name Ressource D Ext-ID D1 Ext-ID D2 Ext-ID D3 A D C B Abbildung 3: Namensraum und Identitäts/Ressource-Mapping 12/48

13 In dieser Abbildung werden externe IDs (Ext-ID) über eine Tabelle auf die eigentlichen Ziel-ID abgebildet. Man sieht z.b. dass die unterschiedlichen externen Identitäten Ext-ID A1 und Ext-ID A2 beide zur gleichen Ressource Name Ressource A führen. Die externe Identität Ext-ID C2 führt zur Ressource Name Ressource C. Die externen Identitäten können natürlich noch weitere Namensräume benutzen Attribute Nebst dem eindeutigen Identifikator können Identitäten Attribute haben, welche zusätzliche Eigenschaften beschreiben, z.b. ist es üblich bei einem Subjekt Benutzer Attribute wie Name, Vorname, Telefonnummer oder adresse als Attribute anzufügen. Attribute Attribute sind Informationsfelder (Behälter) beliebiger Art, welcher einer Identität zugeordnet sind. Sie dienen zur Beschreibung von Subjekteigenschaften. Eine dieser Eigenschaften von Subjekten ist ein Set von Zugriffsregeln, also z.b. wer eine Ressource in welcher Art verwenden darf (Access Management). Oft werden Attribute auch gruppiert (siehe Abbildung 7), um sie einfacher verwalten zu können, bzw. um die Zuständigkeit der Verwaltung klarer zu regeln. Nachfolgend eine mögliche Gruppierung von Attributen am Beispiel der Attribute für die Benutzerverwaltung: Verbindliche Attribute wie Name, Vorname, adresse, usw. Access Management Attribute wie z.b. Benutzer hat die Rollen Office, Internet, Steuerverwalter, Geschäftsprüfungskommissionsmitglied, Benutzer darf Anwendung X, Y, Z verwenden Benutzer darf Daten U, S, W lesen und K, S modifizieren. Spezifische Attribute wie z.b. Angaben zur Organisationseinheit, Vorgesetzter Private Attribute, z.b. Private Wohnadresse, Bild des Benutzers, ; In diesem Beispiel könnten z.b. die privaten Attribute unter alleiniger Obhut des Benutzers selbst sein, d.h. er ist zuständig für die Pflege dieser Attribute. Im Unterschied dazu werden natürlich die Access Management Attribute von den dafür autorisierten Stellen verwaltet und gepflegt. Anmerkung: Es ist eine besondere Herausforderung, die zu einer Identität notwendigen und richtigen Attribute zu definieren. Oft weiss man ja erst durch den Verwendungszweck oder den Kontext, welche Attribute wirklich gebraucht werden. Deshalb wurde das Prinzip der Claims bzw. Claimsets entwickelt (siehe 3.8). 13/48

14 Claimset 3.8. Claim, Claimset Claim (engl. für Behauptung) ist ein neueres Konzept im IAM Umfeld. Es erlaubt die Entkopplung von Identitäten und Attributen. Claim Ein Claim ist eine Behauptung über ein Subjekt oder eine Ressource, welche von einer offiziellen, vertrauensvollen Stelle als korrekt bestätigt wurde, z.b. Subjekt ist 18 Jahre alt, Subjekt ist Arzt. Claimset Ein Claimset ist eine Sammlung von Claims, welche, wie ein einzelner Claim, von einer offiziellen, vertrauensvollen Stelle als korrekt bestätigt wurde. Abbildung 4 zeigt beispielhaft einen Claimset, eine Sammlung einzelner Claims, welcher als Ganzes (Security Token) signiert ist. Security Token Claim 1 Claim 2 Name, Vorname Claim 3 Claim n Adresse Alter Signatur Abbildung 4: Security Token mit Claimset und Signatur Claims erlauben sozusagen das Outsourcen der Attribut-Verwaltung. Diese findet nicht im Zielsystem oder dem Ziel-IAM statt. Die notwendigen Attribute werden vom Benutzer als signierte Security Tokens der Anwendung oder dem Zielsystem übergeben. Diese Zielanwendung oder das Zielsystem vertraut auf die Angaben im Claimset, da sie eine Vertrauensbeziehung zur Ausgabestelle der Claims hat (siehe 3.9 STS). 14/48

15 3.9. Security Token Service STS, Relying Party RP Claimsets werden vom sogenannten Security Token Service STS gebildet (siehe 3.8). STS wird im Zusammenhang mit den sogenannten Relying Parties RP erklärt. STS Als Security Token Service STS bezeichnet man die Infrastruktur welche in der Lage ist, Security Tokens nach international gültigem Standard zu erzeugen, zu signieren und als Service zur Verfügung zu stellen. Anmerkung: Im Umfeld werden STS als CAS (Claim Assertion Service) bezeichnet (siehe 3.10). RP Die Relying Party als Eignerin der Ressource vertraut (engl. trusts) im juristischen Sinn den Claims, welche von einem vertrauenswürdigen Security Token Service STS herausgegeben worden sind. Der Ausdruck Relying Party wird oft in Zusammenhang mit Claims und Security Token Service STS verwendet. Üblicherweise handelt es sich bei der Relying Party RP um eine IT Anwendung oder um IT Systeme. Nachfolgende Abbildung 5 zeigt das Prinzip des STS Service. In diesem Beispiel braucht es zwei STS Services um die gesamte geforderte Information zusammen zu stellen (federation von Security Token Services). trust trust STS-A STS-B Benutzer RP Abbildung 5: Federated Security Token Service 15/48

16 Vorbedingung: Die Relying Party RP vertraut auf die beiden Security Token Service Provider STS-A und STS-B. Beschreibung des Anwendungsfalls: 1) RP fragt nach den entsprechenden Attributen, z.b. Geschäfts- adresse, Heimadresse und Alter 2) Der Benutzer konsultiert STS-A für seine Attribute Heimadresse und Alter. 3) Diese Angaben werden ihm in einem Security-Token als Claimset von STS-A zurückgegeben. 4) Der Benutzer schickt dieses Security-Token zum STS-B um die Geschäfts adresse hinzuzufügen. 5) Das mit der Adresse angereicherte Security-Token (Claimset) wird dem Benutzer zurück gegeben. 6) Der Benutzer entscheidet, dass er dieses Security-Token (Claimset) zum RP schickt Claim Assertion Service, Claim Assertion Infrastructure, Identity Provider, Service Provider im Umfeld Im Umfeld von werden Begriffe wie CAS, CAI, IdP und SP intensiv verwendet: CAS Claim Assertion Service ein Security Token Service (STS) im Umfeld der. STS ist genauer im Kapitel 3.9. beschrieben CAI Claim Assertion Infrastructure Infrastruktur welche verwendet wird um in Verzeichnissen oder Registern hinterlegte Attribute (Claims) von Benutzenden mit formellem Einverständnis der Benutzenden sicher verfügbar zu machen. IdP Identity Provider Ein Service zur Verifikation (Überprüfung) von Authentifizierungszertifikaten. SP Service Provider Entspricht dem Begriff RP (siehe 3.9). 16/48

17 Das Konzept von CAS, CAI, IdP und SP wird in folgender Abbildung 6 gezeigt: Kern Infrastruktur CSP Infrastruktur Directory- und Assertion- Service IdP CAS Other IdP Other CAS Interface Interface Interface Interface Claim Assertion Infrastructure CAI Interface Browser Interface Service Provider (SP) Benutzende Anwendungen Abbildung 6: Claim Assertion Infrastructure CAI Die Claim Assertion Infrastructure CAI ist das Bindeglied zwischen den verschiedenen Partnern, welche gemäss der technischen Spezifikation (siehe [3]) aus folgenden Teilen besteht: Kern Infrastruktur: CSP (Certification Service Provider) Infrastruktur, bestehend aus: IdP Identity Provider CAS Claim Assertion Service Directory- und Assertion Service: Optional weitere IdP und CAS Service Provider Benutzende (mit ): verwenden Anwendungen von einem Anbieter (Service Provider SP) Service Provider (SP): Anwendungsanbieter oben (siehe 3.9) allgemeiner als Relying Party (RP) bezeichnet Ein typischer Anwendungsfall mit einem Claimset im Umfeld wird im Kapitel 8.7 erklärt IAM - Identity und Access Management Namen von Subjekten und Ressourcen werden durch das Identity Management verwaltet. Meistens werden zusätzlich auch deren Attribute und Zugriffsregeln verwaltet. Dies führt zum Namen IAM Identity und Access Management: 17/48

18 IAM Identity und Access Management befasst sich mit dem Managen (Verwalten) der Identitäten, deren Attribute und speziell den Zugriffsregeln. Die mittels IAM verwaltete Information (eine Art IAM Record oder Container) könnte dann z.b. für einen IT Benutzer (Subjekt) wie folgt aussehen: IT Benutzer Identifikator Verbindliche Attribute Access Management Attribute Spezifische Attribute Private Attribute Abbildung 7: Beispiel IAM Record Benutzerverwaltung Anmerkung: Im Umfeld egov IAM wird ein minimales Set von Attributen im Digitalen Zertifikat vorhanden sein. Grundsätzlich können in der Schweiz aus Gründen des Datenschutzes nur unkritische Attribute wie z.b. Name, Vorname dazu verwendet werden Register Register sind Verzeichnisse. In der Schweiz gibt es eine grosse Zahl von Registern, z.b. die Einwohnerregister, Anwaltsregister, Zivilstandsregister, Motorfahrzeugregister usw. Sie werden in der Regel von offiziellen Stellen (Behörden) geführt. Nebst diesen offiziellen Behördenverzeichnissen gibt es eine Reihe von weiteren Verzeichnissen, z.b. Verzeichnisse über Berufsabschlüsse an Universitäten, der ETH, der verschiedenen Fachhochschulen etc. Verzeichnisse enthalten spezifische Informationen zu einer Person oder einer Organisation. Diese Informationen sind zum Teil vertraulich. Register Verzeichnis (Datenbank) zur Verwaltung spezifischer Informationen zu einer Person, einer Berufsgruppe oder einer Organisation. Die besondere Herausforderung bei den Registern ist die grosse Anzahl unterschiedlicher Verzeichnisse. Diese Herausforderung ist auch z.b. unter dem Titel Register- 18/48

19 harmonisierung im Bundesamt für Statistik beschrieben (siehe: ) Vertrauensbeziehung (Trust) Im Umfeld IAM ist Vertrauen zwischen beliebigen Partnern von zentraler Bedeutung. Wer traut wem und welche Kriterien gibt es dafür. Trust Formell definierte Vertrauensbeziehung zwischen Entitäten, z.b. die formelle Beschreibung der Kriterien, welche erfüllt sein müssen, damit sich zwei Domänen gegenseitig trauen. 19/48

20 Interface Interface Interface Interface 4. Vision Die Vision geht davon aus, dass IAM im E-Government-Umfeld basierend auf einem föderalistischen Ansatz realisiert werden soll. Es geht darum, dass Subjekte beliebige Ressourcen in beliebigen Namensräumen auffinden (d.h. adressieren) können und sie in der dafür vorgesehenen Art und Weise verwenden können (Access Management). Die egov IAM Basisinfrastruktur besteht aus: Mindestens einer Registrierungsstelle (Registration Authority RA) mit einer zugehörenden Zertifizierungsstelle (Certification Authority CA), bei welcher Subjekte und Ressourcen eine digitale Identität erlangen können (z.b. CSP) Einem Datenträger für den Transport der digitalen Identität, z.b. Smartcard, USB Token Die egov IAM Basisdienste Schweiz mit einem Verzeichnisdienst für das Auffinden von Ressourcen, z.b.: - Offiziell akkreditierten Registrierungsstellen (CA Dienste) - Behörden - Firmen - Register - ev. weitere Optional können weitere Dienste wie z.b. STS (Security Token Service) angeboten werden. egov IAM Domain Adapter Service (Anschlussframework an die unterschiedlichen Domänen Details siehe 4.1) Ein Repository, welches Informationen zu organisatorischen, rechtlichen und semantischen Rahmenbedingungen und zu Haftungsfragen enthält. Die Basisdienste IAM können von Benutzern mit einem digitalen Zertifikat einer anerkannten Ausgabestelle kostenlos benutzt werden. Abbildung 8 zeigt schematisch eine Übersicht dieser Vision in Form einer IAM Topologie mit dem Subjekt Benutzer sowie den Ressourcen Behörden, Firmen und Register: Behörden trust egov IAM Infrastruktur Schweiz 2 CSP ID CA 1 Benutzende Register CSP Infrastruktur IdP CAS 3 2 trust CSP Certification Provider IdP Identity Provider CAS Claim Assertion Service 2 Firmen trust Abbildung 8: egov IAM Topologie 20/48

21 Die statische Sicht der egov IAM Architektur in Abbildung 8 besteht aus: egov IAM Infrastruktur: Diese besteht im Fall aus den CSPs (Certification Service Providern) sowie aus der CSP Infrastruktur mit IdP (Identity Provider Service) und CAS (Certification Assertion Service). Subjekte und Ressourcen: Benutzer, CA Dienste ( CA), Behörden, Firmen, Register, IAM Basisdienste Schweiz. Die verschiedenen Subjekte und Ressourcen befinden sich üblicherweise in unterschiedlichen Namensräumen (Domänen). Vertrauensbeziehungen (Trust): Alle Ressourcen - d.h. in diesem Beispiel die Domänen CA Dienste, Behörden, Register und Firmen - haben zur Domäne egov IAM Basisdienste Schweiz eine Vertrauensbeziehung. Domänen Adapter-Service: Abbildung der Domänen-externen Welt auf die IAM Architektur innerhalb der Domäne (Details siehe 4.1). Die dynamische Sicht der egov IAM Architektur in Abbildung 8 stellt sich wie folgt dar: Benutzende möchten einen bestimmten Behördendienst aufrufen. Dazu können sie wie folgt vorgehen: 1) Benutzende registrieren sich bei der Registrierungsstelle 3 (z.b. ) und erhalten ein digitales Zertifikat (z.b. auf einer Smartcard) 2) Benutzende verwenden z.b. einen bestimmten Behördenservice. Sie authentisieren sich stark mit Hilfe des Authentifizierungszertifikats. 3) Die Identität der Benutzenden wird beim Identityprovider IdP verifiziert. Allfällige zusätzliche erforderliche Angaben zu den Benutzenden werden beim CAS (Claim Assertion Service) des CSP unter Zustimmung der Benutzenden nachgefragt egov IAM Domänen Adapter-Service Um die externe auf die interne IAM Welt abzubilden wird vorgeschlagen einen sogenannten egov IAM Domänen Adapter-Service zu verwenden: 3 Streng genommen wird zwischen der Registrierungsstelle (Registration Authority) und der Zertifizierungsstelle (Certification Authority), der Ausgabestelle der Zertifikate, unterschieden. 21/48

22 Abbildung 9 zeigt schematisch den Aufbau dieses Service: Adapter-Service Legislative Identifikation Administration Autorisierung Exekutive Authentifizierung Name Mapping Registrierung Access Control Mapping Verteilung Abbildung 9: Adapter-Service Dieser Adapter-Service besteht aus zwei Teilen: Legislative: Hier werden die Prozesse festgelegt, wie die Identifikation, Administration und Autorisierung von Subjekten erfolgen soll. Diese Prozesse bestimmen z.b., wie der Registrierungsservice der Executive ausgebildet werden soll. Ebenfalls wird bestimmt, wie das Access Control Mapping erfolgen soll (Autorisierung innerhalb der Domäne) und wohin die Identität verteilt werden soll (auf welche Zielsysteme). Exekutive: Hier geht es um Services, welche von Anwendungen aufrufbar sind. Die Exekutive des Adapter-Service kann folgende Funktionen haben: Authentifizierung: Die externe Identität wird authentifiziert, d.h. es wird z.b. überprüft, ob sie eine gültige digitale Identität von einer bekannten Ausgabestelle besitzt. Name Mapping: Abbildung der externen Identität auf die intern gebräuchliche Identität (siehe Abbildung 3). Registrierung: Erzeugen der Domänen Identität nach den Regeln der Domäne. Allenfalls wird direkt der externe Name zur Registrierung verwendet 4. Access Control Mapping: Autorisierung gemäss den Regeln der Domäne. Die Autorisierung kann implizit auf Grund von vordefinierten Regeln oder explizit erfolgen. In diesem Fall müsste als erster Serviceaufruf ein Autorisierungsantrag gestellt werden. Implizite Autorisierungsregeln könnten z.b. sein, dass Inhaber einer bestimmte Services aufrufen dürfen. 4 Anmerkung: Die Registrierung ist immer notwendig, wenn ein externes Subjekt eine Ressource einer Domäne verwenden will. Existiert die Identität bereits auf Grund einer früheren Registrierung, kann diese natürlich weiter verwendet werden. 22/48

23 Verwaltung und Verteilung der Identität: Es wird der Verwaltungs und Verteilungsprozess im internen IAM System ausgelöst. Nach der Abbildung der externen Identität auf die interne Identität kann die interne Ressource oder der Service verwendet werden. Es gelten jetzt die Spielregeln der Domäne, d.h. es können nur autorisierte Funktionen und Daten verwendet werden. Der Adapter-Service ermöglicht somit durch seine Mapping-Funktionalität dem Benutzer den Zugriff auf die internen Ressourcen oder Services einer Domäne. Dabei profitiert der Benutzer von der Tatsache, dass er mit einer einzigen Identität Zugriff auf interne Ressourcen/Services verschiedener Domänen erhält. Auf Seite der Ressourcen/Service-Besitzer ermöglicht die Mapping-Funktionalität den Administratoren einer Domäne eine feingranulare Zuteilung von Regeln/Rollen. Die Funktionen der Exekutive werden nachfolgend vertieft. Darin enthalten sind auch Prozesse der Legislative Authentifizierung Die externe Identität wird z.b. mit Hilfe ihres digitalen Zertifikats authentifiziert. Damit ist zuerst nur sicher gestellt, dass es sich um eine gültige Identität handelt, besteht doch eine Vertrauensbeziehung zur egov IAM Infrastruktur und somit indirekt zur registrierten CA, welche das digitale Zertifikat erstellt hat. Damit kann dieses Zertifikat auf seine Gültigkeit überprüft werden. Die eigentliche Identifikation findet erst im nächsten Schritt statt (siehe 4.1.2) Name Mapping Wie bereits im Kapitel 3.6 bei der Erklärung zu den Namensräumen erklärt wurde, müssen die externen Identitäten (die Identifkatoren, die Namen der Identitäten) auf die internen Identitäten abgebildet werden. Wie in Abbildung 3 gezeigt wurde ist es möglich, dass ein Subjekt mehrere unterschiedliche Identifikatoren haben kann. Name Mapping kann auch, je nach Bedarf, die mit der Identität mitgelieferten Attribute auf interne Attribute abbilden. Dafür sind entsprechende Regeln im Adapters- Service zu definieren Registrierung der Identität Die Registrierung besteht aus einer Reihe von legislativen Prozessen 5 Identifikation: Die Legislative bestimmt wie externe Identifikatoren und Identitäten im eigenen Namensraum verwendet werden. Administration: Hier wird bestimmt, mit welchen Attributen die Identitäten (Zeichenketten) ausgestattet sind. 5 Die IAM Prozesse innerhalb einer Domäne werden im Detail in Kapitel 6 erklärt. 23/48

24 Nachdem die Identität (der interne Repräsentant) registriert ist, kann sie innerhalb der Domäne für Single Sign-On verwendet werden (sichere Delegation) Access Control Mapping Wenn eine Identität erzeugt wird, müssen ihr noch die für die Domäne gültigen Autorisierungsattribute zugewiesen werden. Die Legislative bestimmt im Autorisierungprozess, wie dieser zu erfolgen hat. Es kann z.b. eine Regel geben, dass externe Identitäten mit der Rolle Gast ausgestattet werden. Das Festlegen der Rechte und Privilegien der Rolle Gast fällt auch in diese Aktivität Verwaltung und Verteilung der Identität Nachdem sämtliche Kriterien zur Erzeugung der Identität klar sind, werden die exekutiven Prozesse Verwaltung und Verteilung ablaufen. Verwaltung: Dieser Prozess erzeugt die Identität mit ihren Attributen im IAM Verzeichnis der Domäne. Verteilung: Dieser Prozess verteilt die Identität auf die notwendigen Zielsysteme. 24/48

25 5. Prinzipien, Anforderungen, Standards 5.1. Prinzipien Für die egov IAM Infrastruktur gelten folgende Prinzipien: Föderalistischer Ansatz: egov IAM muss in der Lage sein die föderalistische Struktur der Schweiz zu unterstützen. Einheitliche Architektur: egov IAM hat eine Schweiz weit gültige Architektur. Schweiz weite Basisinfrastruktur: egov IAM unterstützt den föderalistischen IAM Ansatz durch den Aufbau und Betrieb der dazu notwendigen Basisservices. Dezentrale Umsetzung: Die Integration von egov IAM mit den einzelnen Namensräumen erfolgt dezentral in der Hoheit der jeweiligen Namensraumeigner. egov IAM Koordination: Die Prinzipien und Anforderungen für die egov IAM Infrastruktur werden Schweiz-weit durch eine entsprechende Arbeitsgruppe koordiniert. Vertrauensbeziehungen unter den Domänen: Formelle Vertrauensbeziehungen zwischen den verschiedenen Domänen (Namensräumen) werden etabliert. Standard Attribute: Für IT Benutzer (Subjekt) soll ein minimaler Satz von Attributen wie z.b. Name, Vorname etc. standardisiert werden. Dies erleichtert die Verwendung von digitalen Identitäten Anforderungen Verfügbarkeit: Die egov IAM Infrastruktur ist hoch verfügbar (365 Tage, 24 Stunden) mit einer wohl definierten Performance. Vordefinierte Servicefenster sind vorzusehen. Dabei wird angestrebt, dass auch während diesen Servicefenstern die Verfügbarkeit mit reduzierter Performance bestehen bleibt. Performance: Die Performance der Infrastruktur ist definiert, also z.b. die maximale Antwortzeiten auf eine Serviceabfrage, die maximale Anzahl paralleler Serviceabfragen, die durchschnittlich zu erwartende Service-Zeit für eine Abfrage. Skalierbarkeit: Die egov IAM Infrastruktur definiert die Kapazität der Einträge (Anzahl Identitäten) welche verwaltet werden können. Ebenfalls wird die zu erwartende Entwicklung berücksichtigt, damit die Infrastruktur Schritt halten kann. Benutzerzentrierte Gestaltung des Zugangs und der Services: Das Benutzerinterface für die Benutzung der egov IAM Infrastruktur, insbesondere bei der Registrierung, ist so einfach und klar wie möglich zu gestalten. 25/48

26 Vertrauen durch Kenntnisse der Prozesse, rechtlichen Rahmenbedingungen und verwendeten Infrastrukturen: Es besteht ein verlässlicher vereinbarter Konsens (Garantie) bezüglich Terminologie, Semantik und Interoperabilitäts- Konzepte zwischen den involvierten Vertrauensdomänen. Sicherheit und Datenschutz: Der Benutzer kann auf einen Schutz seiner Handlungen und Daten gemäss jeweiligen Stand der Technik vertrauen und wird wenn notwendig auf allfällige Gefahren hingewiesen. Die Verarbeitung basiert nur auf authentischen und somit verlässlichen Quellen. Es besteht grösstmögliche Transparenz und Nachvollziehbarkeit für den Anwender. Dies gilt besonders für die Validierung von Sicherheitsinformationen. Kontrolle der Domänen-Identitäten: Jede Domäne im Vertrauensverbund garantiert eine sichere Verwaltung und Kontrolle (geregelter Zugriff, Audit) seiner Identitäten. Transparenz der föderalen Systemlandschaft: Im Sinne des GRC (Governance, Risc and Compliance) ist die notwendige Transparenz zu gewährleisten. Dies gilt insbesondere für die von den einzelnen Anwendungen bestimmten und verlangten Identifikatoren und Zugriffsregeln. Einbindung privater Domänen: Die Systemlandschaft ist unter der Voraussetzung entsprechend notwendiger Vereinbarungen und gesetzlichen Rahmenbedingungen gegenüber privaten Domänen offen. Multilevel Zutrittssicherheit: Die IAM-Systeme können mit verschiedenen, definierten Sicherheitsebenen umgehen, z.b. öffentliche Ebene, schwachauthentisierte Ebene, stark authentisierte Ebene. Auditierbarkeit und Nachvollziehbarkeit: Die IAM-Prozesse müssen auditierbar sein. Im Betrieb besteht ein Monitoring. Sicherheitsrelevante Aktionen müssen nachvollziehbar sein (Logging) Vorgaben und Standards Die egov IAM Infrastruktur hält sich an vorgegebene Standards. Von zentraler Bedeutung sind: ech E-Government-Standards EU: Vorgaben und Standards: U.a. MODINIS, IDABC, STORK, CEN Internationale technische IT-Standards: OASIS, WS-*, SOAP, SAML, 26/48

27 6. Prozesse im IAM Umfeld Identity und Access Management hat in erster Linie mit Organisation und Abläufen (Prozessen) zu tun. Die nachfolgende Prozesslandkarte ist in Anlehnung an das ech Referenzmodell IAM in eine Gruppe Legislative und eine Gruppe Exekutive Prozesse aufteilt (Abbildung 10): Abbildung 10: Prozesse im egov IAM Nachfolgend werden diese Prozesse im Einzelnen beschrieben Legislative Identifikation Dieser Prozess ist zuständig für die eindeutige Identifikation einer Ressource. Dazu braucht es eine vertrauensvolle Stelle, welche nach vorgegebenen Kriterien die Subjek- 27/48

28 te und Ressourcen prüft (registriert). Diese Prüfung kann entweder selbst erfolgen, oder man vertraut auf eine externe Stelle, zu welcher ein definiertes Vertrauensverhältnis besteht. Nach erfolgreicher Prüfung der Subjekte und Ressourcen werden diesen eine für diesen Namensraum gültige, eindeutige Identifikation zugewiesen. Dieser Prozess wird ebenfalls initiiert, wenn externe Identitäten domäneninterne Ressourcen verwenden wollen (siehe Kapitel 4.1.3). Anmerkungen: Administration RA Registration Authority: Oft spricht man im Zusammenhang der Identifikation von der Registrierung. Die Stelle, welche diese Registrierung durchführt ist die Registrierungsstelle (engl. Registration Authority RA). CA Certification Authority: Dem Subjekt / der Ressource werden oft nicht einfach nur ein Identifikator (ein eindeutiger Name) ausgestellt. Die Zertifizierungsstelle (engl. Certification Authority CA) stellt ihnen ein digitales Zertifikat aus. Nachdem die Identität des Subjektes geklärt ist, müssen dessen Attribute bestimmt werden. Es wird ein Set verbindlicher Attribute, Access Management Attribute, Spezifische Attribute und Private Attribute zu definieren sein (siehe Kapitel 3.7). Für die Benutzer von IT Ressourcen könnten z.b. der Name, Vorname und die adresse zu den verbindlichen Attributen gehören. Verbindliche Attribute werden oft von zentraler Stelle verwaltet. Private Attribute werden üblicherweise vom Benutzer selbst verwaltet Autorisierung Subjekte (Benutzer) erhalten Rollen und Rechte. Dafür sind üblicherweise Abläufe definiert, wie sie in Abbildung 11 für die Autorisierung eines IT Benutzers beispielhaft dargestellt sind: Abbildung 11: Autorisierung eines IT Benutzers 28/48

29 Die einzelnen Schritte in diesem Beispiel: 1) Der Benutzerverantwortliche sendet einen Autorisierungsantrag an seinen Vorgesetzten. 2) Dieser visiert den Antrag und leitet ihn an den IT Support weiter. 3) Dort wird der Antrag hinsichtlich existierender Autorisierungsprofile verifiziert. Falls die gewünschten Profile dem Antrag entsprechen, wird das Profil direkt zugewiesen (siehe Punkt 6). 4) Muss ein neues Profil erstellt werden, müssen die Anwendungsverantwortlichen konsultiert werden. Diese erstellen allenfalls ein neues Profil. 5) Neue Profile müssen vom IT Security Officer geprüft werden. 6) Anschliessend können die Access Attribute dem neu erstellten Profil zugewiesen werden. 7) Dem Benutzerverantwortlichen und seinem Vorgesetzten wird der Abschluss der Autorisierung zurückgemeldet. Wichtig: Die eigentliche Autorisierung ist der Prozess, wie die Rollen definiert werden, in unserem Beispiel das Erstellen der Standard Profile oder die Erstellung neuer Profile auf Anfrage hin. Ebenfalls zur Autorisierung gehört der Prozess der Zuweisung der Access Profile zum Benutzer. Beides sind legislative Tätigkeiten. Standard Profile könnten dann z.b. genutzt werden, um Access Control Attribute externen Ressourcen automatisch zuzuweisen (siehe 4.1.4). Die Umsetzung bzw. Durchführung der Autorisierung am System selbst sind rein administrative Abläufe Executive Verwaltung Identitäten werden verwaltet. Dies kann durch eine Papierablage - oder natürlich eleganter - mit Hilfe einer IAM Infrastruktur erfolgen. In einer IAM Infrastruktur werden Identitäten und deren Attribute sinnvollerweise in einem Repository (Datenbank, Directory) gespeichert. In obiger Abbildung 11 werden Identitäten vom IT Support verwaltet. 29/48

30 Die Verwaltung selbst ist in nachfolgender Abbildung 12 dargestellt: Verteilung Abbildung 12: IAM Verwaltung und Verteilung Die Verwaltung erzeugt die Identitäten mit deren Attribute im IAM Directory der Domäne der Zielsysteme. Die Verteilung auf die Zielsysteme wird im nachfolgenden Kapitel beschrieben. Identitäten und deren Attribute werden von einer Reihe von Zielsystemen verwendet. Sie müssen also verteilt werden. Ebenfalls muss dafür gesorgt werden, dass die zentrale Verwaltung und die Zielsysteme synchron bleiben, d.h. ihre Identitätsinformationen abgeglichen sind. Abbildung 12 zeigt die Anbindung der IAM Infrastruktur an verschiedene Systeme wie Windows AD, SAP Authentisierung Ressourcen im IT System müssen sich authentisieren, d.h. ausweisen, wer sie sind. Im Umfeld egov IAM wird angenommen, dass sich Subjekte mit einem digitalen Zertifikat einer offiziellen Stelle ausweisen (starke Authentisierung) Authentifizierung Die Überprüfung der Identität eines Subjektes nennt man Authentifizierung. Im Unterschied zum englischen Sprachgebrauch, wo to authenticate für authentisieren und authentifizieren steht, werden im Deutschen die Begriffe unterschieden. Im Umfeld egov IAM bedeutet dieser Prozess die Überprüfung, ob das digitale Zertifikat einer Identität gültig ist, und von einer offiziellen Ausgabestelle stammt. Im Umfeld wir das Authentifizierungszertifikat mit Hilfe des IdPs (Identity Provider Service) vom CSP (Certification Service Provider) authenifiziert. 30/48

31 consults Error consults Access OK Access Control Zugriffsschutz ist der Prozess der dafür sorgt, dass auf eine Ressource nur in der vorgesehenen Art und Weise zugegriffen werden kann. Man unterscheidet zwischen Funktions- Access Control und Daten-Access Control. Funktions-Access Control stellt sicher, dass im Kontext eines Subjektes nur die dafür autorisierten Funktionen ausgeführt werden können. Daten-Access Control stellt sicher, dass das Subjekt nur auf diejenigen Daten in der dafür vorgesehenen Weise zugreifen kann, für welche sie autorisiert ist, also z.b. Read Access auf den Kalender eines anderen Benutzers. Abbildung 13 zeigt ein generisches Access Control Modell. 1 Access Request Access Control Interface 7 Access granted 2 IAM 3 Check credentials Authentication Verification 6 Error Logger 4 5 Fetch Access Control Ruleset Error Access Policy Evaluator Abbildung 13: Generisches Access Control Modell Audit Dieser Prozess zeichnet sicherheitsrelevante Daten im Umfeld IAM auf. Im egov IAM werden die Daten lokal in den einzelnen Domänen geloggt. In der egov IAM Architektur wird festgelegt, welche Ereignisse im Umfeld ech IAM zwingend aufzuzeichnen sind. 31/48

32 7. Technische Architektur Zuerst wird das technische Referenz-Modell (engl. Technical Reference Model, TRM) vorgestellt. Dann wird auf die System-Topologie der vorgeschlagenen Architektur eingegangen. Im Weiteren folgt die Vertiefung entlang der Business-Prozesse, wie sie im Kapitel 6 eingeführt worden sind Technisches Referenz-Modell Das Referenz-Modell wird hauptsächlich aus zwei Gründen eingeführt: Einführung einer konsistenten Taxonomie. Diese definiert eine Terminologie und ermöglicht eine einheitliche Beschreibung der Komponenten sowie der konzeptionellen Strukturen der IAM-Umgebung. Einführung einer entsprechenden TRM-Grafik. Diese enthält eine visuelle Darstellung der verwendeten Taxonomie und verbessert somit das Verständnis für die Taxonomie. Die folgende Abbildung beschreibt eine weitläufig akzeptierte Taxonomie für das Identitäts-Management und die entsprechende visuelle Repräsentation. Abbildung 14: Technische Referenz-Model (TRM) für IAM 6 6 Quelle: Adaption an das Modell von The Open Group 32/48

33 Interface Interface Interface Interface 7.2. IT-Architektur IAM System-Topologie Die egov IAM Systemtopologie wurde bereits in der Vision skizziert: Behörden trust egov IAM Infrastruktur Schweiz 2 CSP ID CA 1 Benutzende Register CSP Infrastruktur IdP CAS 3 2 trust CSP Certification Provider IdP Identity Provider CAS Claim Assertion Service 2 Firmen trust Abbildung 15: Systemtopologie egov IAM IAM Architekturbausteine Die egov IAM Infrastruktur besteht aus vier Architekturbausteinen 7 (Architecture Building Blocks ABB): Registrierungs- und Ausgabestelle für Zertifikate (CSP), CSP Infrastruktur, Träger mit Digitalem Zertifikat, und egov IAM Domänen Adapter- Service. Die CSP und der Träger mit dem Digitalen Zertifikat werden in diesem Dokument nicht weiter vertieft. Beschreibung Funktionen / Prozesse CSP Infrastruktur Zu dieser Infrastruktur gehört im Minimum: IdP (Identity Provider Service): Ein Service zur Verifikation von Authentisierungszertifikaten. Optional können zusätzliche Dienste wie z.b. ein Security Token Service STS (siehe 3.9) angeboten werden (wird bei bekanntlich als CAS Claim Assertion Service bezeichnet). Verifikation Authentifizierungszertifikat Optional: STS Service für Bildung von Security Token mit Claimset und Signatur 7 TOGAF (The Open Group Architectural Framework) verwendet den Begriff der ABBs (Architecture Building Blocks). 33/48

34 egov IAM Domänen Adapter-Service Beschreibung Funktionen / Prozesse Service für das Mapping von externen Identitäten zu internen Identitäten Authentifizierung Name Mapping Registrierung Access Control Mapping Verwaltung und Verteilung auf die internen Zielsysteme. Die Funktionen des egov IAM Domänen Adapters-Service sind in Kapitel 4.1 im Detail beschrieben. Um den Partnern die Teilnahme an der egov IAM Infrastruktur zu erleichtern, wird der egov IAM Domänen Adapter-Service als Standardservice in den gebräuchlichsten Technologien zur Verfügung zu stellen sein. Anmerkung: Der egov IAM Domänen Adapter-Service besteht nicht nur aus Technologie, sondern auch aus der Definition einer Reihe von Prozessen wie z.b. der Regeln, wie Access Control Attribute erstellt werden sollen bzw. welche Abläufe dazu einzuhalten sind (siehe auch Kapitel 7.3.1) Identitäten Im egov Umfeld werden verschiedene CA Dienste unterschiedliche Identitäten 8 mit unterschiedlichen Attributen anbieten. Die Identitäten werden daher unterschiedlich aufgebaut sein. Es wäre natürlich erstrebenswert im egov IAM Umfeld für jede Art von Subjekten und Ressourcen ein gemeinsames, minimales Set von Attributen vorzugeben. Dadurch könnte die egov Infrastruktur effizienter werden. Diese Forderung ist jedoch aus funktionaler Sicht keine Vorbedingung Informationen über Zugangs-Rechte, Privilegien und Rollen Eine IAM Lösung verwaltet normalerweise Zugangsrechte, Privilegien und Rollen zu einer bestimmten Identität. Diese Access Management Attribute werden föderalistisch in den einzelnen Domänen verwaltet, also in der Regel nicht auf der Ebene egov. Auf Ebene egov können jedoch Regeln und Empfehlungen zum Autorisierungsprozess vorgeschlagen werden. Regeln könnten z.b. wie folgt aussehen: Inhaber einer haben Leserecht auf eine bestimmte Datenbank, z.b. auf ihr Einwohnerregister. Eine Notarielle Beglaubigung kann durch das digitale Zertifikat des Notars (, Überprüfung Notariatsregister) geprüft werden. Inhaber einer, welcher zu der Behörde Gemeinde X gehört, darf innerhalb der Gemeinde die Funktionen X, Y, Z ausführen. 8 Hier wird nicht unterschieden zwischen externen und internen Identitäten, geht es doch an dieser Stelle um Identitäten an sich. 34/48

35 Diese Autorisierungsregeln können vom egov IAM Adapter-Service angewendet werden, d.h. bei der Erstellung der internen Identität werden die Access Control Attribute entsprechend diesen Regeln erzeugt. Anmerkung: Die Gültigkeit der Abbildung von externen Access Control Attributen zur internen Abbildung muss bei jedem Aufruf verifiziert werden Identitäts-Speicherung Identitäten werden in der Zertifizierungsstelle (Certification Authority CA) in einem Directory gespeichert. Sie werden den Subjekten und Ressourcen in geeigneter Form zur Verfügung gestellt, z.b. Benutzern auf einer Smart Card oder USB Sticks in Form eines Digitalen Zertifikats. Abbildung 16: Symbolische Darstellung von Trägern (Karte, USB Stick) 7.5. Subjekte und Ressourcen Die Begriffe Subjekt und Ressource wurden im Kapitel Fehler! Verweisquelle konnte nicht gefunden werden. eingeführt. Identitäten werden für unterschiedliche Subjekte und Ressource-Arten verwendet. Flüchtig betrachtet stehen im Umfeld egov IAM die Subjekte IT Benutzer im Vordergrund. Bereits bei der Systemtopologie egov IAM sehen wir jedoch, dass wir uns nicht nur auf diese beschränken dürfen. Im ech Umfeld von zentralem Interesse sind folgende Arten von Subjekten und Ressourcen: Subjekte Normaler Benutzer - Identität für individuelle Personen Funktionaler Benutzer (Delegierte/r) von Firmen Funktionaler Benutzer (Delegierte/r) von Behörden Technische Benutzer, z.b. funktionaler Benutzer eines Service, eines Prozesses, 35/48

36 Interface Ressourcen Anwendungen Services Systeme (z.b. Computer, Drucker, ) weitere 7.6. Provisionierung Abbildung 17 zeigt beispielhaft wie Identitäten eines Benutzers via Notebook, Internet zur Zieldomäne transportiert (provisioniert) werden. Adapter-Service Benutzende 1 Legislative Identifikation Administration Autorisierung Domäne Ressource Ressource Ressource Ressource ID Verifikation Internet egov IAM Infrastruktur Schweiz Exekutive Authentifizierung 2 Name Mapping Registrierung Access Control Mapping Verteilung 5 Lotus Notes Windows AD IAM Domäne SAP IAM Verwaltung IAM Directory Other Appl. RP CSP ID CA CSP Infrastruktur IdP CAS 3 Domänen-ID Registrierung, Access Control Mapping 4 IAM Directory trust Abbildung 17: Provisionierung einer Identität Für die Domäne hat die Legislative die Regeln zur Identifikation, Administration und Autorisierung bestimmt (siehe Kapitel 6.1). Diese Regeln sind im Adapter-Service eingepflegt. In diesem Beispiel verwendet der Benutzer seine Smartcard in seinem Notebook. Sein digitales Zertifikat wird via Internet zum egov IAM Adapter-Service der Zieldomäne gesendet. Im Adapter-Service erfolgen folgende Schritte: 2) Authentifizierung: Es geht um die Verifikation der Identität gemäss dem digitalen Zertifikat. Dies geschieht in der egov IAM Infrastruktur Schweiz, zu welcher die Zieldomäne eine Vertrauensbeziehung hat. 3) Name Mapping: Die externe ID wird gemäss den Regeln der Legislativen zu einer internen ID gemappt. 4) Registrierung: Falls die interne ID noch nicht existiert, wird sie erzeugt. Ihr externer Name wird als Attribut registriert. Es werden allenfalls weitere Attribute angefügt oder beim Benutzer abgefragt (siehe 3.8 Claims und 3.9 Security Token Service STS). 36/48

37 Interface Access Control Mapping: Basierend auf den Regeln der Legislative werden die Access Control Attribute gebildet und registriert. Auch hier könnten zusätzliche Attribute beim Benutzer abgefragt werden. 5) Verteilung: Die interne ID wird an die Zielsysteme in der Domäne provisioniert. 8. Typische Anwendungsfälle Die nachfolgenden Beispiele sollen helfen, die beschriebenen Prozesse besser verstehen zu können Benutzer schaut seine Einwohnerregister-Daten an Vorbedingungen: Benutzer hat Einwohnerregister des Benutzers ist via Internet verfügbar Einwohnerregister hat eine Vertrauensbeziehung zur egov IAM Infrastruktur Innerhalb der Domäne Einwohnerregister gibt es eine IAM Infrastruktur. Diese ist in der Lage für alle Benutzer eine eindeutige Identifikation (Domänen weite Funktion) zu erzeugen. Legislative von Einwohnerregister hat festgelegt: Benutzer sind Einwohner mit einer Jeder Benutzer hat das Recht seine Einwohnerdaten zu sehen (lesen) Benutzer 1 Internet 10 egov IAM Infrastruktur Schweiz CSP ID CA 2 Adapter-Service Legislative Identifikation Administration Autorisierung 9 Lotus Notes 3 Executive 4 Authentifizierung5 Name Mapping Unique ID Registrierung 5 Access Control 6 Mapping Verteilung 7 Windows AD IAM Domäne Domäne Einwohnerregister SAP Einwohnerregister 8 IAM Verwaltung IAM Directory CSP Infrastruktur IdP CAS trust Abbildung 18: Benutzer schaut seine Einwohnerregister-Daten an 37/48

38 1) Der Benutzer verwendet seine an seinem Notebook. Er wählt sein Einwohnerregister. Dort kann er die Funktion Meine Einträge auswählen 2) Das digitale Zertifikat des Benutzers wird an den Domänen Adapter des Einwohnerregisters geschickt. 3) Im Adapter-Service wird als erstes der Authentifizierungsschritt ausgeführt. 4) Mit Hilfe der egov IAM Infrastruktur wird der Benutzer authentifiziert 5) Wenn die Identität des Benutzers verifiziert ist wird für ihn eine eindeutige Domänen Identität erzeugt oder (5 ) eine bereits bestehende ID verwendet. 6) Falls der Benutzer noch nicht im lokalen IAM Directory existiert, wird er registriert. 7) Die Access Control Attribute werden gemäss den Regeln der Legislative implementiert, z.b. Benutzer mit einer haben generell Leserecht auf das Einwohnerregister 8) Der IAM Eintrag wird auf das (die) Zielsystem(e) verteilt oder synchronisiert. 9) Die Abfrage wird vom Adapter zum Einwohnerregister gesendet (im Kontext der lokalen Identität) 10) Die Antwort wird zum Benutzer gesendet Prozesse und Operationen im egov IAM Adapter-Service Der egov IAM Adapter-Service definiert Prozesse und Operationen, wie sie in nachfolgender Abbildung beispielhaft illustriert werden: IAM Regeln Adapter-Service Für Einwohner der Gemeinde gilt: 1. Alle Einwohner der Gemeinde haben einen eindeutigen Eintrag im IAM 2. Elektronische Abfragen werden nur für Benutzer mit einer unterstützt 3. Alle Inhaber von Zertifikaten erhalten Read-Access beim Einwohnerregister 4. Aus Regel 1 folgt, dass für alle Einwohner eine eindeutige Identität erstellt wird. 5. Diese wird im IAM Directory gespeichert. 6. Die notwendigen Access Attribute werden gesetzt, also z.b. Read Access für alle Einwohner im Einwohnerregister. 7. Die Kommunikation mit dem Einwohnerregister erfolgt über Legislative Identifikation Administration Autorisierung Windows AD Domäne Einwohnerregister SAP Einwohnerregister Exekutive Authentifizierung Name Mapping Registrierung Access Control Mapping Verteilung Unique ID 5 IAM Domäne IAM Verwaltung IAM Directory 6 Abbildung 19: Prozesse und Operationen im egov IAM Adapter-Service 38/48

39 Die Legislative der Domäne Einwohnerregister legt die lokalen IAM Regeln fest, zum Beispiel: 1) Alle Einwohner der Gemeinde haben einen eindeutigen Eintrag im IAM der Gemeinde 9. 2) Elektronische Abfragen werden nur für Benutzer mit einer unterstützt 3) Alle Inhaber von Zertifikaten erhalten Read-Access beim Einwohnerregister 4) Aus Regel 1 folgt, dass für alle Einwohner eine eindeutige Identität erstellt wird (innerhalb der Gemeinde). 5) Diese Identität wird im IAM Directory gespeichert. 6) Die notwendigen Access Attribute werden gesetzt, also z.b. Read Access für alle Einwohner im Einwohnerregister. 7) Die Kommunikation mit dem Einwohnerregister erfolgt über Überprüfung eines Dokuments von Notar X durch Benutzer Y Vorbedingungen: Notar und Benutzer haben bereits beide eine eigene Der Notar ist im Anwaltsregister registriert. Dieses Register kann digitale Zertifikate für die darin registrierten Notare ausgeben. Das Anwaltsregister hat eine Vertrauensbeziehung (Trust) zur egov IAM Infrastruktur. 9 Anmerkung: Oft betreiben mehrere Gemeinden zusammen ein Directory, was in diesem Anwendungsfall nicht berücksichtigt wird. 39/48

40 Interface Die folgende Abbildung zeigt einen möglichen Ablauf: Notar Benutzer 1 Dokument Notar Zert Internet Notar Zert Anwaltsregister egov IAM Infrastruktur Schweiz CSP ID CA 3 CSP Infrastruktur IdP CAS trust Abbildung 20: Überprüfung notarielle Beglaubigung eines Dokuments 1) Der Notar verwendet seine an seinem Notebook. 2) Er beantragt ein Notar-Zertifikat bei seinem Anwaltsregister. 3) Das Anwaltsregister überprüft die Identität anhand der des Notars 4) Das digitale Notar-Zertifikat wird dem Notar ausgestellt. 5) Der Notar verpackt das Dokument, sein Zertifikat und das Notar Zertifikat und verschlüsselt das gesamte Paket mit seinem geheimen Schlüssel. Das Packet wird via an den Empfänger (Benutzer) geschickt. 6) Der Benutzer ist ebenfalls mit seiner am Notebook angemeldet. 7) Er enthält das vom Notar, entschlüsselt das Paket mit dem öffentlichen Schlüssel des Notars. Anschliessend schickt er das Notar-Zertifikat zusammen mit seinem Zertifikat zum Anwaltsregister. 8) Auf Grund der Tatsache, dass der Benutzer eine hat ist er berechtigt, diese Anfrage auf Gültigkeit des Notar-Zertifikats auszuführen. Er erhält die entsprechende Antwort. 40/48

41 Interface 8.4. Benutzer (Bürger) wird Mitarbeiter bei einer kantonalen Verwaltung Vorbedingungen: Die kantonale Verwaltung hat beschlossen, dass Benutzer in ihrem IAM Umfeld nur eine einzige Identität haben. Somit verwenden Bürger, welche auch Mitarbeiter sind, die gleiche Identität. Die kantonale Verwaltung hat ein Vertrauensverhältnis (Trust) mit der egov IAM Infrastruktur In der kantonalen Verwaltung werden für die Benutzer zur Authentisierung s auf Smartcards verwendet. Die Legislative der kantonalen Verwaltung hat festgelegt, dass jeder IT Benutzer in der Domäne kantonale Verwaltung nur genau einen IAM Eintrag hat. Mehrere externe Identitäten könne auf eine einzelne Identität in der Domäne abgebildet werden (siehe Abbildung 3). Beim Benutzer X handelt es sich um eine Person, welche bereits zuvor elektronische Dienste mit Hilfe seiner in der kantonalen Verwaltung verwendet hat. Dadurch existiert der Benutzer bereits im IAM Directory der Verwaltung. Nachfolgend ein mögliches Szenario: Benutzer X Vorgesetzter von X Benutzer X Internet Adapter-Service Legislative Identifikation Administration Autorisierung 2 Kantonale Verwaltung egov IAM Infrastruktur Schweiz CSP ID CA Executive Authentifizierung Namemapping Registrierung Access Control Mapping Verteilung Lotus Notes Unique ID 3 HR Windows AD IAM Domäne 3 SAP Other Appl. 4 IAM Verwaltung IAM Directory CSP Infrastruktur IdP CAS trust Abbildung 21: Benutzer X wird Mitarbeiter bei der kantonalen Verwaltung 41/48

42 1) X wurde vom Vorgesetzten angestellt. 2) X wird im Personalsystem (HR) eröffnet. 3) Im IAM Directory der kantonalen Verwaltung wird eine eindeutige Identifikation für X erzeugt. Da diese bereits besteht (siehe Vorbedingungen) wird die bestehende Identifikation weiter verwendet. Allerdings wird ein Attribut Mitarbeiter kantonale Verwaltung angefügt. Als Mitarbeiter der kantonalen Verwaltung erhält er gemäss den Regeln der Legislative die für seine Arbeit notwendigen Access Control Eigenschaften. 4) Seine Identität inkl. der notwendigen Attribute wird zu den Zielsystemen provisioniert. 5) Benutzer X mit seiner meldet sich am Arbeitsplatz (PC, Notebook) der kantonalen Verwaltung an (er authentisiert sich mit Hilfe seiner ). 6) Die Authentifizierung erfolgt lokal, z.b. über das Windows Active Directory, welches in die Vertrauensumgebung der kantonalen Verwaltung mit Trust- Beziehung zur egov IAM Infrastruktur gehört E-Banking eines Kunden mit einer Es wäre natürlich auch möglich dass Benutzer ihre E-Bank Geschäfte mit einer erledigen könnten 10. Vorbedingungen: Die Legislative in der E-Bank hat folgende Regeln festgelegt: Die E-Bank akzeptiert als vertrauensvolles Authentifizierungsmittel. Kunden der E-Bank müssen sich persönlich bei der E-Bank registrieren, um eine Kundenbeziehung aufbauen zu dürfen. Sie brauchen für die Registrierung einen persönlichen Ausweis und ihre persönliche 11, wenn sie diese später für E-Bank Geschäfte verwenden wollen. Authentifizierte Benutzer können alle E-Banking Funktionen auf ihrem Konto ausführen. Der Kunde X hat eine Kundenbeziehung (Konto) bei der E-Bank. Die Initialisierung der Kundenbeziehung ist bereits erfolgt, gemäss den Regeln der Legislative (siehe blaue Pfeile in nachfolgender Abbildung 22). Die E-Bank hat eine Trust-Beziehung zur egov IAM Infrastruktur. 10 Dieser Anwendungsfall ist momentan nicht im Fokus für die. 11 Anmerkung: Bankkunden, welche ein anderes als das eigene Konto mit E-Banking verwalten wollen, brauchen dazu eine ganz normale Vollmacht. Die Bank wird dann die Access Control Attribute in ihrer Domäne entsprechend setzen. Für Eltern gilt normalerweise, dass sie die automatisch im Besitz der Vollmacht ihrer noch nicht volljährigen Kinder sind. 42/48

43 Interface Internet Eine Abfrage seines Kontostands könnte auf folgende Art erfolgen: Kunde X 1 Kundenbeziehung Adapter-Service 2 Legislative Identifikation Administration Autorisierung 7 E-Bank egov IAM Infrastruktur Schweiz 4 3 Executive Authentifizierung Name Mapping Registrierung Access Control Mapping Verteilung 5 Kunden ID 6 Kontoführung CSP ID CA CSP Infrastruktur IdP CAS trust Abbildung 22: Kunde X macht eine Kontoabfrage bei E-Bank 1) Kunde X verwendet an seinem Notebook oder PC seine. 2) Er ruft die E-Bank Anwendung im Internet auf. 3) Dort wird er mit seinem digitalen Zertifikat authentifiziert. 4) Dieses Zertifikat wird via egov IAM Infrastruktur verifiziert. 5) Wenn es gültig ist erfolgt das Name Mapping, d.h. das Abbilden seiner auf die interne Kontonummer. 6) Die Kontoführungsanwendung wird für Kunde X aufgerufen. 7) Kunde X kann die Kontoführungsanwendung verwenden. Den Authentifizierungsschritt (Schritt 3) kann die Bank noch verstärken z.b. durch die Aufforderung der Eingabe einer Zufallszahl, beispielsweise unter Verwendung eines RSA Tokens. Anmerkung: Im egov IAM Adapter-Service wird in diesem Beispiel lediglich die Funktion Authentifizierung und Name Mapping verwendet. 43/48

44 Interface 8.6. Ein Landwirt greift mit einer Suisse-ID auf ein Teilnehmersystem (z.b. Kantonssystem) zu Vorbedingungen: Die Legislative von agate.ch (dem Web Portal von ASA2011) hat folgende Regeln festgelegt: Agate.ch akzeptiert die als vertrauensvolles Authentifizierungsmittel. Agate.ch geht davon aus, dass Landwirte bereits bei ihrem kantonalen Landwirtschaftsamt registriert sind. Auf Stufe Bund sind alle Landwirte bereits in einem IAM der ASA2011 Domäne registriert. Diese Registrierung beruht auf den Registrierungen in den kantonalen Landwirtschaftsämtern. Webapplikationen kantonaler Landwirtschaftssysteme wie z.b. Agriportal, Agrogate, Acorda, Gelan und Systeme des Bundes wie z.b. Hoduflu, TVD, DBMilch sind in das Landwirtschaftsportal des Bundes agate.ch eingebunden. Alle kantonalen Landwirtschaftssysteme sowie die Landwirtschaftssysteme des Bundes sowie das neue Portal agate.ch sind in der Domäne ASA2011 zusammengefasst. Diese Domäne hat eine Trust-Beziehung zur egov IAM Infrastruktur. Der Aufruf seiner Daten im Kantonssystem könnte auf folgende Art erfolgen: Landwirt 2 1 Internet egov IAM Infrastruktur Schweiz CSP ID CA 5 Adapter-Service Legislative Identifikation Administration Autorisierung Executive Authentifizierung Name Mapping Registrierung Access Control Mapping Verteilung agate.ch 4 10 IAM Domäne 3 Agriportal 3 Agrogate Acorda Domäne ASA 2011 Systeme Bund DBMilch TVD Hoduflu Systeme Kantone Gelan CSP Infrastruktur IdP CAS trust Abbildung 23: Landwirt X greift auf seine kantonalen Daten zu. 44/48

45 1) Landwirt X verwendet an seinem Notebook oder PC seine. 2) Er ruft das agate.ch Portal auf. In dieses Portal sind sowohl kantonale wie auch Systeme vom Bund eingebunden. 3) Er selektiert eine Funktion eines kantonalen Systems, z.b. Einsehen von Direktzahlungsdaten im Agriportal. Die Funktion dieses Systems verlangt eine starke Authentisierung. 3 : Zeigt Aufruf eines Bundessystems. Die einzelnen nachfolgenden Schritte bleiben sich jedoch gleich. 4) Der Authentifizierungsservice im Adapter-Service wird aufgerufen 5) Zertifikat wird verifiziert 6) Im IAM der Domäne wird geprüft, ob diese bereits vorhanden ist. Wenn ja ist der Benutzer bereits eindeutig authentifziert. Weiter mit Schritt 12. 7) Namemapping ist verantwortlich für das Abbilden der auf die ID des bekanntlich bereits registrierten Landwirts (siehe Vorbedingung) 12. 8) Zum bereits bekannten Eintrag für den Landwirt im IAM der Domäne wird die registriert. 9) Allenfalls spezifizierte Access Control Regeln der Legislative werden als Attribute im IAM der ASA2011 Domäne für den Landwirt angelegt / ergänzt ) Abschluss der Authentisierung: Gewünschter Service kann im Kontext des Benutzers aufgerufen werden Benutzer kauft bei einem Versandhaus ein In diesem Anwendungsfall wird das Prinzip der Claims erklärt im Umfeld. Vorbedingungen: Benutzer hat Versandhaus ewärli vertraut auf egov Infrastruktur (Trust-Beziehung), d.h. akzeptiert Kunden, welche sich mit ausweisen. Kunden müssen sich für den Einkauf bei ewärli registrieren. 12 Der Landwirt ist bekanntlich bereits im IAM von ASA 2011 registriert. Dort weiss man vorerst noch nichts von seiner. Aufgrund der Angaben der muss herausgefunden werden, um welchen Landwirt es sich handelt. Können die Angaben in der (konkret die Attribute im Zertifikat) direkt einem registrierten Landwirt zugeordnet werden, ist die Identifikation eindeutig und kann automatisch geschehen. Sind diese Angaben nicht eindeutig, werden vom Landwirt zusätzliche Angaben verlangt um diese Eindeutigkeit herzustellen. Dies könnte z.b. mit Claims wie im Anwendungsfall 8.7 erfolgen. Nachdem der Landwirt das erste Mal eindeutig identifiziert worden ist, wird seine als Attribut zu seinem Identifikator im IAM der ASA2011 Domäne gespeichert. Bei einem erneuten Aufruf mit der gleichen würde er dann direkt gefunden ohne zusätzliche Angaben. 13 Die Autorisierung des Landwirts erfolgte bereits bei der Registrierung des Benutzers. Hier würden nur zusätzliche Autorisierungsattribute aus den Regeln der Legislative im Zusammenhang mit der Anbindung der umgesetzt. 45/48

46 Interface CA Datenfreigabe Anfrage von: https://*.ewaerli.ch Ihre Nummer: Name: Hans Muster https://*. ewaerli.ch fragt nach folgenden Angaben: Name Wert Status Übertragung Name Peter Muster erforderlich -Nr erforderlich Über 18 Ja erforderlich optional Geburtstag optional OK Abbrechen Der Ablauf für die Kundenregistrierung könnte etwa wie folgt aussehen: Kunde egov IAM Infrastruktur Schweiz 1 CSP ID CA CSP Infrastruktur IdP CAS Privacy Statement: https://www.ewaerli/privacy-policy.html 7 6 Internet 5 Adapter-Service Legislative Identifikation Administration Autorisierung Executive Authentifizierung Name Mapping Registrierung Access Control Mapping Verteilung 4 8 Login Kasse eshop Warenkorb Kunden-DB Sortiment ewärli trust Abbildung 24: Kunde registriert sich bei Versandhaus ewärli 1) Kunde verwendet an seinem Notebook die 2) Er ruft den eshop des Versandhauses ewärli auf 3) Dort wählt er die Login Funktion. Da er noch nicht ein bekannter Kunde ist, muss er sich registrieren. 4) Authentifizierung mit 5) Verifikation der beim IdP des CSP 6) Für die Registrierung des Kunden braucht es folgende Informationen: Über 18 Jahre alt Adresse (optional) Genaues Geburtsdatum (optional) Dazu sendet der eshop eine Anfrage an den Browser des Kunden mit einem redirect zum Claim Assertion Service des CSPs. 46/48

47 7) Der CAS zeigt folgenden Dialog im Browser: CA Datenfreigabe Anfrage von: https://*.ewaerli.ch Ihre Nummer: Name: Hans Muster https://*. ewaerli.ch fragt nach folgenden Angaben: Name Wert Status Übertragung Name Peter Muster erforderlich -Nr erforderlich Über 18 Ja erforderlich optional Geburtstag optional Privacy Statement: https://www.ewaerli/privacy-policy.html OK Abbrechen Abbildung 25: Claims zur Freigabe durch den Benutzer Der Kunde muss einverstanden sein, dass sein Name, die Nummer sowie das Attribut Über 18 verwendet werden. Optional kann er noch das Attribut und Geburtstag freigeben. Drück er auf OK werden die entsprechenden Angaben an ewärli übermittelt, sonst wird der Vorgang abgebrochen. 8) Bei Freigabe der erforderlichen Attribute wird der Login Vorgang fortgesetzt. Es erfolgt das interne Namemapping, die Registrierung in der Kundendatenbank sowie das Access Control Mapping gemäss den Regeln der Legislative. 9) Damit ist der Login Vorgang beendet; der Kunde kann einkaufen. 10) Einkaufsdialog mit dem Kunden. Falls der Kunde bereits registriert ist, wird nach der Verifikation der (Schritt 5) direkt die Login Prozedur abgeschlossen (Schritt 9). 47/48

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause 1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management Deckblatt Bremen, E-Government in medias res, 12. Juli 2007 Internationale Standards zu Identity Management 3 Dataport 12.Juli 2007

Mehr

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick Dr. Joachim Gerber INFORA-Kompetenzteam Informationssicherheit & Id-Management München, 14.06.2010 Agenda 1. Identität Begriff

Mehr

1. Sept. 2010. Über Keyon

1. Sept. 2010. Über Keyon Über Keyon 1 Eidgenössisches Volkswirtschaftsdepartement EVD Staatssekretariat für Wirtschaft SECO 1. September 2010, Zürich eberhard@keyon.ch 3 SuisseID: Kurz-Steckbrief Die SuisseID ist: ein ZertES-konformes

Mehr

(c) 2014, Peter Sturm, Universität Trier

(c) 2014, Peter Sturm, Universität Trier Soziotechnische Informationssysteme 6. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 1 Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung Nachweis einer behaupteten

Mehr

Fachgruppe IAM (Identity & Access Management) Fachgruppenleitung: Hans Häni AFI Kanton Thurgau Markus Itin KITT Kanton Zürich

Fachgruppe IAM (Identity & Access Management) Fachgruppenleitung: Hans Häni AFI Kanton Thurgau Markus Itin KITT Kanton Zürich Generalversammlung ech, 7. März 2008, Fribourg Fachgruppe IAM () Fachgruppenleitung: Hans Häni AFI Kanton Thurgau Markus Itin KITT Kanton Zürich IAM auf dem Weg zum ech-standard GV_eCH_IAM: 07.03.2008

Mehr

Generalversammlung ech 13. März 2009, Luzern

Generalversammlung ech 13. März 2009, Luzern Generalversammlung ech 13. März 2009, Luzern ech-fachgruppe IAM (Identity und Access Management) Co-Fachgruppenleiter: Hans Häni AFI Kanton Thurgau Identity und Access Management Basisbausteine für Anwendungen

Mehr

Identity as a Service

Identity as a Service Identity as a Service Michael Seeger Siemens IT Solutions and Services CISM. Identity as a Service Geschichtlicher Abriss Technik oder the gory details Voraussetzungen Business case Referenzen und Links

Mehr

IAM-Lösungsarchitektur CH

IAM-Lösungsarchitektur CH IAM-Lösungsarchitektur CH ffo B2.06 Identifikation und Berechtigungsverwaltung ech FG-IAM Identity & Access Management egov Lunch BFH 26.08.2010, Bern Autor: Hans Häni AFI TG, Co-Leiter e-ch-fg IAM und

Mehr

S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen

S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen Herzlichen Dank! Projektleitung S.A.F.E.: Meinhard Wöhrmann (meinhard.woehrmann@olg-duesseldorf.nrw.de)

Mehr

Federated Identity Management

Federated Identity Management Federated Identity Management Verwendung von SAML, Liberty und XACML in einem Inter Campus Szenario d.marinescu@gmx.de 1 Fachbereich Informatik Inhalt Grundlagen Analyse Design Implementierung Demo Zusammenfassung

Mehr

SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung

SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung Ergebnisse der TeleTrusT-AG "SOA" SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung Arbeitsergebnisse des SOA Security AKs Anfang 2009 - Themenfindung für das Dokument Mitte 2009 Vorgehenskonzept

Mehr

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter SAML/Shibboleth Ein Vortrag von Florian Mutter Security Assertion Markup Language XML-basierter Standard für den Austausch von Authentifizierungs-, Attributs- Berechtigungsinformationen Seit 2001 von OASIS

Mehr

SECURITY DESIGN PATTERN FÜR EHEALTH-PLATTFORMEN

SECURITY DESIGN PATTERN FÜR EHEALTH-PLATTFORMEN Matthias Heyde / Fraunhofer FOKUS SECURITY DESIGN PATTERN FÜR EHEALTH-PLATTFORMEN Dr. Jörg Caumanns Fraunhofer FOKUS, Berlin BEISPIELE FÜR EHEALTH ARCHITEKTUREN Security Security Security c c c c c c S

Mehr

Dienste für Identifikation und Berechtigungsverwaltung

Dienste für Identifikation und Berechtigungsverwaltung Dienste für Identifikation und Berechtigungsverwaltung Referent: Hans Häni Co-Leitung ech-fachgruppe IAM ech-gv 23.03.2012: H. Häni 1 Inhalt - IT-Architekturwandel - Konsequenzen für IAM - Federated IAM

Mehr

Identity and Access Management for Complex Research Data Workflows

Identity and Access Management for Complex Research Data Workflows Identity and Access Management for Complex Research Data Workflows Richard Zahoransky, Saher Semaan, Klaus Rechert richard.zahoransky@rz.uni-freiburg.de, semaan@uni-freiburg.de, klaus.rechert@rz.uni-freiburg.de

Mehr

Whitepaper bi-cube SSO Synergien durch die Anbindung eines externen SSO an bi-cube IPM

Whitepaper bi-cube SSO Synergien durch die Anbindung eines externen SSO an bi-cube IPM Whitepaper bi-cube SSO Synergien durch die Anbindung eines externen SSO T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g Inhalt 1 ZIEL...3 2 FUNKTIONS-KONZEPT...3 2.1 Struktur...3

Mehr

Sichere Datenhaltung in verteilten Systemen

Sichere Datenhaltung in verteilten Systemen Sichere Datenhaltung in verteilten Systemen Bericht über ein Großprojekt im medizinischen Bereich Dipl. Inform. Ramon Mörl Ausgangssituation Heterogene Infrastruktur verteilt über mehrere Standorte Mainframes,

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de Grundlagen AAI, Web-SSO, Metadaten und Föderationen Wolfgang Pempe, DFN-Verein pempe@dfn.de DFN-AAI IdP-Workshop, 24./25. Juni 2015, HS Amberg-Weiden Was ist DFN-AAI? AAI Authentifizierung Autorisierung

Mehr

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language.

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language. Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo Security Assertion Markup Language Björn Rathjens Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo 1 Einführung

Mehr

Mobile ID für sichere Authentisierung im e-government

Mobile ID für sichere Authentisierung im e-government Mobile ID für sichere Authentisierung im e-government Patrick Graber Senior Security Consultant, dipl. El.-Ing. ETH Swisscom (Schweiz) AG Grossunternehmen Agenda 2 Einführung in Mobile ID Mobile ID für

Mehr

Metadaten. Organisationsstrukturen und Sicherheit in Shibboleth. Authentifizierung, Autorisierung und Rechteverwaltung

Metadaten. Organisationsstrukturen und Sicherheit in Shibboleth. Authentifizierung, Autorisierung und Rechteverwaltung Authentifizierung, Autorisierung und Rechteverwaltung Metadaten Organisationsstrukturen und Sicherheit in Shibboleth 3. Shibboleth-Workshop Freiburg, 10. Oktober 2006 Bernd Oberknapp, UB Freiburg E-Mail:

Mehr

Di 8.3. Windows CardSpace und das Identity Metasystem Philosophie, Technik und Praxis. Dominick Baier

Di 8.3. Windows CardSpace und das Identity Metasystem Philosophie, Technik und Praxis. Dominick Baier Di 8.3 January 21-25, 2008, Munich, Germany ICM - International Congress Centre Munich Windows CardSpace und das Identity Metasystem Philosophie, Technik und Praxis Dominick Baier In-depth support and

Mehr

Kobil Roundtable 2013. Identity Federation. Konzepte und Einsatz

Kobil Roundtable 2013. Identity Federation. Konzepte und Einsatz Kobil Roundtable 2013 Identity Federation Konzepte und Einsatz Basel, 23. Oktober 2013 3 AD domain controller AD domain controller csi-domäne File server Exchange server Basel, 23. Oktober 2013 4 cnlab-domäne

Mehr

SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen

SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen Thomas Lenggenhager thomas.lenggenhager@switch.ch Bern, 11. Juni 2010 Übersicht Die Shibboleth basierte SWITCHaai

Mehr

Identity Management. Nutzen Konzepte Standards. Dr. Oliver Stiemerling

Identity Management. Nutzen Konzepte Standards. Dr. Oliver Stiemerling Identity Management Nutzen Konzepte Standards Dr. Oliver Stiemerling ecambria systems GmbH Hospeltstr. 35a 50825 Köln Tel.: 0221 595527-0 Fax.: 0221 595527-5 os@ecambria-systems.com http://www.ecambria-systems.com

Mehr

MOA-ID Hands-On Workshop

MOA-ID Hands-On Workshop MOA-ID Hands-On Workshop Architektur und Neuerungen Wien, 27.05.2014 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz Neuerungen Datenbankbasierte

Mehr

Glossar zum S.A.F.E. Feinkonzept

Glossar zum S.A.F.E. Feinkonzept Glossar zum S.A.F.E. Feinkonzept Thema: Verantwortlich: Secure Access to Federated E-Justice/E-Government Bund-Länder-Kommission für Datenverarbeitung und Rationalisierung in der Justiz Version.Release:

Mehr

Mobile ID für sichere Authentisierung im e-government

Mobile ID für sichere Authentisierung im e-government Mobile ID für sichere Authentisierung im e-government Patrick Graber Senior Security Consultant, dipl. El.-Ing. ETH Swisscom (Schweiz) AG Grossunternehmen Agenda 2 Einführung in Mobile ID Mobile ID für

Mehr

S.A.F.E. 4. Dresdner Forum für Notarrecht. Secure Access to Federated E-Justice/E-Government

S.A.F.E. 4. Dresdner Forum für Notarrecht. Secure Access to Federated E-Justice/E-Government 4. Dresdner Forum für Notarrecht S.A.F.E. Secure Access to Federated E-Justice/E-Government Sven Voss 29. Juni 2012 Ausgangslage Ich möchte elektronisch rechtswirksame Erklärungen abgeben Einsicht in Register

Mehr

Aufbau einer AAI im DFN. Ulrich Kähler, DFN-Verein kaehler@dfn.de

Aufbau einer AAI im DFN. Ulrich Kähler, DFN-Verein kaehler@dfn.de Aufbau einer AAI im DFN Ulrich Kähler, DFN-Verein kaehler@dfn.de Motivation Physiker aus unterschiedlichen Hochschulen sollen auf einen gemeinsamen Datenbestand zugreifen. Mitarbeiter und Studierende einer

Mehr

Single Sign-On / Identity Management

Single Sign-On / Identity Management Ein Überblick Michael Jäger 15. Juni 2010 1 / 55 Inhalt 1 Begriffe Web Single Sign-On Identität und Web-SSO SSO Szenarien Föderative Identitätsverwaltung SSO und SOA 2 Identitätsverwaltungssysteme Überblick

Mehr

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Ein Großteil der heutigen Kommunikation geschieht per email. Kaum ein anderes Medium ist schneller und effizienter. Allerdings

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Positionspapier: Portalverbund und ehealth

Positionspapier: Portalverbund und ehealth Positionspapier: Portalverbund und ehealth e-government Arbeitsgruppe Integration und Zugänge (AG-IZ) Dr. Wilfried Connert Franz Hoheiser-Pförtner, MSc Rainer Hörbe Peter Pfläging Juli 2009 Inhalt Zielsetzung

Mehr

Implementierung von PVP 2.0 für neue Wege im Federated Identity Management

Implementierung von PVP 2.0 für neue Wege im Federated Identity Management Standardportal 2.0 Implementierung von PVP 2.0 für neue Wege im Federated Identity Management Bundesministerium für Inneres und Land-, forst- und wasserwirtschaftliches Rechenzentrum GmbH Inhalt LFRZ GmbH

Mehr

Kapitel. Sicherheit. Seite. Kapitel. Sicherheit. Workplace & WebSphere Domino & Notes

Kapitel. Sicherheit. Seite. Kapitel. Sicherheit. Workplace & WebSphere Domino & Notes Sicherheit 99 9 Sicherheit 7. Ergänzungslieferung 02/2007 Ein ITP-Handbuch 9 Sicherheit 9 Moderne Anwendungen müssen einer Vielzahl von Anforderungen gerecht werden. Mit dem Siegeszug der IT in die Geschäftswelt

Mehr

Erstellen sicherer ASP.NET- Anwendungen

Erstellen sicherer ASP.NET- Anwendungen Erstellen sicherer ASP.NET- Anwendungen Authentifizierung, Autorisierung und sichere Kommunikation Auf der Orientierungsseite finden Sie einen Ausgangspunkt und eine vollständige Übersicht zum Erstellen

Mehr

Modernes Identitätsmanagement für das Gesundheitswesen von morgen

Modernes Identitätsmanagement für das Gesundheitswesen von morgen Modernes Identitätsmanagement für das Gesundheitswesen von morgen Berlin, 26.04.2012 Dr. Detlef Hühnlein, ecsec GmbH 2012 ID4health Copyright 2010 ecsec GmbH, All Rights Reserved. Agenda Ausgangssituation

Mehr

1 Die Active Directory

1 Die Active Directory 1 Die Active Directory Infrastruktur Prüfungsanforderungen von Microsoft: Configuring the Active Directory Infrastructure o Configure a forest or a domain o Configure trusts o Configure sites o Configure

Mehr

ech-0107 Gestaltungsprinzipien für die Identitäts- und Zugriffsverwaltung

ech-0107 Gestaltungsprinzipien für die Identitäts- und Zugriffsverwaltung E-Government-Standards Seite 1 von 53 ech-0107 Gestaltungsprinzipien für die Identitäts- und Zugriffsverwaltung (IAM) Name Standard-Nummer Kategorie Reifegrad Gestaltungsprinzipien für die Identitäts-

Mehr

Föderiertes Identity Management

Föderiertes Identity Management Föderiertes Identity Management 10. Tagung der DFN-Nutzergruppe Hochschulverwaltung Berlin, 09.05.-11.05.2011 Peter Gietz, CEO, DAASI International GmbH Peter.gietz@daasi.de 1 von 23 (c) Mai 2011 DAASI

Mehr

Die elektronische Identität - einmal registriert, überall akzeptiert. Oberlandesgericht DüsseldorfD

Die elektronische Identität - einmal registriert, überall akzeptiert. Oberlandesgericht DüsseldorfD Die elektronische Identität - einmal registriert, überall akzeptiert. Dipl.-Phys. Meinhard Wöhrmann, W Oberlandesgericht DüsseldorfD IT-Forum: E-Justice Im Dienste der Gesellschaft Oberlandesgericht Köln,

Mehr

IA&DT Sharepoint Extranet mit IA&DT Single Sign On (SSO) Authentifizierung

IA&DT Sharepoint Extranet mit IA&DT Single Sign On (SSO) Authentifizierung IA&DT Sharepoint Extranet mit IA&DT Single Sign On (SSO) Authentifizierung Inhalt SSO Account... 1 Erstkontakt mit dem System (Internet / Kundensicht)... 2 Erstkontakt mit dem System (Intranet)... 3 Funktionen

Mehr

Allgemeine Erläuterungen zu

Allgemeine Erläuterungen zu en zu persönliche Zertifikate Wurzelzertifikate Zertifikatssperrliste/Widerrufsliste (CRL) Public Key Infrastructure (PKI) Signierung und Verschlüsselung mit S/MIME 1. zum Thema Zertifikate Zertifikate

Mehr

VERZEICHNISDIENSTE IN E-GOVERNMENTSYSTEMEN

VERZEICHNISDIENSTE IN E-GOVERNMENTSYSTEMEN Marcel Huth, 31.07.2008 VERZEICHNISDIENSTE IN E-GOVERNMENTSYSTEMEN Schwerpunkt DVDV und SAFE Huth, Strack Inhalt 1. Allgemeines zu Verzeichnisdiensten 2. Das Projekt DVDV 1. Allgemeines 2. Komponenten

Mehr

Thomas Kessler Identity Provider kurze strategische Betrachtung Fachvortrag an der security-zone 2013

Thomas Kessler Identity Provider kurze strategische Betrachtung Fachvortrag an der security-zone 2013 Thomas Kessler Identity Provider kurze strategische Betrachtung Fachvortrag an der security-zone 2013 Thomas Kessler / thomas.kessler@temet.ch / 079 508 25 43 / www.temet.ch Inhalt Angaben zum Referenten

Mehr

Die SuisseID ts- und Funktionsnachweis. 11.06.2010 BAT Architekturforum Urs Bürge; mail@ursbuerge.ch

Die SuisseID ts- und Funktionsnachweis. 11.06.2010 BAT Architekturforum Urs Bürge; mail@ursbuerge.ch Die SuisseID für r Identitäts ts- und Funktionsnachweis 11.06.2010 BAT Architekturforum Urs Bürge; mail@ursbuerge.ch 1 Inhaltsverzeichnis 1. Ausgangslage und Zielsetzung 2. Was ist die SuisseID 3. Die

Mehr

GeoXACML und SAML. Ubiquitous Protected Geographic Information. Dr. Andreas Matheus Universität der Bundeswehr München Andreas.Matheus@unibw.

GeoXACML und SAML. Ubiquitous Protected Geographic Information. Dr. Andreas Matheus Universität der Bundeswehr München Andreas.Matheus@unibw. GeoXACML und SAML Ubiquitous Protected Geographic Information Dr. Andreas Matheus Universität der Bundeswehr München Andreas.Matheus@unibw.de Was erwartet Sie in diesem Vortrag? Einleitung OpenGIS Web

Mehr

Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences

Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences WISSENSCHAFTLICHE WEITERBILDUNG Fernstudium Industrial Engineering Produktions- und Betriebstechnik Kurseinheit 98 und

Mehr

Sichere Web-Services in einem föderierten Umfeld

Sichere Web-Services in einem föderierten Umfeld Sichere Web-Services in einem föderierten Umfeld ZKI Arbeitskreis Verzeichnisdienste ZEDAT FU Berlin Axel Maurer Die Kooperation von Forschungszentrum Karlsruhe GmbH und Universität Karlsruhe (TH) integrierte

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG 1 Portalverbundprotokoll Version 2 S-Profil Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG Kurzbeschreibung Das S-Profil von PVP2 verwendet SAML WebSSO für die Authentifizierung von Benutzern mit Webbrowser.

Mehr

Programmierhandbuch SAP NetWeaver* Sicherheit

Programmierhandbuch SAP NetWeaver* Sicherheit Martin Raepple Programmierhandbuch SAP NetWeaver* Sicherheit Galileo Press Bonn Boston Inhalt Vorwort 13 2.1 Sicherheit und serviceorientierte Architekturen 24 2.1.1 Sicherheitsziele der Informationssicherheit

Mehr

Identity-Management flexible und sichere Berechtigungsverwaltung

Identity-Management flexible und sichere Berechtigungsverwaltung Identity-Management flexible und sichere Berechtigungsverwaltung Neue Herausforderungen im nationalen und internationalen Einsatz erfordern dynamische IT- Prozesse Bonn, 06. November 2009 Herausforderungen

Mehr

Was ist Identity Management?

Was ist Identity Management? DECUS IT - Symposium 2005 Andreas Zickner HP Deutschland 2004 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Problem IT Admin Mitarbeiter

Mehr

Einrichtung einer Testumgebung zur Demonstration zertifikatsbasierter Anwendungen

Einrichtung einer Testumgebung zur Demonstration zertifikatsbasierter Anwendungen Einrichtung einer Testumgebung zur Demonstration zertifikatsbasierter Anwendungen Knowlegde Guide Wien, Februar 2004 INHALT Für den Test von zertifikatsbasierten Anwendungen in einer Windowsumgebung benötigt

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

egov aus dem Baukasten

egov aus dem Baukasten 1 egov aus dem Baukasten Am Beispiel von ZEMIS Hans Burger Senior IT Consultant 4. November 2014 Agenda AdNovum egov-baukasten ZEMIS Übersicht Nutzungsbeispiele Baukasten Fazit 3 AdNovum Swiss Quality

Mehr

ech-0167 SuisseTrustIAM Rahmenkonzept

ech-0167 SuisseTrustIAM Rahmenkonzept E-Government-Standards Seite 1 von 29 ech-0167 SuisseTrustIAM Rahmenkonzept Name Standard-Nummer Kategorie Reifegrad SuisseTrustIAM Rahmenkonzept ech-0167 Standard Definiert Version 1.0 Status Genehmigt

Mehr

Server Installation 1/6 20.10.04

Server Installation 1/6 20.10.04 Server Installation Netzwerkeinrichtung Nach der Installation müssen die Netzwerkeinstellungen vorgenommen werden. Hierzu wird eine feste IP- Adresse sowie der Servername eingetragen. Beispiel: IP-Adresse:

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

Veröffentlichung und Absicherung von SharePoint Extranets

Veröffentlichung und Absicherung von SharePoint Extranets Veröffentlichung und Absicherung von SharePoint Extranets Denis Holtkamp, ITaCS GmbH Senior Consultant IT-Infrastruktur Goldsponsor: Partner: Silbersponsoren: Veranstalter: Agenda Intranet Extranet-Szenarien

Mehr

Bürgerkonto Niedersachsen Eine Anmeldung für Bürgerservices

Bürgerkonto Niedersachsen Eine Anmeldung für Bürgerservices Bürgerkonto Niedersachsen Eine Anmeldung für Bürgerservices 28.08.2013 Agenda Warum Bürgerkonto Niedersachsen? Übersichtliches Portal Bausteine der Lösung und Kommunikationsprozess Derzeit in Planung Bürgerkonto

Mehr

Testbed II GDI NRW. Geodateninfrastruktur Nordrhein-Westfalen. Web Authentication & Authorization Service. Dokumentation Version 1.0.

Testbed II GDI NRW. Geodateninfrastruktur Nordrhein-Westfalen. Web Authentication & Authorization Service. Dokumentation Version 1.0. GDI NRW Geodateninfrastruktur Nordrhein-Westfalen Testbed II Web Authentication & Authorization Service Februar Dezember 2002 Dokumentation Version 1.0 Teilnehmer AED Graphics con terra FhG ISST GIA GIUB

Mehr

ISSS Security Lunch - Cloud Computing

ISSS Security Lunch - Cloud Computing ISSS Security Lunch - Cloud Computing Technische Lösungsansätze Insert Andreas Your Kröhnert Name Insert Technical Your Account Title Manager Insert 6. Dezember Date 2010 The Cloud Unternehmensgrenzen

Mehr

Enterprise Web-SSO mit CAS und OpenSSO

Enterprise Web-SSO mit CAS und OpenSSO Enterprise Web-SSO mit CAS und OpenSSO Agenda Gründe für SSO Web-SSO selbst gemacht Enterprise Web-SSO mit CAS Enterprise Web-SSO mit SUN OpenSSO Federation-Management Zusammenfassung Gründe für SSO Logins

Mehr

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen D-TRUST GmbH Kommandantenstraße 15 10969 Berlin für den Zertifizierungsdienst D-TRUST SSL Class 3 CA 1 EV

Mehr

Aktuelle Entwicklungen zu GridShib

Aktuelle Entwicklungen zu GridShib Aktuelle Entwicklungen zu GridShib Ralf Gröper und Christian Grimm, RRZN Reimer Karlsen-Masur, DFN 2. D-Grid Security Workshop 27. März 2007 Agenda Das IVOM-Projekt Übersicht GridShib: Komponenten und

Mehr

Social Login mit Facebook, Google und Co.

Social Login mit Facebook, Google und Co. IAM EXCELLENCE OAuth 2.0 und OpenID Connect Social Login mit Facebook, Google und Co. Stefan Bohm www.ic-consult.com Geschützte Ressourcen = Userattribute + Steuerung des Logins + Information über Login

Mehr

Freie Zertifikate für Schulen und Hochschulen

Freie Zertifikate für Schulen und Hochschulen Freie Zertifikate für Schulen und Hochschulen Dr. Thomas Bremer CAcert Inc. Public Key Kryptographie Zwei Schlüssel: ein Öffentlicher und ein Privater Damit kann man Daten verschlüsseln und digital signieren

Mehr

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet SEC Für ein sicheres Internet Was ist SEC? SEC ist eine Erweiterung des Domain Namen Systems (), die dazu dient, die Echtheit (Authentizität) und die Voll ständig keit (Integrität) der Daten von - Antworten

Mehr

Herzlich Willkommen! Seminar Web Engineering: Vortrag Thema: Federated Identity Management Systems Von: Thomas Blasek Betreuer: Stefan Wild

Herzlich Willkommen! Seminar Web Engineering: Vortrag Thema: Federated Identity Management Systems Von: Thomas Blasek Betreuer: Stefan Wild Herzlich Willkommen! Seminar Web Engineering: Vortrag Thema: Federated Identity Management Systems Von: Betreuer: Stefan Wild Einleitung Federated System -> Verbund von Teilnehmern Austausch von Identitätseigenschaften

Mehr

FirstWare FreeEdition Quick Start Guide. Version 1.3

FirstWare FreeEdition Quick Start Guide. Version 1.3 FirstWare FreeEdition Quick Start Guide Version 1.3 Inhaltsverzeichnis 1 Einleitung...3 2 Systemvoraussetzungen...4 2.1 Lokale Installation...4 2.2 Web Server Installation (IIS)...5 3 Installationsanleitung...6

Mehr

1 ZIEL: ENGE INTEGRATION EINER PKI MIT EINEM IDENTITY & PROVISIONING MANAGEMENT SYSTEM (IPM)...2 3 PKI-PROZESSE...3. 3.1 Tokenverwaltung...

1 ZIEL: ENGE INTEGRATION EINER PKI MIT EINEM IDENTITY & PROVISIONING MANAGEMENT SYSTEM (IPM)...2 3 PKI-PROZESSE...3. 3.1 Tokenverwaltung... IPM mit integrierter PKI Inhalt 1 ZIEL: ENGE INTEGRATION EINER PKI MIT EINEM IDENTITY & PROVISIONING SYSTEM (IPM)...2 2 BI-CUBE PKI...3 3 PKI-PROZESSE...3 3.1 Tokenverwaltung...3 3.2 Tokenzuweisung...4

Mehr

SUN IDENTITY MANAGEMENT

SUN IDENTITY MANAGEMENT SUN IDENTITY MANAGEMENT OCG - 12. Competence Circle DI Bernhard Isemann Geschäftsführer Sun Microsystems Austria Fachliche Anforderungen Identity Management Lösungen adressieren konkurrierende Ziele Corporate

Mehr

agate.ch - Plattform für Applikationsintegration Yannick Beaud Fachgruppenleiter Architektur und Strategie, ISCeco EVD Reto Kohlas IT Architect, [ipt]

agate.ch - Plattform für Applikationsintegration Yannick Beaud Fachgruppenleiter Architektur und Strategie, ISCeco EVD Reto Kohlas IT Architect, [ipt] agate.ch - Plattform für Applikationsintegration Yannick Beaud Fachgruppenleiter Architektur und Strategie, ISCeco EVD Reto Kohlas IT Architect, [ipt] From stable... to table. Portfolio Lebensmittelkette-Sicherheit

Mehr

Identity Management Service-Orientierung. 27.03.2007 Martin Kuppinger, KCP mk@kuppingercole.de

Identity Management Service-Orientierung. 27.03.2007 Martin Kuppinger, KCP mk@kuppingercole.de Identity Management Service-Orientierung 27.03.2007 Martin Kuppinger, KCP mk@kuppingercole.de Das Extended Enterprise verändert den Umgang mit Identitäten und Sicherheit Mitarbeiter Kunden Lieferanten

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Windows Server 2008 für die RADIUS-Authentisierung einrichten

Windows Server 2008 für die RADIUS-Authentisierung einrichten Windows Server 2008 für die RADIUS-Authentisierung einrichten Version 0.2 Die aktuellste Version dieser Installationsanleitung ist verfügbar unter: http://www.revosec.ch/files/windows-radius.pdf Einleitung

Mehr

MSP SSO. Portalübergreifendes Single Sign-on. Von MSP SSO unterstützte Standards:

MSP SSO. Portalübergreifendes Single Sign-on. Von MSP SSO unterstützte Standards: MSP SSO Portalübergreifendes Single Sign-on Für das Abwickeln von Online- Geschäftsprozessen ist es wichtig, sein Gegenüber zu kennen. Das gilt sowohl für den Kunden als auch den Betreiber des Online-

Mehr

I A M. Multidisziplinäre Perspektiven

I A M. Multidisziplinäre Perspektiven I A M Multidisziplinäre Perspektiven Wie wir zu sauberen Modellen, vernünftigen Anforderungen und einer breiten Benutzerakzeptanz im virtuellen Identitäts- und Zugriffsmanagement kommen Berner Prof. Fachhochschule

Mehr

Einmal registriert, von allen akzeptiert

Einmal registriert, von allen akzeptiert DEUTSCHLAND ONLINE Workshop E-Government-Standards für Wirtschaft und Verwaltung der Initiative D21 am 27. und 28. November 2008 BMWi Berlin Einmal registriert, von allen akzeptiert S.A.F.E. - Secure Access

Mehr

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch ARTS Server 3.5 Produktbeschreibung Uptime Services AG Inhaltsverzeichnis 1 Einleitung... 2 2

Mehr

Office 365 - Authentisierung in der Cloud

Office 365 - Authentisierung in der Cloud Paninfo AG 6. Oktober 2011 Fabrizio Lamari _ Office 365 - Authentisierung in der Cloud 6. Oktober 2011 Seite 1 Paninfo AG 6. Oktober 2011 Fabrizio Lamari _ Office 365 Agenda 09:00-10:15 Overview Office

Mehr

Digitales Zertifikat für die Authentifizierung

Digitales Zertifikat für die Authentifizierung Single Sign On Waisenhausgasse 36-38a 50676 Köln Tel.: +49 221 4724-1 Fax +49 221 4724-444 posteingang@dimdi.de www.dimdi.de Ansprechpartner: Helpdesk Technik Tel: +49 221 4724-270 helpdesk@dimdi.de Digitales

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Exchange Verbund WOLFGANG FECKE

Exchange Verbund WOLFGANG FECKE Exchange Verbund WOLFGANG FECKE Verbundvertrauensstellung Eine Beziehung mit Microsoft Federation Gateway, die die folgenden Komponenten für Ihre Exchange-Organisation definiert: Kontonamespace Anwendungs-ID

Mehr

E-Mail-Verschlüsselung Vorrausetzungen

E-Mail-Verschlüsselung Vorrausetzungen E-Mail-Verschlüsselung Vorrausetzungen Datum: 09.08.2011 Dokumentenart: Anwenderbeschreibung Version: 2.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3 2. Voraussetzungen...4

Mehr

Neuerungen bei Shibboleth 2

Neuerungen bei Shibboleth 2 Neuerungen bei Shibboleth 2 Shibboleth-Workshop BW Stuttgart, 7. Februar 2008 Bernd Oberknapp Universitätsbibliothek Freiburg E-Mail: bo@ub.uni-freiburg.de Übersicht Aktueller Status Kommunikation IdP

Mehr

Sichere Authentifizierung SSO, Password Management, Biometrie. 21.06.2007 Dr. Horst Walther, KCP hw@kuppingercole.de

Sichere Authentifizierung SSO, Password Management, Biometrie. 21.06.2007 Dr. Horst Walther, KCP hw@kuppingercole.de Sichere Authentifizierung SSO, Password Management, Biometrie 21.06.2007 Dr. Horst Walther, KCP hw@kuppingercole.de Single Sign-On, Password Management, Biometrie Single Sign-On: Anmeldung an mehreren

Mehr

Version 4.1. securitymanager. What's New?

Version 4.1. securitymanager. What's New? Version 4.1 securitymanager What's New? 1 Neue Features der Version 4.1 3 2 Neue Features der Version 4.0 6 3 Neue Features der Version 3.2 7 4 Neue Features der Version 3.1.1 8 5 Neue Features der Version

Mehr

midentity midentity Manager Basic KOBIL midentity Manager Basic Meine kleine, aber feine Verwaltung

midentity midentity Manager Basic KOBIL midentity Manager Basic Meine kleine, aber feine Verwaltung KOBIL Meine kleine, aber feine Verwaltung KOBIL ist ein Managementsystem zum Verwalten digitaler Identitäten mit Einmalpasswörtern und Zertifikatstechnologie. wurde speziell für Standard-Microsoft-Umgebungen

Mehr

Version 4.1. licensemanager. What's New

Version 4.1. licensemanager. What's New Version 4.1 licensemanager What's New 1 Neue Features der Version 4.1 3 2 Neue Features der Version 4.0 4 3 Neue Features der Version 3.2 5 4 Neue Features der Version 3.1.1 6 5 Neue Features der Version

Mehr

Sicheres Single Sign-On mit dem SAML Holder-of-Key Web Browser SSO Profile und SimpleSAMLphp

Sicheres Single Sign-On mit dem SAML Holder-of-Key Web Browser SSO Profile und SimpleSAMLphp Sicheres Single Sign-On mit dem SAML Holder-of-Key Web Browser SSO Profile und SimpleSAMLphp Andreas Mayer Adolf Würth GmbH & Co. KG Künzelsau-Gaisbach Prof. Dr. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit

Mehr

Transaktionskosten senken mit dem Wirtschaftsportalverbund

Transaktionskosten senken mit dem Wirtschaftsportalverbund Transaktionskosten senken mit dem Wirtschaftsportalverbund Rainer Hörbe Leiter Arbeitskreis WPV 8. März 2013 1 1 Identifikation + Berechtigung + Sicherheitsmaßnahmen Problemstellung: Vertrauen im Internet?

Mehr

Glossar. Begriffsbestimmungen im Themenkomplex des Identity und Access Managements A B C D E F G H I J K L M N O P Q R S T U V W X Y Z.

Glossar. Begriffsbestimmungen im Themenkomplex des Identity und Access Managements A B C D E F G H I J K L M N O P Q R S T U V W X Y Z. Glossar Begriffsbestimmungen im Themenkomplex des Identity und Access Managements Inhalt A B C D E F G H I J K L M N O P Q R S T U V W X Y Z A Begriffsbestimmungen Access Management Das Access Management

Mehr

On breaking SAML. Be Whoever You Want to Be. von David Foerster

On breaking SAML. Be Whoever You Want to Be. von David Foerster On breaking SAML Be Whoever You Want to Be von David Foerster Gliederung Übersicht & Motivation XML Signature Wrapping Attacks Vorstellung Gegenmaßnahmen Zusammenfassung 2 Übersicht & Motivation SAML Übersicht

Mehr

Siemens Business Services egov Framework

Siemens Business Services egov Framework Siemens Business Services egov Framework Bausteine des egovernment Das egov Framework von Siemens Business Erfolgreiche egovernment-lösungen basieren auf einer umfassenden Verallgemeinerung architektureller

Mehr