1 / 34

Federated Security

Lecture on. Federated Security. Can delegated trust work?. Walter Kriha. Overview. Why we need federated trust? Direct trust does not scale in distributed systems What makes federated trust secure? Leveraging high quality direct trust relations and delegation of authority

hjerry
Download Presentation

Federated Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture on Federated Security Can delegated trust work? Walter Kriha

  2. Overview • Why we need federated trust? Direct trust does not scale in distributed systems • What makes federated trust secure? Leveraging high quality direct trust relations and delegation of authority • Cross-Domain Trust between infrastructures • Web-SSO Architectures • Identity and Federation in Social Networks (Facebook etc.)

  3. Super-Hub Architecture Direct trust does not scale!

  4. Ways to combine registries Meta Directory Virtual Directory Federated Identities META Registry Service Interface User Registry User Registry copy and replicate dynamically pull User Registry User Registry User Registry User Registry exchange metadata on users. Allow aliases to protect users. Do not expose login credentials Consistency? Name clashes? Privacy? Politics and Economics? Performance? Name clashes? Privacy? Politics and Economics? Trust? Control? QoS?

  5. Federated Visa Card System Dealer Present card Customer Request payment Issue card Card Issuing Bank Dealers Bank clearing Visa

  6. „Outsourcing“ of Trust Establishment Present request and Proof of Identity Identity Provider Token Return signed token containing authentication statement Trust relation to IP Present token to establish remote, authenticated session Service Provider

  7. Third Party Identity Assertion and Authorization Log-in to SSO System Company Request token for supplier Token Return signed token containing authentication statement and optionally autorisation to order stuff from supplier Employee Trust relation secured by certificates Present token to prove work-relation and optional authority. Supplier Check signature of company. Knows now a) employee really works for company b) Employee is authorized to order (optional)

  8. Why Third Party Trust is OK • Does receiver really have a trust relation to employee of the company? • What does it mean for the receiver to give the foreign employee a login name and credential? • What happens if the employee • Changes job function? • Leaves the company? • Uses credentials a year later? • Starts buying non-authorized things? • Hands-over login credentials? • How many login credentials does the employee need? • How many times does she use them?

  9. Federated Identity Management Across Domains Token Token User Registry Customer alias Credent. Vault. Author. Server Identity Server Authent Server client Token Reverse Proxy App. Server App. Server Host CSIv2 CSIv2 Internet CSIv2 Token Token Token App. Server WS-S WS-S Internet Token Customer alias Internet External TTP Point of contact Other Company App. Server Token Domain Bridge (TTP) Authentication provider Infrastructure converter GEN0190n.ppt

  10. WS-Trust Server checking foreign Token WS-Trust Server Token Token

  11. Web-based SSO Scenarios • Redirect Mechanism • Background communication • Where are you from • Privacy issues

  12. Redirect of unauthenticated request to identity provider: Pull Szenario 2. Service Provider 1 Identity Provider 302 www.ip.com/original_request= „GET:http://www.SP1.com“ GET:http://www.IP.com with IP-Adresse of SP1.com ls parameter GET:http://www.SP1.com 1. 3. User

  13. Re-redirect back to Service Provider Service Provider 1 Identity Provider 4. Redirect: http://www.IP.com/sp=.... Redirect to Service Provider with token as parameter TOKEN 5. TOKEN User

  14. Functional Extensions to simple Web-SSO • WAYF (Where are you from): How can the service provider know which STI the customer is using? • Account Linking (SP and Customer are members of several STIs/IPs) • Size and content of token • Different user agents and transport protocols (e.g. web-services)

  15. Federative Extensions to simple Web-SSO • Both Service Provider and IP run their own identity management with separate user registries • The customer is using several IPs • The SP has several contract relations with other SPs

  16. Redirect of authenticated user to selected SP (Push Model) „Clicked“ by user TOKEN1 • Dynamic Menue: • Link to SP1 • Link to SP2 • Link to SP3 TOKEN2 TOKEN3 Service Provider 1 Identity Provider Redirect to Service Provider with token as parameter GET:http://www.SP1.com TOKEN1 TOKEN1 GET:http://www.IP.com/loginForm.html User

  17. Front-Channel vs. Back-Channel Back channel communication for extended user information Service Provider 1 Identity Provider Redirect: http://www.IP.com/sp=.... Redirect to Service Provider with token as parameter push mechanism Pull mechanism TOKEN Random number or extended user information (SAML) User Front channel

  18. Account linking with User Alias User_X, PW_X, IP_Alias 123 X_User, PW_Z, IP_Alias 123 Back channel communication for automatic provisioning Service Provider 1 Identity Provider Redirect: http://www.IP.com/sp=.... Redirect to Service Provider with token as parameter Allows mapping between IP Alias and own UserID for user TOKEN: IP_Alias 123 Front channel mapping User At IP: User_X, PW_X At SP1: X_User, PW_Z

  19. Secure Messages with „Active Profile“ – Web Service enabled communication 2. Service Provider 1 Identity Provider, WS-Trust Server WS-Profile data 3. WS-Federation Requests based on WS-Security Messages WS-Profile Messages to learn about requirements 1. 4. TOKEN TOKEN 5. Web Service Client Application

  20. Secure Association Markup Language (SAML) • Policy Expression Language • XML based language for secure statements (Assertions) • Elements like user, attributes, validity constraints, QoS etc. • Authentication Assertion • Attribute Assertion • Authority Assertion • Binding information about transport protocols, get/post methods etc. • Object/Message based security instead of only channel based security

  21. SAML Assertion (example) <saml:Assertion Version="2.0„ ID="_34234se72„ IssueInstant="2005-04-01T16:58:33.173Z"> <saml:Issuer>http://authority.example.com/</saml:Issuer> <ds:Signature>...</ds:Signature> <!– issuer signature  <saml:Subject> <saml:NameID format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"> jygH5F90l </saml:NameID> </saml:Subject> <saml:AuthnStatement AuthnInstant="2005-04-01T16:57:30.000Z"> <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> From: [ANTON06]

  22. SAML embedded in SOAP Header <SOAP-ENV:Envelope> <!– SOAP Spec.  <SOAP-ENV:Header> <wsse:Security> <!– Web Services Security Spec.  <saml:Assertion>user, authentication, issuer etc. </saml:Assertion> </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body>... </SOAP-ENV:Body> </SOAP-ENV:Envelope> From: [ANTON06]

  23. WS-Federation Active Profile Example CompanyXYZ TelCo Provider SSO Portal Internal STI Conference System Link with Forms Post to TelCo Own Token SPNEGO login User: XYZ_guest CN: foo Email: foo@xyz.com TOKEN Company: XYZ User: foo Email: foo@xyz.com employee Mapping of all employees to ONE guest account for XYZ at access manager of TelCo SAML Assertion in Token

  24. ID and time of issued assertion, namespaces galore <saml:Assertion AssertionID="…„ IssueInstant="2007-03-20T12:30:50Z" Issuer="https://www.xyz.com/wsf" MajorVersion="1„ MinorVersion="1„ xmlns:ds=http://www.w3.org/2000/09/xmldsig# xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"> <saml:Conditions NotBefore="2005-07-16T15:14:29Z„ NotOnOrAfter="2005-07-16T15:34:29Z"> <saml:AudienceRestrictionCondition> <saml:Audience>https://www.telco.com/wsf </saml:Audience> </saml:AudienceRestrictionCondition> </saml:Conditions> <saml:AuthenticationStatement AuthenticationInstant="2005-07-16T15:24:29Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"> <saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> emp1@<xyz.com </saml:NameIdentifier> </saml:Subject> </saml:AuthenticationStatement> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> emp1@xyz.com </saml:NameIdentifier> </saml:Subject> <saml:Attribute AttributeName="cn„ AttributeNamespace="http://www.xyz.com/cn"> <saml:AttributeValue>Employee One </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> When is this statement valid? Who is the receiver? Who is authenticated? (subject) What attributes does subject have? federation part of assertion – defines conditions, authentication, subject and subject attributes

  25. <ds:Signature Id="uuid203f1582-0105-efbb-6039-8ce3efd72411„ xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> • <ds:SignedInfo> • <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> • <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> • <ds:Reference URI="#Assertion-uuid203f1557-0105-f23c-5b82-8ce3efd72411"> • <ds:Transforms> • <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> • <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> • <xc14n:InclusiveNamespaces PrefixList="saml ds„ xmlns:xc14n="http://www.w3.org/2001/10/xml-exc-c14n#"/> • </ds:Transform> • </ds:Transforms> • <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> • <ds:DigestValue> sWS4qUyQXSgMRHM62ADxLHGfFD4= • </ds:DigestValue> • </ds:Reference> • </ds:SignedInfo> • <ds:SignatureValue> signature over assertion (according to XMLDsig Spec.)... • </ds:SignatureValue> • <ds:KeyInfo> • <ds:X509Data> • <ds:X509Certificate> XYZ Corp. Certificate,...... • </ds:X509Certificate> • </ds:X509Data> • </ds:KeyInfo> • </ds:Signature> • </saml:Assertion> How signature was created Signature value to Check against Who did it: Signers certificate so receiver (telco) can check signature Non-federation part of assertion – deals only with message security of assertion statement

  26. Identity and Federation in Social Networks • The Tripartite Identity Pattern • OpenID (Technology and the Nascar Problem) • OAuth (Granular access delegation) • XRD/JRD

  27. Randy Farmer developed the above pattern which separates functions of IDs along the dimensions of uniqueness and memorizablity. Account IDs are uniq and can be of arbitrary complexity as they are used only for internal linking and bookkeeping and are never exposed. Login IDs are critical because they need to be both unique and easy to remember. Public IDs are not unique but should be easy to remember. They need additional criteria for disambiguation (pictures, friends, actions). The diagram is taken from „ Super Social Everybody – how to survive in the social web“, Thomas Fankhauser, Stuttgart Media University 2010

  28. OpenID/OAuth • The Password Anti-Pattern • The Nascar Problem • Acceptance and Problems • Service Providers as Identity Provider

  29. The Nascar Problem Too many big labels/icons of identity providers (from: http://factoryjoe.com/blog/2009/04/06/does-openid-need-to-be-hard/)

  30. OAuth/WRAP • Granular Token Generation for Mashups • Message/API Signatures • Simple Bearer Tokens • The Question of Channel Security Spec. At http://oauth.net/core/1.0a/, http://hueniverse.com/2010/05/introducing-oauth-2-0/ http://hueniverse.com/2010/01/open-questions-about-oauth-2-0-authentication/ http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/#comments http://hueniverse.com/oauth/

  31. OAuth Sequence Diagram From: http://d.hatena.ne.jp/ZIGOROu/20090811/1250006392

  32. Facebook Authorization Example From: http://www.uml-diagrams.org/sequence-diagrams-examples.html

  33. Security Analysis • Token Integrity and Confidentiality • Token Verification • Phising with bad redirect to phony IP • Customer confusion about credentials if both SP and IP support their own identity management mechanisms • Privacy problems with Identity Provider • Log-out problem: Guarantees for customer? • Token abuse by SP? • Attack on tokens at client? • Session to IP?

  34. Resources [Anton] E. Anton, Web Services in realen Business-Anwendungen – Sicherheit, Transaktionalität, Geschäftsprozess-Modellierung, Diplomarbeit HdM 2006, http://www.kriha.de/krihaorg/dload/uni/anton.pdf [EBR] J. Eisenmann, A. Rauber, S. Simon, Single Sin On, Software-Projekt HdM 2003, http://www.kriha.de/krihaorg/dload/uni/eisenmann_rauber_simon.zip [Bueck] A. Buecker, W.Filip, H.Hinton, H.Hippenstiel, M.Hollin, R.Neucom, S.Weeden, J.Westman, Federated Identity Management and Web Services Security, IBM Redbook 2005 [End] D. Endler, SessionID Hacking, http://www.idefense.com [SAML] Security Assertion Markup Language(SAML) 2.0: Technical Overview. 2006, http://www.oasis-open.org/committees/download.php/20645/sstc-saml-tech-overview-2%200-draft-10.pdf [Wind] P. J. Windley, Digital Identity – unmasking Identity Management Architecture (IMA), O’Reilly 2005 [WS-FED] H. Lockhart et al., Web Services Federation Language Version 1.1 (2006), http://www.ibm.com/developerworks/library/specification/ws-fed/ [WS-SEC] B. Atkinson et al.: Web Services Security (WS – Security), http://www.ibm.com/developerworks/library/ws-secure

More Related