Bericht. Stabi3eGov B2.06 IAM Lösungsarchitektur. ech Fachgruppe IAM E-Government Vorhaben B2.06. <Versanddatum>, Projekt-Nr

Transkript

1 Bericht Stabi3eGov B2.06 IAM Lösungsarchitektur ech Fachgruppe IAM E-Government Vorhaben B2.06 <Versanddatum>, Projekt-Nr

2 Dokumentinformationen Titel: Projektnummer: Datum: 4. Januar 2011 Datei: Anzahl Seiten: Geprüft durch Koreferent bzw. Projektbegleiter: Stabi3eGov B2.06 IAM Modellarchitektur C:\Users\Mem\Documents\_11_proj\projekte\12_564_eCH_IAM_Modellarchitektur\Berichte\B er_110104_stabi3egov B2 06 IAM Lösungsarchitektur-120.doc 101 exkl. Beilagen Version Datum Wichtigste Änderungen Verantwortlich V Erster Entwurf bis inkl. Geschäftsarchitektur Mem V Anpassung in der Metadomäne Mem V Update und Einarbeiten Feedback Mart, Häni Mem V Update nach WS Gemeinden Mem V Update nach Spec. Camp 2 Mem V Update Informations-/Anwendungsarchitektur Mem V Einarbeiten Feedback Arbeitsgruppe Mem V Ergänzung Services aus Prozessen Mem V Update Prozesse und Einarbeitung Feedback Projektmitglieder Wag V Konsolidierung der Begriffe und Definitionen mit ech-0107 und Überarbeitung der Services V Korrekturlesen und Überarbeitung gemäss Feedback Wag V Update / Review Mem V Version 1.0 als Basis für die Diskussion vom Spec. Camp. III Mem V Inkl. Feedback vor Spec. Camp III Mem V Überarbeitung nach Feedback Spec.Camp III Mem V Einarbeitung Feedback / Qualitätssicherung Mem/Wag V Mehr Feedback einarbeiten Mem V Update nach Rücksprache mit Hans Häni: Erweiterungen in der Informationsarchitektur, Interdomänenstrukturen sowie im Kapitel technische Architektur unter Einbezug der aktuell definierten PoCs V Feedbackrunde AWK Mem/Wag V Einarbeitung letzter Feedback Arbeitsgruppe Wag Mem E-Government ffo B2.06 Dieser Bericht ist öffentlich. Jedermann steht das Recht zu, die hier publizierten Arbeitsergebnisse mit Zitierung von Titel und Ersteller des Dokuments weiter zu verwenden. AWK Group AG Leutschenbachstrasse 45 CH-8050 Zürich Tel Fax /101

3 Referenzierte Dokumente Titel Autor/Herausgeber Datum Link/Datei [1] ech Referenzmodell IAM Whitepaper No.: IAM [2] ech-0107 IAM Gestaltungsprinzipien [3] SuisseID Specification 1.3 English [4] egov: IAM Infrastruktur Vision [5] National Strategy for Trusted Identities in Cyberspace [6] The National Strategy for Trusted Identities in Cyberspace: Cyperspace Policy Review Assuring a Trusted and Resilient Information and Communications Infrastructure [7] Cross Domain community Roadmap, V1.0 N. Haenni, M. Itin, V. Kulhavy, H. Rüger, C. Winteregg SEAC: W. Müller, H. Häni 23. April 2007 Entwurf SECO June 10, 2010 E-Government (Hans Häni), AWK (Markus A. Meier) unternehmen/technik/index.html?lang=de U.S. Department of Homeland Security ale.com/ The White House gov/blog/2010/06/25/na tional-strategy-trustedidentities-cyberspace Unified Cross Domain Management Office (UCDMO) CD%20Community%20 Roadmap%20Exec%20Over view%20v7.pdf [8] STORK: D4.2 Final report STORK-eID Consortium on eid process flows [9] Liberty Alliance Project Liberty Alliance [10] Identity Management The Open Group March > IdM Whitepaper [11] NSTAC Report to the President on Identity Management Strategy [12] Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance NSTAC May 21, 2009 ICAM November 10, c/reports/2009/nstac %20IDTF%20Report.pd f s_events/privilegemanagementworkshop/presentations/jud y_paul%20.pdf 3/101

4 Inhaltsverzeichnis 1. Zusammenfassung Einleitung Ausgangslage Ziele der E-Government IAM Lösungsarchitektur Motivation Vorgehen Begriffe Subjekt Ressource Digitale Identität Identifikator Digitales Zertifikat Domäne Namensraum Attribute Claim, Claimset Funktion, Rolle Ermächtigung Credential Claim Assertion Service, Claim Assertion Infrastructure, Identity Provider, Service Provider im Umfeld SuisseID OASIS Begriffe Security Token Service STS, Relying Party RP IAM - Identity und Access Management Register Trust (Vertrauen) Authentisierung, Authentifizierung Autorisierung (Administration, Laufzeit) Access Control Zugriffsregel Anforderungen Geschäftsarchitektur /101

5 6.1. Beteiligte Parteien/Rollen Prozesse der Legislative L1: Governance L2: Riskmanagement L3: Compliance Management Prozesse der Exekutive M1: Digitale Identitäten M2: Zugriffsregeln M3: Claims M4: Credentials Runtime Prozess der Exekutive R1: Access Control Informationsarchitektur IAM Metamodell IAM Infrastruktur IAM Verzeichnisse IAM Serviceprovider und deren Services IAM Administration Domänen Policies und Richtlinien in einer Domäne Herausforderungen in föderierten Domänen Policies, Standards und Trust zwischen Domänen Identitätsmapping Identifikatoren Credentials Zugriffsregeln Claim Access Control Modelle Lösungsansätze Interdomänenstrukturen IAM in einer Domäne IAM im losen Domänenverbund IAM im Verbund mit Masterdomäne IAM mit Metadomäne Services der Metadomäne Weiter mögliche Varianten Dokumentation und Dokumentenmanagement sicherstellen Föderierter Single Sign-On /101

6 Pull / Push SSO Account Linking Where are you from (WAYF) Session Management, Logout, Cleanup Global Good-bye Account delinking Technologie Architektur Wichtige Technologie-Standards im föderierten Identity Management Umfeld SSL/TLS SAML Security Assertion Markup Language Shibboleth Liberty Alliance Web Services-Federation Web Services-Trust Web Services-Security Architektur zur Unterstützung der Föderation im IAM Umfeld HTTP Point of Contact (Browser) SOAP/XML Point of Contact (WS Client) SSO Protocol Service Trust Services Key Services Identity Services Authorization Servcice Provisioning Service Management Service Audit Services A. Proof of Concept /101

7 1. Zusammenfassung Die Nutzung des Internets hat in den letzten Jahren kontinuierlich zugenommen. Immer häufiger wird das Internet nicht nur als Informationsquelle, sondern auch zum tätigen von Geschäften verwendet, wie z.b. die neuste Statistik zu diesem Thema des BfS 1 aufzeigt. Die IAM Lösungsarchitektur hat zum Ziel mit Hilfe von standardisierten, vereinheitlichten Begriffen die Prozesse in einem E-Government Umfeld klar darzustellen, da diese für IAM von zentraler Bedeutung sind. Die digitale Identität wird im Kapitel Informationssystemarchitektur mit Hilfe des folgenden Metamodells vertieft: Subjekt 0..n besitzt tritt auf als Ressource hat Credential 0..n besitzt 1..n Digitale Identität erfüllt 0..n 0..n Claim verwendet Zugriffsregel 0..n hat einen Identifikator 1 Domäne hat Vertrauen (Trust) 0..n Abbildung 1: IAM Informationsmetamodell für eine digitale Identität Es werden unterschiedliche Ansätze gezeigt, wie digitale Identitäten in einem E- Government Umfeld registriert und verwaltet werden können. Ein besonderes Augenmerk wird auf die Föderation der Domänen gelenkt, entspricht diese doch dem alltäglichen Umfeld der Schweiz. Einige wichtige technologische Aspekte zur Föderation von Identitäten werden im Kapitel 9 ( 1 Details siehe 7/101

8 Technologie Architektur) vertieft. Die präsentierten Lösungsansätze werden als Anwendungsmuster präsentiert. Diese werden zurzeit mittels verschiedener Proof of Concept (PoC) Aktivitäten technisch verifiziert. Das Resultat dieser PoCs wird dokumentiert und als Anhang zu diesem Dokument die Lösungsmuster für die technische Umsetzung enthalten. 8/101

9 2. Einleitung 2.1. Ausgangslage Der Schlüssel zur erfolgreichen Verwendung digitaler Identitäten liegt in einer effektiven und effizienten Verwaltung von Subjekten und Ressourcen (Identity Management) mit deren Claims (Access Management). Bereits im März 2004 erwähnt The Open Group im Identity Management Report (siehe [10]) eine Reihe von Argumenten wie z.b. Enable a higher level of e-business by accelerating movement to a consistent set of identity management standards. Auch im NSTAC Report an den amerikanischen Präsidenten vom März 2009 (siehe [11]) wird IAM als Schlüsseltechnologie empfohlen um z.b. Kostenersparnisse im E-Government Umfeld zu erreichen. Wir alle wissen das die Nutzung des Internets in den vergangenen Jahren kontinuierlich zugenommen hat, wie nicht zuletzt die aktuelle Statistik des BfS 2 aufzeigt. In dieser Statistik sieht man auch, dass heute ca. 1/3 der Internetnutzenden auch Geschäfte über das Internet abwickeln (siehe Abbildung 2): Internetnutzung in der Schweiz nach Nutzungszwecken und Häufigkeit, 2008 In % der Internetnutzer (zu Hause) Versand/Empfang von s Suche von Informationen Fahr-, Flug-, Reiseinfos einholen Lexika, Nachschlagewerke Veranstaltungskalender Lesen tagesaktueller Nachrichten Homebanking Preisvergleiche Stellen- und Wohnungsmärkte & Kleinanzeigen Einkaufen Musikstücke herunterladen Auktionen Chatten Internettelefonie Herunterzuladen von Filmen Um sich in einer virtuellen Welt zu bewegen Häufigkeit Internet-Nutzung: Täglich oder fast täglich Häufigkeit Internet-Nutzung: einmal pro Woche oder weniger häufig Internetnutzer insgesamt:internet in den letzten 3 Monaten genutzt Abbildung 2: Internetstatistik 3 2 Details siehe 3 Quelle: Publicadata/IGEM: KommTech; 2009 OFS-BFS-UST / SUKO 9/101

10 Ebenfalls sehen wir, dass Homebanking von ca. 40% der Schweizer Bevölkerung genutzt wird und dass der Versand/Empfang von s mit über 80% an der Spitze liegt. Damit ist das Internet (die US Regierung spricht von Cyberspace [6]) zu einem Grundpfeiler für die Abwicklung vieler Geschäfte geworden. Wir wissen ebenfalls von fast täglichen Schlagzeilen in den Medien, dass die Sicherheit sowie der Umgang mit der Privatsphäre der raschen Entwicklung des Mediums Internet nicht Schritt gehalten hat. Wir geben unsere Daten Preis, ohne dass wir genau wissen, wofür sie verwendet oder an wen sie weiter gegeben werden. Das Internet ist nicht nur ein Segen. Es bildet auch die Basis für kriminelle Geschäfte aller Art, welche zum Teil unsere heutige Vorstellungskraft bei Weitem übersteigen. Der Ausdruck Cyberwar ist nicht nur ein Begriff aus einem Science Fiction Film. Bereits im September 2009 hat das Schweizer Parlament per Gesetz ein drittes konjunkturelles Stabilisierungspaket beschlossen (Stabi3eGov), wovon ein Teil zur Förderung der E-Economy in der Schweiz vorgesehen ist. Mit den IKT-Massnahmen des Paketes soll dem elektronischen Geschäftsverkehr zum Durchbruch verholfen werden, unter anderem durch die Unterstützung der Entwicklung und Einführung eines Mittels zur sicheren elektronischen Authentisierung, welche mittlerweilen unter dem Namen SuisseID eingeführt wurde. In der Medienmitteilung vom EVD per 30. September 2010 werden die beschlossenen Massnahmen wie folgt bewertet 4 : Bern, Die Umsetzung des E-Government-Pakets, das vom Bundesrat im Rahmen der dritten Stufe konjunktureller Stabilisierungsmassnahmen beschlossen wurde, schreitet zügig voran. Die unterstützten priorisierten Vorhaben laufen nach Plan und zeigen erste positive Ergebnisse. Per Ende Jahr werden alle priorisierten Vorhaben mindestens die Konzeptphase abgeschlossen haben. In der gleichen Stellungnahme wird auch die Wichtigkeit von IAM betont: Ein Schwerpunkt der unterstützten E-Government-Vorhaben ist «Identity and Access Management (IAM)». IAM befasst sich mit der Verwaltung von Benutzerdaten und Zugriffsrechten, was insbesondere auch unter dem Aspekt des Datenschutzes und der Benutzerfreundlichkeit bei E-Government von Bedeutung ist. Dadurch kann zum Beispiel sichergestellt werden, dass bei einem Baubewilligungsverfahren nur die berechtigten Personen Einsicht erhalten. IAM ist ein typisches Querschnittsvorhaben, dessen Nutzen sich auf viele E-Government-Leistungen erstreckt und nur durch eine starke schweizweite koordinierte Umsetzung effizient realisieren lässt. Es existieren eine ganze Reihe von Initiativen, auch im internationalen Umfeld mit dem Ziel, das Internet für den Gebrauch sicher zu machen. Eine dieser Initiativen ist die von der US Regierung unter Barack Obama initiierte Idee der Entwicklung einer Strategy for Trusted Identities in Cyberspace [5] unter der Leitung des Department of Homeland Security. Im europäischen Ausland befasst sich das Projekt STORK (Secure Identity Across Borders Linked [8]) um die Etablierung einer Plattform, um digitale Identitäten unter den verschiedenen Mitgliedstaaten sicher verwenden zu können. 4 Details unter: 10/101

11 2.2. Ziele der E-Government IAM Lösungsarchitektur Die E-Government IAM Lösungsarchitektur will folgende Ziele erreichen: Einheitliche Begriffswelt schaffen (Kapitel 4): Die E-Government IAM Lösungsarchitektur erklärt und definiert die wesentlichen Begriffe zum Thema. Die Definitionen sind an das Dokument ech-0107 IAM Gestaltungsprinzipien [2] angelehnt. E-Government IAM Prozesse aufzeigen (Kapitel 6): IAM ist in erster Linie eine organisatorische Herausforderung. Die angestrebte Lösungsarchitektur muss die Geschäftsprozesse für IAM abbilden. Ebenfalls sind die Stakeholder, die Akteure und deren Rollen / Funktionen zu identifizieren. Aufzeigen der Informationssystemarchitektur (Kapitel 7): Erklärt wird das Informationsmetamodell für eine digitale Identität und die Herausforderungen von interagierenden digitalen Identitäten in verschiedenen Umfeldern (Domänen). Verschiedene mögliche Anwendungsmuster zeigen Lösungsansätze auf. Mögliche technische Umsetzungen: Die E-Government Lösungsarchitektur wird mit Hilfe verschiedener konkreter Anwendungsfeldern verifiziert (Proof of Concept). Die in diesen PoCs überprüften technischen Umsetzungen führen zu Umsetzungsmustern, welche abstrahiert und dokumentiert werden. Hinweis: Die technischen Umsetzungsergebnisse werden als separate Dokumente während den PoC erstellt und können diesem Dokumente zu einem späteren Zeitpunkt als Anhang beigefügt werden. Ein weiteres wichtiges Ziel dieser Lösungsarchitektur ist die damit verbundene Diskussion und Verbreitung der hier vorgestellten Ansätze. Dies wird erreicht durch die Verankerung in einem breit abgestützten Mitgliederkreis der Arbeitsgruppe: Nachname Vorname Organisation Arnegger Armin Innosolv Baumgartner Martin VRSG Berger Adrian Ergon Dolf Christian Kanton St. Gallen Dornbierer Christof AdNovum Eberhard René keyon AG Häni Hans AFI Kanton Thurgau Hoffmann Enno Siemens Itin Markus Kitt ZH Kräuchi Martin BIT Kulhavy Vladimir Siemens Marti Adrian AWK Mayer Elias Abraxas Informatik AG Meier Markus AWK Milde Oldrich GS EVD Müller Willy ISB Oexl Thomas indato GmbH Perroud Thierry BIT Petralia Andreas AdNovum Re Roberto Abraxas Informatik AG Reçi Mirushe E-Government Schweiz, Programm Office Salzmann Andre Ruf Sameli Mischa Backslash Schnetzler Steff iweb 11/101

12 Access Control Virtic Anton Clavid Wagner Rolf AWK Walser Konrad Berner Fachhochschule Weber Simon Softec Zweiacker Marc Zweiacker IT Management Tabelle 1 Mitwirkende der Arbeitsgruppe 2.3. Motivation Im E-Government IAM Umfeld geht es vereinfacht darum, dass Subjekte (Bürger, Organisationen, Firmen, spezifische Applikationen) E-Government Ressourcen (Services der Gemeinden, der Kantone, des Bundes) verwenden möchten, wie in Abbildung 3 dargestellt wird: Domäne A Domäne B verwenden Subjekte Identitäten Identitäten Ressourcen Subjekt Eigenschaften Zugriffsregeln Wer darf Was Abbildung 3: Wer darf was? Die Ressourcenverantwortlichen bestimmen die Kriterien (Zugriffsregeln) für die Verwendung der Ressourcen (Wer darf was). Subjekte, welche Ressourcen verwenden wollen, benötigen die entsprechenden nachweisbaren Eigenschaften für den Zugriff. Access Control vergleicht zur Laufzeit Subjekteigenschaften mit den für den Ressource-Zugriff erforderlichen Regeln und gewährt den Zugriff oder verweigert ihn. Eine besondere Herausforderung im E-Government oder E-Economy Sektor ist die Tatsache, dass Ressourcen und Subjekte sich in unterschiedlichsten Umgebungen befinden können, dargestellt als Domäne A und B in Abbildung 3. Weitere Herausforderungen für die Verwendung von domänenübergreifenden Services sind deren Auffindbarkeit, die Vertrauensbasis des Serviceanbieters die dezentrale Registrierung von Subjekten (Benutzenden) sowie das Mapping von digitalen Identitäten beim Service-Zugriff. 12/101

13 Interface Diese etwas abstrakte Darstellung wird in Abbildung 4 durch einen realistischen Anwendungsfall konkretisiert. Annahmen: Einwohner A ist wohnhaft in einer Gemeinde (Domäne B) und will seine Einwohnerregisterdaten mit seinem Notebook ansehen. Die Umgebung des Bürgers A mit seinem Notebook kann wie eine kleine eigene Domäne betrachtet werden. Gemäss Gesetz darf jeder Einwohner einer Gemeinde seine Einwohnerregisterdaten ansehen Der Einwohner A hat eine SuisseID Der Einwohner ist mit seiner SuisseID bei der Gemeinde (Domäne B) bereits bekannt (registriert) Einwohner A Domäne A 2 1 SuisseID Internet 6 Gemeindeportal Access Control Domäne B Gemeinde 4 SuisseID Suisse CSP ID CA 3 Zugriffsregeln (wer darf was?) 5 Einwohnerregister CSP Infrastruktur IdP CAS trust Abbildung 4: Bürger benutzt Service der Gemeinde Die einzelnen Schritte des immer noch stark vereinfachten Anwendungsfalls: 1. Der Einwohner benutzt seine SuisseID an seinem Notebook (in seiner Domäne A). 2. Er ruft via Internet das Gemeindeportal auf. 3. Die Gültigkeit seiner digitalen Identität (SuisseID) wird beim Identity-Provider geprüft. 4. Access Control überprüft, ob die digitale Identität registriert ist und prüft mit Hilfe der Zugriffsregeln, welche Ressourcen der Einwohner verwenden darf, also z.b. das Einwohnerregister mit seinen Einträgen. 13/101

14 5. Die entsprechende Funktion wird aufgerufen. 6. Das Resultat der Abfrage wird dem Einwohner präsentiert. Folgende Fragen stellen sich: Wie stellt man fest, dass ein Einwohner A tatsächlich Einwohner der Gemeinde (Domäne B) ist? Wie kann ein mit einer SuisseID authentifizierter Benutzer aus Domäne A auf das Subjekt Einwohner der Gemeinde (Domäne B) abgebildet werden (Identitäts- Mapping)? Wer definiert die Zugriffsregeln für die Ressource Einwohnerregister? Woher weiss man, dass die Verwendung der SuisseID in diesem Kontext vertrauenswürdig ist? 14/101

15 3. Vorgehen Die Modellarchitektur in diesem Dokument wird nach der vom Bund vorgegebenen Architekturmethode ADM (Architecture Development Method) aus TOGAF 5 (The Open Group Architecture Framework) entwickelt. Prelim: Framework And Principles H Architecture Change Management A Architecture Vision B Business Architecture G Implementation Governance Requirements C Information System Arch. F Migration Planning E Opportunities and Solutions D Technology Arch. Abbildung 5: TOGAF ADM Zyklus Das Dokument e:gov: IAM Infrastruktur Vision [4] deckt die Visionsphase ab. Im vorliegenden Dokument liegt der Fokus gemäss den Zielen (siehe 2.2) auf den TOGAF ADM Phasen B, C und D. Die Geschäftsarchitektur (TOGAF ADM Phase B) wird mit Hilfe der Prozesse im IAM Umfeld dokumentiert. Diese werden mit BPMN (Business Process Modeling Notation) dargestellt. In der Informationssystemarchitektur (TOGAF ADM Phase C) wird zuerst der Fokus auf die Informationen selbst, d.h. auf die Informationsarchitektur gelegt. Im Zentrum steht das IAM Metamodell. 5 Details unter: 15/101

16 In der Technologie Architektur (TOGAF ADM Phase D) werden Schlüsseltechnologien für die Umsetzung von föderierten Identitäten aufgezeigt. Anhang A zeigt einige technologische Umsetzungsvarianten auf, welche sich in den Proof of Concept Projekten bewährt haben (spezieller Anhang zu diesem Dokument, nach Abschluss der PoCs). 16/101

17 4. Begriffe 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 die Begriffe des Dokuments egov IAM Infrastruktur Vision [4] wo sinnvoll wiederholt und ergänzt, damit die vorliegende Lösungsarchitektur als eigenständiges Dokument lesbar ist. Quellen sind das Glossar des ech IAM- Referenzmodells [1], das Dokument ech-0107 IAM Gestaltungsprinzipien [2] sowie Dokumente aus dem Umfeld SuisseID [3]. Zum Teil werden die englischsprachigen Begriffe verwendet, da diese auch in unserem Umfeld weit verbreitet und bekannt sind. Wo notwendig werden die Begriffe mit Hilfe von Beispielen und Zeichnungen illustriert und vertieft. Eine weitere Quelle für Begriffe ist OASIS (Organization for the Advancement of Structured Information Standards), eine internationale, nicht-gewinnorientierte Organisation, die sich mit der Weiterentwicklung von E-Business- und Web-Service- Standards beschäftigt 6. Im Zusammenhang E-Government IAM Modellarchitektur von Interesse sind z.b. die OASIS Dokumente zu: Web Services Security (WS-Security): Beschreibt Kommunikationsprotokolle mit Berücksichtigung von Sicherheitsaspekten bei Webservices. Web Services Security Policy (WS-Security Policy): Definiert sicherheitsbasierte Policy Assertions für Webservices (Zusicherungen, damit sicherheitsrelevante Aspekte zwischen Webservices erfüllt sind). Web Services Trust (WS-Trust): Beschreibt Mechanismen für die Zusicherung von bestimmten Eigenschaften von Subjekten von Domänen und zwischen den Domänen. Diese heute von OASIS verabschiedeten Begriffe und Standards werden beispielsweise bei grossen Firmen wie IBM, Oracle oder Microsoft angewendet. Diese Begriffe decken sich nicht immer mit den in der Schweiz verwendeten Begriffen, vor allem im Umfeld der SuisseID (Beispiel: Bei OASIS wird von einem STS - Security Token Service gesprochen; im SuisseID Umfeld entspricht dies dem CAS Claim Assertion Service). Die OASIS Begriffe werden hier ebenfalls erwähnt um die Brücke zu den Schweizer Begriffen schlagen zu können. Die Begriffe werden nicht nach alphabetischer Reihenfolge sondern nach logischem Aufbau des Dokuments sowie entsprechend dem Zusammenhang unter den Begriffen selbst eingeführt Subjekt /101

18 Subjekt Ein Subjekt ist ein Akteur, welche auf eine Ressource zugreift oder zugreifen möchte. Es kann sich um eine natürliche oder juristische Person oder auch um eine Maschine handeln. Das Subjekt ist im Zusammenhang mit digitalen Zertifikaten (4.5) Inhaber des privaten Schlüssels Ressource Ressource Eine Ressource ist eine Anwendung, ein Service, eine Funktion, ein Prozess oder eine Datenmenge, auf welche ein Subjekt zugreifen möchte. Ressourcen können auch Subjekte sein, resp. durch Subjekte repräsentiert werden, z.b. wenn eine Ressource (z.b. ein Service) eine andere Ressource (z.b. einen anderen Service) verwendet Digitale Identität Digitale Identität Eine digitale Identität hat einen Identifikator (eindeutigen Namen), meist zusammen mit einer Menge von zusätzlichen Attributen, welche innerhalb eines Namensraumes (und damit einer Domäne) eindeutig einem Subjekt zugewiesen werden können Ein Subjekt kann mehrere digitale Identitäten haben Identifikator Identifikator Ein Identifikator ist eine Zeichenkette, welche ein Subjekt innerhalb eines Namensraumes eindeutig bezeichnet. Der eindeutige Identifikator eines Subjektes 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. Identifikatoren werden auch CUID genannt (Common Unique Identifier). Anmerkung: Der Identifikator eines Subjekts im Umfeld SuisseID ist die eindeutige SuisseID Nummer in der Form /101

19 4.5. Digitales Zertifikat Digitales Zertifikat Ein digitales Zertifikat verbindet einen öffentlichen Schlüssel mit Daten, die es erlauben, ein Subjekt oder eine Ressource zu identifizieren (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 (z.b. Verschlüsselungsalgorithmus) Informationen zur Gültigkeitsdauer des Zertifikates Den öffentlichen Schlüssel, zu dem das Zertifikat Angaben macht Den Namen (oder eine andere identifizierende Bezeichnung) des Eigentümers des öffentlichen Schlüssels (d.h. 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 noch von Zertifikat gesprochen. Gemeint ist immer ein digitales Zertifikat. Die digitale Identität des Subjektes (der Identifikator) ist nicht automatisch mit dessen Zertifikat gleichzusetzen. Ein Subjekt oder eine Ressource kann mehrere Zertifikate besitzen. Ein Zertifikat bezieht sich immer auf ein einziges Subjekt / auf eine einzige Ressource. Öfters interagieren zwei Subjekte miteinander, z.b. via SSL-Handshake: Client und Server agieren beide als Subjekte, die miteinander den sicheren Datenaustausch sicherstellen Domäne Der Begriff Domäne kommt vom lateinischen dominium (französisch: domaine) Herrschaft, Herrschaftsbereich. In der Informatik beschreibt er einen zusammenhängenden Bereich und wird vielfältig verwendet, z.b. als Administrationsdomäne, Anwendungsdomäne, Datendomäne oder als Netzwerkdomäne. Im föderativen Gebilde Schweiz mit Bund, Kantone und Gemeinden gibt es eine grosse Anzahl von Domänen im Sinn des ursprünglichen französischen Begriffs. Innerhalb 19/101

20 einer Domäne definiert die verantwortliche Organisation oder die Zusammenarbeitsvereinbarung bei einem föderativen Zusammenschluss die für die Domäne gültigen Regeln (Policy). Domäne (IAM) Eine Domäne besteht aus einer Menge von Informationsobjekten und einem gemeinsamen Satz von Regeln und Prozessen. Domänen können Domänen enthalten. Jedes Subjekt besitzt innerhalb einer Domäne eine eineindeutige digitale Identität. Domänen können Vertrauensbeziehungen zueinander eingehen und bilden somit einen Circle of Trust (siehe Liberty Alliance Standard), in dem zusätzliche Regeln und Prozesse gelten Namensraum Namensraum (IAM) Ein Namensraum ist ein abstraktes Gebilde um Identifikatoren von Domänen von Subjekten gemäss semantischen Regeln logisch zu ordnen. 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 innerhalb von Domänen sind im IAM Umfeld von grösster Wichtigkeit, um innerhalb einer IAM-Umgebung die sich darin befindenden Subjekte eindeutig identifizieren zu können. Anmerkung zur Eindeutigkeit: Das ech Referenzmodell definiert, dass eine Person (Subjekt) mehrere digitale Identitäten haben kann. Innerhalb eines Namensraums (und einer Domäne) erlaubt eine Ressource immer nur eine eindeutige digitale Identität. Um diese Mehrdeutigkeit zu beherrschen braucht es also ein Identitäts-Mapping von digitalen Identitäten aus unterschiedlichen Domänen (Namensräumen). Dieses Identitäts-Mapping könnte man als eine Art indirekte Adressierung bezeichnen (siehe Abbildung 6): 20/101

21 Namensraum X Ext-ID A1 Name Ressource A Ext-ID A1 A B Ext-ID A2 Ext-ID A3 Ext-ID A3 Name Ressource B Ext-ID B1 Ext-ID B2 C Ext-ID B3 Name Ressource C Ext-ID C1 Ext-ID C2 Ext-ID C2 Ext-ID C3 Name Ressource D Ext-ID D1 D Ext-ID D2 Ext-ID D3 Abbildung 6: Namensraum und Identität -Mapping In dieser Abbildung werden IDs (Ext-ID) über eine Tabelle auf die eigentlichen Ziel- ID abgebildet. Man sieht z.b. dass die unterschiedlichen digitale Identitäten Ext-ID A1 und Ext-ID A2 beide zur gleichen Ressource Name Ressource A führen. Die digitale Ext-ID C2 führt zur Ressource Name Ressource C Attribute Nebst dem eindeutigen Identifikator können digitale Identitäten weitere 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 von Ressourcen sind z.b. Applikationsrollen, Privilegien etc. Attribut Ein Attribut ist ein Informationsfeld (Behälter) beliebiger Art, welches einer digitalen Identität zugeordnet ist. Es dient der Beschreibung von Identitätseigenschaften. Oft haben digitale Identitäten spezielle Attribute, die im Rahmen des Access Control Prozesses (siehe 4.20) von Bedeutung sind. 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 IAM Attributen am Beispiel Benutzerverwaltung: Verbindliche Attribute wie Name, Vorname, adresse, usw. Access Management Attribute (siehe 4.20) 21/101

22 z.b. Subjekt hat die Rollen Office, Internet, Steuerverwalter, Geschäftsprüfungskommissionsmitglied, Nicht IAM Attribute sind z.b.: Spezifische Attribute wie Angaben zur Organisationseinheit innerhalb einer Firma oder der Name des Vorgesetzten Private Attribute wie z.b. Private Wohnadresse, das Bild des Benutzers, Sie werden in diesem Dokument nicht weiter vertierft. Die Gruppierung mittels IAM verwalteter Informationen (eine Art IAM Record oder Container) könnte dann für einen IT Benutzer (Subjekt) z.b. wie folgt ausgestaltet werden: IT Benutzer Identifikator Verbindliche Attribute Access Management Attribute Spezifische Attribute Private Attribute Abbildung 7: Beispiel IAM Record - Benutzerverwaltung Anmerkung: Im Umfeld E-Government 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 (nicht besonders schützenswerte Personendaten) wie z.b. Name, Vorname, dazu verwendet werden. 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 geschieht die Verwaltung und Pflege der Access Management Attribute durch die dafür autorisierten Stellen. 22/101

23 Attribute können der Aussenwelt z.b. von einem Directoryserver über eine LDAP Schnittstelle zur Verfügung gestellt werden (siehe Kapitel 7.2) Claim, Claimset Es ist eine besondere Herausforderung, die zu einer digitalen Identität notwendigen und richtigen Attribute zu definieren. Oft zeigt sich erst durch den Verwendungszweck oder den Kontext, welche Attribute wirklich gebraucht werden. Deshalb wurde das Prinzip der Claims bzw. Claimsets entwickelt. Claim (engl. für Behauptung) ist ein neueres Konzept im IAM Umfeld. Es beschreibt, wie beglaubigte Attribute einer digitalen Identität zur Verfügung gestellt werden können. Die Beglaubigung erfordert einen unterstützenden, nachvollziehbaren Prozess. Claim Ein Claim ist eine Behauptung über ein Subjekt, welche von einer offiziellen, vertrauenswürdigen Stelle als korrekt bestätigt wurde. Claims können Attribute eines Subjekts oder einer Ressource sein, z.b. Subjekt ist Arzt. Claims können aber auch aus deren Attribute abgeleitet werden, z.b. Subjekt ist 18 Jahre alt. Claimset Ein Claimset ist eine Sammlung von Claims, welche, wie ein einzelner Claim, von einer offiziellen, vertrauenswürdigen Stelle als korrekt bestätigt wurde. Abbildung 8 zeigt beispielhaft einen Claimset, eine Sammlung einzelner Claims, welcher als Ganzes signiert ist (Ein Security Token entspricht einem signierten Claimset). 23/101

24 Claimset Security Token Claim 1 Claim 2 Name, Vorname Notar Claim 3 Claim n Mitarbeiter der Firma xyz Alter Signatur Abbildung 8: Security Token mit Claimset und Signatur Claims haben häufig die Form von: Bestätigung der Rollenzughörigkeit, z.b. ist Mitarbeiter unserer Firma Bestätigung einer Funktion, z.b. ist Arzt, ist Notar, ist amtlicher Vermesser im Kanton Bern Anmerkung: Im Unterschied zu Attributen zu einer digitalen Identität, welche in einem eigenen IAM verwaltet werden (siehe 4.8) und z.b. über eine LDAP Schnittstelle verwendet werden können, sind Claims vom Claim Provider bestätigte (signierte) Attribute zu einer digitalen Identität, welche als Security Token im Internet sicher zur Verfügung gestellt werden können Funktion, Rolle Rolle Eine Rolle ist eine Eigenschaft, welche einer digitale Identität (eines Subjekts) zugewiesen werden kann, im Sinn des RBAC 7 Modells. 7 RBAC: Role Based Access Control 24/101

25 Funktion Eine Funktion ist eine öffentlich beglaubigte Rolle, z.b. Arzt, Anwalt, Polizist, Geschäftsführer, Handlungsbevollmächtigter, etc. Die Funktion eines Subjekts kann für seine digitale Identität mittels einer entsprechenden Rolle abgebildet werden. Diese Rolle kann zur Erteilung von Zugriffsberechtigungen verwendet werden. Funktionen und Rollen sind Attribute, die für die Nutzung im IAM von einer vertrauenswürden Stelle bestätigt werden müssen. Im IAM-Kontext müssen sie daher als Claims behandelt werden Ermächtigung Als Ermächtigung 8 (empowerment) bezeichnen wir den auf einen konkreten Geschäftsfall bezogenen Handlungsspielraum (und damit Handlungsbedarf) einer Person oder eines Systems. Ermächtigungen haben die Eigenschaft, dass sie über die Domänengrenzen hinweg verständlich und sicher darlegen, welche Aufgabe und welche relevanten Eigenschaften die anfragende Person/Maschine hat. Ermächtigungen sind die Basis für eine domänen-übergreifende, gegenseitige Anerkennung von Handlungskompetenzen. Ihr Aufbau kann vielschichtig sein und es muss einen gemeinsamen Verständigungsrahmen über alle Domänen hinweg geben. Ermächtigung Temporäre Berechtigung, welche einer digitalen Identität mit der nachweisbaren Rolle (Funktion) zugewiesen werden kann. Abbildung 9 zeigt schematisch den Ansatz von Ermächtigungen: Aufgabe 1 A C Paket 2 trust trust Aufgabe Ermächtigung 4 B 3 5 CAS für Ermächtigungen Paket Resultat 7 6 Ermächtigung Abbildung 9: Ermächtigung 8 Oft wird im E-Government Umfeld auch von E-Ermächtigung gesprochen 25/101

26 Vorbedingung: A und C haben sich abgesprochen, dem CAS (für Ermächtigungen) zu trauen. Die einzelnen Schritte: 1. A hat eine Aufgabe. Er beabsichtigt, diese an B zu delegieren. 2. Er erzeugt ein Aufgabenpaket mit der Aufgabe 3. und der Ermächtigung für B. 4. Das Aufgabenpaket überreicht er B. 5. B führt die Aufgabe aus. Es entsteht das Resultat. 6. Das Resultat kann z.b. an C übergeben werden. 7. C ist in der Lage die Ermächtigung zu überprüfen. Ebenfalls kann C überprüfen, woher das Paket gekommen ist Credential Credential Ausweis, mit dessen Hilfe die behauptete digitale Identität eines zugreifenden Subjekts überprüft werden kann. Credentials können Ausweispapiere, Zeugnisse, Passwörter oder digitale Zertifikate sein, welche es erlauben, ein Subjekt eindeutig zu authentifizieren Claim Assertion Service, Claim Assertion Infrastructure, Identity Provider, Service Provider im Umfeld SuisseID Im Umfeld von SuisseID werden folgende Begriffe verwendet: Claim Assertion Service CAS Begriff aus dem Umfeld der SuisseID und entspricht dem Begriff Security Token Service STS (siehe 4.14) von OASIS. Claim Assertion Infrastructure CAI 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. 26/101

27 Identity Provider IdP Ein Service zur bestätigten Ausgabe von Identity Claims. Service Provider SP Entspricht dem Begriff RP von OASIS (siehe 4.14). Das Konzept von CAS, CAI, IdP und SP wird in Abbildung 10 gezeigt: Kern Infrastruktur Directory- und Assertion-Service CSP Infrastruktur IdP CAS Other IdP Other CAS Interface Interface Interface Interface Claim Assertion Infrastructure CAI SuisseID Interface Browser Interface Service Provider (SP) Benutzende Anwendungen Abbildung 10: Claim Assertion Infrastructure CAI Die Claim Assertion Infrastructure CAI ist das Bindeglied zwischen den verschiedenen Partnern, welche gemäss der technischen Spezifikation SuisseID (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 SuisseID): Verwenden Anwendungen von einem Anbieter (Service Provider SP) 27/101

28 Service Provider (SP): Anwendungsanbieter oben (siehe 4.14), allgemeiner als Relying Party (RP) bezeichnet OASIS Begriffe Security Token Service STS, Relying Party RP Claimsets werden in der Begriffswelt von OASIS von sogenannten Security Token Services STS gebildet (siehe 4.9). STS wird im Zusammenhang mit den sogenannten Relying Parties RP erklärt. Security Token Service STS Als Security Token Service STS bezeichnet man die Infrastruktur welche in der Lage ist, Security Tokens nach international gültigem Standard 9 zu erzeugen, zu signieren und als Service zur Verfügung zu stellen. Anmerkung: STS entspricht im SuisseID Umfeld dem CAS (Claim Assertion Service) Relying Party 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 in Zusammenhang mit Claims und Security Token Service STS verwendet. Eine Relying Party stützt sich auf Informationen in Claims oder STS ab, um den Dienst zu erbringen. Nachfolgende Abbildung 11 zeigt das Prinzip des Security Token Service STS. In diesem Beispiel braucht es zwei STS um die gesamte geforderte Information zusammen zu stellen (Föderation von Security Token Services). 9 OASIS 28/101

29 trust trust STS-A STS-B RP 6 Benutzer Abbildung 11: Federated Security Token Service Vorbedingung: Relying Party RP vertraut den beiden Security Token Service Provider STS-A und STS-B. Beschreibung des Anwendungsfalls: 1. RP fragt nach den entsprechenden Attributen (Claim), z.b. Firmenzugehörigkeit 2. Der Benutzer konsultiert STS-A für seine Attribute (Claim) Firmenzugehörigkeit 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 seine Funktion (z.b. Notar) zu ergänzen (STS-B muss STS-A nicht zwingend vertrauen, da RP beiden Instanzen vertraut) 5. Das mit Funktion angereicherte Security-Token (Claimset) wird dem Benutzer zurück gegeben 6. Der Benutzer entscheidet, dass er dieses Security-Token (Claimset) zur RP schickt IAM - Identity und Access Management Digitale Identitäten von Subjekten werden durch das Identity Management verwaltet. Meistens werden zusätzlich auch deren Attribute (siehe 4.8) und Zugriffsregeln (siehe 4.21) verwaltet. Dies führt zum Namen IAM Identity und Access Management: 29/101

30 IAM Identity und Access Management befasst sich mit der Definition und Ausgabe von digitalen Identitäten, Credentials und Claims, der Definition von Zugriffsregeln und der Überwachung und Überprüfung der Zugriffe auf die zu schützenden Ressourcen. Ein IAM System besteht in der Regel aus zwei Teilen: Verwaltung: Digitale Identitäten und deren Attribute / Claims werden verwaltet (erzeugt, modifiziert, gelesen, aktiviert, deaktiviert, freigegeben etc.). Directory: Ein Directory ist eine für die Identitätsverwaltung optimierte Datenbank Register Register sind Verzeichnisse (siehe auch Kapitel 7.2.1) in der Verwaltungssprache, wie 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 (Handlungsvollmacht). Die besondere Herausforderung bei den Registern ist die grosse Anzahl unterschiedlicher Verzeichnisse. Diese Herausforderung ist auch z.b. unter dem Titel Registerharmonisierung im Bundesamt für Statistik beschrieben (siehe: ). Register werden oft weiter unterteilt in: Funktionsregister: Register, welche eine Funktion beschreiben, z.b. Arzt, Notar, Anwalt Berechtigungsregister: Register, welche Berechtigungen enthalten, z.b. Unterschriftenregelung Der Inhalt von Registern kann z.b. als Claim Assertion Service (CAS) zu Verfügung gestellt werden. 30/101

31 4.17. Trust (Vertrauen) Im Umfeld IAM ist Vertrauen zwischen den Partnern von zentraler Bedeutung. Es geht um die Frage, wer traut wem und welche Kriterien gibt es dafür. Trust Formell definierte Vertrauensbeziehung zwischen verantwortlichen Stellen, z.b. die formelle Beschreibung der Kriterien, welche erfüllt sein müssen, damit sich zwei Domänen gegenseitig vertrauen Authentisierung, Authentifizierung Im Unterschied zum englischen Sprachgebrauch, wo to authenticate für authentisieren und authentifizieren steht, werden im Deutschen die Begriffe unterschieden. Sie bezeichnen eigentlich nur zwei Aspekte desselben Vorgangs. Authentisierung Nachweis der digitalen Identität eines Subjekts. Authentifizierung Vorgang zur Überprüfung einer behaupteten digitalen Identität (Subjekt). E Es gibt unterschiedliche Authentisierungsmethoden: Schwache Authentisierung: Generell gilt die Authentisierung mittels Benutzernamen und Passwort als schwach. Passwörter können relative einfach abgehört oder sogar mit entsprechender Rechenleistung ermittelt werden. Starke Authentisierung: Zwei- oder Mehrfaktor-Authentisierung. Darunter versteht man die Kombination von mehreren Kategorien von Merkmalen, die als Beweismittel für eine erfolgreiche Authentisierung vom Benutzer verlangt werden. Es werden in der Regel folgenden Merkmalkategorien unterschieden: Was der Benutzer hat (Bsp.: Smartcard, Streichliste, Security Token) Was der Benutzer weiss (Bsp.: Passwort oder PIN-Code) Was der Benutzer ist (körperliche Merkmale wie Fingerabdruck, Venenbild, Irisbild usw.) Autorisierung (Administration, Laufzeit) Der Begriff Autorisierung wird in zwei unterschiedlichen Kontexten verwendet: Einerseits für den Vorgang, bei dem einer digitalen Identität die Zugriffsberechtigungen zugewiesen werden (eine administrative Tätigkeit, nach den Vorgaben der Legislative), 31/101

32 andererseits für den Vorgang der Überprüfung der Zugriffsberechtigung zur Laufzeit (Runtime). Autorisierung (Administration) Definition der Zugriffsregeln auf eine Ressource. Synonym: Access Management Das Erteilen der Autorisierung (Administration) wird oft auch Access Management genannt. Autorisierung (Laufzeit) Prüfen von Zugriffsrechten einer digitalen Identität (Subjekt, Ressource) auf eine Ressource und erteilen des Zugriffs zur Laufzeit Synonym: Access Control Die Überprüfung der Zugriffsberechtigung zur Laufzeit wird auch Access Control genannt Access Control Access Control Access Control ist der Prozess, der die Einhaltung der Regeln für den Zugriff einer digitalen Identität auf eine Ressource kontrolliert und garantiert. Synonym: Autorisierung (Laufzeit). Der Access Control Prozess ist im Kapitel im Detail beschrieben Zugriffsregel Ressourcenverantwortliche definieren die Zugriffsregeln für ihre Ressourcen. Die Regeln werden als Zugriffsprofil der Ressource zugewiesen und können z.b. in einem Directory gespeichert sein. Zugriffsregel Regeln für den Zugriff auf Ressourcen. 32/101

33 5. Anforderungen Prelim: Framework And Principles A Architecture H Vision Architecture Change Management G Implementation Requirements Governance F Migration Planning E Opportunities and Solutions B Business Architecture C Information System Arch. D Technology Arch. Anforderungen stehen im Zentrum der TOGAF ADM Methode. Anforderungen an ein spezifisches Umfeld können nicht generalisiert werden. Es muss ein geordneter Anforderungsmanagement Prozess eingeführt werden, in welchem Anforderungen spezifiziert und verwaltet werden. Abbildung 12 zeigt die Prozesse als BPMN: Anforderungen spezifizieren Anforderungen verwalten Abbildung 12: Anforderungsmanagement Prozesse Nebst dem formellen Aufsetzen des Anforderungsmanagements werden auch die Akteure und deren Rollen für das Anforderungsmanagement definiert. Üblicherweise werden folgende Rollen zugewiesen: Anforderungsmanager Aufgaben: Initialisierung des Anforderungsmanagements; Durchführen des Prozess Anforderungsverwaltung Kompetenzen: Definieren, wie das Anforderungsmanagement in seinem Zuständigkeitsbereich durchgeführt werden soll; Einbeziehen der zur Unterstützung des Anforderungsmanagements notwendigen Stellen. Verwalten von Anforderungen in den entsprechendem Kompetenzbereichen (Vorhaben, Projekt, Organisation) Verantwortung: Stellt sicher, dass die Prozesse des Anforderungsmanagements effizient und effektiv gemäss den Randbedingungen des Vorhabens aufgesetzt und durchgeführt werden. Durchführung der Anforderungsverwaltung gemäss den Vorgaben des Anforderungsmanagements. Pflege der Verwaltungsattribute in der Anforderungsliste. Anforderungsmanagementboard Aufgaben: Mitglieder des Anforderungsmanagementboard haben die Aufgabe darüber zu wachen, dass das Anforderungsmanagement im entsprechenden Aufgabengebiet gemäss den Richtlinien, welche in der Anforderungsinitialisierung festgelegt worden sind, umgesetzt werden. Sie beurteilen abschliessend Anforderungen. Kompetenzen: Sie führen den Anforderungsmanager und die Anforderungsentwicklung. Sie beurteilen, ob und welche Anforderungslieferanten einbezogen werden sollen. Verantwortung: Sie entscheiden über das Was und Wie des Anforde- 33/101

34 Anforderungsentwicklung Anforderungslieferant rungsmanagements innerhalb ihres Verantwortungsbereichs. Aufgaben: Bereits implizit oder explizit bestehende Anforderungen werden gesammelt, die Anforderungen der Stakeholder werden entwickelt. Kompetenzen: Entwickeln von Anforderungen je nach Kompetenzbereich (Vorhaben, Projekt, Organisation). Notwendige Partner / Stakeholder können zur Erfüllung der Aufgabe beigezogen werden. Verantwortung: Die Rolle ist verantwortlich für das Entwickeln der Anforderungen sowie den Einsatz der Anforderungswerkzeuge (Tools). Zur Rolle gehört, dass die Anforderungen entsprechend dem bei der Initialisierung definierten Vorgaben als Anforderungsobjekt festgehalten werden. Ebenfalls gehört die Pflege die Anforderungsliste dazu. Aufgaben: Formulieren von Anforderungen gemäss den Vorgaben der Anforderungsentwicklung. Aktive Mitwirkung bei der Anforderungsentwicklung. Kompetenzen: Anforderungen stellen, formulieren. Verantwortung: Sicherstellen, dass alle in ihrem Interessegebiet gestellten Anforderungen in die Anforderungsentwicklung eingeflossen sind. Anforderungen werden in geeigneter Form dokumentiert. Die nachfolgende Tabelle wurde auf Basis der groben Anforderungen aus dem Dokument ech-0107 IAM Gestaltungsprinzipien [2] erstellt. Diese Anforderungen dienen als Gedankenstütze/Checkliste bei der Erstellung einer konkreten Anforderungsliste im Rahmen eines Anforderungsmanagements. Im Anforderungsmanagement muss die Relevanz und Priorität einzelner Anforderungen individuell entsprechend der Ausgangslage beurteilt werden. Nr Titel Beschreibung Akzeptanzkriterien Kommentar 1 Identitätsnachweis nur wenn nötig Die digitale Identität eines Subjekts soll nur dort überprüft werden, wo dies aus Sicherheitsgründen notwendig ist. Nachweis durch Analyse der entsprechenden Anwendungsfälle. Akzeptanz steigt im Bezug auf Datenschutz (es werden keine unnötigen Daten erhoben). 2 Überprüfung Credentials Die Credentials einer digitalen Identität (Subjekt) werden nur dort geprüft, wo dies aus Sicherheitsgründen notwendig ist. Nachweis durch Analyse der entsprechenden Anwendungsfälle. Akzeptanz steigt in Bezug auf Datenschutz (es werden keine unnötigen Daten erhoben). 3 Ortsunabhängiger Ressourcenzugriff Ein Subjekt kann unabhängig vom Standort auf eine Ressource zugreifen, vorausgesetzt, sie ist im Internet "sichtbar" und das zugreifende Subjekt hat die notwendigen Zugriffsrechte. Nachweis durch Analyse der entsprechenden Anwendungsfälle. Diese Anforderung kann nur erfüllt werden, wenn eine Reihe von Rahmenbedingungen erfüllt ist. So muss die Ressource vom Subjekt aus sichtbar sein. Ebenfalls muss die Domäne der Ressource in der Lage sein, mit den benötigten Claim Providern eine entsprechende Trust Verbindung zu unterhalten. 34/101

35 Nr Titel Beschreibung Akzeptanzkriterien Kommentar 4 Kleine Anzahl digitale Identitäten 5 Kleine Anzahl zu verwaltender Credentials 6 Preis für elektronische Identitäten 7 Einfache Beschaffung für elektronische Identitäten und Credentials Es ist aus praktikablen Gründen erstrebenswert, eine möglichst kleine Anzahl von digitalen Identitäten verwalten und pflegen zu müssen. Im Idealfall benötigt ein Subjekt genau eine, universell nutzbare digitale Identität. Die Anzahl der zu verwaltenden Credentials soll aus praktischen Gründen möglichst klein sein. Im Idealfall hat ein Subjekt genau ein Credential pro digitale Identität. Der Preis für die Ausstellung von Identitätsträgern muss günstig sein (vergleichbar mit dem Preis einer EC Karte). Der Prozess zur Beschaffung von elektronischen Identitäten muss für den Endbenutzenden einfach und klar nachvollziehbar sein. 8 Stellvertreter Bei den Berechtigungen zu einer digitalen Identität muss es möglich sein, Stellvertreter zu spezifizieren. 9 Eindeutigkeit Die digitale Identität eines Subjekts ist innerhalb seiner Domäne eineindeutig. 10 Ressourcenzugriff Der Ressourcenverantwortliche definiert abschliessend, wer (digitale Identität) in welcher Art und Weise (Autorisierung) auf seine Ressource zugreifen darf (Missbrauch muss ausgeschlossen sein). 11 Zuverlässigkeit Die E-Government Lösung ist zuverlässig und robust. Innerhalb der Schweiz wird angestrebt, dass eine natürliche Person mit einer einzigen digitalen Identität sich auf Stufe Bund, Kantone und Gemeinden ausweisen kann. Weitere digitale Identitäten sind für die Verwendung ausserhalb E-Government möglich. Die Anzahl Credentials zu einem Subjekt können gezählt werden. Für die Schweiz gilt die Anforderung, dass für die einzelne digitale Identität für alle Geschäfte im E- Government Umfeld für Bund, Kantone und Gemeinden auch nur ein einziger Credential ausreichend ist. Vergleich des Preises des Identitätsträgers mit den gängigen EC- und Kreditkarten. Vor der Umsetzung: Analyse des Beschaffungsprozesses; Nach der Umsetzung: Umfrage bei den Benutzenden. Nachweis durch Analyse der entsprechenden Anwendungsfälle. Nachweis durch Analyse der entsprechenden Anwendungsfälle. Nachweis durch Analyse der entsprechenden Anwendungsfälle. Es muss ein Access Contnrol Prozess umgesetzt sein, der diese Funktion nachweisbar übernimmt. Überprüfung durch Verifikation sowohl im Design (Anwendungsfälle), intensiver Systemtest, Monitoring im laufenden Betrieb. Der Kontext dieser Anforderung beschränkt sich zurzeit auf E-Government. Der Kontext dieser Anforderung beschränkt sich auf E-Government. Der Preis beeinflusst stark die Akzeptanz einer elektronischen Identität. Der Beschaffungsprozess beeinflusst stark die spätere Benutzungsquote. Entspricht der Vollmacht im üblichen Geschäftswesen. Diese Anforderung darf nicht verwechselt werden mit der Anforderung, dass Subjekte unterschiedliche Namen haben können, z.b. Synonyme. Allenfalls muss diese Anforderung noch durch richterliche Beschlüsse ergänzt werden. Hier kann Erwartungsmanagement helfen, z.b. die transparenten Darstellung der Zuverlässigkeit für Benutzende. 35/101

36 Nr Titel Beschreibung Akzeptanzkriterien Kommentar 12 Verfügbarkeit Die E-Government Lösung ist in der Regel 7x24 Stunden verfügbar. Wartungsfenster sind dem Benutzer transparent anzuzeigen (maximal 4h pro Monat, insgesamt 20h im Jahr). 13 Performance Die E-Government Infrastruktur ist so zu konzipieren, dass Interaktionen mit dem System in der Regel nach maximal 3 Sekunden eine Antwort ergeben. In Ausnahmefällen darf die Antwortzeit maximal 30 Sekunden betragen. In diesem Fall müssen jedoch Benutzende einen entsprechenden Hinweis erhalten. 14 Minimaler Aufwand für Administration elektronischer Identitäten und deren Credentials 15 Minimaler Aufwand für die Administration von Attributen (Claims) zu digitalen Identitäten 16 Einhaltung der gesetzlichen Vorgaben Der Aufwand für die Verwaltung von Identitäten und deren Credentials soll effektiv und effizient erfolgen. Der Aufwand für die Verwaltung von Attributen (Claims), z.b. der Zugriffsrechte von digitalen Identitäten auf Ressourcen, soll effektiv und effizient erfolgen. Die E-Government Infrastruktur muss die gesetzlichen Vorgaben vom Bund, der Kantone und Gemeinden einhalten. 17 Auditierbarkeit Es muss möglich sein, konfigurierbar unterschiedliche Aktionen innerhalb der E-Government IAM Infrastruktur entsprechend den Vorgaben zu loggen um die Auditierbarkeit (Nachvollziehbarkeit) sicher zu stellen. 18 Geringe Hürde für Benutzbarkeit Die Benutzer möchten ohne grossen Installationsaufwand und ohne Kompatibilitätsprobleme auf dem Client auf die Ressourcen zugreifen können. Monitoring des laufenden Betriebs. Monitoring des laufenden Betriebs (Auswertung durch Benutzende). Monitoring des Verwaltungsaufwands des Identitätsproviders Monitoring des Verwaltungsaufwands des Security Token Services (Claim Provider) Abnahme der Modellarchitektur durch unabhängige Auditstelle Überprüfung durch Verifikation im Design (Anwendungsfälle), intensiver Systemtest, Monitoring im laufenden Betrieb. Überprüfung durch Verifikation des gesamten IAM- Prozesses aus Benutzersicht (Usability). Die geplante Verfügbarkeit soll so hoch wie notwendig, jedoch aus Kostengründen nicht höher. Interaktive Systeme müssen eine getätigte Eingabe rasch quittieren, da Endbenutzende sonst dazu neige, die Eingabe zu wiederholen. Der Verwaltungsaufwand hat direkte wiederkehrende Kostenfolgen und soll deshalb so gering wie möglich gehalten werden. Der Verwaltungsaufwand hat direkte wiederkehrende Kostenfolgen und soll deshalb so gering wie möglich gehalten werden. Insbesondere Informationssicherheit: Vertraulichkeit, Verfügbarkeit und Integrität. Es muss jederzeit möglich sein, den Zusammenhang zwischen digitaler Identität und den dazugehörigen Credentials zu jedem Zeitpunkt herstellen zu können. Der Zugriff auf Ressource und Aktionen, die durchgeführt wurden, muss nachvollzogen werden können. Einfache und verständliche Prozesse erhöhen die Benutzerakzeptanz. 36/101

37 Nr Titel Beschreibung Akzeptanzkriterien Kommentar 19 Wartbarkeit / Änderbarkeit Die E-Government-Lösung muss so konzipiert sein, dass sich ändernde Rahmenbedingungen schnell und kostengünstig umgesetzt werden können: Gesetzesänderungen, Sicherheitsrelevante Anpassungen (aktueller technischer Stand), etc. Nachweis durch Analyse der entsprechenden Anwendungsfälle. 37/101

38 6. Geschäftsarchitektur Prelim: Framework And Principles In der Phase B Geschäftsarchitektur des TOGAF ADM Zyklus wird die Zielarchitektur aus Geschäftssicht beschrieben. H Architecture Change Management A Architecture Vision B Business Architecture Im Kontext E-Government IAM werden die Prozesse gemäss dem ech Referenzmodell [1] aufgeteilt in Legislative (Prozesse zur Steuerung) und Exekutive (Prozesse zur Verwaltung und zum Betrieb) 10. G Implementation Governance Requirements C Information System Arch. F Migration Planning E Opportunities and Solutions D Technology Arch. Legislative (Steuerung) L1: Governance Festlegung Policy Festlegung Organisation / Zusammenarbeit Zusammenarbeit Interdomäne Definition von Rollen mit AKV L2: Riskmanagement Identifikation Schutzbedarf Risikoanalyse Risikomanagement ISDS Konzept L3: Compliance Review IAM Regulationen Audit IAM Prozesse Sicherstellung Einhaltung Vorgaben Management Prozesse M1: Digitale Identitäten M3: Claims M4: Credentials Exekutive (Verwaltung, Betrieb) Runtime M2: Zugriffsregeln R1: Access Control Authentifizierung Authorisierung Abbildung 13: E-Government IAM Prozess Landkarte Aus den Prozessen der Exekutive können die Services für die IAM Infrastruktur abgeleitet werden. Die durch die Prozesse identifizierten Services sind Teil der in Kapitel 8 beschriebenen Anwendungsarchitektur. Hinweis: Die hier jeweils angefügten BPMN-Prozesse stellen einen groben möglichen Ablauf dar. Im konkreten Fall müssen diese Prozesse aufgrund der spezifischen Anforderungen detailliert oder sogar geändert werden Beteiligte Parteien/Rollen Die Prozesse werden durch Akteure ausgeführt. Diese Akteure haben eine (eventuell mehrere) Rollen. Nachfolgend sind die wichtigsten Rollen exemplarisch mit Aufgaben, 10 Im Dokument [5] National Strategy for Trusted Identities in Cyberspace werden drei Ebenen unterschieden: Governance Layer: Entspricht der legislativen Ebene Management Layer: Entspricht den Managementprozessen aus der Exekutive Execution Layer: Entspricht der runtime Ebene 38/101

39 Kompetenzen und Verantwortung aufgelistet. Das Zusammenspiel dieser Rollen ist in den BMPN-Prozessen ersichtlich. Entscheidungsinstanz Sicherheitsbeauftragter (CISO Chief Information Security Officer) Auditor / Revisor Identifikationsstelle Identity Provider Credential Provider Claim Provider Aufgaben: Managementunterstützung für Governance, Riskmanagement und Compliance. Entscheidet abschliessend über die IAM-Vorgaben für den Betrieb. Formelle Abnahme des IAM Konzepts. Kompetenzen: Definition / Abnahme der Policy, Definition / Abnahme der Organisation; Übernahme von Restrisiken aus der Risikoanalyse Verantwortung: Sicherstellung der Governance; Sicherstellung des Riskmanagements; Sicherstellung Compliance Aufgaben: Berät zum vorgeschlagenen IAM Konzept und betreibt das Sicherheitsmanagement aus Sicht IAM Kompetenzen: Weisungsbefugt für die Sicherheitsaspekte der angestrebten IAM Lösung Verantwortung: Sicherstellung der Identifikation, Einschätzung und Adressierung von Sicherheitsrisiken. Sicherstellung der Policy-Konformität der IAM Architektur Aufgaben: Führt Audits durch Kompetenzen: Festlegung, was und wie auditiert wird. Verantwortung: Durchführung von Audits gemäss der festgelegten Policy. Aufgaben: Prüft die notwendigen Angaben und die Identifikation des Antragstellers (z.b. mit Hilfe des Pass / Identitätskarte). Leitet den geprüften Antrag mit den notwendigen Unterlagen auf sicherem Weg zum Identity Provider weiter. Kompetenzen: Kann den Identitätsantrag ablehnen, z.b. wenn Angaben des Antragstellers fehlen oder die Identifikation des Antragstellers nicht eindeutig erfolgen kann. Verantwortung: Kenntnis und korrekte Durchführung des Identifikationssubprozesses. Aufgaben: Betreibt die Identitätsmanagementprozesse (u.a. digitale Identitäten herausgeben). Interne Identity Provider (z.b. innerhalb einer Firma): Personaldienst, Fachstelle für externe Mitarbeitende. Externe Identity Provider: Provider (z.b. Post, Quovadis, Swisscom, BIT für die SuisseID ). Kompetenzen: Bereitstellen der Organisation und Infrastruktur für die Umsetzung der Prozesse. Verantwortung: Verfügbarkeit der Identitäts-Dienste gemäss SLA (Service Level Agreement). Aufgaben: Erzeugen der Credentials, z.b. Username/Password oder Authentifizierungszertifikat Kompetenzen: Definition der Credentials, z.b. Regeln für Benutzernamen, Passwörter oder Festlegung, wie das Authentifizierungszertifikat aussehen soll. Verantwortung: Anbieten eines entsprechenden Dienstes mit SLA (Service Level Agreement). Aufgaben: Legt die Claims fest; definiert den Claim-Service; Betreibt den Claim-Service Kompetenzen: Legt fest, mit welchen Credentials ein Claim abgefragt werden kann. Verantwortung: Stellt entsprechenden Dienst zur Verfügung (CAS Claim Assertion Service) mit SLA (Service Level Agreement). Nachfolgend werden Rollen von eher abstrakter Natur aufgeführt, welche so nicht zwingend als Standard-Rollen in jedem IAM definiert werden müssen. Lediglich die in den Prozessdarstellungen damit zusammenhängenden Schritte sollten bewusst in ei- 39/101

40 nem IAM berücksichtigt werden. Beispiel: Der (interne) Identitätsverantwortliche einer IAM-Domäne regelt / kontrolliert die Zusammenarbeit mit dem externen Identity Provider und regelt allenfalls auftauchende Sonderfälle. Identitätsverantwortlicher Ressourcenverantwortlicher Domänenverantwortlicher Antragsteller für digitale Identität Prozessverantwortlicher Aufgabe: Identitätsverantwortliche sind die Stellen, welche die digitalen Identitäten in ihren Domänen verwalten. Kompetenzen: Beauftragen von (internen / externen) Identity Providern Verantwortung: Verwalten der Identitäten gemäss den Vorgaben Aufgaben: Kennt die Ressourcen, für in seinem Verantwortungsbereich. Definiert die für seine Ressourcen gültigen Zugriffsregeln. Kompetenzen: Definition von Rollen (in Absprache mit dem Sicherheitsbeauftragten). Verantwortung: Erstellen der Zugriffsregeln für seine Ressourcen nach Vorgabe. Aufgaben: Erstellt und kommuniziert das Domänenkonzept. Kompetenzen: Bestimmt, was zur Domäne gehört; Bestimmt die Regeln (Policy) innerhalb der Domäne Verantwortung: Sorgt dafür, dass die Domänenpolicy vom Sicherheitsbeauftragten abgenommen wird; macht die Regeln innerhalb der Domäne bekannt und setzt sie durch. Aufgaben: Stellt den Antrag für eine digitale Identität (z.b. Subjekt, Vorgesetzter, Systemverantwortlicher, Human Ressources, etc.) Kompetenzen: Entscheidet, ob er eine digitale Identität beantragen will. Verantwortung: Stellt die für die Registrierung notwendigen Unterlagen bereit und legt diese bei der Registrierung vor (z.b. gültigen Pass oder gültige Identitätskarte als Identitätsnachweis zur Beantragung einer SuisseID). Aufgaben: Definiert und verwaltet die Prozesse für eine bestimmtes Aufgabengebiet. Kompetenzen: Definiert die Standards, wie die Prozesse definiert werden; Verantwortung: Prüft die Prozesse auf Konsistenz und Compliance gemäss den Vorgaben. Anmerkung: Welche Rollen es in einem bestimmten IAM Umfeld, in einer Domäne oder einem Domänenverbund wirklich braucht, muss konkret bei der Erstellung des IAM Konzepts ausgearbeitet werden. Dabei sollen auch die Aufgaben, Kompetenzen und Verantwortung genauer und spezifischer festgelegt werden Prozesse der Legislative Dazu gehören die Prozesse im Umfeld GRC (Governance, Risk, Compliance) zur Steuerung von E-Government IAM. Legislative (Steuerung) L1: Governance Festlegung Policy Festlegung Organisation / Zusammenarbeit Zusammenarbeit Interdomäne Definition von Rollen mit AKV L2: Riskmanagement Identifikation Schutzbedarf Risikoanalyse Risikomanagement ISDS Konzept L3: Compliance Review IAM Regulationen Audit IAM Prozesse Sicherstellung Einhaltung Vorgaben Abbildung 14: Prozesse der Legislative 40/101

41 Sie beschreiben die Abläufe für die Definition der notwendigen Vorgaben und Rahmenbedingungen für den Betrieb der IAM Umgebung, wie z.b. das Definieren des Angebots, das Definieren der Regeln und Abläufe, dem Festlegen der Revision etc L1: Governance Definiert die IAM-Infrastruktur und die IAM-Organisation. Dazu gehören: Festlegung der IAM Policy: Die IAM Policy definiert die Randbedingungen und den Scope für die angestrebte IAM Lösung. Wichtig ist insbesondere die Sicherstellung der Nachvollziehbarkeit des gesamten Prozessablaufs (z.b. das Ablegen der relevanten Dokumente in Repositorien). Festlegung der Organisation (Akteure) sowie ihrer Beziehung untereinander (Zusammenarbeit): Die IAM Organisation beschreibt, wie die verschiedenen involvierten Partner und Akteure miteinander in Beziehung stehen, wer Entscheidungen trifft, wie die Verantwortlichkeiten geregelt sind, wie Ressourcen eingesetzt werden etc. Den entsprechenden Akteuren werden die geeigneten Rollen zugewiesen. Identifikation / Festlegung der Zusammenarbeit von Domänen: Im E-Government Umfeld erfolgt IAM in der Regel über mehrere Domänen. Die Organisation und Abläufe zwischen den Domänen ist klar zu regeln. Definition der Rollen mit Aufgaben, Kompetenzen und Verantwortung. Die Prozesse werden durch Akteure ausgeführt. Diese Akteure haben eine (eventuell mehrere) Rollen (siehe 6.1) BPMN L1 Governance Prozess zur Sicherstellung der Governance durch Definieren / Überprüfen der Vorgaben der IAM-Organisation und IAM-Infrastruktur. 41/101

42 Abbildung 15 : BPMN L1 Governance Beteiligte Parteien: Sicherheitsbeauftragter: Arbeitet für die Legislative IAM-spezifische Vorgaben aus und unterbreitet diese der Entscheidungsinstanz Entscheidungsinstanz: Definition / Abnahme der Policy, Definition / Abnahme der Organisation, Übernahme von Restrisiken aus der Risikoanalyse, Entscheidet abschliessend über die IAM-Vorgaben für den Betrieb. IAM-Executive: Administriert das IAM-System technisch, Berät u.a. die IAM-Legislative hinsichtlich der Umsetzungsauswirkungen von IAM-Vorgaben. z.b.: IT-Spezialist L2: Riskmanagement Definiert die Abläufe zur Risikobehandlung (Risikoeinschätzung und -adressierung) für IAM-Prozesse. Für Bundesprojekte ist das Vorgehen nach Hermes genau definiert 11 : 11 Details unter: Projekthilfsmittel unter: 42/101

43 Abbildung 16: Vorgaben und Vorgehen für Projekte mit erhöhten Sicherheitsanforderungen Zu erstellen sind: Schutzbedarfsanalyse Schuban Risikoanalyse ProtAn ISDS Konzept Die Schutzbedarfsanalyse gewährleistet angepasste Sicherheitsanforderungen (so viel Sicherheit wie nötig, nicht so viel wie möglich). Alternativ oder ergänzend kann sich das Riskmanagement auch auf das Informationssicherheitsmanagementsystem (ISMS) nach ISO abstützen. Der in einschlägigen ISO-Normen (27000, 9000, etc.) definierte Verbesserungsprozess stellt in ISO die kontinuierliche Verbesserung des Sicherheitsmanagements sicher: Aufgrund der aktuellen Situation werden periodisch Massnahmen geplant, umgesetzt, überprüft und optimiert. Dieser kontinuierliche Verbesserungsprozess ist ein bewährtes und effizientes Vorgehen und heute ein Kernelement von Best Practice: Act Check Plan Do Abbildung 17 : Kontinuierlicher Verbesserungsprozess nach ISO.org 43/101

44 BPMN L2 Riskmanagement Prozess zur Sicherstellung des Riskmanagements durch regelmässige Auslösung der Risikobehandlung. Abbildung 18 : Prozess L2 Riskmanagement Beteiligte Parteien: Sicherheitsbeauftragter / CISO - Chief Information Security Officer: Abnahme des IAM Konzepts und betreiben des Sicherheitsmanagements aus Sicht IAM, Sicherstellung der Identifikation, Einschätzung und Adressierung von Sicherheitsrisiken, Sicherstellung der policy-konformen IAM Architektur. Prozessverantwortlicher: Analyse des Business Impact bei Beeinträchtigung der Prozesse, Einschätzung der Risiken z.b. gemäss ISO Entscheidungsinstanz: Entscheidet über die beantragten Massnahmen, respektive übernimmt die akzeptablen Restrisiken. IAM-Exekutive: Administriert das IAM-System technisch und erstellt dabei beispielsweise Zugriffsregeln gemäss Auftrag. z.b. IT-Spezialist 44/101

45 L3: Compliance Die IAM Lösung soll den gültigen Vorgaben entsprechen. Compliance wird erreicht durch: Erarbeiten und Aktualisieren der relevanten Vorgaben: Identifikation der geltenden Regularien (Gesetzte, Verordnungen, Best Practices). Ebenfalls sollen Veränderungen in den Vorgaben verfolgt und allfällige daraus resultierende Massnahmen identifiziert werden. Auditieren und kontrollieren der Umsetzung der Vorgaben: Die IAM Landschaft (die Prozesse, die Organisation, die technische Umsetzung) wird durch regelmässige Audits geprüft. Dadurch soll sichergestellt werden, dass die Umsetzung den Vorgaben entspricht BPMN L3.1 Review Regularien Prozess zur Sicherstellung der regelmässigen Überprüfung und Überarbeitung der Regularien. Abbildung 19 : Prozess L3.1 Review Regularien Beteiligte Parteien: Auditor / Revisor: Ist von der Entscheidungsinstanz beauftragt Stellt Veränderungen in den geltenden Regularien sicher Überwacht die rechtliche Situation bezüglich IAM Schlägt falls nötig Anpassungen / Massnahmen vor. Sicherheitsbeauftragter / Prozessverantwortlicher: Analysiert die Auswirkungen von geänderten Rechtsvorgaben bezüglich IAM 45/101

46 Koordiniert die Umsetzung der von der Entscheidungsinstanz beschlossenen/bewilligten Massnahmen. Entscheidungsinstanz: Entscheidet für die beantragten Massnahmen, resp. über die akzeptablen Restrisiken. IAM-Exekutive: Administriert das IAM-System technisch Setzt beschlossene Massnahmen um. z.b. IT-Spezialist BPMN Audit IAM Prozess zur Sicherstellung der regelmässigen Überprüfung des IAM auf Konformität zu den Vorgaben. Abbildung 20 : Prozess L3.2 Audit IAM Beteiligte Parteien: Auditor / Revisor: Ist von der Entscheidungsinstanz beauftragt, Führt regelmässig interne Audits durch. Prozessverantwortlicher: Ist verantwortlich für den Betrieb der IAM-Prozesse gemäss Vorgaben. IAM-Executive: Ist verantwortlich für den Betrieb des IAM-Monitoring gemäss Vorgaben. 46/101

47 6.3. Management Prozesse der Exekutive Die Management Prozesse der Exekutive beschreiben die Abläufe für die Verwaltung der IAM-Objekte gemäss dem in Abbildung 32 gezeigten Informationsmetamodell. Management Prozesse M1: Digitale Identitäten M3: Claims M4: Credentials M2: Zugriffsregeln Abbildung 21: Management Prozesse der Exekutive M1: Digitale Identitäten Die digitale Identität ist das zentrales Element jeder IAM Umgebung. Im Informationsmetamodell (siehe Abbildung 32) wird deutlich, dass ein Subjekt innerhalb einer Domäne immer mindesten eine digitale Identität hat Registrieren und erstellen einer digitalen Identität Im E-Government IAM Umfeld soll der Registrierungsprozess angelehnt an die Vorgaben des Bundesgesetztes über Zertifizierungsdienste im Bereich der elektronischen Signatur (ZertES) umgesetzt werden. Dies bedeutet: Registrierung eines Subjekts in seiner Organisation (Mitarbeitende des Bundes/Kanton/Gemeinde): In einer Organisation wird eine digitale Identität üblicherweise durch den Personaldienst auf Grund der Personalunterlagen sowie den Vorgaben der Organisation zur Erstellung einer digitalen Identität erstellt, nachdem ein Arbeitsverhältnis vereinbart wurde. Mitarbeitende sind persönlich bekannt und ihre Angaben sind glaubhaft. Registrierung eines Subjekts ausserhalb seiner Organisation (Bürger, Einwohner etc.): Im E-Government Umfeld wird falls notwendig die Registrierung bei einem Identity Provider vorausgesetzt, welcher die ZertES Registrierungsvorgaben einhält. Registrierung einer Ressource repräsentiert durch ein Subjekt: Eine Ressource (z.b. ein bestimmter Server oder eine Anwendung / ein Service) wird mit einer digitalen Identität versehen. Der Ressourcenverantwortliche stellt die für die Registrierung notwendigen Informationen zusammen. 47/101

48 Anmerkung zu digitalen Identitäten von Ressourcen : Grundsätzlich haben nur Subjekte eine digitale Identität. Sobald eine Ressource allerdings die Rolle eines Subjektes einnimmt, hat auch diese eine Identität. Per Definition gilt: (1) (Nur) ein Subjekt hat eine Identität. (2) Ein Subjekt ist ein Akteur welche auf eine Ressource zugreift. (3) Eine Ressource ist eine Anwendung, ein Service, eine Funktion, ein Prozess oder besteht aus Daten, auf welche ein Subjekt zugreifen möchte. (4) Eine Ressource hat eine Identität, wenn diese auch die Rolle eines Subjektes einnimmt (d.h. auf eine Ressource zugreift). Folgeschluss: (5) Eine Ressource welche nicht auf eine andere Ressource zugreift, hat keine Identität Abbildung 22 zeigt beispielhaft, wann eine Ressource eine Identität haben kann: Subjekt A (Person) benützt Ressource R1 (Service): Aufgrund (1), (2) A ist ein Subjekt und hat eine Identität Ressource 2 & 3 (z.b. Daten, Service) greifen nicht auf andere Ressourcen zu: Aufgrund (5) Ressourcen (2) und (3) sind keine Subjekte und haben keine Identitäten Ressource 1 (z.b. Service) greift auf die Ressource 2,3 zu: Aufgrund (2), (4) Ressource (1) ist ein Subjekt und hat eine Identität Hat Identität Subjekt A (Person) Hat keine Identität Ressource R2 (z.b. Daten) Ressource R1 (z.b. Service) Ressource R3 (z.b. Service) Abbildung 22 : Beispiel Ressource hat digitale Identität 48/101

49 BPMN M1.1 Digitale Identität registrieren Ziel des Prozesses ist die Registrierung eines Subjektes für eine digitale Identität. Dabei wird unterschieden ob das Subjekt eine Person oder ein System (Service, Anwendung, etc.) repräsentiert. Falls die Identität ein System ist, muss ein Risikoeinschätzungsprozess ausgelöst werden, um allfällige Risiken und Abhängigkeiten für das IAM oder das System zu adressieren (z.b. ob das System den Zugriff auf eine Ressource kontrolliert). Hinweis: Das Credential- und Identifikator-Management kann ein eigenständiger Prozess bei eigenständigen Providern sein. Er wird hier der Einfachheit halber als Subprozess dargestellt. Abbildung 23 : Prozess M1.1 "Digitale Identität registrieren" Beteiligte Parteien: IAM-Legislative: Definiert und aktualisiert die Vorgaben bezüglich der Identitätsverwaltung regelmässig. Diese Vorgaben können u.a. fachliche oder technische Anforderungen an die Umsetzung des Prozesses enthalten. Identitätsverantwortlicher: Verwaltet digitale Identitäten gemäss den legislativen Vorgaben, z.b. Systemverantwortliche (falls System), HR (falls Person) Antragsteller: 49/101

50 Beantragt die Erstellung einer neuen digitalen Identität. Der Antragsteller kann das Subjekt selber oder z.b. auch der Vorgesetzte / Systemverantwortliche sein. Identifikationsstelle: Identifiziert das Subjekt eindeutig gemäss den legislativen Vorgaben z.b. an Hand amtlicher Dokumente / System-ID. Zwischen der Identifikationsstelle und dem Identitätsverantwortlichen braucht es ein Vertrauensverhältnis. Sicherheitsbeauftragter: Behandelt Fälle in welchen die legislativen Vorgaben unklar oder nicht definiert sind. Identity Provider: Erstellt die Identität Ist Schnittstelle zum Credential- und Identifikator-Provider. Change Management Board: Entscheidet über die Einbindung des Systems in das (domänenübergreifende) IAM BPMN M1.2 Identität Löschen Ziel des Prozesses ist das Löschen einer digitalen Identität. Hinweis: Das Credential- Management kann ein eigenständiger Prozess bei verschiedenen Providern sein. Er wird hier der Einfachheit halber als Subprozess dargestellt. 50/101

51 Abbildung 24 : Prozess M1.2 "Identität Löschen" Beteiligte Parteien: IAM-Legislative: Definiert und aktualisiert die Vorgaben bezüglich der Identitätsverwaltung regelmässig. Diese Vorgaben können u.a. fachliche oder technische Anforderungen an die Umsetzung des Prozesses enthalten. Identitätsverantwortlicher: Verwaltet die digitalen Identitäten gemäss den legislativen Vorgaben. z.b. Systemverantwortlicher(Identität= System), HR (Identität=Person) Identity Provider: Löscht die digitale Identität Ist Schnittstelle zum Credential-Provider. Initiator: Initiiert die Löschung. Bsp.: Subjekt selbst, Vorgesetzter, Systemeigner, Behörden, IAM- Verantwortliche, etc. 51/101

52 M2: Zugriffsregeln Zugriffsregeln werden meist lokal als Attribute zu einer Ressource in einem IAM Directory verwaltet. Grundsätzlich sind jedoch Zugriffsregeln nichts anderes als Claims (Zugriffsattribute). Diese können über einen CAS erschlossen werden (z.b. via LDAP). Auch hier gilt, dass die Definition der Zugriffsregeln allenfalls von einer speziellen Autorisierungsstelle geprüft werden müssen (Freigabe der Zugriffsregeln) BPMN M2.1 Zuweisen Zugriffsregeln Ziel des Prozesses ist das Definieren und/oder Zuweisen von Zugriffsrechten zu einer oder mehrerer Ressourcen an Hand definierter Zugriffsregeln. Dabei müssen die beteiligten Claim Provider mit einbezogen werden um z.b. neue Claim zu definieren, welche dann in den Zugriffsrechten verwendet werden können oder auch um ein Vertrauensverhältnis zwischen dem IAM-System und dem CAS aufzubauen. Abbildung 25 : Prozess M2.1 Zuweisen Zugriffsregeln Beteiligte Parteien: IAM-Legislative: Definiert und aktualisiert die Vorgaben bezüglich der Zugriffsverwaltung von Ressourcen regelmässig. 52/101

53 Diese Vorgaben können u.a. fachliche oder technische Anforderungen an die Umsetzung des Prozesses enthalten. Ressourcenverantwortlicher: Verwaltet die Ressourcen gemäss den legislativen Vorgaben. Antragsteller: Beantragt das Zuweisen oder Löschen von Zugriffsregeln zu einer Ressource (Bsp.: ein Subjekt) Chief Information Security Officer (CISO): Behandelt Fälle in welchen die legislativen Vorgaben unklar oder nicht definiert sind. Claim Provider: Verwaltet und betreibt Claim Assertion Services (können mehrere sein) BPMN M2.2 Löschen Zugriffsregeln Ziel des Prozesses ist das Löschen von Zugriffsrechten einer Ressource (Zugriffsregeln). 53/101

54 Abbildung 26 : Prozess M2.2 Löschen Zugriffsregeln Beteiligte Parteien: IAM-Legislative: Definiert und aktualisiert die Vorgaben bezüglich der Zugriffsverwaltung regelmässig. Diese Vorgaben können u.a. fachliche oder technische Anforderungen an die Umsetzung des Prozesses enthalten. Ressourcenverantwortlicher: Verwaltet die Ressourcen gemäss den legislativen Vorgaben. Antragsteller: Beantragt das Entfernen von Zugriffsregel einer Ressource. Claim Provider: Verwaltet und betreibt Claim Assertion Services (können mehrere sein). 54/101

55 M3: Claims Claims sind gemäss der Definition vom Kapitel 4.9 geprüfte Behauptungen über ein Subjekt oder einer Ressource. Der Prozess wie diese Behauptungen zu prüfen sind ist genau zu beschreiben (z.b. bei der SuisseID durch Vorlegen eines amtlichen Ausweises bei der Registrierungsstelle). In IAM Umfeldern spricht man oft von Berechtigungsworkflows, um z.b. einem Mitarbeitenden die für seine notwendigen Aufgaben notwendigen Rechte zu erteilen. Genau genommen ist dies nichts anderes als ein Prozess zur Erteilung von Claims. In diesem Beispiel verlangt ein Antragsteller für ein Subjekt die Zuteilung einer neuen Rolle. Der Antrag wird zur Beglaubigung an eine dafür autorisierte Stelle geschickt. Nach erfolgreicher Beglaubigung kann die Rolle dem Mitarbeitenden (Subjekt) zugeteilt werden. Damit verfügt er über den entsprechenden Claim. Die bei der Registrierung erhobenen / vorgelegten Attribute können zur digitalen Identität abgespeichert werden. Der Identity Provider kann auch zum Claim Provider werden, indem er Claims, die sich auf diese Attribute beziehen, mittels eines Claim Assertion Service zur Verfügung stellt. Da die Angaben während der Registrierung gemäss dem Registrierungsprozessvorgaben (ZertES) zu prüfen sind, gelten diese als beglaubigt zum Zeitpunkt der Registrierung. Claims können auch generell von einem Claim Provider verwaltet und mittels eines Claim Assertion Service CAS Nutzenden zur Verfügung gestellt werden (siehe 4.13 in Bezug auf die SuisseID oder 4.14 in Bezug auf OASIS) BPMN M3 Claim Management Dargestellt sind Prozesskategorien des Claim Managements. Der Claim Provider muss allenfalls auch Identitätsinformationen vom Identity Provider abfragen können (z.b. Verifikation der digitalen Identität). Abbildung 27 : Prozess M3 Claim Management 55/101

56 Beteiligte Parteien: Claim Provider: Bietet die Schnittstellen / Services zur Definition / Erstellung, Änderung, Löschung und Abfrage von Claims an. IAM Executive: Repräsentiert das IAM für welche der Claim Provider seine Services anbietet wie z.b. das Erstellen von neuen Claims oder das Abfragen von bestehenden Claims. Siehe dazu auch M2.1 "Zuweisen Zugriffsregeln" oder R1 "Access-Control". Identity Provider: Liefert dem Claim Provider allenfalls benötigte Informationen zu digitalen Identitäten M4: Credentials Im E-Government IAM Umfeld existieren die folgenden Credentials: Authentisierungszertifikat: Für die sichere Authentisierung von Subjekten Signierungszertifikat: Signatur für Subjekte Im E-Government IAM Umfeld werden folgende Zertifikate eingesetzt: Für Subjekte aus Bund, Kanton und Gemeinden: Die Zertifikate aus der Admin- PKI (später Verwaltungs-SuisseID 12 ) Für andere Subjekte: SuisseID Zertifikate Credentials werden auf dem Identitätsträger (z.b. SmartCard) erzeugt (privater und öffentlicher Schlüssel). Der zu den Credentials gehörende öffentliche Schlüssel wird im Directory des Identity Providers zur digitalen Identität des Subjekts gespeichert. Der Identitätsträger wird dem Subjekt ausgehändigt BPMN M4 Credentials Management Dargestellt sind die groben Kommunikationsverbindungen des Credential Managements. Die Services des Credential Managements werden meistens im Rahmen der Identitäts-Managementprozessen aufgerufen. Ausgeführt werden sie durch den Identity Provider ausgeführt. 12 Aktueller Arbeitstitel 56/101

57 Abbildung 28 : Prozess M4 "Credential Management" Beteiligte Parteien: Credential Provider: Bietet die Schnittstellen / Services zur Erstellung und Löschung und von Credentials. Identity Provider: Nutzer der Services des Credential Providers. Der Credential Provider liefert die für das Erstellen und allenfalls Löschen und Revozieren von Credentials notwendigen Services Runtime Prozess der Exekutive In diese Kategorie gehört der Access Control Prozess mit Authentifizierung und Autorisierung. Runtime Prozess der Exekutive R1: Access Control Authentifizierung Authorisierung Abbildung 29: Runtime Prozess der Exekutive R1: Access Control Der Access Control Prozesse besteht aus den beiden Teilen: Authentifizierung, 57/101

58 Autorisierung überprüfen überprüfen Zugriff erlaubt Autorisierung, und ist in Abbildung 30 dargestellt. ID 1 Zugriffswunsch Access Control 6 Zugriff Ressource Subjekt 2 5 Identity Provider 3 IdP Überprüfen Identity Authentication Aktivitäten, Fehler, etc. Ressourceeigner bestimmt 4 Monitoring Claim Assertion Service CAS 4b Claims ermitteln Authorization 4a Zugriffsregel ermitteln Zugriffsregeln Zugriff ist erlaubt, wenn ermittelte Claims den Zugriffsregeln entsprechen Abbildung 30: Access Control Prozess 1. Das Subjekt meldet seinen Zugriffswunsch auf die Ressource. 2. Das Subjekt wird mithilfe von Credentials authentifiziert (Authentication Service: Verifikation der vorgelegten Credentials, z.b. eines digitalen Zertifikats). 3. Sofern dies lokal nicht möglich ist, wird die digitale Identität des Subjekts mithilfe des IdPs (Identity Providers) verifiziert. 4. Authorization überprüft die Autorisierung: 4a: Die Zugriffsregeln für den Zugriff auf die Ressource werden ermittelt und daraus die benötigten Claims abgeleitet. 4b: Anschliessend werden diese durch den CAS beglaubigt. 5. Der Zugriff wird erlaubt. 6. Der Zugriff erfolgt. Anmerkungen: Die Zugriffsregeln der Ressource könnten z.b. in einem Directory gespeichert sein. 58/101

59 Auftretende Fehler (wie z.b. ungültige Credentials oder fehlende Zugriffsrechte) haben einen Abbruch des Prozessablaufs bei den jeweiligen Überprüfungsschritten zur Folge. Fehlermeldungen werden protokolliert (Monitoring) BPMN R1 Access-Control Ziel des Access Control Prozess ist die kontrollierte und garantierte Einhaltung der Regeln für den Zugriff eines Subjekts auf eine Ressource. Abbildung 31 : Prozess R1 "Access-Control" Beteiligte Parteien: IAM-Legislative: Definiert und aktualisiert die Vorgaben regelmässig. Diese Vorgaben können u.a. fachliche oder technische Anforderungen an die Umsetzung des Prozesses enthalten. Access Control Service: Koordiniert den Zugriffsrequest der Ressource, 59/101

60 Stellt die Einhaltung der Regeln für den Zugriff auf eine Ressource sicher. Der Access Control Service benützt dazu den Authentication und den Authorization Service. Authentication Service: Überprüft ob das Subjekt derjenige ist, welcher es behauptet zu sein. Benützt dazu allenfalls den Identity Provider zur Verifikation der digitale Identität (falls Verifikation lokal nicht möglich). Authorization Service: Überprüft ob das Subjekt das Recht hat, auf die Ressource zuzugreifen. Benützt dazu allenfalls den Claim Provider zur Verifikation von Claims (falls Verifikation lokal nicht möglich). Subjekt: Ein Subjekt ist ein Akteur, welche auf eine Ressource zugreift oder zugreifen möchte. Es kann sich um eine natürliche oder juristische Person oder auch um eine Maschine / ein System handeln. Identity Provider: Unterstützt den Authentication Service in der Authentifizierung des Subjekts falls nötig durch die Verifikation der digitalen Identität. Claim Provider: Unterstützt den Authorization Service in der Authorisation des Subjekts falls nötig durch die Verifikation von Claims. 60/101

61 7. Informationsarchitektur Prelim: Framework And Principles A Architecture H Vision Architecture Change Management G Implementation Requirements Governance F Migration Planning E Opportunities and Solutions B Business Architecture C Information System Arch. D Technology Arch. Dieses Kapitel entspricht dem Teil Informationsarchitektur aus der TOGAF Phase Informationssystemarchitektur (ADM Phase C). Der Teil Applikationsarchitektur folgt als Kapitel Lösungsansätze (siehe Kapitel 8). Im Fokus stehen: IAM Metamodell IAM Infrastruktur (Administration, Services) Domänen und ihre Beziehungen zueinander Access Control Modelle Diese Punkte beleuchten schwerpunktemässig einige der wichtigsten Techniken und Standards im IAM Umfeld. Sie haben nicht den Anspruch, das Thema vollständig von allen Seiten und umfassend zu beleuchten. Es wird oft Bezug auf die vorhergehenden Kapitel genommen, insbesondere auf das Kapitel 6, welches die Prozesse und Abläufe beschreibt IAM Metamodell Abbildung 32 zeigt das Informationsmetamodell (Informationsobjekte und deren Beziehungen untereinander) für eine digitale Identität: Subjekt 0..n besitzt tritt auf als Ressource hat Credential 0..n besitzt 1..n Digitale Identität erfüllt 0..n 0..n Claim verwendet Zugriffsregel 0..n hat einen Identifikator 1 Domäne hat Vertrauen (Trust) 0..n Abbildung 32: IAM Informationsmetamodell für eine digitale Identität 61/101

62 Subjekte und Ressourcen sind reale Objekte ausserhalb einer Domäne. Die digitale Identität eines Subjektes existiert innerhalb der Domäne. Eine Ressource kann als genau ein Subjekt auftreten. Ressourcen haben 0..n Zugriffsregeln. Diese können allgemeiner Art sein oder sich auf die Domäne beziehen (deshalb wird der Informationsobjekt Zugriffsregel auf die Grenze der Domäne gelegt). Anmerkung: Zugriffsregeln werden oft als ACL (Access Control List) bezeichnet. Die Domäne hat Vertrauen zu 0..n weiteren Domänen und damit allenfalls zu den jeweilig darin existierenden digitalen Identitäten. Innerhalb der Domäne: Ein Subjekt besitzt 1..n Identitäten (Idealfall: Nur eine Identität pro Domäne). Die digitale Identität hat einen Identifikator (eindeutiger Name). Eine digitale Identität besitzt 1..n Credentials. Eine digitale Identität erfüllt 0..n Claims. Zugriffsregeln verwenden 0..n Claims Die formale Definition des Metamodells erfolgt im Rahmen eines Umsetzungskonzepts und ist nicht Bestandteil dieses Dokumentes IAM Infrastruktur Der Schlüssel zur erfolgreichen Verwendung digitaler Identitäten liegt in einer effektiven und effizienten IAM Infrastruktur für Subjekte und Ressourcen (Identity Management) sowie deren Claims (Claim Management 13, Attribut Management). Diese Infrastruktur besteht aus einer Administrationsschicht, einem geeigneten Verzeichnis sowie Services für deren Verwendung. Die Infrastruktur setzt die in Kapitel 6 aufgezeigten Geschäftsprozesse um. In heutigen IT Umfeldern fehlt meistens eine solche IAM Infrastruktur. Die Administration von Subjekten (Benutzenden) sowie deren Claims (Berechtigungen) erfolgt in der Regel dezentral verteilt über unterschiedliche Systemplattformen und Anwendungen dezentral verteilt. Ressourcen werden, wenn überhaupt, separat in einem Konfigurationsmanagement System verwaltet, welches selten einen Zusammenhang mit IAM hat IAM Verzeichnisse Subjekte oder Ressourcen und deren Attributen können prinzipiell in jeder modernen Datenbank als entsprechende Objekte gespeichert und zur Verfügung gestellt werden. 13 Claim Management manchmal auch als Access Management bezeichnet. 62/101

63 Weit verbreitet ist der Aufbau eines sogenannte Directory Service, auch Verzeichnisdienst genannt. Dieser erlaubt die Ablage der Daten in einer streng hierarchischen Struktur. Frühere Implementierungen basierten meist auf dem X.500 Standard der ITU-T 14. Heute erfolgt der Zugriff auf Verzeichnisdienste meist über das LDAPv3 15 Protokoll. In diesem Zusammenhang spricht man oft auch von sogenannten LDAP Verzeichnissen mit ihrer hierarchischen Datenstruktur, dem sogenannten DIT (Directory Information Tree). Auch Register sind Verzeichnisse, wie bereits im Kapitel 4.16 erläutert worden ist. Ein Verzeichniseintrag für ein Subjekt könnte in einem LDAP Verzeichnis etwa wie in Abbildung 33 aussehen: dn: uid=mam, ou=subject, ou=security, ou=section, c=ch, o=awk cn: Markus Meier givenname: Markus sn: Meier Telephonenumber: mail: Abbildung 33: Symbolische Darstellung eines Verzeichniseintrags eines Subjekts Abbildung 34 zeigt schematisch eine mögliche hierarchische Struktur eines DITs: dn: c=ch, o=awk objectclass: top objectclass: organization o: AWK dn: ou=section, c=ch, o=awk objectclass: top objectclass: organizationalunit ou: section dn: ou=role, c=ch, o=awk objectclass: top objectclass: organizationalunit ou: role dn: ou=ressoure, c=ch, o=awk objectclass: top objectclass: organizationalunit ou: ressource dn: ou=subject, ou=section, c=ch, o=awk objectclass: top objectclass: organizationalunit ou: subject dn: uid=pcons, ou=role, c=ch, o=awk role: principal consultant dn: ou=services, ou=ressoure, c=ch, o=awk objectclass: top objectclass: organizationalunit ou: services dn: uid=mam, ou=subject, ou=section, c=ch, o=awk cn: Markus Meier givenname: Markus sn: Meier Telephonenumber: mail: dn: uid=servicex, ou=services, ou=ressource, c=ch, o=awk ACL: aaaccclll dn: uid=mam, ou=digid, ou=subject, ou=section, c=ch, o=awk identifikator: credentials: claim1: xxx claim2: uid=pcons Abbildung 34: Directory Information Tree (DIT) 14 X.500 entspricht ISO/IEC , Details unter: 15 LDAP: Lightweight Directory Access Protocol spezifiziert in (und weitere) 63/101

64 In diesem Beispiel ist die Wurzel des DITs der Verzeichniseintrag der Firma AWK. Auf der zweiten Ebene sind die verschiedenen Kategorien im Directory-Baum: ou=section: In diesem Teilbaum befinden sich alle Mitarbeitenden (Subjekte) mit ihren digitalen Identitäten. ou=role: In diesem Teilbaum befinden sich alle Rollen in der Firma AWK, z.b. Consultant, Principal Consultant, ou=ressource: In diesem Teilbaum befinden sich Ressourcen, z.b. Services sowie deren Zugriffsregeln. Eigenschaften von LDAP Verzeichnissen: Sie sind leseoptimiert mit dem Ziel, Autorisierungs- und Authentifizierungsinformation möglichst rasch und effizient während des laufenden Betriebs zur Verfügung zu stellen. Sie können relativ einfach auf unterschiedliche Standorte verteilt werden. Dies gilt auch für die delegierte Administration z.b. eines Teilbaums. Die grosse Verbreitung im IT Umfeld (ein de-facto Industriestandard) ist ein Vorteil. Die meisten heutigen Produkte auf dem Markt welche eine Benutzerverwaltung verwenden, können über eine LDAP Schnittstelle angesprochen werden. Wird ein LDAP Verzeichnis mit einer darunterliegenden relationalen Datenbank realisiert, gelten gewisse Einschränkungen bezüglich der üblicherweise bei relationalen Datenbanken vorhandenen Funktionalität. So kann mittels LDAP Protokoll z.b. keine Join (Kreuzprodukt) Abfrage gemacht werden. Im Webservices Umfeld kann LDAP z.b. über DSML (Directory Service Markup Language) verwendet werden. LDAP Verzeichnisse können auch über Programmierschnittstellen angesprochen wer, z.b..net oder Java (Methoden aus der Class Library JNDI) Verknüpfung von Verzeichnissen Verzeichnisse können je nach Bedarf verknüpft werden. Dadurch kann z.b. innerhalb einer Domäne ein zentraler Verwaltungsansatz realisiert werden, wie er im Kapitel 8.1 vorgeschlagen wird. Es gibt zwei unterschiedliche Ansätze für die Verknüpfung von Verzeichnissen: Metadirectory: In diesem Ansatz werden mit Hilfe von Metadaten die Verzeichniseinträge unterschiedlicher verlinkter Verzeichnisse einheitlich zur Verfügung gestellt. Dies geschieht in der Regel durch das Kopieren und verlinken der entsprechend eingebundenen Verzeichnisse. Virtual Directory: Dies ist ein neueres Konzept, welches an das Metadirectorykonzept angelehnt ist, jedoch lediglich eine einheitliche Sicht auf unterschiedliche 64/101

65 Directories gewährt. Dabei werden die erschlossenen Verzeichnisse nicht ins Metadirectory kopiert. Abbildung 35 zeigt schematisch die Verknüpfungsfunktionalität, wie sie bei Metadirectories oder virtuellen Directories verfügbar ist: Subjekt AD Name Prename Tel Fax PersNr Subjekt SAP Name FirstName ZweiterVorname Telefon Fax PersonalNummer epost IAM Subjekt IAM Name Vorname Telephone Fax PersonalNumber Abbildung 35: Verknüpfung von Verzeichnissen Verknüpft werden die verschiedenen Verzeichnisse, im Beispiel von Abbildung 35 das AD und das SAP Directory. Zusätzlich werden Verknüpfungsregeln definiert, um z.b. bei einem Subjekt die Attributbezeichnung FirstName aus SAP oder Prename aus AD auf die Attributbezeichnung Vorname abzubilden Verzeichnis Replikation Eine grosse Herausforderung in einem IAM Umfeld sind Verfügbarkeit, Performance, Zuverlässigkeit und Redundanz. Dies kann durch die geeignete Replikation von Verzeichnissen erreicht werden. Heute unterstützen praktisch alle Produkte im IAM Umfeld effiziente Replikationstechniken. Es gibt jedoch grosse Freiheiten bezüglich der am besten geeigneten Konfiguration, welche in einem IAM Detailkonzept gemäss den Anforderungen ausgestaltet werden kann. Im Detailkonzept u.a. berücksichtigt werden, von wo Verzeichnisse hauptsächlich gelesen oder von wo sie hauptsächlich mutiert (geschrieben) werden. Heute spricht man meist nicht mehr vom Master-Directory sondern von den sogenannten Supplier-Directories, d.h. die Produkte unterstützen heute Ansätze, wo mehrere Knoten auch Daten updaten dürfen. Verzeichnisse, welche nur lesende Zugriffe unterstützen werden in diesem Zusammenhang als Consumer bezeichnet. 65/101

66 IAM Serviceprovider und deren Services Der direkte Zugriff auf ein Verzeichnis innerhalb einer Domäne erfolgt in der Regel über LDAP, wie im Kapitel mit unterschiedlichen Methoden und unterschiedlichen Klienten erklärt wurde. An dieser Stelle sollen weitere Methoden diskutiert werden, um Verzeichnisinformationen domänenübergreifend zur Verfügung stellen zu können. Um Subjekte in der digitalen Welt identifizieren zu können brauchen sie eine digitale Identität, welche durch einen Identity Provider ausgegeben wird. Die digitale Identität enthält Credentials, welche es Subjekten erlaubt sich z.b. zu authentisieren. Mit ihrer digitalen Identität sind Subjekte z.b. auch in der Lage auf ihre Claims bzw. Claimsets zuzugreifen, wie sie im Kapitel 4.9 beschrieben worden sind. Claims werden z.b. vom CAS (Claim Assertion Service im SuisseID Umfeld siehe Kapitel 4.13) oder als STS (Security Token Service nach OASIS Terminologie siehe Kapitel 4.14) zur Verfügung gestellt Identity Provider Identity Provider stellen digitale Identitäten für Subjekte aus. Der Identity Provider einer Firma kann z.b. auch die eigene Betriebsorganisation sein. Er registriert Subjekte, erstellt und verwaltet deren digitalen Identitäten und verteilt diese gemäss den internen Vorgaben. Im föderierten Umfeld E-Government können digitale Identitäten typischerweise von unterschiedlichen Identity Providern ausgestellt werden. Im SuisseID Umfeld gibt es z.b. die Identity Provider Quo Vadis Trustlink Schweiz AG und die Schweizerische Post/SwissSign AG, welche sowohl Unternehmen wie Privatpersonen beliefern. Die Swisscom (Schweiz) AG beliefert zurzeit ausschliesslich Unternehmen. Das Bundesamt für Informatik und Telekommunikation BIT liefert die SuisseID für Verwaltungsbedürfnisse. Die Identity Provider operieren nach genauen Vorgaben, welche von einer Revisionsstelle formell bestätigt werden müssen. Zertifikatbasierte Identity Provider stellen folgende Services zur Verfügung: Zentraler Verzeichnisdienst: Die zu veröffentlichenden Zertifikate werden in einem zentralen Verzeichnisdienst veröffentlicht und können über LDAP abgefragt werden. Auskunft über Zertifikatsstatus: Mit dem OCSP Protocol (Online Certificate Status Protocol) muss der Status von Zertifikaten abgefragt werden können. Allgemeine Informationen: Identity Provider sollen eine Webseite unterhalten, wo sie allgemeine Informationen zu ihren Zertifikatsdiensten publizieren. 66/101

67 Credential Provider Credentials sind gemäss Definition im Kapitel 4.12 Hilfsmittel, mit denen eine digitale Identität eines Subjekts überprüft werden kann. Credential Provider erzeugen Credentials und händigen diese auf sichere Art und Weise dem Subjekt aus. Im einfachsten Fall ist ein Credential ein Passwort. Im E-Government IAM Umfeld wird jedoch die Zweifaktor Authenisierung vorausgesetzt, die heute üblicherweise mittels Authentisierungszertifikaten erfolgt. Im Verwaltungsumfeld sind heute mit der AdminPKI des BIT unterschiedliche Zertifikatstypen im Einsatz 16. Diese soll in Zukunft gemäss eines Bundesratsbeschluss vom Sommer 2010 zur Verwaltungs-SuisseID vereinigt werden. Im SuisseID Umfeld wird das Authentisierungszertifikat auf einem Hardware Security Token (z.b. Smartcard, USB Stick) ausgegeben. Das Schlüsselpaar (privater und öffentlicher Schlüssel) wird direkt auf dem HW Security Token erzeugt. Der private Schlüssel kann im Normalfall nicht vom Security Token ausgelesen werden. Damit erreicht man, dass das Security Token zwingend als Faktor besitzt werden muss um sich erfolgreich authentisieren zu können. Der öffentliche Schlüssel wird anschliessend beim Credential Provider (in der Regel der Identity Provider) zur digitalen Identität gespeichert. Credentials müssen in der Regel bei der ersten Benutzung personalisiert werden. Bei Passwörtern bedeutet dies, dass bei der ersten Benutzung mit dem Initialpasswort durch das Subjekt ein regelkonformes Passwort gewählt werden muss. Bei HW Security Token muss in der Regel das Initialpasswort zum Öffnen des Trägers sowie das Passwort für die Verwendung des Authentisierungszertifikats gemäss den Vorgaben personalisiert werden Claim Provider und Claim Assertion Service Claims sind gemäss Begriffsdefinition in Kapitel 4.9 beglaubigte Attribute zu einem Subjekt, z.b. Subjekt ist Arzt, über 18 Jahre alt oder Mitarbeiter einer Firma. Claim Provider sind Organisationen, welche Claims nach den Regeln von OASIS als Claim Assertion Service (siehe 4.13) oder Security Token Service (siehe 4.14) zur Verfügung stellen können. Die Erhebung von Informationen zu einer digitalen Identität kann auf unterschiedliche Art erfolgen. Im Umfeld der SuisseID werden z.b. zum beantragenden Subjekt die Informationen des für die Registrierung erforderlichen Personalausweises gespeichert. Diese Informationen können anschliessen von den Claim Service Providern der SuisseID (die gleichen vier wie die Identity Provider) zu einem Subjekt als Claims abgefragt werden. 16 Details siehe: 67/101

68 Kontextabhängige Claims Ein Subjekt mit einer einzelnen digitalen Identität kann unter Umständen unterschiedliche Claims in verschiedenen Umfeldern haben. Die Claims in unterschiedlichem Kontext müssen vollständig unabhängig voneinander verwaltet und abgefragt werden können. Beispiel: Das Subjekt X hat eine einzige digitale Identität im IAM seines Unternehmens. X hat aber zwei verschiedene Anstellungsverhältnisse (z.b. 20 % Projektleiter, 80% Sicherheitsbeauftragter) aufgrund welcher er verschiedene Claims, resp. Zugangsberechtigungen hat. Nach dem Auflösen des Anstellungsverhältnisses Projektleiter, müssen alle Claims / Zugangsberechtigungen welche in diesem Zusammenhang stehen, gelöscht werden. Alle mit dem Anstellungsverhältnis Sicherheitsbeauftragter in Zusammenhang stehenden Claims / Zugangsberechtigungen müssen erhalten bleiben IAM Administration Zur Administration gehören Aufgaben wie z.b. Aufsetzen / Konfiguration der Server, auf welchen das IAM Verzeichnis läuft Aufsetzen / Konfiguration des Verzeichnisses selbst Management des Verzeichnisinhalts Implementierung der Sicherheitsvorgaben gemäss der für das Verzeichnis gültigen Sicherheitspolitik Management der Replicas (Kopien der Verzeichnisse) Management der Referrals (Referenzen auf eingehängte Verzeichnisse) Management der virtuellen Verzeichnisse (einheitliche Sicht auf unterschiedliche Verzeichnisse) Management der Zugriffsverwaltung / Zugriffsregeln für die Einträge Management der Claim Services (Security Token Services) für Provider, welche selbst als Identity oder Claim Provider auftreten Umsetzen der Auditpolitik gemäss den Sicherheitsvorgaben (z.b. Einstellung der Loglevel, Festlegung der Logfilecontainer) Performance Management und Monitoring Heutige IAM Produkte bieten meistens ein Management Oberfläche an, um diese Funktionen interaktiv und mit grafischer Oberfläche bedienen zu können. Die Managementfunktionen können jedoch auch über einfache Schnittstellen (z.b. Eingabe eines Befehls wie in Kapitel beschrieben wurde) oder über Programmierschnittstellen (z.b. mit Methoden aus der Java Class Library JNDI) ausgeführt werden. 68/101

69 7.3. Domänen Eine Domäne, wie sie als Begriff im Kapitel 4.6 eingeführt wurde, umfasst einen wohl definierten Namensraum. In der Domäne gibt es eine Legislative, welche die für die das IAM Umfeld in der Domäne gültigen Regeln bestimmt (GRC Governance, Riskmanagement, Compliance, siehe Kapitel 6.1). Die Exekutive der IAM Domäne ist zuständig für den Betrieb des IAM und damit für die Verwaltungsprozesse (siehe Kapitel 6.3) und die Run-time Prozesse (siehe Kapitel 6.4) Policies und Richtlinien in einer Domäne In jeder Domäne gibt es domänenspezifische Policies und Richtlinien welche in der IAM-Legislative definiert und überwacht werden müssen (siehe 6.2 Prozesse der Legislative). Innerhalb der Domäne ist die Bedeutung und der Umgang mit digitalen Identitäten klar geregelt. Es ist klar, wie digitale Identitäten und deren Identifikator zu einem Subjekt oder eine Ressource gebildet werden. sind die für das Identitätsmanagement notwendigen Prozesse klar definiert. klar geregelt, wer und wie Zugriffsregeln auf Ressourcen definiert werden. klar geregelt, wer die Claims definiert und woher sie bezogen werden. Ebenfalls ist in der Domäne klar geregelt, wie sich Subjekte oder Ressourcen authentisieren (welche Credentials sie dazu verwenden) und wie sie authentifiziert werden (wie die Credentials verifiziert werden). Auch ist in der Domäne festgelegt wie die Autorisierung vor dem Zugriff auf Ressourcen geprüft werden kann (ob die vorgelegten Claims den Anforderungen für den Zugriff auf die Ressource entsprechen). Innerhalb der Domäne stellt der Betrieb die Verfügbarkeit der einzelnen Services sicher Herausforderungen in föderierten Domänen Wenn Subjekte einer Domäne auf Ressourcen anderer Domänen zugreifen, spricht man von föderierten Domänen. Dieser Ansatz bringt zusätzliche Herausforderungen mit sich, wie sie beispielhaft in Abbildung 36 dargestellt sind. 69/101

70 Subjekt Ressource Subjekt Ressource Zugriffsregel f Zugriffsregel Credential Identifikator Digitale Identität Domäne A Claim d c e b Credential Identifikator Digitale Identität Domäne B Claim g a Abbildung 36: Herausforderungen zwischen zwei Domänen a) Policies, Standards, Trust zwischen Domänen: Welche Sicherheitsstandards und Policies gelten in den beiden Domänen (formelle Abmachung über das gegenseitige Vertrauen)? b) Identitätsmapping: Wie muss in Domäne B mit digitalen Identitäten der Domäne A umgegangen werden? c) Identifikator: Welcher Identifikator soll in B für die digitale Identität aus der Domäne A verwendet werden? d) Credentials: Wie können sich domänenfremde Subjekte oder Ressourcen authentisieren (welche Credentials verwenden sie)? e) Überprüfung Credentials: Wie kann die Authentifizierung überprüft werden (wie können die Credentials überprüft werden)? f) Zugriffsregeln: Wie lauten die Zugriffsregeln für domänenfremde digitale Identitäten und wo werden diese verwaltet? g) Claims: Welche Claims (Rollen) werden ausgetauscht (benutzt) bzw. wie erfolgt die Zugriffskontrolle für domänenfremde digitale Identitäten (Überprüfung der für den Zugriff notwendigen Claims)? Diese Punkte sind zu klären wenn digitale Identitäten domänenübergreifend eingesetzt werden sollen Policies, Standards und Trust zwischen Domänen Im Zusammenspiel verschiedener Domänen spielt das gegenseitige Vertrauen eine zentrale Rolle. Dieses Vertrauen wird durch gegenseitige Transparenz erreicht. Die Partner müssen verstehen, welche Policies und Standards in den unterschiedlichen Domänen gelten. Gegenseitiges Vertrauen kann z.b. erreicht werden durch eine unabhängige oder belegbare Einstufung in bestimmte Sicherheitslevels. In einem Verbund ist die Sicherheit nur so gut, wie die Sicherheit des schwächsten Glieds der Kette. Beim europäischen Ansatz STORK (siehe [8]) spricht man vom QAA Quality Authentication Assurance) für das Vertrauen bezüglich der Identifikation und Authenti- 70/101

71 sierung/authentifizierung von digitalen Identitäten in verschiedenen Domänen. STORK kennt vier Sicherheitslevel: QAA Level Beschreibung 1 Keine oder minimale Sicherheit 2 Kleine Sicherheit 3 Erhebliche Sicherheit 4 Grosse Sicherheit Ganzheitlich gesehen ist das Vertrauen in die Methoden des Identitätsnachweises nur ein Teilaspekt für den Aufbau eines gegenseitigen Vertrauens unter Domänen, da damit keine Aussage über die grundsätzliche IT-Sicherheit in einer anderen Domäne gemacht werden kann. Bei der Trustbildung sind somit auch andere Sicherheitsmerkmale relevant (z.b. wie digitale Identitäten autorisiert werden), welche aber in diesem IAMspezifischen Dokument nicht weiter beschrieben werden: Auf internationaler Ebene gibt es verschiedene Ansätze, wie sie z.b. in der Cross Domain Community Roadmap von UCDMO [7] beschrieben sind. Im Umfeld des Department of Defense 17 (DoD) wurden Kriterien für Systeme definiert, welche vor allem in den Gebieten Policy, Haftung, Sicherheit und Dokumentation spezifisch sind. Systeme wurden in vier Klassen eingeteilt von D (minimal Anforderungen) bis A (Sicherheit verifiziert) E-Government Schweiz: Resultierende Security Level Im E-Government Ansatz Schweiz sollen in Anlehnung an die erwähnten (STORK-) Ansätze ebenfalls vier Sicherheitslevel für digitale Identitäten von Subjekten definiert (E-Government- Security-Level) werden: Level 1: Dies ist der unterste Sicherheitslevel im E-Government Umfeld Schweiz. Hier werden digitale Identitäten nicht weiter verifiziert. Level 2: Auf dieser Sicherheitsstufe geht es um Geschäfte von digitalen Identitäten mit minimalem Schadenspotential. Beispiele hierfür sind z.b. Ticketkäufe oder Formularbestellungen, wo Benutzende eine adresse hinterlegen oder sich allenfalls mit ihrer gültigen adresse registrieren müssen, bevor ein Geschäft, z.b. gegen Rechnung, getätigt werden kann. Level 3: Auf dieser Sicherheitsstufe geht es um Geschäfte von digitalen Identitäten mit grösserem Schadenspotential. In diese Kategorie fallen z.b. die üblichen Kreditkartengeschäfte via Internet, selbstverständlich über eine gesicherte SSL Verbindung /101

72 Level 4: Bei der höchsten Sicherheitsstufe können nur formell validierte digitale Identitäten Geschäfte tätigen, z.b. Subjekte (Benutzende) mit einer SuisseID. Anmerkung: Diese Security Level sind wie bei der EU für die Schweiz noch präzise zu definieren und zu standardisieren. Ebenfalls sind die Kriterien für die Einordnung in einen entsprechenden Security Level noch genau festzulegen. Ebenfalls braucht es eine Zertifizierungsstelle, welche als unabhängige Instanz die Domänen entsprechend den Vorgaben einstufen kann. Diese Security-Level Einstufung erleichtert den Domänen im gegenseitigen Verkehr die für die Sicherheit notwendigen Massnahmen zu treffen. Es wäre z.b. möglich dass Subjekte mit einer digitalen Identität aus einer Level 4 Domäne auch in anderen Level 4 Domänen als sicher authentifiziert gelten Identitätsmapping Eine besondere Herausforderung in einem Domänen-Verbund ist das Mapping von digitalen Identitäten von Subjekten, da in der Regel die gleichen Subjekte in verschiedenen Domänen bereits gültige, unterschiedliche digitale Identitäten besitzen (historische Entwicklung, kein Ansatz auf der grünen Wiese). Dies ist die heutige Standardsituation und nicht die Ausnahme Illustration der Herausforderung Die Herausforderungen sollen an zwei konkreten Beispielen kurz illustriert werden. Beispiel 1: International tätige Schweizer Firma: Situation: International tätige Schweizer Firma mit regionalen, selbstständigen IT Organisationen in USA, Grossbritannien und Japan. Die verschiedenen Regionen verfügen bereits über ein eigenes IAM. Ziel: Ein gemeinsames IAM soll aufgebaut werden, bei welchem sämtliche Mitarbeitenden eine einheitliche digitale Identität besitzen. Herausforderungen: Konsolidierung der digitalen Identitäten: Mehrere Mitarbeitenden arbeiten mit ihren IT Hilfsmitteln in verschiedenen Regionen. Sie verfügen jeweils lokal in diesen Regionen bereits über eine digitale Identität. Diese wurde nach regionalen Richtlinien erstellt. Wie können diese unterschiedlichen digitalen Identitäten konsolidiert werden? Rollen/Funktionen, Authentisierung, Authentifizierung, Access Control: Auf Grund der regionalen Hoheit für die Erstellung von Berechtigungen gibt es kein globales Berechtigungskonzept. 72/101

73 Wie könnte es gelöst werden, dass ein Manager aus der Schweiz, wenn er lokal in Japan ist, sein Notebook ans lokale Firmennetzwerk einstecken und auf seine Ressourcen wie , Internet oder lokale Drucker in Japan zugreifen kann? Beispiel 2: Zusammenarbeit unter Verwaltungsdomänen: Situation: In einem Kanton gibt es verschiedene Verwaltungsdomänen mit eigener IAM- Informatik Infrastruktur, z.b. für die Staatsverwaltung, für die Gemeinden, für das Gesundheitswesen (Spitäler). Anzustrebendes Ziel: Subjekte sollen sich mit einer digitalen Identität sicher authentisieren können, unabhängig davon, welche Rolle sie haben, z.b. als Angestellter der Staatsverwaltung, als Angestellter einer Gemeinde oder als Angestellter im Gesundheitswesen. Ebenfalls müsste es z.b. möglich sein, dass ein Bürger des Kantons sich als Patient im Spital in der Domäne Gesundheitswesen sicher authentisieren kann. Der Bürger könnte gleichzeitig auch Angestellter der Staatsverwaltung oder der Gemeinde sein. Herausforderungen: Konsolidierung der digitalen Identitäten: Mitarbeitende in den verschiedenen Domänen besitzen oft bereits heute in verschiedenen Domänen eine digitale Identität, welche nicht nach einheitlichen Kriterien gebildet worden ist. Das Gleiche gilt für Bürger oder Patienten. Rollen/Funktionen, Authentisierung, Authentifizierung, Access Control: In den verschiedenen Domänen gibt es keinen einheitlichen Ansatz für Rollen/Funktionen. Ebenfalls sind die Authentifizierungsmethoden sowie der Access Control Prozess nicht vereinheitlicht Lösungsansatz Damit sich Subjekte in einer Domäne eindeutig authentisieren können, müssen sie ihre Identität gegenüber der Domäne ausweisen. Die Authentifizierung setzt voraus, dass die Identität von Subjekten in einem Verzeichnis des Identity Providers als digitale Identität registriert ist. Nur so ist es möglich die Authentifizierung mit Hilfe der digitalen Identität durchzuführen. In den oben beschriebenen Beispielen (Kapitel ) besitzen die Subjekte bereits eine digitale Identität. Im ersten Fall (international tätige Schweizer Firma) existieren diese Identitäten bereits in den jeweiligen regionalen Zentren. Im zweiten Fall (Zusammenarbeit unterschiedlicher Verwaltungsdomänen) existieren diese Identitäten jeweils in den lokalen Domänen. Es gibt nun verschiedene Möglichkeiten, wie die damit einhergehenden Herausforderungen gemeistert werden können: 73/101

74 Gemeinsame Vereinbarung über digitale Identität: Die einzubindenden Partner einigen sich auf ein gemeinsames Konzept zur Erzeugung einer gemeinsamen digitalen Identität. Dies bedingt die Festlegung auf einen Identity Provider 18 (ev. einen eigenen). Sämtliche existierenden Identitäten in allen existierenden Umfeldern (in den jeweiligen Verzeichnissen) müssten mit der neuen digitalen Identität des neu festgelegten Providers ergänzt werden. Für neue Subjekte würde ausschliesslich die neue gemeinsame digitale Identität verwendet. Multiple digitale Identitäten: Die einzubindenden Partner einigen sich darauf, dass Subjekte einer fremden Domäne ihre existierende digitale Identität auch innerhalb von Partnerdomänen registrieren können, d.h. im jeweiligen Verzeichnis wird der Eintrag des Subjekts mit einer weiteren digitalen Identität ergänzt. Meistens (jedoch nicht zwingend) bedeutet dies auch, dass die beiden Domänen unterschiedliche Identity Provider haben. Die beiden Ansätze sind gar nicht so verschieden, braucht es doch bei beiden einen entsprechenden Registrierungs- bzw. Konsolidierungsprozess in den jeweiligen lokalen Verzeichnissen der Identitätsverwaltung. Der Registrierungsprozess stellt eine besondere Herausforderung dar für Subjekte, welche bereits in den jeweiligen Domänen mit unterschiedlichen digitalen Identitäten existieren. Für diesen Abgleichprozess gibt es kein Patentrezept. Allenfalls können Konsolidierungsservices helfen ähnliche Identitäten zu identifizieren. So ist es z.b. mit grösster Wahrscheinlichkeit möglich Subjekte (Bürger der Schweiz) mit Hilfe des vollständigen Namens, des Geburtsdatums und des Heimatorts eindeutig zu identifizieren. Ein Konsolidierungsprozess verlangt immer eine nachvollziehbare Freigabe durch die Konsolidierungsverantwortlichen der beteiligten Domänen. Es gibt aber noch eine weitere Möglichkeit ohne lokale Registrierung: Vertrauen in bestimmte digitale Identitäten: Eine Domäne kann z.b. festlegen, dass sie digitalen Identitäten bestimmter Identity Provider vertraut, ohne selbst einen Eintrag in einem IAM vorzunehmen (keine lokale Registrierung). Damit die Autorisierung überprüft werden kann ist erforderlich, dass die Claims des Subjekts bekannt sind oder abgefragt werden können, wie dies im Prozess Access Control im Kapitel schematisch erklärt wurde. Hier könnten folgende Ansätze gewählt werden: Gemeinsamer Claims Assertion Service (CAS) im Verbund: Die Partner einigen sich auf einen von den Domänen unabhängigen CAS. Dieser stellt Claims zu Subjekten in der gewünschten Form zur Verfügung. Der CAS könnte von allen Partnern im Domänenverbund verwendet werden um z.b. Funktionen oder Rollen von Subjekten in Erfahrung zu bringen. Pflegen von lokalen Claims: Bei der Registrierung werden z.b. die Autorisierungsattribute im lokalen IAM eingepflegt. Dies können dann als lokale IAM Abfrage ausgewertet werden. 18 Theoretisch könnte man sich auf mehrere Identity Provider einigen. 74/101

75 Anmerkung: Die Verwendung von Identitäten von Subjekten in unterschiedlichen Domänen wird auch als Account Linking bezeichnet (siehe Kapitel 8.7.2) Identifikatoren Credentials Identifikatoren, wie sie im Kapitel 4.4 eingeführt wurden, helfen im Umgang von digitalen Identitäten. Der Identifikator hilft z.b., dass digitale Identitäten einfacher gefunden oder verglichen werden können. In unterschiedlichen Domänen können digitale Identitäten unterschiedliche oder sogar gar keine Identifikatoren haben. Oft wird als Identifikator auch die Sozialversicherungsnummer verwendet, was jedoch aus Sicht des Datenschutzes eine artfremde Verwendung ist und deshalb nicht erlaubt ist. Identifikatoren sind ein Bestandteil der digitalen Identität, wie im Informationsmodell (Kapitel 7.1) dargestellt. Sie werden nie separat behandelt. Die Einbindung in andere Domänen erfolgt immer zusammen mit der digitalen Identität eines Subjekts, wie in Kapitel erklärt. Anmerkung: Identifikatoren sind ein wichtiges Hilfsmittel, wenn digitale Identitäten von Subjekten in unterschiedlichen Domänen verwendet werden (siehe auch Account Linking im Kapitel 8.7.2). Credentials einer digitalen Identität eines Subjekts erlauben dessen eindeutige Identifikation (siehe Kapitel 4.12). Die Authentifizierung erfolgt mit Hilfe der Credentials, welche vom Credential Provider (siehe Kapitel ) ausgegeben worden sind. Credentials sind wie Identifikatoren ein Bestandteil der digitalen Identität, wie im Informationsmodell (Kapitel 7.1) dargestellt. Sie werden nie separat behandelt. Die Einbindung in andere Domänen erfolgt immer zusammen mit der digitalen Identität eines Subjekts Zugriffsregeln Zugriffsregeln auf Ressourcen werden von deren Ressourcenverantwortlichen definiert (siehe Begriffe Kapitel 4.21 und IAM Metamodell Kapitel 7.1). Da die Verwaltung von Ressourcen nicht so einheitlich geregelt ist wie die Verwaltung von Subjekten, können Zugriffsregeln von Ressourcen auch an verschiedenen Orten (z.b. in einem IAM Verzeichnis oder in einem Konfigruationsmanagementverzeichnis) abgelegt sein. Oft sind Zugriffsregeln heute auch noch direkt in Anwendungsprogrammen ausprogrammiert, was eigentlich eine Verletzung von good Practices in der Programmierung darstellt. In dieser Lösungsarchitektur wird vorgeschlagen, dass Ressourcen strikt in einem IAM Verzeichnis verwaltet werden inklusive deren dazugehörenden Zugriffsregeln. Nur so 75/101

76 Claim ist garantiert, dass Zugriffsregeln auf einheitliche Art und Weise in den Domänen zur Verfügung stehen. Tritt eine Ressource als Subjekt auf (siehe Abbildung 22), z.b. wenn sie einen andern Service verwendet, kommen die Zugriffsregeln der Zielressource zur Anwendung. Die aufrufende Ressource, in diesem Fall als das Subjekt, verwendet ihre Credentials zur Authentisierung bzw. ihre Claims zur Autorisierung. Zwischen Domänen ist keine Abbildung von Zugriffsregeln notwendig. Die Verantwortung für die Autorisierungsüberprüfung liegt immer bei der Zieldomäne bzw. bei den dort vorhandenen Ressourcen und deren Ressourceneigner. Claims gehören zur digitalen Identität. Sie enthalten beglaubigte Eigenschaften eines Subjekts (siehe Kapitel 4.9), z.b. die Rolle oder Funktion eines Subjekts (siehe Kapitel 7.4). Claims sind wie der Identifikator ein Bestandteil der digitalen Identität, wie im Informationsmodell (Kapitel 7.1) dargestellt. Sie werden nie separat behandelt. Die Einbindung in andere Domänen erfolgt immer zusammen mit der digitalen Identität eines Subjekts, wie im Kapitel erklärt Access Control Modelle IAM hat nicht nur mit Identity Management sondern, wie der Buchstabe A bereits impliziert, auch mit Access Management zu tun. Es ist deshalb angebracht die verschiedenen Access Control Modelle genauer zu betrachten. RBAC: Role Based Access Control: Bei diesem Modell erfolgt die Autorisierungsüberprüfung eines Subjekts an Hand seiner Rolle(n) oder Funktion(en), d.h. nicht direkt auf Grund seiner Identität. Der Ressourceneigner bestimmt welche Rollen oder Funktionen auf seine Ressourcen in welcher Art und Weise Zugriff haben. ABAC: Attribute Based Access Control: Die Idee attributbasierter Zugriffskontrolle besteht darin, Zugriffsrechte zwischen den Subjekten und Ressourcen nicht statisch zu definieren, sondern ihre Eigenschaften oder Attribute dynamisch als Grundlage der Autorisierung zu nutzen. Dabei kann es sich um allgemeine Eigenschaften wie beispielsweise die Position des Benutzers im Unternehmen handeln, aber auch um Attribute wie Alter oder aktuelle Kreditwürdigkeit. Attribute können, im Gegensatz zu eher statisch definierten Rollen, sehr dynamisch sein und werden jeweils realtime von einem Claim Assertion Provider nachgefragt, resp. bestätigt. RBAC ist eine Art Subset des weiter gefassten ABAC. DAC: Discretionary Access Control: Bei diesem Modell erfolgt die Autorisierungsüberprüfung eine Subjekts direkt an Hand seiner Identität, d.h. der Ressourceneigner bestimmt individuell pro Subjekt die Art und Weise des Zugriffs auf eine bestimmte Ressource. 76/101

77 MAC: Mandatory Access Control: Hier bestimmen die Ressourceeigner notwendige Eigenschaften, welche ein Subjekt für den Zugriff auf die Ressource zwingend aufweisen muss. Ein Beispiel dafür ist die Dokumentenklassifizierung mit Klassen wie Öffentlich, Vertraulich, Geheim. Die Zugriffsregel kann dann z.b. lauten, dass nur Subjekte, welche geheime Dokumente lesen dürfen, auch Zugriff auf diese geheimen Dokumente haben. Im Umfeld von E-Government IAM wird in der Regel ein RBAC oder ein ABAC Modell eingesetzt. Das RBAC/ABAC Modell kann bei Bedarf durch MAC Eigenschaften praktisch beliebig ergänzt werden. Beispiel: In einem Medizinportal gibt es Services, wo alle Ärzte darauf zugreifen dürfen. Einige dieser Services sind jedoch speziell geschützt, da sie nur lokal (d.h. nicht via Internet) verwendet werden dürfen (z.b. für Administratoren). Der Nachweis, ob ein Subjekt Arzt ist, kann über ein Claim eines vertrauensvollen Arztregisters erfolgen. Die Feststellung, ob der Service vom Internet oder von einem lokalen Benutzenden erfolgt, ist eine Eigenschaft, welche der Service selbst herausfinden kann (siehe dazu auch WAYF in Kapitel 8.7.3). Anmerkungen: In dieser IAM-Lösungsarchitektur werden Rollen, wie auch weitere Attribute eines Subjekts als Claims (Claimsets) möglichst von einem Claimprovider zur Verfügung gestellt. Die Claims eines Subjekts können bei einem intern vorhandenen IAM auch direkt von diesem IAM Verzeichnis z.b. via LDAP zur Verfügung gestellt werden. Prinzipiell ist dies nichts anderes als wie die Abfrage von Claims bei einem Claimprovider. Das Entwickeln von durchgängigen Rollenmodellen für ein bestimmtes Umfeld stellt eine besondere Herausforderung dar, welche einerseits mit der Sache an sich sowie ganz entscheidend mit der dafür notwendigen Governance zu tun hat. Als Faustregel gilt, weniger ist mehr, d.h. beim Rollendesign soll man sich auf Schwerpunkte konzentrieren. Oft müssen für die Umsetzung von Rollenmodellen in einer Firma oder in einer Verwaltungseinheit bestehende Strukturen überarbeitet werden, um die daraus geeigneten Rollen (Funktionen) herleiten zu können. 77/101

78 8. Lösungsansätze Interdomänenstrukturen H Architecture Change Management Prelim: Framework And Principles A Architecture Vision B Business Architecture Für E-Government IAM gibt es nicht einen allumfassenden Ansatz, welcher jeder Situation gerecht wird und überall identisch verwendet werden kann. In diesem Dokument werden deshalb mögliche IAM Lösungsansätze aufgezeigt, welche vor allem den engeren oder loseren Verbund von Domänen ansprechen. G Implementation Governance F Migration Planning Requirements E Opportunities and Solutions C Information System Arch. D Technology Arch. Anmerkung zur Methode: Die Lösungsansätze sind zu verstehen als mögliche Applikationsarchitektur im Sinn der TOGAF ADM Phase C Informationssystem- Architektur IAM in einer Domäne In einer Domäne soll mit Hilfe von IAM ein zentrales Identitäts- und Access Management für die Einbindung verschiedener Zielsysteme aufgebaut werden. Ebenfalls will man erreichen, dass Subjekte (Mitarbeitende) sich nur einmal am System anmelden müssen (SSO Single Sign-On). Dies ist der triviale Fall und die Situation, wie sie heute in vielen Firmen oder in Verwaltungsdomänen anzutreffen ist. Vorteile: Klare Organisation, Zuständigkeiten und Governance Zentraler, umfassender IAM-Ansatz Grosse Effektivität und Effizienz Nachteile: Keine Unterstützung für Föderation Herausfordernde Einbindung von Partnern, z.b. müssen Subjekte von anderen Domänen im Domänen-IAM separat registriert werden. Verlangt von den partizipierenden Teilnehmern ein gewisses Mass an Flexibilität. Könnte z.b. bedeuten, dass alle Subjekte eine neue digitale Identität, neue Benutzernamen etc. bekommen. HR 5 Mitarbeitende Domäne SSO 1 Neuer MA ID Identity Provider Appl-1 Windows AD SAP andere Appl. 2 4 HR 3 IAM Domäne IAM Verwaltung IAM Directory Abbildung 37: IAM in einer Domäne 78/101

79 Die einzelnen Schritte für die Registrierung, Identitätserstellung und die Verteilung der digitalen Identität an den Benutzer sind als Beispiel in Abbildung 37 dargestellt: 1. Der Personaldienst (HR) stellt einen neuen Mitarbeiter ein. Dieser hat eine bestimmte Rolle / Funktion. 2. Die digitale Identität wird vom Identity Provider erstellt. 3. Im IAM der Domäne, bestehend aus einem Verwaltungsteil und einem Directory, wird der Mitarbeitende eröffnet gemäss den Regeln für die Domäne. Er erhält die digitale Identität vom Identity Provider. Seine Claims werden abgeleitet aus seiner Rolle / Funktion und als Attribut zu seiner digitalen Identität im IAM gespeichert. 4. Die Benutzerinformationen und seine Claims werden vom IAM an alle angeschlossenen Zielsysteme propagiert, z.b. zu Appl-1, Windows AD, SAP und andere Applikationen. 5. Der neue Mitarbeitende erhält auf dem für die Verteilung von Credential vorgesehenen Weg seine Credentials. Ein Benutzer kann nun seine Credentials verwenden um sich zu authentisieren (SSO - Single Sing-On). Seine digitale Identität (ID) ist innerhalb der Domäne bekannt. Diese IAM Form ist typisch für kleiner Firmen oder einzelne Verwaltungsdomänen welche beschliessen, innerhalb ihres Umfelds ein zentrales IAM zur Verwaltung von Subjekten und Ressourcen anzulegen. Oft ist damit auch der Wunsch nach einer einheitlichen Single Sign-On Lösung verbunden. Das IAM System, bestehend aus einem Verwaltungs- und einem Verzeichnisteil dient zur Integration der verschiedenen unabhängigen Verzeichnisse. Im IAM System werden über entsprechende Adapter Benutzerverzeichnisse wie z.b. Active Directory, SAP Directory oder individuelle Benutzerverzeichnisse von Anwendungen integriert. Ebenfalls können Ressourcenverzeichnisse integriert werden (z.b. Konfigurationsmanagement Datenbank). Man unterscheidet in der Regel zwischen Quellsystemen (Lieferanten von digitalen Identitäten, z.b. das HR System) und Zielsystemen (z.b. Active Directory, SAP Directory). Die Adapter in heutigen IAM Produkten sind sehr intelligent und lassen sogar eine bidirektionale Integration zu, wenngleich dies aus Gründen der einzuhaltenden Prozesse (Legislative) nicht immer erlaubt sein soll (siehe auch Kapitel ). Bei der Realisierung dieser Variante auf der grünen Wiese können im IAM Konzept alle Belange wie Governance, notwendige Prozesse, digitale Identität, Identity Provider, Claims, Anbindung von Quell- und Zieldirectories, Single Sign-On etc. von Grund auf konzeptionell durchgängig erarbeitet werden. Bei der Realisierung in bestehenden Umfeldern ist die Realisierung etwas aufwendiger, ist doch oft nicht einmal die bestehende IST Situation (Baseline) vollständig klar und muss zuerst analysiert werden. Die Integration der verschiedenen Zielumgebungen wie z.b. Active Directory, SAP oder Anwendungen ist vergleichbar mit der Thematik der domänenübergreifenden IAM Herausforderung, wie sie in Kapitel über föderierte Domänen ausführlich beschrieben worden ist. Dabei können die einzelnen existierenden Zielsysteme/Anwendungen als separate Domänen aufgefasst werden. Ebenfalls existieren oft unterschiedliche Identity Provider in einem beschränkten Umfeld, z.b. HR (Personaldienst) für interne Mitarbeitende oder einzelne Abteilungen für externe Mitarbeitende. 79/101

80 Besteht die Absicht domänenfremde Subjekte ebenfalls zu integrieren, müssen diese lokal registriert werden und eine digitale Identität haben IAM im losen Domänenverbund Wird IAM über einen losen Domänenverbund realisiert, bedingt dies entsprechende Absprachen zwischen den Domänen. Ein möglicher Ansatz dazu ist Shibboleth 19. Vorteile: Pragmatischer Ansatz. Dank ähnlichen Organisationsformen können digitale Identitäten und Rollen unter den Partnerdomänen rasch definiert und etabliert werden. Für einfache, klar strukturierte Domänenverbunde geeignet (z.b. Universitäten, Schulen, Fachhochschulen, ) Ist relativ schnell umsetzbar Nachteile: Nicht geeignet für Domänen mit stark unterschiedlichen Organisationsformen Nicht geeignet für Domänen mit erhöhter Sicherheitsanforderung, da sich dann die Beschreibung und Sicherstellung des gegenseitigen Vertrauens (Trust) nicht effektiv und effizient umsetzen lässt. Benutzende Domäne A Domäne B HR 5 SSO Zugriff auf Ressource in Domäne B 1 Neuer MA ID Appl-1 Windows AD SAP andere Appl. Appl-B1 HR 3 4 IAM Domäne IAM Verwaltung Trust IAM Domäne B 2 IAM Directory Trust Trust Identity Provider Verzeichnis der Rollen im Verbund Gemeinsame Policies Abbildung 38: IAM in über mehrere Domänen mit gemeinsamen Policies In der Architektur, wie sie in Abbildung 38 gezeigt wird, haben sich verschiedene Domänen auf ein gemeinsames Format der digitalen Identität geeinigt (in dieser Abbildung durch einen gemeinsamen Identity Provider dargestellt). Ebenfalls haben sie sich auf ein Standardset gemeinsamer Rollen geeinigt. Es kann deshalb von klar definierten Trust-Verbindungen zwischen den einzelnen Domänen gesprochen werden. 19 Details siehe: 80/101

81 Innerhalb der einzelnen Domänen wird davon ausgegangen, dass bereits ein domäneninternes IAM umgesetzt ist, wie er im Ansatz in Kapitel 8.1 beschrieben ist. Die Schritte zur Erlangung der digitalen Identität sind identisch wie im dort beschriebenen Beispiel für eine einzelne Domäne. Will der Benutzer aus Domäne A eine Ressource in der Domäne B verwenden, kann seine digitale Identität gemäss der Vereinbarung zwischen den Domänen verwendet werden. Er authentisiert sich mit seinen Credentials in seiner Heimatdomäne A. Seine Claims werden an die Zieldomäne B propagiert. Dort wird seine Autorisierung (Standardset von Rollen zwischen den Domänen und Abgleich mit den Zugriffsregeln der gewünschten Ressourcen) verifiziert und es wird über den Zugriffs entschieden IAM im Verbund mit Masterdomäne In grösseren Organisationen gibt es oft eine hierarchisch organisierte Struktur von Domänen. Ein möglicher Aufbau für IAM ist in Abbildung 39 gezeigt. Vorteile: Klare und einfach zu verwaltende Hierarchien (Zuständigkeiten) im IAM-Verbund Einheitliche IAM-Architektur über alle Domänen Gemeinsamer Identity Provider und gemeinsame digitale Identität für alle Domänen Trotz Verbund grosse Autonomie der Domänen Masterdomäne ermöglicht den effizienten und effektiven Übergang zwischen den Domänen Nachteile: Gemeinsame Teile der Architektur brauchen entsprechende Koordination Der Architekturzusammenschluss bewirkt auch weitere konzeptionelle Voraussetzungen, vor allem in Bezug auf das gegenseitige Vertrauen (Trust) Das Verlinken der Directories im Master IAM erhöht das Sicherheitsrisiko, falls die begleitenden Sicherheitsmassnahmen (z.b. Delegation der Administrationshoheit) nicht durchgängig umgesetzt werden. Mitarbeitende Domäne A Domäne B HR 5 SSO 1 Neuer MA Appl-1 Windows AD SAP andere Appl. HR 3 4 IAM Domäne IAM Verwaltung Trust IAM Domäne B 2 IAM Directory Trust Trust Identity Provider IAM Domäne A IAM Domäne B IAM Domäne C Master IAM Masterdomäne Abbildung 39: IAM im Verbund mit Masterdomäne 81/101

82 Typisch für diese Organisationsform ist die Unabhängigkeit der einzelnen Domänen. Trotzdem beabsichtigt die Gesamtorganisation mit Hilfe einer Masterdomäne einheitliche digitale Identitäten innerhalb des gesamten Verbunds zu verwenden. Wie sich die verbundenen Domänen gegenseitig vertrauen ist über Trust-Vereinbarungen formell festgelegt. Operationen zwischen den Domänen entsprechen diesen Trust- Vereinbarungen. Mit dem in Abbildung 39 gezeigten Ansatz wird als Beispiel die Einstellung eines Mitarbeitenden in der Domäne A gedanklich durchgespielt: 1) Der Personaldienst (HR) von Domäne A stellt einen neuen Mitarbeiter ein. Dieser hat eine bestimmte Rolle / Funktion (in der Domäne A). 2) Die digitale Identität wird vom Identity Provider der Masterdomäne erstellt. 3) Im IAM der Domäne A (bestehend aus einem Verwaltungsteil und einem Directory) wird der Mitarbeitende eröffnet gemäss den für die Domäne geltenden Regeln. Der Mitarbeitende erhält seine digitale Identität vom Identity Provider. Seine Claims werden aus seiner Rolle / Funktion in der Domäne A abgeleitet und als Attribut zu seiner digitalen Identität im IAM der Domäne A gespeichert. 4) Die Benutzerinformationen und seine Claims werden vom IAM an alle in der Domäne A angeschlossenen Zielsysteme propagiert, z.b. zu Appl-1, Windows AD, SAP und zu weiteren Applikationen. 5) Der neue Mitarbeitende (Subjekt) erhält seine digitale Identität (auf sicherem Weg). Anmerkungen: In der Masterdomäne befindet sich in diesem Beispiel ein Verzeichnis aller verlinkten Domänen IAMs, angedeutet als Master IAM. Über dieses Masterverzeichnis wäre es möglich sämtliche Subjekte und deren digitale Identitäten in allen angeschlossenen IAM zu finden, geeignete Berechtigung vorausgesetzt. Die Masterdomäne könnte z.b. mit den digitalen Identitäten von allen Subjekten ergänzt werden, d.h. die Identitäten würden nicht nur im domänen-lokalen IAM, sondern ebenfalls in der Masterdomäne gespeichert (nur die Identitäten selbst, keine zusätzlichen Claims). Dieses Beispiel geht davon aus, dass jede Domäne einen IAM Ansatz wie im Kapitel 8.1 verfolgt. Die Transition von einem allfällig bestehenden Umfeld ohne Domänen- IAM wird hier nicht speziell erwähnt. Im Unterschied zur Konsolidierungsaufgabe einer einzelnen Domäne mit der Integration einzelner Quell- und Zielsysteme müssen in diesem Fall verschiedene IAM Systeme integriert werden. Die besonderen Herausforderungen ist die föderierte Integration, wie sie Kapitel detailliert beschrieben ist. Es ist jedoch durchaus möglich, dass lokale Identitäten weiter verwendet werden und 82/101

83 Identitäten von Subjekten mittels Identitätsmapping, wie im Kapitel beschrieben, aufeinander abgebildet werden IAM mit Metadomäne Im E-Government Umfeld sind die Domänen der digitalen Identitäten oft föderalistisch verwaltet. Ein möglicher Ansatz ist hier, dass sich die Domänen untereinander selbst organisieren, d.h. es würde jeweils an den Partnern liegen, miteinander bilaterale Verträge zwischen den jeweiligen Domänen dafür abzuschliessen. Dies würde aber mit zunehmender Anzahl Domänen eine grosse Komplexität mit sich bringen, wie in Abbildung 40 mit 4 Domänen und 4 Registern schematisch dargestellt ist: Domäne A Domäne B Domäne C Domäne D SuisseID Service Provider Register X Register Y Register Z Abbildung 40: Herausforderungen 4 Domänen, Register Im Beispiel von Abbildung 40 haben 4 Domänen (jede zu jeder) eine Beziehung. Total resultieren 6 Beziehungen. Jede der Domänen hat zu jedem Register eine Beziehung, d.h. 4 pro Domäne insgesamt 16 Beziehungen. Für alle Domänen und Register zusammen wären somit 22 Beziehungen formell zu spezifizieren. Der hier vorgeschlagene Metadomänen-Ansatz hilft die Anzahl notwendiger Beziehungen zu reduzieren. Die einzelnen individuellen Domänen verwenden eine übergeordnete Domäne (Metadomäne) mit welcher jede dieser Domäne eine Vertrauensbeziehung eingeht. Das Prinzip dieses Verbunds mit Hilfe einer Metadomäne ist in Abbildung 41 dargestellt Vorteile: Föderativer Ansatz, gebildet durch gemeinsame Absprache im Domänenverbund. Dieser Ansatz ist verwandt mit dem Masterdomänenansatz, jedoch verlangt deren Umsetzung keine so enge Kopplung, wie der Masterdomänen Ansatz. Optimal für grosse / komplexe E-Government IAMs da nur wenige Trustbeziehungen definiert 83/101

84 werden müssen. Nachteile: Metadomäne muss nach Absprache des Domänenverbunds systematisch für eine konkrete Umgebung entwickelt werden. Verfügbarkeit der Metadomäne muss gewährleistet sein. Es braucht einen Betreiber für die Metadomäne. Subjekt Ressource Subjekt Ressource Zugriffsregel Zugriffsregel Credential Digitale Identität Claim Credential Digitale Identität Claim Identifikator Domäne A Identifikator Domäne B trust trust Service Schnittstelle Metadomäne Dokumente DMS für Ablage Web-Auftritt Services für Formatdefinitionen Semantikregeln Konsolidierung Verbund Services Services für Management / Betrieb der Metadomäne Management Services Domäne A Domäne B Domäne n Verzeichnis Id Verzeichnis Verzeichnis Verbund CAS IdPs Dokumentation Metadirectory Abbildung 41: Metadomäne mit Serviceschnittstelle und Metadirectory Die Metadomäne enthält nebst dem Verzeichnis aller mit ihr vertraulich verbundenen Domänen, auch Regeln (Policies) für das Verhalten innerhalb des Verbunds. Die Policies spezifizieren beispielsweise: den Sicherheitslevel der verschiedenen eingebundenen Domänen sowie die formelle Beschreibung der untereinander verabredeten Vertrauensbeziehung, welche Identity Provider (Verzeichnis IdPs) anerkannte Aussteller für Identitäten sind, ein Verzeichnis von vertrauenswürdigen Claim Providern (Verzeichnis CAS), das Format von digitalen Identitäten und dazugehörenden Attributen, das Format des Identifikators, das Format von Zugriffsregeln, welche Credentials verwendet werden sollen, sowie deren möglichen Formate inklusive secure propagation zwischen den Domänen, wie Claims gebildet werden und wie sie verwendet werden können. Die Metadomäne wird auch ein minimales Set von Regeln und Konventionen definieren, welche die teilnehmenden Domänen zwingend einzuhalten haben. Diese Regeln 84/101

85 stehen auch in geeigneter Form elektronisch zur Verfügung (Dokumentenmanagement, Web-Seiten). Die Metadomäne bietet auch einen oder mehrere CAS (Claim Assertion Service), um gewisse Informationen aus der Metadomäne als Claims zur Verfügung zu stellen. Abbildung 42 zeigt die gleiche Situation wie in Abbildung 40, jedoch mit dem Konstrukt einer Metadomäne: Domäne A Domäne B Domäne C Domäne D SuisseID Service Provider trust trust trust trust Register X Register Y Register Z trust trust trust trust Service Schnittstelle Metadirectory Domäne A SuisseID Domäne B Register X Domäne C Register Y Domäne D Register Z Metadomäne Dokumentation Verbund Services Management Services Abbildung 42: Metadomäne mit 4 Domänen und 4 Registern Wie in Abbildung 42 erkennbar ist, reduzieren sich die notwendigen Vertrauensbeziehungen (Trusts) auf 8 im Vergleich zu 22 ohne Metadomänenansatz für die gleich grosse Anzahl von Domänen und Registern. In diesem Beispiel interessiert nicht, ob die einzelnen Domänen einen lokalen IAM Ansatz verfolgen. Hingegen interessiert z.b. welchen Identity Provider sie für digitale Identitäten von Subjekten verwenden und wie deren digitale Identität oder deren Claims aussehen, da ja die entsprechende Metainformation im Metadirectory gespeichert werden soll. Auch hier gibt es die besondere Herausforderung der föderierten Integration, wie sie Kapitel detailliert beschrieben ist. Möglich wäre z.b. das im Kapitel beschriebene Identitätsmapping im Metadirectory durchzuführen. Dies hätte unter Umständen den Vorteil, dass das Mapping immer nach standardisierten Ansätzen erfolgen könnte Services der Metadomäne Die Informationen zu digitalen Identitäten sowie dem Verzeichnisverbund der verschiedenen Domänen werden in der Metadomäne in einem Directory abgelegt. Dort können z.b. Domänen eingetragen und verwaltet werden. Ebenfalls kann das Metadirectory ein Verbundsdirectory der digitalen Identitäten (Verzeichnis Id Verbund) enthalten, um z.b. die Föderation von digitalen Identitäten in verschiedenen Domänen zu unterstützten. 85/101

86 Das Metadirectory ist meistens ein streng hierarchisch organisiertes Verzeichnis (siehe Kapitel 7.2.1). Es kann nach verschiedenen Ansätzen erstellt werden. Eine mögliche Implementierung ist in Abbildung 43 schematisch dargestellt: root Verzeichnis IdPs Verzeichnis CAS Verbund-ID (ID-Mapping) konsolidierte ID X ID X in A ID X in B ID X in n konsolidierte ID Y ID Y in A ID Y in B ID Y in C Verbund Domäne A Domäne B Domäne n konsolidierte ID Abbildung 43: Metadirectory Struktur Auf der obersten Stufe befinden sich in diesem Beispiel die Verzeichnisse der Vertrauensvollen Identity Provider (IdPs) und Claim Assertion Services (CAS), das Verbund- ID Verzeichnis mit den konsolidierten IDs im Verbund und das Verbunddirectory mit dem Verzeichnis der im Verbund eingetragenen Partner Weiter mögliche Varianten In den vorangegangenen Kapiteln wurden die IAM Varianten schematisch aufgezeigt. Möglich sind auch Kombinationen dieser Varianten, z.b. die Integration von Variante 8.1 IAM in einer Domäne mit dem Metadomänenansatz von Kapitel 8.4 oder sogar die Kombination vom Masterdomänenansatz des Kapitels 8.3 mit dem Metadomänenansatz aus Dokumentation und Dokumentenmanagement sicherstellen Unabhängig von der gewählten Lösungsarchitektur müssen die gemeinsamen Regeln und Policies einer IAM Umgebung in einer geeigneten Dokumentenablage (Repository) abgelegt werden. Diese Ablage könnte ein einfaches Fileablagesystem sein, welches über ein Web-Interface erschlossen ist und allen Subjekten im Domänenverbund zugänglich ist. Empfohlen wird jedoch die Zurverfügungstellung eines Dokumentenmanagementsystems um gewisse minimale Anforderung an das Dokumentenmanagement zu erfüllen. Dazu gehören: 86/101

87 Automatische Versionierung Erzeugen und Signieren von Dokumenten Bearbeiten von Dokumenten Zurückladen eines bearbeiteten Dokuments in einer neuen Version Zusammenführungsunterstützung bei gleichzeitiger Bearbeitung von Dokumenten Transaktionsorientierte Operationen mit sicherem Roll-Back Effiziente Suchfunktionen Mögliche Eingabe von Metainformationen zu einem Dokument Konfigurationsmöglichkeiten für das Verhalten des Managementsystems, z.b. Vorgaben für die Eingabe von Metainformationen Ein Dokumentenmanagementsystem ermöglicht auch die Sicherstellung der Nachvollziehbarkeit gemäss den Vorgaben der Legislative Föderierter Single Sign-On In den Beispielen in diesem Kapitle findet man die Komponente SSO Single Sing- On. Darunter wird im E-Government Umfeld der föderierte Single Sign-On verstanden, welcher in in Abbildung 44 schematisch dargestellt ist: Benutzerinteraktion Web basierte Interaktion Domäne A IdP Internet Benutzende Domäne B Web Portal Domäne C Web Anwendung C Abbildung 44: Föderierter Single Sign-On Im in Abbildung 44 gezeigten Beispiel gibt es einen Identity Provider IdP in der Domäne A, ein Web Portal in Domäne B sowie eine Web Anwendung C in der Domäne C. Ziel ist es, dass ein Benutzender (Subjekt) mit der digitalen Identität, welche er vom IdP (Domäne A) bekommt, am Web Portal der Domäne B anmeldet und ohne sich erneut anzumelden, die Web Anwendung C in der Domäne C verwenden kann. 87/101

88 Single Sing-On kann mit unterschiedlichen Protokollen erreicht werden, z.b. SAML (siehe 9.1.2), Liberty ID-FF (siehe 9.1.4) oder WS-Federation (siehe 9.1.5). In diesem Abschnitt werden die folgenden relevanten Aspekte zum Thema Single Sign-On SSO vertieft: Pull / Push SSO Protokolle Account linking Where are you from (WAYF) Session Management Logout Credential clean-up Global good-bye Account de-linking Pull / Push SSO Pull SSO: Der Benutzende will sich beim Service Provider anmelden. Der Service Provider erfragt das Security Token des Benutzenden beim Identity Provider. Push SSO: Der Identity Provider, ausgelöst vom Benutzenden, schickt ein Security Token mit den Informationen des Benutzenden direkt an den Service Provider. Anmerkung: Bei der SuisseID wird Pull SSO verwendet. Die Abfrage erfolgt über den Browser des Benutzers, welcher die Antwort des Identity Providers freigeben muss Account Linking Benutzende können über verschiedene Identitäten in unterschiedlichen Domänen verfügen. Eine einfache Art diese Identitäten aufeinander abzubilden ist das sogenannte Account Linking. Dazu ist es erforderlich, dass sich die verschiedenen Domänen untereinander auf die Form eines gemeinsamen Identifikators einigen, des sogenannten CUID (Common Unique Identifier). Benutzende erhalten bei der Registrierung vom Identity Provider einen Identifikator zugesprochen. Damit dieser Identifikator in den verschiedenen Zieldomänen bekannt ist, braucht es einen entsprechenden Registrierungsprozess, d.h. die lokal verwalteten Benutzerdaten müssen mit diesem Identifikator ergänzt werden. Zur Registratur sind unterschiedliche Abläufe denkbar, z.b. persönliches Vorsprechen oder aber Registrierung mit Hilfe eines vorgegeben Ablaufs. Beispiel: E-Government Steueranwendung für einen Steuerpflichtigen (Das Web Portal der Domäne B ist das Gemeindeportal, die Web Anwendung C in der Domäne C entspricht der Steueranwendung). 88/101

89 Annahme: Der Steuerpflichtige hat eine SuisseID (ausgegeben vom IdP der Domäne A). Möglicher Prozesse zur Registrierung der SuisseID für die Verwendung in diesem Zusammenhang: Der Steuerpflichtige erhält zusammen mit den Unterlagen zum Einreichen der Steuererklärung einen Registrierungscode. Dieser Registrierungscode berechtigt zusammen mit weiteren Angaben des Steuerpflichtigen zum interaktiven Registrieren mit der SuisseID. Bei Registrierung für die Verwendung der SuisseID gibt der Steuerpflichtige das Einverständnis, dass seine Claims (Name, Vorname, Geburtsdatum, SuisseID Nummer) vom Claimprovider der SuisseID an das Steueramt übermittelt werden. Ebenfalls gibt der Steuerpflichtige manuell den Registrierungscode ein, welchen er mit den Steuerunterlagen erhalten hat. Anmerkung: Die Registrierung muss in unserem in Abbildung 44 gezeigten Beispiel nur einmal erfolgen, wenn Domäne B und Domäne C ein gemeinsames Benutzerverzeichnis unterhalten. Sonst muss die Registrierung in beiden Domänen separat erfolgen. Der Registrierungsprozess überprüft die Eingaben. Auf Grund des Registrierungscodes kann der Steuerpflichtige im Verzeichnis des Steueramts gefunden werden. Seine SuisseID Nummer kann abgelegt werden. Somit ist der Steuerpflichtige im Steueramtsverzeichnis mit der SuisseID des Steuerpflichtigen verlinkt. Eine andere Möglichkeit zur Registrierung wäre die Verwendung der Pass- oder ID Nummer. Bekanntlich ist der Pass oder die ID das Ausweisdokument, welches bei der Registrierung zur SuisseID vorgelegt werden muss. Diese Nummer wird als Attribut zur SuisseID des Benutzenden abgespeichert und kann jederzeit als Claim abgerufen werden. Hätte das Steueramt Zugriff auf die Ausweisdaten der steuerpflichtigen Person, könnte über die Ausweisnummer des Passes oder der ID die eindeutige Übereinstimmung erreicht werden und somit die Registrierung erfolgen. Denkbar sind natürlich andere, einfacher und teilweise weniger sichere Registrierungsoperationen, um ein Account Linking zu erwirken Where are you from (WAYF) Für gewisse Operationen im föderierten Identitätsmanagement ist es entscheidend zu wissen, von wo sich jemand sich anmeldet. Es kann z.b. sein, dass sich ein Subjekt mit unterschiedlichen digitalen Identitäten beim gleichen Service Provider anmeldet (und registriert). Im Beispiel von Abbildung 44 könnte der Benutzende z.b. einmal sich als Verwaltungsmitarbeiter mit der Verwaltungs-SuisseID, das andere Mal mit seiner privaten SuisseID anmelden. Der Service Provider könnte z.b. mit Hilfe des Organisationeintrags (welcher bei der privaten SuisseID fehlt) feststellen, in welchem Kontext die SuisseID verwendet wird. 89/101

90 Session Management, Logout, Cleanup Wenn ein Subjekt sich erfolgreich bei einem Service Provider anmeldet, entsteht eine lokale Session im Kontext des Subjekts. Diese Session muss die Regeln des Service Providers einhalten. Dieser ist verantwortlich dies zu überwachen, z.b. stellt er die Autorisierung sicher und sorgt dafür, dass ein ordnungsgemässer Session Logout erfolgt. Ebenfalls überwacht er die Aktivitäten und löst z.b. einen time-out Logout aus. Ein Logout muss unter Umständen auch an weitere Services weiter gegeben werden. In unserm Beispiel müsste der Logout auch an die Web-Anwendung C weiter gegeben werden. Zusammen mit dem Logout müssen in den verschiedenen Zielsystemen alle mit der Session verbundenen Aktivitäten aufgeräumt werden (cleanup). Dies gilt besonders z.b. für Hintergrundprozesse, welche mit den Credentials des Benutzenden irgendwelche Aktionen ausführen könnten. Es muss verhindert werden, dass diese z.b. mutwillig in schadhafter Absicht weiter verwendet werden können (Nachvollziehbarkeit). Anmerkung: Zur Autorisierung können z.b. Claims des Subjekts verwendet werden. Natürlich können zwischen Partnern auch Rollen vereinbart worden sein, wie es z.b. der Shibboleth Ansatz vorsieht Global Good-bye Global good-bye beschreibt die Auflösung der Vertrauensbeziehung zwischen einem Identity Provider und einem Service Provider. Damit werden alle Identitäten für den entsprechenden Service Provider ungültig. Falls Account Linking (siehe Kapitel 8.7.2) mit diesem Identity Provider angewendet wurde, müssen diese Links für ungültig erklärt werden (siehe auch 8.7.6). Im Beispiel von Abbildung 44 müssten sämtliche Referenzen des Subjekts in Domäne B und C auf die Domäne A gelöscht werden Account delinking Account delinking ist die Umkehroperation von Account Linking, wie sie im Kapitel erklärt wurde. Dies kann z.b. zur Anwendung kommen, wenn ein Subjekt sich entscheidet, einen anderen Identity Provider zu wählen. Beispiel von Abbildung 44: Ein Benutzer hat bei einer SuisseID von SwissSign (Domäne A) registriert. Aus irgendwelchen Gründen will er zum Identity Provider Quo- Vadis wechseln (nicht Teil der Abbildung). Er beschliesst eine neue SuisseID Nummer zu verwenden. Die alte SuisseID will er jedoch für andere Zwecke weiter verwenden. Er sollte also ein Delinking seiner alten SuisseID bei Domäne B und C durchführen können. 90/101

91 9. Technologie Architektur Prelim: Framework And Principles A Architecture H Vision Architecture Change Management G Implementation Requirements Governance F Migration Planning E Opportunities and Solutions B Business Architecture C Information System Arch. D Technology Arch. Die Technologie Architektur hat zum Ziel, Technologieansätze zu identifizieren welche im föderierten E-Government Umfeld im Bereich IAM zum Einsatz kommen sollen. Dazu gehören: Technologie-Standards im föderierten Identity Management Umfeld Services zur Unterstützung der Föderation im IAM Umfeld 9.1. Wichtige Technologie-Standards im föderierten Identity Management Umfeld SSL/TLS Es sind grundsätzlich die Technologie-Standards gemäss ech-0014 SAGA.ch zu berücksichtigen. Secure Socket Layer (SSL, heute als TLS Transport Layer Security standardisiert) ist der Standard, welcher heute in der Internetkommunikation einen sicheren Kommunikationskanal zwischen Partnern etablieren kann. SSL kann auch im föderativen Identitymanagement verwendet werden, da es mit Hilfe von digitalen Zertifikaten erlaubt, die Datenintegrität und Vertraulichkeit zu sichern. SSL kann sowohl zwischen Browsern und Web-Servern wie auch bei Server-Server Kommunikation verwendet werden. SSL hat aber auch zwei wichtige Nachteile: Granularität: Entweder sind alle Daten einer Session verschlüsselt oder keine. Dies kann z.b. hinderlich sein, wenn die Vertraulichkeit nur für einen Teil der Daten erforderlich ist (Mehraufwand für das Verschlüsseln von nicht besonders schützenswerten Daten). End-to-End: SSL Verschlüsselung erlaubt keine sichere End-to-End Verschlüsselung. Eine SSL Kommunikation ist immer strikt zwischen zwei Partnern. Dies ist z.b. der Fall, wenn in einer DMZ der Datenverkehr zwecks Inspektion nach Malware untersucht werden soll. In diesem Fall endet der sichere Kommunikationskanal in der DMZ und allfällige vertrauliche Daten können (falls sie nicht anderweitig geschützt worden sind) dort eingesehen werden. Web Services Security (siehe Kapitel 9.1.7) kann diesen Mangel umgehen SAML Security Assertion Markup Language SAML (Security Assertion Markup Language) wurde spezifiziert um Hersteller unabhängig Single Sign-on zu ermöglichen. SAML ist ein XML Framework, mit dessen 91/101

92 Hilfe Authentifizierungs- und Autorisierungsinformationen ausgetauscht werden können. SAML wurde von einem internationalen Konsortium 20 entwickelt. Heute hat SAML im OASIS Umfeld ein eigenes Wiki unter Dort findet man auch die aktuelle Spezifikation. SAML besteht aus zwei Teilen: SAML Assertions: Eine SAML Assertion ist ein XML Token, welches die digitale Identität plus optional zusätzliche Attribute eines Subjekts enthält. Dieses Token wird normalerweise auf Anfrage eines vertrauensvollen Service Providers vom Identity Provider erstellt. Im SuisseID Umfeld geht diese Anfrage über das Subjekt, welches erlauben muss, dass dieses Token an den Service Provider übermittelt wird. SAML Binding and Profile: Angaben über das eingesetzte Protokoll (SAML 1.0, 1.1, 2.0) Shibboleth Shibololeth ist mit SAML verwandt, stammt jedoch aus dem Hochschulsektor. Shibooleth verwendet Teile des SAML Protokolls erweitert um Eigenschaften, welche vor allem im Hochschulumfeld von Bedeutung sind, z.b. Where are You From? um herauszufinden, von welcher Hochschule jemand kommt. Dadurch können z.b. sowohl Push- wie Pull 21 -basierte Single Sign-On Protokolle unterstützt werden. Im Shibboleth Umfeld gibt es strikte Regeln, z.b. für die Rollenzuweisung (ob jemand die Rolle Student oder Professor hat) Liberty Alliance Das Projekts Liberty Alliance hatte zum Ziel eine föderative Single Sign-On Lösung für das Internet zu entwickeln und zur Verfügung zu stellen, welche sowohl für Privatpersonen wie auch für Geschäftskunden geeignet ist. Das Framwork Liberty Identify Framework, ID-FF 22 beschreibt die Funktionalität, welche über diese ursprüngliche Idee hinausgeht. Das Projekt wurde übergeführt in die Kantara Initiative Web Services-Federation Web Services (WS)-Federation 24 wurde von IBM, Microsoft, VeriSign und RSA zusammen entwickelt. Heute ist die Thematik unter der Obhut von OASIS. 20 Zu diesem Konsortium gehörten: Sun Microsystems, IBM, Nokia und SAP 21 Details zu Single Sign-On siehe Kapitel Details siehe: 23 Details siehe: 24 Details siehe unter: 92/101

93 WS-Federation beschreibt, wie mit den existierenden Security Webservices Föderation inklusive Trust, Single Sign-On (und Single Logout) sowie Attributmapping zwischen unterschiedlichen Plattformen realisiert werden kann. Die eigentliche Spezifikation besteht aus drei Teilen: WS-Federation WS-Federation Passive Client WS-Federation Active Client Web Services-Trust Web Services (WS)-Trust 25 wird verwendet, um das Vertrauen zweier Partner herzustellen. Dazu müssen sie Credentials entweder direkt oder indirekt untereinander sicher austauschen können. Technisch geht es bei Trust um kryptografische Schlüssel und Methoden, um Meldungen zwischen Partnern sicher auszutauschen. Kommunikation: Die Kommunikation soll über SSL Kanäle oder über sichere Webservices (WS-Security) erfolgen. Meldungen: Meldungen sollen verschlüsselt und signiert übertragen werden, um deren Integrität sicher zu stellen. Token: Informationen über Benutzer sollen mit Hilfe eines Security Tokens übertragen werden. Tokens sind Zusatzinformationen, welch z.b. in einer Meldung eingebunden werden können Web Services-Security Web Services (WS)-Security 26 ist per se keine Spezifikation. WS-Security beschreibt, wie ein Webservice Security Token über SOAP (Simple Object Access Protocol 27 ) aussieht. Abbildung 45 zeigt schematisch den Aufbau einer sicheren SOAP Message: 25 Details siehe unter: 26 Details siehe unter: 27 SOAP Spezifikation siehe unter: 93/101

94 Envelope Header Security Element Security Element Security Token Body <application data> Signature Encrypted Data Abbildung 45: WS-Security: SOAP Meldung mit Security Erweiterung im Header Eine derartige SOAP Meldung ist per se fälschungssicher und vertraulich. Der Absender der Meldung steht im Security Token. Versucht jemand diese Meldung zu verändern, ist keine erfolgreiche Signaturprüfung mehr möglich. Damit ist die Integrität der Meldung überprüfbar. Security Tokens werden verwendet, um in einem föderierten Ansatz Single Sign-On umzusetzen, wie er im Kapitel erklärt wird Architektur zur Unterstützung der Föderation im IAM Umfeld Um in einem föderierten Umfeld IAM zu unterstützen, ist eine Reihe von Standard Services erforderlich. Erst dadurch kann eine föderierte IAM Infrastruktur, wie sie im E-Government Umfeld gebraucht wird, effektiv und effizient umgesetzt werden. Abbildung 46 zeigt schematisch einen möglichen Ansatz innerhalb einer Domäne: 94/101

95 Point of Contact (HTTP Reverse Proxy) Browser Client Console Management Services Browser Client Session Management Service Authentication Service Identity federation run-time SSO Protocol Service Trust Services STS Key Services (Key encryption, Signing) Protected Ressources Web Server Application Web Services Gateway Alias Service WS-Trust Handler Service WS Client Application Server WS Handler Provisioning Services Authorization Service Identity Management Service LDAP User Registry Web Service Application Abbildung 46: Föderierter IAM Service Architektur 28 Die einzelnen Komponenten dieser Architektur sind: HTTP Point of Contact (Browser) In dieser Umgebung erfolgt die Authentifizierung und das Session Management (siehe Kapitel 8.7.4). Authentifizierung: Hier werden die Credentials des Subjekts verifiziert. Möglich sind z.b. username/password, secure ID, X.509 Zertifikate oder natürlich das SuisseID Authentisierungszertifikat. Die Validierung der Credentials kann z.b. über einen Identityprovider (z.b. bei der SuisseID) oder über ein lokales LDAP Verzeichnis erfolgen. In föderierten Umgebungen erfolgt die Authentifizierungsüberprüfung in der Regel über den SSO Protocol Service (siehe 9.2.3). Session Management: Wie bereits im Kapitel beschrieben wurde, ist die lokale Domäne für das Session Management verantwortlich SOAP/XML Point of Contact (WS Client) Web Services Aufrufe erfolgen in der Regel über einen sogenannten Web Service Gateway. Dieser Gateway hat eine ähnliche Funktion wie der Reverseproxy bei http basierter Kommunikation. Abbildung 47 zeigt eine schematische Gegenüberstellung dieses Ansatzes: 28 Federated Identity Manager services architecture, nach IBM, Redbook Enterprise Security Architecture, sg /101