IT-Sicherheit Anwendungssicherheit: AuthN/AuthZ in der Cloud

Transkript

1 Karl Martin Kern IT-Sicherheit Anwendungssicherheit: AuthN/AuthZ in der Cloud

2 Überblick Was ist das Problem? Anforderungen an IdM in verteilten Systemen Gebräuchliche Protokolle OpenID Oauth / OAuth2 SAML 2

3 Was ist eigentlich das Problem? Konventionelle Webanwendung: Google: Verschiedene Identitäten bei verschiedenen Diensten Redundante Informationen Extra Login bei jeder Anwendung Sharing von Daten nur innerhalb Anwendung Facebook: Pseudo Nym OWASP: securityfreak Work: Von: 3

4 Wunschzettel Einheitliche Identität über verschiedene Dienste hinweg Einheitliche Credentials Einmalige Anmeldung 4

5 Mehr Wünsche Kontrollierte Freigabe von Daten Sicherer, eingeschränkter Zugriff durch Dritte Dienstübergreifende Freigabe 5

6 Lösungsansätze Verschiedene Ansätze (MS Passport, Liberty Alliance, ) Derzeit Konzentration auf zwei verbreitete Standards: OpenId und OAuth 6

7 Wunschzettel OpenId Einheitliche Identität für verschiedene Websites Sicherer Umgang mit Credentials Single Sign On Kontrollierte Weitergabe von Benutzerdaten an Anwendungen OAuth Erlaubt Dritten den Zugriff auf Dienste im Namen des Nutzers Sicherer Umgang mit Credentials Gezielte Freigabe bestimmter Daten 7

8 OpenID Protokoll für Authentifizierung und SSO URL-basierte ID (z. B. Dezentralisiert: keine Einschränkung auf bestimmten Provider Protokollerweiterungen erlauben z. B. Austausch von beliebigen Attributen Anforderung / Prüfung von Login-Methoden 8

9 OpenID Benutzer (Webbrowser) http(s) https https OpenID Relying Party OpenID-Provider 9

10 OpenID-Ablauf Benutzer identifiziert sich bei der RP mit seiner OpenID RP bestimmt zuständigen OP aus ID (Discovery per XRI, YADIS) RP assoziiert sich mit OP (Schlüsselaustausch) RP stellt Authentifizierungsanfrage an OP per Redirect 10

11 OpenID User Identifier Benutzer registriert sich bei OpenID-Provider erhält einen Identifier (eine OpenID ) OpenID-Identifier ist http/https-uri oder XRI Identifier enthält Information über Provider ( Discovery) Provider sind z. B. Google, Yahoo, Flickr, Wordpress Auch eigener Provider möglich (falls von RP akzeptiert) 11

12 OpenID Initiierung und Discovery Benutzer identifiziert sich gegenüber der RP mit seiner OpenID RP normalisiert Eingabe zu Identifier RP führt Discovery durch (nicht näher behandelt) liefert nötige Informationen für weiteren Ablauf: OP Endpoint URL Protocol Version 12

13 OpenID Request Format OpenID-Nachrichten: Liste von Key-Value-Paaren Keys beginnen mit openid Meist als HTTP-GET oder -POST-Parameter Werte kommen nicht mehrfach vor Alle http-requests enthalten die Parameter openid.ns (fester Wert ) openid.mode: gibt die Art der Nachricht an 13

14 OpenID Association (optional) RP sendet direkten Request an OP mit openid.mode=associate openid.assoc_type (Signaturalg.) openid.session_type (Plain Text oder DH) Weiteren, typabhängigen Parametern, z. B. Parameter für Diffie-Hellman-Schlüsselaustausch 14

15 OpenID Association (optional) OP sendet response mit Parametern im body: assoc_handle assoc_type session_type expires_in Weiteren, typabhängigen Parametern, z. B. Parameter für Diffie-Hellman-Schlüsselaustausch 15

16 OpenID Association (optional) Ergebnis: shared secret für Signatur weiterer Requests 16

17 OpenID-Ablauf OP liefert Login-Formular an Benutzer Benutzer authentisiert sich gegenüber OP OP bestätigt Authentifizierung per Redirect zur RP mit digital signierten Daten RP validiert Gültigkeit der Antwort (mittels Daten aus Assoziation) Über Protokollerweiterung können Zusatzdaten (Name, E- Mail, ) übertragen werden. 17

18 OpenID Authentisierungs-Request RP schickt indirekten Request (Redirect im Browser) an OP Parameter: mode (checkid_immediate, checkid_setup) claimed_id, identity assoc_handle return_to Realm (Info für Benutzer über Scope der AuthN) 18

19 OpenID Authentisierung OP authentifiziert Benutzer Nicht durch OpenID spezifiziert z. B. per Passwort Benutzerinteraktion nur bei checkid_setup checkid_immediate ohne Interaktion Vorhandene Session z. B. Anschlusserkennung 19

20 OpenID Authentisierung Positive assertion: OP antwortet mit indirektem response (redirect) mode=id_res op_endpoint claimed_id, identity return_to response_nonce assoc_handle signed sig 20

21 OpenID Authentisierung Negative assertion: OP antwortet mit indirektem response (redirect) mode=setup_needed, cancel 21

22 OpenID Authentisierung RP prüft Response: URL vs. return_to Discovery Info(Claimed_identifier) Nonce Signatur Falls keine Association vorhanden OP verwendet lokale Association Signaturprüfung über direkten Request (mode=check_authentication) 22

23 OpenID Extensions Extension-Mechanismus erlaubt Übertragung weiterer Informationen Können selbst definiert werden Standard definiert bereits Extensions AX (Attribute Exchange) PAPE (Provider Authentication Policy Extension) Simple Registration Extension 23

24 OpenID Attribute Exchange OpenID Extension Erlaubt Austausch von zusätzlichen Informationen Name Zusätzliche Parameter openid.ax.* 24

25 OpenID PAPE OpenID Extension Erlaubt Austausch von Informationen über geforderte und erfüllte Authentisierungsklassen Zusätzliche Parameter openid.pape.* 25

26 So besser nicht... Willkommen bei FaceTube++ Wenn du möchtest, können wir alle deine Freunde automatisch hier einladen. Gib uns doch einfach deinen Benutzernamen und dein Passwort für deinen - Account und dein Adressbuch Wir stellen auch sicher nix damit an, fest versprochen! Anforderungen: Sicheres Handling von Credentials Autorisierung auf Ressourcenebene 26

27 Oauth (RFC 5849) Protokoll zur Autorisierung von API-Zugriffen Tokenbasiert Sicherer Umgang mit Credentials Prinzipiell unabhängig von Authentisierungsprotokoll Für Verwendung mit OpenID entworfen und geeignet Von: 27

28 OAuth-Rollen Benutzer Konsument Service Provider Identity Provider (z. B. OpenID Provider) 28

29 Oauth-Ablauf (Setup) Assoziation erfolgt nicht eigenständig Entwickler / Admin meldet Konsument beim Service- Provider an Service Provider stellt ID und Secret zur Verfügung Entwickler / Admin integriert / konfiguriert ID und Secret beim Konsumenten 29

30 Oauth-Ablauf (Request Token) Konsument fragt Daten bei SP an. SP fordert Autorisierung Konsument fordert Request-Token an SP stellt unautorisiertes Request-Token aus Konsument leitet Benutzer zum SP zur Autorisierung 30

31 Oauth-Ablauf (User Consent) SP authentisiert Benutzer (z. B. per OpenID) SP erfragt Freigabe vom Benutzer Benutzer erteilt Freigabe SP kennzeichnet Request- Token als autorisiert SP leitet Benutzer zurück zum Konsumenten 31

32 Oauth-Ablauf (Access Token) Konsument tauscht Request-Token bei SP gegen Access-Token aus. Konsument fragt Daten erneut an und autorisiert sich mit Access Token Service Provider verifiziert Token und liefert Daten aus Konsument verarbeitet Daten wie gewünscht. 32

33 Oauth-Requests OAuth-Requests mit zwei Sätzen von Credentials Authentisierung des Client Authentisierung des Resource Owner Client-Authentisierung über Shared Secret oder RSA-Keypaar Resource Owner-Authentisierung über Token 33

34 Oauth-Signatur Authentisierung über Parameter und Signaturen Übertragung über Http-Authorization-Header Http-Request-Body (POST-Parameter) Http-Query-Parameter (GET-Parameter) Parameter: oauth_consumer_key: Identifiziert Client (analog username) oauth_token oauth_signature_method (HMAC-SHA1,RSA_SHA1,PLAINTEXT) oauth_timestamp oauth_nonce oauth_version 34

35 Oauth-Signatur Normalisierung des Requests per Signature Base String Elemente des Requests werden zu einem String zusammengefügt, getrennt mit & HTTP-Request-Methode (GET, POST) Hostname (Host-Header) Basis-URL des Requests Normalisierte Liste der Parameter Signatur wird über Base String erstellt und als oauth_signature-parameter angefügt 35

36 Oauth 1 - Erfahrungen Einheitlicher Flow gut geeignet für Webanwendungen Nur begrenzt geeignet für Standalone-Apps und mobile Anwendungen Schlecht skalierbar Krypto-lastiges Protokoll, aufwendig und komplex umzusetzen Langlebige Tokens sind Sicherheitsrisiko 36

37 Oauth 2.0 Entwicklung auf Basis der Erfahrung mit OAuth 1 Ziele der Weiterentwicklung Flexiblerer Einsatz in verschiedenen Szenarien Verschiedene Flows / Grant types Einfacheres Handling für Entwickler Bearer tokens und vereinfachte Signaturen Sauberere Trennung verschiedener Rollen Trennung in AuthN-Server und Resource-Server Begrenzung der Token-Lebensdauer Trennung in request und access tokens 37

38 Oauth 2.0 Protocol Flow 38

39 Oauth 2.0 Grant Types getrennte Flows für unterschiedliche Use Cases Authorization Code Autorisierung über AuthZ-Server Implicit vereinfachter Authorization Code flow, z. B. für Browser-Clients Resource Owner Password Credentials für Clients, die Credentials zwar durchreichen, aber nicht speichern sollen Client Credentials Client erhält Token über seine eigenen Credentials (Client ist resource owner oder Autorisierung wurde auf getrenntem Kanal vereinbart) 39

40 Oauth 2.0 Client Types Confidential client Kann seine Credentials geheim halten (z. B. Webserver) oder sich auf sonstige Weise sicher authentisieren Public client Keine sichere Speicherung von Credentials oder sonstige sichere Authentisierung möglich (z. B. AJAX-Client) Native application Public client auf Device beim Resource Owner (z. B. App auf mobilem Endgerät), kann dynamische, aber nicht statische Credentials geheimhalten 40

41 Oauth 2.0 Access Token Autorisierung des Zugriffs auf Ressourcen Für den Client undurchsichtiger String Kann Referenz auf die AuthZ-Info sein oder diese direkt enthalten Struktur und Inhalte nicht weiter spezifiziert Oft kurzlebiges, eingeschränktes Token (in Zusammenhang mit Refresh Token) 41

42 Oauth 2.0 RefreshToken Autorisierung für Ausstellung neuer Access Tokens (optional) Für den Client undurchsichtiger String Nur Referenz auf AuthZ-Information Wird nur mit AuthZ-Server, nicht mit Resource Server verwendet langlebig 42

43 Oauth 2.0 Authorization Code Flow 43

44 Oauth 2.0 Resource Owner Password Flow 44

45 Oauth 2.0 Zugriff auf Resourcen Verschiedene Token-Typen mit unterschiedlichem Vorgehen bei der Nutzung Bearer token: Token selbst genügt als Autorisierung Token wird mit Request übertragen Einfaches Handling Erfordert sichere Übertragungswege MAC token: Request wird mit zum Token gehörigen Key signiert Erschwert Manipulation des Requests Keine Sicherung gegen Mitlesen 45

46 Oauth 2 - Zusammenfassung Flexibler als OAuth1 Einfachere Implementierung Sicherheit basiert auf https, keine eigenen Signaturmechanismen Eher für Enterprise-Einsatz 46

47 Security Markup Assertion Language (SAML) XML-basierter Standard zum Austausch von AuthN-/AuthZ-Informationen Entwickelt durch OASIS (WS-*-Standards) Anwendungsfälle: Single Sign On Autorisierung Verteilte Transaktionen Definiert: Assertions Protokolle Profile 47

48 SAML-Assertions Assertions enthalten Aussagen über ein Subjekt Aussagen werden durch Aussteller bestätigt Aussagen sind Authentication Statements Attribute Statements Authorization Decision Statements 48

49 Authentication Statements Information über durchgeführte Authentisierung Identität des Subjekts Zeitpunkt der Authentisierung Art der Authentisierung <saml:subject> <saml:nameid <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdata NotOnOrAfter=" T02:44:24.173Z" Recipient=" </saml:subjectconfirmation> </saml:subject> <saml:authnstatement AuthnInstant=" T09:22:00" SessionIndex="b07b804c-7c29-ea f3d6f7928ac"> <saml:authncontext> <saml:authncontextclassref> urn:oasis:names:tc:saml:2.0:ac:classes:passwordprotectedtransport </saml:authncontextclassref> </saml:authncontext> 49

50 Attribute Statements Information über Eigenschaften/Attribute des Subjekts Name Adresse... <saml:attributestatement> <saml:attribute FriendlyName="fooAttrib" Name="SFDC_ATTR" NameFormat="urn:oasis:names:tc:SAML:2.0:attrnameformat:unspecified"> <saml:attributevalue xmlns:xs=" xmlns:xsi=" xsi:type="xs:string"> user101 </saml:attributevalue> </saml:attribute> </saml:attributestatement> 50

51 Authorization decision statements Information über Berechtigungen des Subjekts Resource AuthZ-Entscheidung <saml:authzdecisionstatement Resource=" Decision="Permit"> <saml:action Namespace="urn:oasis:names:tc:SAML:1.0:action:ghpp"> GET </saml:action> </saml:authzdecisionstatement> 51

52 SAML-Assertions (Beispiel aus <saml:assertion xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" xmlns:xs=" xmlns:xsi=" ID="b07b804c-7c29-ea f3d6f7928ac" Version="2.0" IssueInstant=" T09:22:05"> <saml:issuer> <ds:signature xmlns:ds=" <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"> 3f7b3dcf ecd-92c8-1544f346baf8 </saml:nameid> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdata InResponseTo="aaf a-fe114412ab72" Recipient=" NotOnOrAfter=" T09:27:05"/> </saml:subjectconfirmation> </saml:subject> 52

53 SAML-Assertions <saml:conditions NotBefore=" T09:17:05" NotOnOrAfter=" T09:27:05"> <saml:audiencerestriction> <saml:audience> </saml:audiencerestriction> </saml:conditions> <saml:authnstatement AuthnInstant=" T09:22:00" SessionIndex="b07b804c-7c29-ea f3d6f7928ac"> <saml:authncontext> <saml:authncontextclassref> urn:oasis:names:tc:saml:2.0:ac:classes:passwordprotectedtransport </saml:authncontextclassref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement> <saml:attribute xmlns:x500="urn:oasis:names:tc:saml:2.0:profiles:attribute:x500" x500:encoding="ldap" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid: " FriendlyName="eduPersonAffiliation"> <saml:attributevalue xsi:type="xs:string">member</saml:attributevalue> <saml:attributevalue xsi:type="xs:string">staff</saml:attributevalue> </saml:attribute> </saml:attributestatement> </saml:assertion> 53

54 SAML-Assertions Assertions können verschlüsselt / signiert sein Nutzung von XML-Standards XML Signature XML Encryption 54

55 SAML-Assertions Nutzung in SAML-Protokollen Nutzung auch in anderen Situationen üblich Als Oauth-Token Als Tokens in WS-Security... 55

56 SAML-Protokolle SAML definiert Protokolle zum Austausch von Assertions: Assertion Query and Request Protocol Authentication Request Protocol Artifact Resolution Protocol Name Identifier Management Protocol Single Logout Protocol Name Identifier Mapping Protocol 56

57 SAML-Protokolle Protokolle XML-basiert Keine Festlegung auf Transportprotokoll Verschiedene Bindings für Transport: SOAP Http-GET Http-POST... 57

58 SAML-Profile Beschreiben das Zusammenspiel von Assertions, Protokollen und Bindings Beschreiben jeweils definierten Use Case Beispiele: Web Browser SSO Profile Identity Provider Discovery Profile Single Logout Profile Assertion Query/Request Profile 58

59 SAML - Web Browser SSO 59