Vorlesung "SOA Entwicklung verteilter Systeme auf Basis serviceorientierter Architekturen" 10. Sicherheitsaspekte (Fortsetzung)

Transkript

1 Vorlesung "SOA Entwicklung verteilter Systeme auf Basis serviceorientierter Architekturen" 10. Sicherheitsaspekte (Fortsetzung) Dr.-Ing. Iris Braun

2 Gliederung WS-Security Authentifizierung Single-Sign-On (SAML) Autorisierung (SAML) Erweiterungen WS-Policy WS-SecurityPolicy WS-Trust WS-Federation WS-SecureConversation Verwendung von WS-Security-Technologien: Proxy Lösungen Implementierungen Zusammenfassung Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 2

3 Abgrenzung Keine Betrachtung von Schutz von Diensten gegen Angriffe oder Ausnutzung von Sicherheitslücken in der Implementierung Exploits, blockierende Aufrufe,... Schutz der Infrastruktur DoS-Attacken, Spoofing,... Konzentration auf Schutz der Daten (Nachrichten) Schutz der Benutzer (Clients) Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 3

4 Wiederholung: WS-Security Erweiterungen Authentifizierung: Sicherheit Username / Passwort, Kerberos, X.509 WS-Security Sicherheit Framework Nachrichten-Integrität: Sicherheit XML Signature Nachrichten-Vertraulichkeit: Sicherheit XML Encryption Autorisierung: Sicherheit SAML-Profile Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 4

5 WS-Security: Authentifizierung Viele verschiedene Möglichkeiten, um Token (Identitätszeugnis) für Identitätsbeweise zu verwenden, z.b. Benutzername / Passwort (Basic Authentication) Kerberos-Ticket (verschlüsselt durch Aussteller, kann durch Dienstanbieter verifiziert und zusätzlich signiert werden) WS-Security erlaubt Verwendung beliebiger Token Flexibilität, Erweiterbarkeit XML Kerberos Username / XML Password WS-Security Sicherheit XML X.509 XML SAML XML... Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 5

6 WS-Security: Beispiel Authentifizierung <soap:envelope> <soap:header> <wsse:security xmlns:wsse="..."> <wsse:usernametoken> <wsse:username>reisebuero</wsse:username> <wsse:password Type="wsse:PasswordDigest"> </wsse:password> </wsse:usernametoken> </wsse:security> </soap:header>... </soap:envelope> UsernameToken nur für Anwendungen mit Sicherheit auf der Transportschicht, z.b. HTTPS (HTTP mit SSL-Sicherung) Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 6

7 SAML: Security Assertion Markup Language SAML: Security Assertion Markup Language OASIS-Standard seit 2001 Ziel: Verfahren zum Austausch sicherheitsrelevanter Informationen zur Authentifizierung und Autorisierung, standardisierte Beschreibung existierender Sicherheitsmodelle Vollständig programmiersprachen-/plattform-/herstellerunabh. Bestandteile: Assertions: Aussagen über Sitzungsinformationen Beispiel: Der Nutzer verwendet ein Passwort, das gültig ist. Protokolle für Anfragen und Übermittlungen solcher Aussagen (Assertion Request/Response) Bindungen und Profile zur Integration von SAML in andere Spezifikationen (auch WS-Security) Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 7

8 SAML: Assertion-Typen Authentication Bestätigung, dass der genannte Dienstnutzer zu einer bestimmten Zeit von einem bestimmten Vermittler authentifiziert wurde Attribute Bestätigung, dass einem bestimmten Dienstnutzer statische oder dynamische Attribute wie Rollen oder Informationen zugeordnet sind Authorization Erklärung einer Autorität, dass ein bestimmter Dienstnutzer die Erlaubnis zu einer Aktivität auf einer Ressource hat -> Analogie zum Notar: Beglaubigung, Vollmacht Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 8

9 SAML: Eigenschaften von Assertions In XML beschrieben Verschachtelung wird unterstützt Einzelne Assertion kann mehrere interne Aussagen enthalten Menge von Assertions kann zu SAML Profile zusammengefasst werden Von SAML Autorität ausgestellt Versionsnummerierung und Signierung möglich SSL für digitale Signierung und Verschlüsselung Schutz gegen Replay-Attacken Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 9

10 SAML: Verwendung des Protokolls Verschiedene Anwendungsszenarien: Single Sign-On (ein Dienstnutzer ist nach der Anmeldung bei einem Dienst automatisch auch zur Benutzung von weiteren Diensten berechtigt) Autorisierungsdienste (eine unbeteiligte Autorität erzeugt und prüft Berechtigungen) Verteilte Transaktionen (mehrere Dienste sind gemeinsam an einer Transaktion beteiligt und teilen sich die Sicherheitsinformationen) Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 10

11 Single Sign-on SOAP-Anfrage Dienstnutzer Dienstanbieter SOAP-Antwort ( authentifiziert ) SOAP-Anfrage ( authentifiziert? ) SOAP ( ja ) SOAP-Anfrage Anderer Dienstanbieter Unterstützung durch folgende Entwicklungen: - Kerberos ( Webseiten - OpenID, OAuth (im REST-Umfeld und für ( Webseiten ).NET Passport/MS CardSpace/Windows Live ID - ( Services - SAML, XACML (SOAP-basierte Web Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 11

12 SAML: Autorisierungsdienst Dienstnutzer Dienstaufruf + Assertion Dienstanbieter Assertion erhalten Gültigkeit einer erhaltenen Assertion überprüfen SAML Autorität Assertions produzieren und konsumieren SAML-Autorität ist keine zentrale Certificate Authority, Assertion kann von einem beliebigen Punkt im Netzwerk zugesichert werden Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 12

13 SAML: Beispielszenario Kunde Authentikation Login per single sign-on SAML Assertion Request Ist Kunde kreditwürdig? Bank SAML Assertion Response Ja, Verfügungsrahmen 2000 EUR Händler Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 13

14 XACML und XKMS XACML: extensible Access Control Markup Language XML-Sprache für Zugriffskontroll-Policies Request-Response-Protokoll zur Abfrage von Zugriffsrechten Regelwerk für die Beschreibung von Leserechten mit XML XKMS: XML Key Management Specification W3C-Spezifikation XML-basierte Verwaltung einer PKI (Public Key Infrastructure) Menge von Web Services als Schnittstelle zu Key-Management- Systemen Unterstützung für die Verteilung bei Private/Public-Key- Mechanismen Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 14

15 WS-Security: Zusammenfassung Einsatz: hauptsächlich Sicherheit auf Nachrichtenebene Definiert, wie Teile der XML-Dokumente signiert oder verschlüsselt werden (neue Header-Elemente) Ermöglicht Verwendung (Sicherung) von Verschlüsselung (Vertraulichkeit) Signaturen (Integrität) Authentifizierung und Autorisierung mittels verschiedener standardisierter Verfahren Keine Alternative / Konkurrenz zu Standards wie XML-Signature, Encryption und SAML (Security Assertion Markup Language), sondern Verwendung dieser Standards Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 15

16 WS-Security: Erweiterungen Offene Fragen: Wie einigen sich Dienstnutzer und Dienstanbieter auf ein Verfahren? Müssen Schlüssel und Identität für jeden Nachrichtenaustausch neu festgelegt und geprüft werden? Erweiterbares Rahmenwerk WS-SecureConvers. WS-Federation WS-Authorization WS-Policy WS-Trust WS-Privacy WS-Security Sicherheit XML SOAP Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 16

17 WS-Policy Entwicklung von Microsoft, IBM, BEA und SAP, 2003 Ziel: Formulierung von (Sicherheits-) Anforderungen und Richtlinien Bedingungen müssen bei Dienstnutzung akzeptiert werden Erweiterbares Framework für einfache Anforderungen vor allem der Übertragung, z.b. Transportprotokoll und Authentifikations- Methode Definiert nicht, wie Policies mit Diensten verbunden, gesucht und verwaltet werden (WS-PolicyAttachment) Ø WS-SecurityPolicy: Erweiterung dieses Frameworks um Sicherheitsaspekte Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 17

18 WS-SecurityPolicy: Beispiel Erlaubt es einem Dienstanbieter, potentiellen Dienstnutzern die notwendigen Sicherheitsanforderungen mitzuteilen <wsp:policy...> <wsp:exactlyone> <wsse:securitytoken wsp:usage="wsp:required" wsp:preference="100"> Bevorzugt <wsse:tokentype>wsse:kerberosv5tgt</wsse:tokentype> </wsse:securitytoken> <wsse:securitytoken wsp:usage="wsp:required" wsp:preference="1"> <wsse:tokentype>wsse:x509v3</wsse:tokentype> </wsse:securitytoken> </wsp:exactlyone> </wsp:policy> Genau eine der beiden Möglichkeiten muss erfüllt werden Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 18

19 WS-Policy: Usage-Attribut wsp:usage kann folgende Werte annehmen: Required Zusicherung muss erfüllt sein, sonst Fehlermeldung Optional Kann erfüllt werden, falls nicht wird kein Fehler erzeugt Rejected Zusicherung wird nicht unterstützt Observed Zusicherung trifft auf alle Policy-Subjects zu, Aufrufer wird informiert Ignored Zusicherung wird bewusst nicht beachtet Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 19

20 WS-Trust Ziel: Sicherstellung der Interoperabilität bei Verwendung von sicherheitstechnischen Daten Regelt den initialen Austausch dieser Daten (vor eigentlichem Web-Service-Aufruf) Erweiterung von WS-Security um Format der sicherheitsrelevanten / geheimen Daten Vertrauensketten (wichtig bei vielen Beteiligten): transitive Ketten oder Trust-Center Definiert Format und Ablauf für den Austausch der mit WS- SecurityPolicy erklärten Sicherheitsanforderungen oder der dafür benötigten Daten Beispiel: Dienstnutzer fordert von Dienstanbieter dessen Public Key an, um die zu sendende Nachricht verschlüsseln zu können Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 20

21 WS-Trust: Überblick Absender Empfänger Anwendung Anwendung Nachrichten Nachrichten Nachrichten Nachrichten Nachrichten Nachrichten Registry Header für Authentifiz. / Autorisierung Request Security Token Body Header für Authentifiz. / Autorisierung Request Security Token Antwort-Body Registry Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 21

22 WS-Trust WS-Trust unterstützt Vereinbarungen über 3 Aspekte von Security-Token in WS-Security: Format Grundsätzliches Verfahren (z.b. X.509) Verschiedene Versionen, unterschiedliche digitale Darstellung Vertrauensbeziehung Aufbau einer Kette einzelner Vertrauensbeziehungen bis zum Unterzeichner eines empfangenen Tokens Namensräume Auflösung von Problemen bei gleichwertigen, aber syntaktisch unterschiedlichen Tokens Beispiel: SAML-Zusicherung über Rolle, die zwar semantisch identisch, aber im Wortlaut unterschiedlich ist Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 22

23 WS-Trust: Ablauf STS: Security Token Service RST: Request Security Token RSTR: RST Response Quelle: ix 5/2006, S. 126, Heise Verlag Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 23

24 WS-Federation: Vertrauen zwischen Domänen WS-Trust ermöglicht Authentisierung von Dienstnutzer und Dienstanbieter einer Security Domain (OASIS-Standard v1.3, 2007) WS-Federation: erweitert das Konzept um die Verwendbarkeit von Authentisierungszeugnissen (Credentials) aus anderen Domänen (OASIS-Standard v1.2, 2009) Spezifiziert Nachrichtenaustausch-Protokoll zur transparenten Übertragung von Identitäten Pseudonyme, um Identitäten geheim zu halten vor allem von IBM, Microsoft und VeriSign vorangetrieben Basis von Active Directory Federation Services (ADFS) von Microsoft Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 24

25 Problem: mehrfache Kommunikation Szenario: Reisebüro stellt viele Buchungsanfragen nacheinander Für jede Anfrage wird neuer symmetrischer Schlüssel erzeugt und asymmetrisch verschlüsselt Aufwand, Rechenzeit Reisebüro Reisebüro Hotelkette Hotelkette Lösung: Bei längerer Konversation einen Sicherheitskontext für diese Sitzung anlegen, der für bestimmten Zeitraum gültig ist Reisebüro Reisebüro Hotelkette Hotelkette Einmalig generierter symm. Schlüssel Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 25

26 WS-SecureConversation (v1.4, März 2009) Gemeinsamer Kontext hat eindeutigen Identifier: <SecurityContextToken wsu:id="..."> <wsc:identifier>... </wsc:identifier> </SecurityContextToken> Speichert beliebige Zusammensetzung von Authentifizierungs-, Autorisierungs- und Verschlüsselungsinformationen, die von mehreren Konversationsteilnehmern verwendet werden Anwendung WS-SC Context WS-SC Context Anwendung SOAP SOAP Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 26

27 WS-SecureConversation: Anforderung Token <soap:body> <wst:requestsecuritytoken> <wst:tokentype> sct </ Security wst:tokentype> Context Token <wst:requesttype> </wst:requesttype> <wsp:appliesto> <wsa:endpointreference> <wsa:address> </wsa:address> </wsa:endpointreference> </wsp:appliesto> </wst:requestsecuritytoken> </soap:body> WS-Provider, an den/ die der gemeinsame Schlüssel/Kontext auch geschickt wird Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 27

28 WS-SecureConversation: Antwort (Key) <soap:body> <wst:requestsecuritytokenresponse> <wst:requestedsecuritytoken> <wsc:securitycontexttoken>... </wst:requestedsecuritytoken> <wst:requestedprooftoken> <xenc:encryptedkey Id="sharedSecretKey">... </xenc:encryptedkey> </wst:requestedprooftoken> <wst:lifetime>... </wst:lifetime> </wst:requestsecuritytokenresponse> </soap:body> ID des neuangelegten Sicherheitskontextes Symm. Schlüssel Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 28

29 Weitere Spezifikationen Wie kann ein WS Vertraulichkeitsforderungen ausdrücken? Wie weist ein WS nach, dass er Daten nach einer WS-Policy vertraulich behandeln kann, oder damit einverstanden ist? WS-Privacy Von Microsoft und IBM, noch unveröffentlicht, beschreibt Syntax und Semantik der Einbindung der Policies Wie werden Zugriffskontrollen auf Dienste spezifiziert und verwaltet? WS-Authorization Ebenfalls noch unveröffentlicht, aber an XACML angelehnt Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 29

30 Proxy für Sicherheit Mögliche Verwendung von WS-Security-Technologien: Implementierung auf dem SOAP-Client Zusätzlicher Aufwand für Benutzer und Entwickler Fehlende Transparenz Modifikation bestehender Web Services notwendig Trusted Intranet Dienstnutzer Dienstanbieter XML Signature Firewall SOAP Transport (HTTP) HTTP Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 30

31 Proxy für Sicherheit Mögliche Verwendung von WS-Security-Technologien: Nutzung eines signierenden Proxy Transparente Erzeugung von Signaturen auf Proxy Service, die dem Header der SOAP-Nachricht hinzugefügt werden Proxy-Authentifizierung möglich bei Zugriff auf PKI Intranet Dienstnutzer Signing Proxy Dienst- Anbieter SOAP Transport (HTTPS) XML Signature SOAP Transport Signing Proxy agiert als Intermediary Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 31

32 Proxy: Empfang der SOAP-Nachricht Authentifizierung der Nachricht mit den im Header eingefügten Informationen Überprüfung der notwendigen Rechte für den Dienstaufruf Entfernung der Sicherheitsinformationen aus dem Header für vollständige Transparenz möglich, aber nicht notwendig Empfänger Dienst- Anbieter Authentifizierung Autorisierung Header-Blocks entfernen (optional) Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 32

33 Proxy: Integration Integration eines Signierenden Proxy leicht möglich: Dienstnutzer muss nur Proxy-Einstellungen ändern Empfänger sollte Firewall um die Überprüfung der Signatur im SOAP-Header erweitern Vorteil: zentrale Administration, Plug-in-Lösung, Interoperabilität gegeben Erweiterung für größere Installationen: Einsatz von Policy-Servern Zentrale Verwaltung von Schlüsseln und Zertifikaten Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 33

34 Implementierungen von WS-Security Microsoft Web Service Enhancements (WSE) Erweiterung des.net Frameworks Authentifizierung mit Benutzername, Kerberos, X.509 Unterstützung für WS-Trust und WS-SecureConversion Systinet Server Web Services Security Framework Unterteilung in Low-level (SSL, X.509, PKI,...), XML level (XML Enc., XML Sig., WS-Security, SAML,...) und Web Services level (Single Sign-On Service, Entitlement Service) WSS4J der Apache Foundation WS-Security-Implementierung, verwendet Apache Axis Verwendung als Library oder API zur Erzeugung der WS-Security Header-Elemente Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 34

35 WSS4J-Beispiel: Signierung eines SOAP-Bodys Document envelope =... WSSignEnvelope signer = new WSSignEnvelope(); Crypto crypto = CryptoFactory.getInstance("crypto.properties"); Vector parts = new Vector(); WSEncryptionPart part = new WSEncryptionPart(soapConstants.getBodyQName().getLocal...,soapConstants.getEnvelopeURI(), "Content"); parts.add(part); // this is optional since the body is signed by default signer.setparts(parts); envelope=signer.build(envelope, crypto); Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 35

36 Zusammenfassung Wichtigste Schutzziele werden mit WS-Security abgedeckt Vertraulichkeit Integrität Verbindlichkeit Authentizität und Autorisierung Gewährleistet Sicherheit auf Nachrichtenebene in SOAP-Nachrichten eingebettet Nutzung standardisierter Sicherheitsverfahren XML Encryption, XML Signature, SAML Erweiterungen für komplexere Anwendungsszenarien Policy, Trust, SecureConversation, Federation, z.t. noch in Entwicklung Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 36

37 Organisatorisches Vorlesung Cloud Computing Software-as-a-Service Vorlesung Entwicklung und Umsetzung serviceorientierter Anwendungen Praxis-Vortrag: Jan Häußler, ITARICON 3.2. Vorlesung: Zusammenfassung, Prüfungsvorbereitung Abschlusspräsentationen der 3.2. Praktikumsergebnisse: alle Gruppen 2.2. Abgabe der Praktikumsergebnisse + Dokumentation Dr.-Ing. Iris Braun Vorlesung SOA, 10. Sicherheit (2) Folie 37