Sicherheit in Service-orientierten Architekturen Aktuelle Herausforderungen von Datenschutz und Datensicherheit in modernen Informationssystemen Seminar im Sommersemester 2007 Ursula Kotzur Betreuerin: Jutta Mülle IPD - Lehrstuhl für Systeme der Informationsverwaltung Universität Karlsruhe (TH)

Nachrichtensicherheit Identitätsmanagement Zusammenfassung Gliederung Einführung Nachrichtensicherheit Identitätsmanagement Zusammenfassung Sicherheit in Service-Orientierten Architekturen

Einführung (I) Was ist eine Service-orientierte Architektur? " Systemarchitektur-Konzept, das die Bereitstellung fachlicher Dienste und Funktionalitäten in Form von Services vorsieht. Ein Service ist in diesem Kontext eine Funktionalität, die über eine standardisierte Schnittstelle in Anspruch genommen werden kann." " Abstraktes Konzept einer Software-Architektur, in deren Zentrum das Anbieten, Suchen und Nutzen von Diensten über ein Netzwerk steht." Merkmale Lose Kopplung Virtualisierung: Austauschbarkeit von Komponenten Interoperabilität Sicherheit in Service-Orientierten Architekturen

Einführung (II) Was sind Web Services? Technologie zur Realisierung von SOAs Dienste, die über das Internet angesprochen werden können (mittels HTTP, FTP und SMTP) Server stellt einen Dienst zur Verfügung Client nimmt einen Dienst in Anspruch Kommunikation mittels XML-Nachrichten ( SOAP) Schnittstellenbeschreibung durch XML ( WSDL) Green White Service- Verzeichnis Yellow WSDL UDDI Service suchen 2 1 Service ver-öffentlichen/ registrieren SOAP SOAP Sprache: XML Service- Konsument Service- Anbieter WSDL SOAP Service nutzen 3 Sicherheit in Service-Orientierten Architekturen

Einführung (III) SSL Sicherheitskontext Dienstnehmer - Website - Dienstanbieter 1 Firewall HTTP-Port (Port 80) meist frei geschalten (ebenso Port 443 für SSL) wenn nicht evtl. SMTP-Port für Mailverkehr  Gefahr, da SOAP-Aufrufe Methoden aufrufen können. "XML Firewalls" SSL/TLS Bietet nur Transportsicherheit von Ende-zu-Ende / "Punkt-zu-Punkt" (von Anfangs zu Endpunkt, zB Bank und genau ein Kunde, 2 Beteiligte)  Für echt verteilte Anwendung, wie sie in einer SOA realisiert wird, meist ungeeignet (Bei Web-Services: Intermediäre)  Komplexe WS-Szenarien, in denen verschiedene Teile für verschiedene Empfänger verschlüsselt werden (feingranulare Sicherung), nur mit Transportsicherheit nicht möglich Bsp: Es existieren Zwischenstellen (Intermediäre), die die Daten auf Anwendungsebene verarbeiten: Versendete Bestelldaten und Kreditkartendaten werden von unterschiedlichen Services bearbeitet Performance leidet, da SSL-Handshake benötigt  Nachrichtensicherheit notwendig! VPN mit IPsec Sicherheitsleistung von IPsec relativ hoch, aber Einrichtung und Kommunikation nicht so flexibel und interoperabel wie bei SSL Endnutzer - Webbrowser - Dienstanbieter 2 Sicherheit in Service-Orientierten Architekturen

Gliederung Einführung Nachrichtensicherheit Identitätsmanagement XML Sicherheit XML Signature (XMLDsig) XML Encryption (XMLEnc) XML Key Management Specification (XKMS) Web Service Sicherheit WS-Security WS-* Family Identitätsmanagement Zusammenfassung Sicherheit in Service-Orientierten Architekturen

Nachrichtensicherheit Standards im Überblick Authen-tizität Autori-sierung Integrität Vertrau-lichkeit XML-Signature +   XML-Encryption XKMS SAML WS-Security Integrität Es ist nicht möglich, die zu schützenden Daten unautorisiert und unbemerkt zu manipulieren Vertraulichkeit Kein unautorisierter Informationsgewinn über die Daten möglich Authentizität / Authentifizierung / Authentifikation Echtheit und Glaubwürdigkeit von Daten oder Subjekten, die anhand eindeutiger Identität oder charakterisierender Eigenschaften überprüfbar ist. Autorisierung ( Zugriffskontrolle) Es sollen lediglich autorisierte Instanzen Zugriff auf bestimmte Dienste oder Daten erhalten Sicherheit in Service-Orientierten Architekturen

XML Signature (I) Status Funktion W3C-Recommendation seit 12. Februar 2002 RFC 3275 bei IETF Funktion Repräsentation digitaler Signaturen in XML Beliebige Teilbäume können signiert werden, ebenso externe Dokumente Ablauf Ausgangspunkt: kanonische XML-Dokumente Berechnung des Hashwerts: Message Digest Signierung mittels Public-Key-Verfahren Basis für XML Encryption ( <KeyInfo>) Kanonische XML-Dokumente: (http://www.w3.org/TR/xml-c14n) eindeutige normalisierte Repräsentation, die aus jedem wohlgeformten XML-Dokument erzeugt werden kann Beispiele: <e1   /> wird zu <e1></e1> <normId id=' &apos;       &apos; '/> wird zu <normId id="' '"></normId> CDATA-Abschnitte und !DOCTYPE werden entfernt Sicherheit in Service-Orientierten Architekturen

XML Signature (II) Erzeugung und Validierung von XML-Signaturen Canonical XML (W3C Standard): definiert eindeutige normalisierte Repräsentation, welche aus jedem wohl geformten XML-Dokument erzeugt werden kann. -- Vorgehen bei der Signierung Referenz(en) auf zu signierende Objekte erzeugen Transformation auf Datenobjekt anwenden (optional) Hashwert berechnen <Reference>-Element erzeugen Signatur erzeugen <SignedInfo>-Element erzeugen mit <SignatureMethod> <CanonicalizationMethod> <Reference>* <SignedInfo> normalisieren, Hashwert berechnen, als <Signature> speichern Schlüssel-Informationen hinzufügen (optional) Alles in ein <Signature>-Element einbetten Vorgehen bei der Validierung <SignedInfo>-Element normalisieren Integrität der Nachricht checken Referenzen auflösen Transformation(en) anwenden Daten hashen Berechnete Hashwerte mit übermittelten Hashwerten vergleichen Signatur verifizieren <SignedInfo>-Element hashen Übermittelten verschlüsselten Hashwert (Signatur) entschlüsseln Beide Hashwerte miteinander vergleichen aus: Melzer, I.: Service-orientierte Architekturen mit Web Services; Konzepte - Standards - Praxis, 2. Auflage, Spektrum 2007 Sicherheit in Service-Orientierten Architekturen

XML Signature (III) <Signature Id="MyFirstSig" xmlns="xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="xmldsig#dsa-sha1"/> <Reference URI="REC-xhtml1-20000126/"> <Transforms> <Transform Algorithm="REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue> <P>...</P><Q>...</Q><G>...</G><Y>...</Y> </DSAKeyValue> </KeyValue> </KeyInfo> </Signature> [s02-12] The required SignedInfo element is the information that is actually signed. Core validation of SignedInfo consists of two mandatory processes: validation of the signature over SignedInfo and validation of each Reference digest within SignedInfo. Note that the algorithms used in calculating the SignatureValue are also included in the signed information while the SignatureValue element is outside SignedInfo. [s03] The CanonicalizationMethod is the algorithm that is used to canonicalize the SignedInfo element before it is digested as part of the signature operation. Note that this example, and all examples in this specification, are not in canonical form. [s04] The SignatureMethod is the algorithm that is used to convert the canonicalized SignedInfo into the SignatureValue. It is a combination of a digest algorithm and a key dependent algorithm and possibly other algorithms such as padding, for example RSA-SHA1. The algorithm names are signed to resist attacks based on substituting a weaker algorithm. To promote application interoperability we specify a set of signature algorithms that MUST be implemented, though their use is at the discretion of the signature creator. We specify additional algorithms as RECOMMENDED or OPTIONAL for implementation; the design also permits arbitrary user specified algorithms. [s05-11] Each Reference element includes the digest method and resulting digest value calculated over the identified data object. It also may include transformations that produced the input to the digest operation. A data object is signed by computing its digest value and a signature over that value. The signature is later checked via reference and signature validation. [s14-16] KeyInfo indicates the key to be used to validate the signature. Possible forms for identification include certificates, key names, and key agreement algorithms and information -- we define only a few. KeyInfo is optional for two reasons. First, the signer may not wish to reveal key information to all document processing parties. Second, the information may be known within the application's context and need not be represented explicitly. Since KeyInfo is outside of SignedInfo, if the signer wishes to bind the keying information to the signature, a Reference can easily identify and include the KeyInfo as part of the signature. Sicherheit in Service-Orientierten Architekturen

XML Encryption (I) Status Funktion W3C-Recommendation seit 10. Dezember 2002 Funktion Repräsentation verschlüsselter Inhalte in XML Beliebige Teilbäume können verschlüsselt werden, ebenso externe Dokumente Beliebige Verschlüsselungsalgorithmen anwendbar Erweitert <KeyInfo> aus digitaler Signatur Übertragung von (verschlüsselten) geheimen Schlüsseln möglich ( <EncryptedKey>) Teile können für verschiedene Empfänger unterschiedlich verschlüsselt werden. (Ein Dokument für verschiedene Empfänger) Sicherheit in Service-Orientierten Architekturen

XML Encryption (II) <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo> <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </PaymentInfo> HIER: vereinfachte Darstellung, natürlich gibt es mehr Tags (KeyInfo, KeyName, …) Quelle: Spezifikation: http://www.w3.org/TR/xmlenc-core/ Kreditkartendaten sollen geschützt werden.  Der Teilbaum "CreditCard" wird verschlüsselt  Man erkennt noch nicht mal was verschlüsselt wurde, ob es sich um Kreditkarten oder Lastschrift gehandelt hat Genau könnten nur die Kinder von "CreditCard" oder einzelne Elemente wie die Kreditkartennummer verschlüsselt werden. Und natürlich die komplette "PaymentInfo". Super-Encryption (mehrfache Verschlüsselung) möglich zB Teile verschieden verschlüsseln und dann das gesamte Dokument Sicherheit in Service-Orientierten Architekturen

Zusammenspiel von XMLDsig und XMLEnc Sicherheit in Service-Orientierten Architekturen

XML Key Management Specification Status W3C-Note seit 30. März 2001 Funktion Protokoll zur Validierung und Verwaltung von PKI-Schlüsseln Kompatibel zu XML Signature und XML Encryption Bestandteile XML Key Information Service Specification (X-KISS) Lokalisierung von Schlüsselinformationen und Validierung von Schlüsseln Delegation von <KeyInfo> an Trust service XML Key Registration Service Specification (X-KRSS) Registrierung und Verwaltung öffentlicher Schlüssel einfaches Protokoll für leichtgewichtige XML Anwendungen, um an die notwendigen Schlüssel für die Signaturen und die Verschlüsselung zu gelangen Sicherheit in Service-Orientierten Architekturen

WS-Security (I) Status Funktion Web Services Security: SOAP Message Security 1.1 (WS-Security 2004) ist OASIS-Standard seit Februar 2006 Funktion Bietet Rahmenwerk zur Einbettung bereits bestehender Standards in den SOAP-Nachrichten-Header XML-Signature zur Signierung XML-Encryption zur Verschlüsselung definiert ein SOAP-Header-Element, in dem sicherheitsbezogene Daten enthalten sind Anhängen von Security Credentials an SOAP-Nachrichten stellt Kontext für sichere Ende-zu-Ende Kommunikation bereit Geschichte 1999 von Microsoft, IBM und VeriSign entworfen Sicherheit in Service-Orientierten Architekturen

WS-Security (II) <S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..." xmlns:xenc="..."> <S11:Header> <wsse:Security> <xenc:ReferenceList> <xenc:DataReference URI="#bodyID"/> </xenc:ReferenceList> </wsse:Security> </S11:Header> <S11:Body> <xenc:EncryptedData Id="bodyID"> <ds:KeyInfo> <ds:KeyName>CN=Hiroshi Maruyama, C=JP</ds:KeyName> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>...</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </S11:Body> </S11:Envelope> Beispiel aus http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SOAPMessageSecurity.pdf Seite 45/46 - 9.1 xenc:ReferenceList Seite 46/47 – 9.2 xenc:EncryptedKey enthält <ds:KeyInfo><wsse:SecurityTokenReference>… Sicherheit in Service-Orientierten Architekturen

Sicherheitstokendienst WS-Security (III) Security Tokens Unsigned Security Token Username Signed Security Token X.509 Zertifikate Kerberos Tickets Seit Ende 2004 auch SAML Token Nachrichtenfluss 1. Anforderung für Tokens wird gesendet. Web Service-Client Sicherheitstokendienst 2. Erhaltene Tokens werden zur SOAP-Nachricht hinzugefügt. 4. Tokens werden überprüft. 3. Nachricht wird signiert und an Web Service gesendet. Web Service 5. Antwort wird empfangen Sicherheit in Service-Orientierten Architekturen

WS-* Family WS-Trust WS-SecureConversation WS-Policy WS-Federation Möglichkeiten zum initialen Austausch von sicherheitsrelevanten und geheimen Daten WS-SecureConversation Rahmen, der das Erzeugen eines Sicherheitskontext (SecurityContextToken) ermöglicht WS-Policy Formulierung von Sicherheitsanforderungen und Richtlinien, die erfüllt werden müssen, um mit einem Dienst interagieren zu können WS-Federation Integration von Vertrauensdomänen über Unternehmensgrenzen hinweg Demo: SSO with WS-Federation (PRP) http://ip.tm.uni-karlsruhe.de/demo/demo/ WS-Privacy Einbindung von Forderung zur Vertraulichkeit WS-Authorization Richtlinien zur Zugriffskontrolle WS-... WS-Federation Verwendet Elemente aus WS-Policy, WS-Trust und WS-SecureConversation OASIS-Standards: WS-SecureConversation v1.3 WS-Trust 1.3 Sicherheit in Service-Orientierten Architekturen

Gliederung Einführung Nachrichtensicherheit Identitätsmanagement Zentrales Identitätsmanagement Microsoft Passport Föderatives Identitätsmanagement Liberty Alliance Shibboleth Zusammenfassung Sicherheit in Service-Orientierten Architekturen

Identitätsmanagement Notwendigkeit eines Identitätsmanagements Bild aus: https://www.prime-project.eu/prime_products/presentations/idmanage-berlin-20060913.pdf Sicherheit in Service-Orientierten Architekturen

Zentrales Identitätsmanagement Microsoft Passport Prinzip Nutzer speichern ihr Profil bei Microsoft mindestens E-Mail und Passwort erforderlich stimmen bei Anmeldung zu, dass ihre Daten an alle beteiligten Dienste weitergegeben werden dürfen Kann per Single-Sign-On alle beteiligten Dienste nutzen Dienste bezahlen für diesen Service Nachteile: Eine Partei (hier: Microsoft) als zentraler Vertrauensanker? Single Point of Failure Globale Benutzer ID Benutzername/Passwort einzige Authentifizierungsmethode Inzwischen abgelöst durch Windows Live ID InfoCard - Eine aktuelle Bemühung von Microsoft in Richtung eines Identity Metasystems. Kernpunkt von InfoCard ist der tief im Betriebssystem eingebettete Identity Selector (WinFX), der es ermöglicht, mit Service Providern und Identity Providern zusammen zu arbeiten, wobei digitale Identitäten auf intuitive visuelle Weise dargestellt werden. Der Benutzer entscheidet, welche Information er an wen preisgeben will. Neben Usability stehen damit auch Privacy-Gedanken im Mittelpunkt. InfoCard basiert auf WS-Trust und verwandten Protokollen. Das Token-Format wird jedoch nicht festlegt, sodass InfoCard als Identity Meta-System arbeitet. Im Weblog des Microsoft Identity Architekten Kim Cameron finden sich weitere Informationen: Identityblog (http://www.identityblog.com/) Sicherheit in Service-Orientierten Architekturen

Föderatives Identitätsmanagement Vorteile: Informationen verteilt auf verschiedenen (von einander unabhängigen) Systemen Somit keine zentrale Kontrolle Verschiedene Authentifizierungsmethoden möglich Bild: http://info.cba.ksu.edu/skovar/844/projects/FIM/ Sicherheit in Service-Orientierten Architekturen

Liberty Alliance (I) 2001 von etwa 30 Organisationen gegründet Mittlerweile um die 150 Mitglieder aus verschiedensten Sparten (auch Behörden) Ziel: Schaffung von Standards, Richtlinien und Methoden für föderiertes Identitätsmanagement Struktur: Management Board Service Group Subteams Identity Services Expert Groups Identity Infrastructure & Policy Special Interest Groups Applying Liberty Sicherheit in Service-Orientierten Architekturen

Liberty Alliance (II) Nutzt bereits bestehenden Standards SAML XML Signature XML Encryption ... Circle of Trust Vertrauensverbund zwischen kooperierenden Unternehmen zur Nutzung von digitalen Identitäten über Unternehmensgrenzen hinweg Beteiligte Principal Identity Provider (IdP) Service Provider (SP) Liberty Enabled Clients or Proxies (LECP) Ein typischer Einsatz von Federated Identity ist, wenn ein Unternehmen oder eine Organisation Angestellte anderer Unternehmen oder Organisationen authentifizieren und autorisieren muss. Jede Organsisation oder Unternehmen würde dabei als Identity Provider für ihre eigenen Angestellten agieren und kann die anderen zur Authentifizierung deren Angestellten verwenden. Ausserdem kann mittels Attribute Discovery derjenige Identity Provider gefunden werden, der ein bestimmtes Attribut für den Benutzer enthält, denn ein Benutzer könnte Konten bei mehreren Identity Providern besitzen, die unterschiedliche Attribute verwalten. Ein Attribut könnte also von einem anderen Identity Provider geholt werden als von dem, der zur Authentifizierung benutzt wurde. Sicherheit in Service-Orientierten Architekturen

Liberty Alliance (III) Enterprise Circle of Trust Supplier 1 Supplier 2 Supplier 3 Name: Joe Self Service Providers Payable Application IdP (e.g. my company) Supply Chain Aggregator Calendar work profile News Source News Source Name: Joe Self News Source Service Providers Merchants IdP (e.g. my bank) Service Aggregator home profile Friends & Family Notification Consumer Circle of Trust Sicherheit in Service-Orientierten Architekturen

Liberty Alliance (IV) Architektur Liberty Identity Federation Framework (ID-FF) ermöglicht Verwaltung und Föderation von Identitäten durch Single-Sign-On und Session-Management Liberty Identity Services Interface Specifications (ID-SIS) ermöglicht interoperable Identitätsdienste Liberty Identity Web Services Framework (ID-WSF) stellt Rahmenwerk zur Bildung interoperabler Identitätsdienste bereit ID-FF Protokolle: Single-Sign-On and Federation defines a request and response protocol Name Registration During federation, the identity provider generates an opaque value that serves as the initial name identifier that both the service provider and the identity provider use in referring to the Principal when communicating with each other. This name identifier is termed the <IDPProvidedNameIdentifier>. Federation Termination Notification When the Principal terminates an identity federation between a service provider and an identity provider from the service provider, the service provider MUST send a <FederationTerminationNotification> message to the identity provider. The service provider is stating that it will no longer accept authentication assertions from the identity provider for the specified Principal. Single Logout Name Identifier Mapping Sicherheit in Service-Orientierten Architekturen

Liberty Alliance (V) Sicherheit in Service-Orientierten Architekturen One day on Sunday, Joe decides to order beers at BlueLiquor website that is his favorite liquor shop. When he tries to access to the BlueLiquor website, he is redirected to WhiteBroadBand website since he has not been authenticated. WhiteBroadBand is his Identity Provider, and he submits his credential to WhiteBroadBand. Once he is authenticated by WhiteBroadBand, he can make access to the BlueLiquor website. He orders a dozen beers at the BlueLiquor website, and asks to deliver them to his pre-registered shipping address. He also requests BlueLiquor to register that his shipping address information is available at this site, to the Discovery Service [LibertyDisco] hosted by WhiteBroadBand, so that his shipping address information attribute at the BlueLiquor website can be shared with other websites. BlueLiquor registers it to Discovery Service, and sets Joe’s attribute sharing policy as it can be shared with other websites. Subsequently, he tries to make access to the YellowPizza website. Since he has already been authenticated by WhiteBroadBand, he does not need to be authenticated again. He orders a pepperoni pizza, and is asked where they should deliver it. He requests YellowPizza to get his shipping address information from other website, and they get it from the BlueLiquor website. Finally, a dozen beers and the mayonnaise pizza are delivered to his residence. Sicherheit in Service-Orientierten Architekturen

Liberty Alliance (VI) Beispiel: T-Online "Netzausweis" T-Com fungiert als Identity Provider Bietet Single-Sign-On, Single-Logout Log-In via E-Mail-Adresse und Passwort Netzausweis-LogIn bei Partnerseiten Verwaltung der LogIn-Einstellungen im Kundencenter Anmeldung zum "Netzausweis Zusatzdienste" notwendig "Automatische Login bei T-Online Partnerseiten" standardmäßig ausgeschaltet Partner: Sicherheit in Service-Orientierten Architekturen

Liberty Alliance (VII) Pressemitteilung auf telekom.com: IDDY Award 2006 der Liberty Alliance für T-Online Netzausweis 14.09.2006 T-Com erhält Auszeichnung für herausragende Leistungen beim Einsatz von Digital Identity Management Lösungen "Wir gratulieren T-Com zur Einführung einer auf den Spezifikationen von Liberty basierenden Lösung, die nach dem Urteil der IDDY-Jury zum "Besten vom Besten" gehört, was das digitale Identitätsmanage-ment heute zu bieten hat." (George Goodman, Präsident des Vorstands der Liberty Alliance und Direktor des Platform Capabilities Lab von Intel.) Sicherheit in Service-Orientierten Architekturen

Zusammenhang zwischen den Standards Microsoft / IBM OASIS Liberty Alliance WS-Federation SAML 2.0 Liberty Phase 3 WSS IDFF 1.2 WSF 1.2 WS-Trust WS-Policy SAML 1.1 IDFF 1.1 WS-Security SAML 1.0 IDFF 1.0 Legend Dependency Relation nach: Windley, Ph.: Digital Identity. 1. Edition. O'Reilly, 2005 Sicherheit in Service-Orientierten Architekturen

Shibboleth (I) 2000 parallel und unabhängig zum Liberty Alliance Project im Hochschul-Umfeld in den USA entstanden ermöglicht SSO, sowie föderierte Administration von zugangsbeschränkten Ressourcen Legt besonderen Wert auf Schutz personenbezogener Daten Grundlage: Family Educational Rights and Privacy Act, 1974 Nutzt bereits bestehende Standards wie SAML, SSL Sicherheit in Service-Orientierten Architekturen

Shibboleth (II) Bestandteile Identity Provider (IdP) Attribute Authority (AA) Handle Service (HS) Attribute sources Local sign-on system (SSO) Service Provider (SP) Assertion Consumer Service (ACS) Attribute Requestor (AR) Resource Manager (RM) Where are you from? (WAYF) Deutsches Forschungsnetz betreibt und pflegt unter DFN-AAI einen WAYF-Server https://www.aai.dfn.de/ Sicherheit in Service-Orientierten Architekturen

Shibboleth (III) Ablauf Benutzer versucht auf eine von Shibboleth geschützte Quelle auf dem Server des Service Providers zuzugreifen. 3., 4. Der Benutzer wird auf einen Where Are You From (WAYF) Server umgeleitet, wo er seine Home Site (IdP) anzeigen/angeben soll. 5. Der Benutzer wird zum Handle Service seines IdP umgeleitet. 6, 7 Benutzer authentifiziert sich bei seinem IdP. Er benutzt hierzu "local credentials" (). 8. Der Handle Service (HS) generiert eine eindeutige ID (Handle) und leitet den Benutzer zum Assertion Consumer Service (ACS) der Service Provider weiter. Der ACS bestätigt/validiert/überprüft die gelieferte 'Erklärung' (Assertion), stellt eine Session/Sitzung her und übergibt sie dem Attributes Requastor (AR). 9, 10. Der AR benutzt das Handle um den AA des IdP nach Attributen anzufragen. Die AA antwortet mit einem 'attribute assertion to attribute release policies'; Die Seite des SP benutzt die Attribute zur Zugriffskontrolle und anderen application-level Entscheidungen. Quelle: http://switch.ch/aai/demo/medium.html Sicherheit in Service-Orientierten Architekturen

Vergleich: Shibboleth – Liberty Alliance Liberty Alliance und Shibboleth haben leicht unterschiedliche Lösungensansätze: Liberty Alliance: "Ich weiß, wer du bist." Shibboleth:"Ich weiß, woher du kommst" Beide sind grundlegend an der Entwicklung von SAML 2.0 beteiligt Internet2 Mitglied bei Liberty Alliance Sicherheit in Service-Orientierten Architekturen

Zusammenfassung Große Auswahl an Sicherheitsstandards Sicherheit sowohl auf Transport- als auch auf Anwendungsschicht möglich Identitätsmanagement gerade im Hinblick auf verteilte Dienste wichtig Zur Zeit ist Liberty Alliance hier führend Clientseitige Technologien wie CardSpace (InfoCard) von Microsoft gewinnen in Zukunft evtl. an Bedeutung Prinzip der Selbstverwaltung Speicherung der Daten auf dem Heimrechner, PDA, o.ä. Sicherheit in Service-Orientierten Architekturen

Ende Fragen ??? Sicherheit in Service-Orientierten Architekturen

Aus der offiziellen Pressemitteilung: "Leitmotiv von PRIME ist, die personenbezogenen Daten unter der Kontrolle des Nutzers zu belassen. Es verfolgt dabei einen integrierten Ansatz mit dem Ziel eines maximalen Datenschutzes über die Durchsetzung von Datenschutz-Policies, wenn der Nutzer seine Daten aus seinem Verfügungsbereich herausgibt. Der Nutzer steht im Zentrum. Ihm wird das für ihn Datenschutzrelevante deutlich gemacht, so dass er informierte Entscheidungen über die Verarbeitung seiner personenbezogenen Daten treffen kann. PRIME bietet Lösungen an und arbeitet heraus, was noch zu tun bleibt." Projektlaufzeit März 2004 bis Februar 2008 Förderung: Das PRIME-Projekt wird gefördert vom Sechsten Forschungsrahmenprogramm der Europäischen Union und vom Schweizer Bundesamt für Bildung und Wissenschaft. PRIME Whitepaper (aktuelle Version: v2.0 vom Juni 2007) https://www.prime-project.eu/prime_products/whitepaper/ Sicherheit in Service-Orientierten Architekturen

Secure Assertion Markup Language (SAML) Status SAML v2.0 ist OASIS-Standard seit 15. März 2005 Funktion Ermöglicht Austausch von authentifizierungs- und autorisierungsbezogenen Informationen (Assertions) Bestandteile: SAML Assertions SAML Protokoll SAML Bindings und Profile Anwendungsfälle Web Browser Single Sign-On (SSO) Authorization Service Back Office Transaction Assertion: Sicherheitsbestätigungen, Vertrauenserklärungen Vollständig programmiersprachen-, plattform- und herstellerunabhängig SAML Protokoll: request/response Protokoll zum Austausch von Assertions SAML Binding: Kommunikation mit SAML authorities SAML request7response Protokoll => Standard Kommunikationsprotokoll (zB SOAP über HTTP) SAML Profile: Beschreiben wie SAML Assertions in ein Rahmenwerk oder Protokoll eingebunden und extrahiert werden Anwendungsfälle (Use Cases): http://www.oasis-open.org/committees/security/docs/draft-sstc-use-strawman-03.html Sicherheit in Service-Orientierten Architekturen

Secure Assertion Markup Language (SAML) SAML Assertions Typ Erklärung Authentication Benutzer oder Dienst wurde authentifiziert Attribute Benutzer oder Dienst werden gewisse Attribute (Rollen, Informationen) zugeordnet Authorization Decision Benutzer oder Dienst ist autorisiert, auf bestimmte Ressourcen zuzugreifen Sicherheit in Service-Orientierten Architekturen