SOA Security mit regelbasierten Ansätzen vereinfachen. Kersten Mebus. Organized by:

Transkript

1 Mi 3.2 January 22 th -26 th, 2007, Munich/Germany SOA Security mit regelbasierten Ansätzen vereinfachen Kersten Mebus Organized by: Lindlaustr. 2c, Troisdorf, Tel.: +49 (0) , Fax.: +49 (0)

2 <Insert Picture Here> SOA Security mit regelbasierten Ansätzen vereinfachen Kersten Mebus Leitender Systemberater Agenda SOA Security Identity & Accessmanagement und SOA Regelbasierte Ansätze mittels Oracle s Manager Überwachung / SLA Compliance Demonstration Zusammenfassung

3 Service Oriented Architecture Überblick Print Invoices Generate POs Credit Verification 1 Account Validation 1 User Authentication 1 Create Customers Credit Verification 2 Account Validation 2 User Authentication 2 Monolithic application silos Print Invoices Generate POs Account Validation Service Create Customers Authentication Service Oracle Fusion Middleware Credit Verification Service Flexible composite applications Warum SOA Security? Überprüfung der Unversehrtheit (Integrität) einer empfangenen Nachricht Vertraulichkeit einer Nachricht muss beibehalten werden Identitätsbestimmung des Senders Ist der Sender autorisiert auf die Operation zuzugreifen die in der Nachricht angegeben ist

4 SOA Security Ansätze Standardansätze um Dienste zu sichern: 1. Protokoll basierend SSL / HTTPS 2. Message basierend XML digital signature XML encryption Security Assertion Markup Language (SAML) SOA Security & Mgt Bedenken Service Provider Service Consumer Wie kontrolliere ich wer auf meine Services zugreift? Wie definiere und überwache ich SLAs? Wie steuere ich QoS (Zuverlässigkeit, Priorisierung, Load Balancing)? Wie regele ich das Auditing? Wie kann ich auf neue Versionen upgraden ohne Kundenstörung? Wie gehe ich mit Fehlern in Services um, von denen meine Applikation abhängt? Wie betreibe ich Ursachenanalyse und identifiziere Services, die Performance/Verfügbarkeitsprobleme für meine Applikation generieren? Wie logge ich Service Requests für Auditzwecke? (Wieviel sollte mir in Rechnung gestellt werden?) Wie gehe ich mit ungleichen Sicherheitsmechanismen in verschiedenen back-end Services um? Wie wechsele ich zu neuen Providern, ohne meine aufrufende Applikation zu ändern? Enterprise IT Business Parameter sind in jeder Verbindung hard-coded (SLAs, security certificates, connection type) Security ist in Applikationen vergraben Überprüfung von Compliance mit Policyrichtlinien ist schwierig Ausbildung und Training auf neue Standards und Technologien erfordert signifikantes Investment Grosse Schwierigkeiten beim Umgang mit sich ändernden Policies Integrationen und Software Upgrades sind kostenintensiv

5 SOA Security & Mgt Vorteile Offenlegung von s Security Keine s Security Silos Fokus auf Fachwissen Entwickler konzentrieren sich auf die Businesslogik Securityarchitekten und Administratoren konzentrieren sich auf Security und Management Erfüllung von Unternehmensanforderungen Zentrale Firmenregeln werden angewandt Security Policies werden zentral definiert Reduzierte Administrationskosten Security Policy Änderungen werden zentral gesteuert, nicht in jedem einzelnen Security Audits / Reports werden über alle s von einem zentralen Punkt aufgerufen s Security und Management Umgebung lässt sich einfacher einsetzen, unterhalten und upgraden Oracle Fusion Middleware

6 Oracle Identity Management Access Manager Web Access Control/Single Sign-On s Manager SOA Security esso Suite Desktop/Legacy Single Sign-On Auditing & Reporting Compliance & Attestation Identity Federation Cross Domain Single Sign-On Identity Manager Enterprise User Provisioning Systems Mgmt Monitoring & Management Directory Services Identity Virtualization, Synch & Storage Oracle SOA Suite Oracle s Manager ist Bestandteil der Oracle SOA Suite, die auch folgende Komponenten beinhaltet: BPEL Process Manager (BPEL PM): Setzt einzelne Services zu einem durchgehenden Prozessfluss zusammen, basierend auf der Business Process Execution Language (BPEL) Business Rules Engine (BRE): Definiert Regeln, um konditionelle (ifthen) Aktionen zu spezifizieren Enterprise Service Bus (ESB): Enabling service-oriented (SOA) und event-driven (EDA) Architekturen (connectivity, transformation, content-based routing) Business Activity Monitor (BAM): Eventbearbeitung (erfassen, korrelieren, analysieren, visualisieren und antworten) JDeveloper: Java integrated development environment (IDE) + business components framework Oracle Containers for Java (OC4J): J2EE-compliant application server hosting the Oracle SOA Suite components

7 Überschneidung Identity Management und SOA Identity Mgt SOA OC4J / UDDI Registry / OLite Oracle Internet Directory Oracle BPEL Process Mgr OWSM Oracle Access Manager Oracle Ent. Service Bus Third-Party Umgebungen - Identity Management Infrastrukturen LDAP Verzeichnisse UDDI registries XML acceleration SOA in der Wirklichkeit portal.net service Oblix AuthN LDAP AuthN Oblix AuthZ LDAP AuthZ Customers SAML J2EE service Oblix AuthN CICS wrap LDAP AuthZ Legacy XSLT Protocol Xlation Routing Oblix AuthZ Trading Partners B2Bi SAML XMLEncrypt AD AuthN AD AuthZ WS-Security Protocol Xlation TIBX process NETE AuthN SLA Routing Biz service CRM DBMS AuthZ WS-Security Failover B2B Exchanges FRONT OFFICE INTEGRATION SERVICES BACK OFFICE Security Architects Operations

8 Keine feste Kopplung in SOA Customers portal.net logic Oblix AuthN LDAP AuthN Oblix AuthZ LDAP AuthZ J2EE logic SAML Oblix AuthN CICS wrap LDAP AuthZ Legacy XSLT Protocol Xlation Routing Oblix AuthZ Trading Partners SAML B2Bi logic AD AuthN AD AuthZ WS-Security XMLEncrypt TIBX logic Protocol Xlation NETE AuthN SLA Routing App logic CRM DBMS AuthZ WS-Security Failover B2B Exchanges FRONT OFFICE INTEGRATION SERVICES BACK OFFICE Security Architects Operations Regelbasiertes, proaktives Management Customers portal.net logic OWSM PEP OWSM PEP CICS wrap Legacy J2EE logic OWSM PEP OWSM PEP Trading Partners B2Bi logic TIBX logic OWSM PEP B2B Exchanges FRONT OFFICE OWSM PEP CRM INTEGRATION SERVICES OWSM Monitor OWSM Policy Manager App logic BACK OFFICE Security Architects OWSM PEP Operations

9 Einführung Oracle WSM Standalone Plattform zur Zugriffssicherung und verwaltung von s eingesetzt vom Entwickler, Deployer, oder Security Administrator verlangt dem Entwickler keine Änderungen an Applikationen oder Services ab (keine programmatische Security notwendig) führt Security Policies in Echtzeit aus überwacht alle Zugriffe (graphische Reports) bietet Werkzeuge zur Definition und Überwachung von service-level agreements (SLA) nutzt Backend Identity Management Infrastrukturen wie den Oracle Access Manager zur Authentifizierung und Authorisierung Support von Key Security Standards Verschlüsselungsalgorithmen: AES-128, AES-256, 3-DES Message Digests: MD5, SHA-1 Message Strukturen: XML / SOAP / WS-Security Security token profiles: Username, X.509, SAML Message Integrität: XML Signature, Verify XML Signature Message Vertraulichkeit: XML Encryption PKI Key encryption: RSA OAEP-MGF1P, RSA V1.5 Signature algorithms: RSA (PKCS #1) (1024-, 2048-bit keys), DSA Credentials store, wallets: PKCS#12

10 Oracle WSM Komponenten Clients Web services Policy Enforcement Points (PEP) Gateway Oracle WSM Server Komponenten Policy Manager Management Konsole Monitor Datenbank Oracle WSM Komponenten Policy Enforcement Points (PEP) Clients Agent Agent Agent Agent Agent Web services Agent Oracle WSM Server Komponenten Policy Manager Management Konsole Monitor Datenbank

11 Vergleich Gateways und Agenten Features Administration Gateways bietet zentrale Administration Agenten Keine neue Komponente zu verwalten Protocol Support Securing Services Impact on Clients leistet Protokollübersetzung Content Routing Kann keine endpoint-level security garantieren einziger enforcement point ist zu verwalten client muss zum Gateway geleitet werden Nutzt bestehende Plattform und Protokoll garantiert endpoint-level security mehrere enforcement points sind zu verwalten Keine Änderungen beim Client oder der UDDI registry nötig Zugriffsschutz auf s mittels Gateway The Request Pipeline specifies the sequence of Policy Steps that should be enforced for incoming requests. Client 1 4 Gateway 2 3 Provider The Response Pipeline specifies the sequence of Policy Steps that should be enforced for outgoing responses Der Gateway sichert Zugriff auf einen oder mehrere s auf Web Service Provider Seite Schritt1: Der Client schickt einen Anfrage an einen Schritt2: Der Gateway fängt die Anfrage ab, wendet Security Policies an (e.g., decryption, signature verification, authentication, authorization) und leitet die Anfrage an den weiter Schritt3: Der schickt eine Antwort Schritt4: Der Gateway fängt die Antwort ab, wendet Security Policies an (e.g., encryption) und leitet die Antwort an den Client weiter

12 Zugriffsschutz auf (s) mittels Server-Side Agent Client 1 4 Agent 2 Provider 3 Der OWSM Agent schützt den Zugriff auf einen auf Seiten des Providers (Server-Side Agent) Schritt1: Der Client schickt eine Anfrage an einen Schritt2: Der Agent fängt die Anfrage ab, wendet Security Policies an (e.g., decryption, signature verification, authentication, authorization) und gibt die Anfrage an den weiter Schritt3: Der schickt eine Antwort Schritt4: Der Agent fängt die Antwort ab, bringt Security Policies an (e.g., encryption) und gibt die Antwort an den Client weiter Zugriff auf (s) erfragen mittels Client-Side Agent 1 Client 4 Agent 2 3 Provider Der OWSM Client-Side Agent setzt s Policies innerhalb der gleichen Webanwendung wie der Client durch Schritt1: Der Client schickt eine Anfrage an einen Schritt2: Der Agent fängt die Anfrage ab, bringt Security Policies an (e.g., encryption, etc.), und leitet die Anfrage an den weiter Schritt3: Der bearbeitet die Anfrage und schickt eine Antwort Schritt4: Der Agent fängt die Anfrage ab, bringt Security Policies an (e.g., decryption) und leitet die Antwort an den Client weiter.

13 Zugriff auf externe s mittels Gateway als Reverse Proxy Server Intranet Internet Client 1 4 Gateway 2 3 Provider Ziel ist hier, nur bestimmten Clients zu erlauben, aus dem Firmennetz auf externe s zuzugreifen Schritt1: Der Client (innerhalb des Firmennetzwerks) schickt einen Request an einen externen Schritt2: Der Gateway fängt das Request ab, bringt Security Policies an (e.g., Authentifizierung, Authorisierung) und leitet den Request an den weiter Schritt3: Der Web service schickt eine Antwort Schritt4: Der Gateway fängt das Request ab, bringt Security Policies an und leitet die Antwort an den Client weiter Mapping von Credentials mittels Gateway und Server-Side Agent Client 1 2 Gateway 6 3 Agent 4 Provider 5 User Id: kmebus erstellt SAML AssN mit User Id kmebus Validiert SAML AssN Client und Provider unterstützen nicht den gleichen Typ von Credentials Schritt1: Der Client nutzt basic credentials ( kmebus ) für seinen Request Schritt2: Das Gateway fängt den Request ab und authentifiziert ihn Schritt3: Nach erfolgreicher Authentifizierung fügt das Gateway eine SAML assertion in den WS-Security Header ein, die es dem Provider als Teil der SOAP Message schickt Schritt4: Der Agent validiert die SAML assertion und leitet den Request an den Web Service weiter Schritt5: Der schickt eine Antwort, die vom Agenten abgefangen wird Schritt6: Der Agent schickt die Antwort direkt an den Client oder über das Gateway

14 Gateway als Vermittler bei heterogenen Protokollen Intranet Internet 1 Client HTTP Gateway JMS Provider 2 Client JMS Gateway HTTP Provider Client und Provider unterstützen nicht das gleiche Protokoll Beispiel 1, Gateway befindet sich im Intranet und übersetzt ein abgehendes HTTP Request in JMS Beispiel 2, Gateway befindet sich ausserhalb des Intranets und bietet Zugriff auf einen HTTP-basierten aus einem JMS-basierten Request Beispiel: XML Verschlüsselung des Headers <Insert Picture Here>

15 Sicherheitstoken Sicherheitstoken (in XML gehaltene SicherheitsInfo): Username/Password Token Binary Security Tokens X.509 Zertifikat, Kerberos Tickets SAML Token Binary Security Tokens (X.509 Zertifikat) Enthält öffentliches Zertifikat in Base64 codierten Daten Encrypted Key 1. Cipher Data enthält verschlüsselten Shared Key (Session Key) 2. KeyInfo bezeichnet den öfftentlichen (asymmetrischen) Schlüssel, verantwortlich für die Verschlüsselung des Shared Keys (Empfänger hat privaten Schlüssel) 3. Algorithmus für asymmetrische Keyverschlüsselung

16 Encrypted Data Enthält den verschlüsselten Header, verschlüsselt durch Shared Key Verschlüsselungsalgorithmus für den Header (Nachricht) XML Digital Signature Sender Receiver Original Message Hello, this is a simple message. 1. One-Way Hash Hello, this is a simple message. liusqdh _igzefd2 YWGZC FDdize# Message Digest Private 2. Encryption with Private Key Signature 3. Append Messages 4. Send Signed Message liusqdh _igzefd2 5. Message : One-Way Hash 7. Comparaison Hello, this is a simple message. liusqdh _igzefd2 Public 6. Signature : Decryption with Public Key YWGZCF Ddize# Signed Message YWGZCF Ddize#

17 Oracle WSM Management Konsole Überwachung: Snapshot aller Aktivitäten

18 Authentication & Authorization Events Überwachung: Traffic Analyse

19 Überwachung: SLA Compliance D E M O N S T R A T I O N OWSM

20 Zusammenfassung OWSM zur Zugriffssicherung und verwaltung von s eingesetzt vom Entwickler, Deployer, oder Security Administrator verlangt dem Entwickler keine Änderungen an Applikationen oder Services ab (keine programmatische Security notwendig) führt Security Policies in Echtzeit aus überwacht alle Zugriffe (graphische Reports) bietet Werkzeuge zur Definition und Überwachung von service-level agreements (SLA) nutzt Backend Identity Management Infrastrukturen wie den Oracle Access Manager zur Authentifizierung und Authorisierung