MIAMI - Das neue Authentifizierungsverfahren

Präsentation zum Thema: "MIAMI - Das neue Authentifizierungsverfahren"—  Präsentation transkript:

1 MIAMI - Das neue Authentifizierungsverfahren
Modular Identity and Access Management Implementation (MIAMI) Andreas KNOLL, Ralf SEHNER / AEW6TA | JBFOne 2008

2 Ziel dieses Vortrags Begriffe Authentifizierung Identität
Autorisierung Architektur von MIAMI Plugin Experten Doorkeeper Promoter Single sign-on am BAP Benötigte Features aus BAP VR-Services aCI e-Banking

3 Agenda Begriffe Historie Zielbild Architektur MIAMI - Server
Architektur MIAMI - Client Single Sign On

4 Agenda Begriffe Historie Zielbild Architektur MIAMI - Server
Architektur MIAMI - Client Single Sign On

5 Begriffe - Authentifizierung
11/137/198 106/172/218 223/234/246 164/197/229 197/199/200 156/157/159 77/75/74 0/66/138 (Überschrift) 242/79/18 (Akzente) 131/174/211 (Hintergrund Schaubild/Foto) 213/227/248 (Hintergrund Text/Diagramm) Füllfarben Begriffe - Authentifizierung Authentifizierung ist der Vorgang der Überprüfung einer behaupteten Identität Authentifizierung ist somit im Prinzip die Überprüfung, ob es sich um das Original handelt. Authentisierung anhand Wissen Kennung und Passwort Besitz Zertifikat Körperlicher Merkmale Stimme

6 Begriffe - Identität 0/66/138 (Überschrift) 242/79/18 (Akzente)
11/137/198 106/172/218 223/234/246 164/197/229 197/199/200 156/157/159 77/75/74 0/66/138 (Überschrift) 242/79/18 (Akzente) 131/174/211 (Hintergrund Schaubild/Foto) 213/227/248 (Hintergrund Text/Diagramm) Füllfarben Begriffe - Identität Summe der Merkmale, anhand derer sich ein Individuum von anderen unterscheiden lässt die Information, die mit der Identifikation einer Einheit innerhalb eines bestimmten Kontext verbunden ist Einheiten können sein: Personen, Geräte, Gruppen, Organisationen Einheiten können mehrere Identitäten haben Identität kann mehrere Einheiten haben (Gruppen)

7 Begriffe - Autorisierung
11/137/198 106/172/218 223/234/246 164/197/229 197/199/200 156/157/159 77/75/74 0/66/138 (Überschrift) 242/79/18 (Akzente) 131/174/211 (Hintergrund Schaubild/Foto) 213/227/248 (Hintergrund Text/Diagramm) Füllfarben Begriffe - Autorisierung Zuweisung und Überprüfung von Zugriffsrechten auf Dienste und Daten Die Autorisierung erfolgt meist nach einer erfolgreichen Authentifizierung.

8 Modular Identity Access Management Implementation Begriffe - MIAMI
11/137/198 106/172/218 223/234/246 164/197/229 197/199/200 156/157/159 77/75/74 0/66/138 (Überschrift) 242/79/18 (Akzente) 131/174/211 (Hintergrund Schaubild/Foto) 213/227/248 (Hintergrund Text/Diagramm) Füllfarben Begriffe - MIAMI Modular Erweiterbar Konfigurierbar Identity Authentifizierungsmöglichkeiten Identitäten Access Zugriff auf Services Management Kein Provisioning Implementation Bereitstellung als Framework

9 Agenda Begriffe Historie Zielbild Architektur MIAMI - Server
Architektur MIAMI - Client Single Sign On

10 Historie – Am Anfang war die BAP-Authentifizierung
RACF XBF LDAP JASS Bankmitarbeiter

11 Historie – Am Anfang war die BAP-Autorisierung … erweitert um Agenturfähigkeit
BAP-Agentur RACF RACF XBF LDAP LDAP JASS JASS XBF Agentur Bankmitarbeiter Mitarbeiter

12 Historie – Am Anfang war die BAP-Autorisierung … Nutzung Agenturfähigkeit mit VRS
JASS XBF LDAP VRS RACF WESPE BAP BAP-Agentur RACF RACF XBF LDAP XBF LDAP JASS JASS Agentur Bankmitarbeiter Mitarbeiter Verbundpartner

13 Agenturen, SB, KKV, Verbundanwendungen
Historie – Am Anfang war die BAP-Autorisierung … Einsatz technischer User bei e-Banking JASS XBF LDAP RACF e-Banking XBF4S Endkunde BAP BAP-Agentur VRS RACF RACF RACF . . . XBF LDAP XBF LDAP LDAP JASS JASS JASS XBF WESPE Agentur Bankmitarbeiter Mitarbeiter Verbundpartner Agenturen, SB, KKV, Verbundanwendungen

14 Agenda Begriffe Historie Zielbild Architektur MIAMI - Server
Architektur MIAMI - Client Single Sign On

15 Zielbild – Grenzen der bisherigen Lösungsansätze
BAP BAP-Agentur VRS e-Banking RACF RACF RACF RACF . . . XBF LDAP XBF LDAP LDAP LDAP JASS JASS JASS JASS XBF XBF WESPE JASS XBF4S Agentur Mitarbeiter Verbundpartner

16 Zielbild – Grenzen der bisherigen Lösungsansätze
JASS-Server Optimale Unterstützung von agree Banken Services ohne Authentifizierung werden konzeptionell nicht unterstützt Kanalspezifische JASS-Server Authentifizierung Fester Bestandteil im JASS nicht kanalübergreifend wieder verwendbar für den Bankarbeitsplatz optimiert Kanalspezifische Anforderung werden außerhalb des Frameworks umgesetzt Identität Bankmitarbeiter ist die zentrale Identität Abbildung auf Bankmitarbeiter Agenturmitarbeiter als Pseudo-Bankmitarbeiter Technische User Agentur-Banken Geräte

17 Zielbild - Lösungsansatz
BAP BAP-Agentur VRS e-Banking RACF LDAP RACF … LDAP JASS JASS JASS JASS XBF XBF XBF XBF WESPE JASS XBF4S Agentur Mitarbeiter Verbundpartner

18 . . . Zielbild BAP BAP-Agentur VRS e-Banking XBF XBF XBF XBF JASS JASS
WESPE JASS XBF4S Agentur Bankmitarbeiter Mitarbeiter Verbundpartner Endkunde

19 Zielbild JASS-Server Bietet Services an
Services ohne Authentifizierung werden weiterhin nicht unterstützt (aber) Services für anonyme Nutzer sind möglich Services un/abhängig von Identitäten Authentifizierung MIAMI bündelt kanalspezifische Anforderungen und macht diese kanalübergreifend verfügbar Für Services optimiert Verschiedene Authentifizierungsmöglichkeiten für eine Identität Unterstützung verschiedener Authentifizierungsverfahren Identität Unterstützung weiterer Identitäten

20 Zielbild - Auftrag Schaffung einer einheitlichen, erweiterbaren Schnittstelle zur kanalübergreifenden Bereitstellung von Authentifizierungsverfahren und Identitäten für den Zugriff und die Ausführung von Services im JASS Bereitstellung und Erweiterungen in MIAMI müssen transparent für die Anwendungen sein

21 Agenda Begriffe Historie Zielbild Architektur MIAMI - Server
Architektur MIAMI - Client Single Sign On

22 MIAMI - Anforderungen Erweiterbarkeit Authentifizierungsverfahren
Identitäten Multiversionssupport Kommunikationsprotokolle Transportprotokolle Performance Peak ca. 40 Authentifizierungen/Sekunde Verfügbarkeit 7/24 Konfigurationsmöglichkeiten Statisch Laufzeit

23 Architektur Server - Modularität
API MIAMI Core

24 Architektur MIAMI - Authentifizierung
Authentifizierungsmerkmale GenoUserId & Passwort LDAP-Simple Bind mit RACF-Kopplung Authentifizierungsverfahren Nicht Authentifiziert Authentifiziert Identitätsschlüssel

25 Architektur MIAMI - Authentifizierung
GenoUserId & Passwort Zertifikat X.509V3 VRNetKey & PIN Authentifizierungsmerkmale Keystore LDAP-Simple Bind mit RACF-Kopplung VRNetKey & PIN-Prüfung A-Verfahren …

26 Architektur MIAMI - Authentifizierung
Authentifizierungsexperten Authentifizierungsmerkmale A-Verfahren LDAP-Simple Bind mit RACF-Kopplung GenoUserId & Passwort GenoUserId & Passwort GenoUserId & Passwort mit LDAP Zertifikat X.509V3 Zertifikat X.509V3 X.509V3 für Agentur Keystore Keystore VRNetKey & PIN VRNetKey & PIN-Prüfung VRNetkey, PIN … …

27 Architektur MIAMI - Authentifizierung
Identitäts-schlüssel Authentifizierungsexperten GenoUserId & Passwort mit LDAP GenoId X.509V3 für Agentur DN VRNetkey, PIN Kundennummer X.509V3 für Verbundpartner … Alias X.509V3 für Bank Fingerprint

28 Architektur Server – Identity (Teil 1)
API MIAMI Core Authentifizierungsexperte

29 Architektur MIAMI - Identitäten
Anonym Identitäten Bank agree Bank non agree Bank externe Partner Verbundpartner IFD Agentur Agenturmitarbeiter Endkunde Bankmitarbeiter Person Gerät

30 Architektur MIAMI - Identitäten
Anonym Identitäten Bank agree Bank non agree Bank externe Partner Verbundpartner IFD Agentur Agenturmitarbeiter Endkunde Bankmitarbeiter Person Gerät Identitätsattribute Person Bedienernummer Name … GenoUserId RZBK Identitäts- verwaltung

31 Architektur MIAMI - Identität
Authentifizierungsexperte Identitätsschlüssel String „GenoUserId“ Identitätsverw. Bankmitarbeiter TAML 50 Identitätsverfahren Schlüssel unbekannt Identität Attribute

32 Architektur MIAMI – Identitätsschlüssel sind nicht disjunkt
Authentifizierungsexperte Identitätsschlüssel Identitätsverfahren Identitätsverfahren Identität Attribute Identität Attribute

33 Architektur Server – Identity (Teil 2)
API MIAMI Core Authentifizierungsexperte Identitätsexperte

34 Architektur MIAMI - Autorisierung
MIAMI kontrolliert Zugriff auf Services im JASS Steuerung über Identitätsgruppen Kanalbindung usw. MIAMI kontrolliert nicht Zugriff auf Daten durch einen Service Zugriffskontrolle auf Daten erfolgt weiterhin durch das Kompetenzsystem der Fiducia Verantwortung des Zugriffssteuerung auf Daten verbleibt im Fachprojekt

35 Architektur Server - Autorisierung
API MIAMI Core Authentifizierungsexperte Identitätsexperte Autorisierungsexperte

36 Architektur Server – Weitere Anforderungen
Problemstellung bei jedem Serviceaufruf Aufwand für Authentifizierung Aufwand für die Identitätsermittlung Lösungsansatz Einführung von Token Unterstützung verschiedener Tokenverfahren Speicherung der Identitäten und deren Attribute mit dem Token Unterstützung verschiedener Persistenzverfahren

37 Architektur Server – Synergieeffekt
API MIAMI Core Authentifizierungsexperte Identitätsexperte Autorisierungsexperte Tokenexperte Persistenzexperte

38 Architektur Server – Synergieeffekte
Token

39 Architektur Server – Anbindung Laufzeitcontainer
Unterstützung verschiedener Transportprotokolle http/s IBM Websphere MQ Unterstützung verschiedener Kommunikationsprotokolle VR-Services aCI IFD xbf

40 Architektur Server - Gesamtsicht
MIAMI Authentifizierungsexperte API Identitätsexperte Autorisierungsexperte Core Tokenexperte Transportexperte Persistenzexperte Protokollexperte

41 Laufzeitalternativen
Stand-alone Server Servlet in Stand-alone tomcat Servlet im JASS JASS-Modul Innerhalb eines JASS-Modul

42 Agenda Begriffe Historie Zielbild Architektur MIAMI - Server
Architektur MIAMI - Client Single Sign On

43 Architektur Server - Gesamtsicht
API MIAMI Authentifizierungexperte Core Transportexperte Identitätsexperte Tokenexperte Persistenzexperte Autorisierungsexperte Protokollexperte

44 Architektur Client – Gesamtsicht
API MIAMI Authentifizierungsprovider Core Transportexperte Protokollexperte

45 Ablauf erste Authentifizierung (Teil 1)
MIAMI - Client MIAMI - Server 1 6 7 3 4 8 2 5 9 Authentifizierungsstack

46 Ablauf erste Authentifizierung (Teil 2)
MIAMI - Client MIAMI - Server 4 3 1 5 2 Wohin jetzt mit dem Token? Authentifizierungsstack

47 Architektur Client – Gesamtsicht
MIAMI - Client

48 Architektur MIAMI Client - Authentifizierungsstack
Dient der Einbindung unterschiedlicher Authentifizierungsmerkmale in den MIAMI-Client Denkbar sind folgende Authentifizierungsprovider GenoID + Password Abgreifen der OS-Anmeldeinformationen (CredentialManager, PAM-Modul) Benutzer-Zertifikate OneTime-Passwörter SmartCards Fingerprint-Sensor :

49 Architektur MIAMI Client
Authentifizierungs-Stack Authentifizierungs-Stack Authentifizierungs-Stack MIAMI Client

50 Architektur MIAMI Client
Die Stacks werden zu einer Kette zusammengefügt und bis zum Erhalt eines Tokens sequenziell abgearbeitet Somit können beliebige Verfahren in den Client integriert und priorisiert werden OS- Authentifizierungs-Stack Authentifizierungs-Stack User-Certificate Authentifizierungs-Stack UserIdPW Promoterexperte

51 Architektur Client – Wie kommt der Token in den Request ?

52 Architektur MIAMI Client
JBF Server MIAMI OS- Authentifizierungs-Stack Authentifizierungs-Stack User-Certificate Authentifizierungs-Stack UserIdPW Promoterexperte agree BAP Web-Browser agree SB Weitere Anwendungen

53 Architektur MIAMI Client
JBF Server MIAMI OS- Authentifizierungs-Stack Authentifizierungs-Stack User-Certificate Authentifizierungs-Stack UserIdPW Service-Stack Service-Stack Service-Stack Promoterexperte agree BAP Web-Browser agree SB Weitere Anwendungen

54 Architektur MIAMI Client
JBF Server MIAMI Transportexperte OS- Authentifizierungs-Stack Authentifizierungs-Stack User-Certificate Authentifizierungs-Stack UserIdPW Service-Stack Service-Stack Service-Stack Protokollexperte Promoterexperte agree BAP Web-Browser agree SB Weitere Anwendungen

55 Agenda Begriffe Historie Zielbild Architektur MIAMI - Server
Architektur MIAMI - Client Single Sign On

56 Architektur MIAMI Client – Anmeldung
JBF Server MIAMI 9 6 2 Doorkeeper Habe ich einen Token? NEIN !!! OS- Authentifizierungs-Stack Authentifizierungs-Stack User-Certificate Authentifizierungs-Stack UserIdPW T + Request 10 3 4 5 Promoterexperte 8 T 11 7 agree BAP 1 Web-Browser agree SB Weitere Anwendungen

57 Architektur MIAMI Client – Single Sign On
Webserver MIAMI 5 2 Doorkeeper Habe ich einen Token? JA !!! OS- Authentifizierungs-Stack Authentifizierungs-Stack User-Certificate Authentifizierungs-Stack UserIdPW T + Request 6 Promoterexperte 4 T 7 3 1 agree BAP Web-Browser agree SB Weitere Anwendungen

58 Architektur MIAMI Client – Single Sign On
Da das Token lediglich im Promoter ermittelt und eingefügt wird, ergibt sich ein Single Sign On von allein Die automatische Anmeldung mit den Anmeldedaten des Betriebssystems ergibt sich aus dem spezialisierten „OSAuthentifizierungsstack“

59 Zusammenfassung MIAMI ist modular und erweiterbar in Form von Plugins
MIAMI kann nur vorhandene Funktionalität nutzen Authentisierungsmerkmale / Authentifizierungsverfahren Identitätsschlüssel / Identitäten MIAMI benötigt organisatorische Rahmenbedingungen Provisioning Administration Infrastruktur MIAMI selbst stellt keine organisatorischen Rahmenbedingungen zur Verfügung! MIAMI macht Authentifizierungsverfahren und Identitäten kanalübergreifend verfügbar. Bereitstellung und Erweiterungen erfolgen transparent für die Anwendungen. MIAMI bringt als Synergieeffekt Single Sign On

60 Fragen? – Diskussion? Andreas Knoll Ralf Sehner
Anwendungsentwicklung Technische Architektur 089 / 9943 – 34 51 Ralf Sehner 089 / 9943 – 39 64

61 Ihr IT-Partner Vielen Dank