Federated Security Patterns with SAML (SSO vs. POLA)

1. Federated Security Patterns with SAML (SSO vs. POLA) A tail of two visions Identity Management dreams of Single Sign-On while Authority Management adopts the Principle of Least Privilege FAU-Secure Systems Research GroupKen Hamer-Hodges, ken@sipantic.net

2. SSO – 8 Unsolved Problems • SSO demands Federated-Trust • Multi-dimensional problem of administration domains • SSO Amplifies staff changes and escalates Roles • Client changes become server overheads • SSO leads to Information Mismanagement • Servers learn about client organization • SSO is Unresponsive to Organization Needs • Delegation consistency is hard to arrange or Revoke • SSO Governance leads to loss of Policy Control • ID and Password abuse and data inconsistency • SSO increases Ambient Authority risks • All of a ‘principals’ domain authorities are exposed to attack • SSO Distributed Management limits scale • Unsynchronized updates lead to service failures • SSO System Improvements are resisted • Complexity lock down Federated evolution

3. SSO - The Simple Case • One on One • Clients must first provide Services • With the URL for the Client’s SSO service • Client’s public key for service to verify SAML responses http://code.google.com/apis/apps/sso/saml_reference_implementation.html

4. eBay PayPal BankAccount FaceBook Corporation Branch 1 1 1 1 Domain 2 2 2 2 3 3 3 3 1 1 1 4 4 4 4 2 2 2 5 5 5 5 3 3 3 6 6 6 6 4 4 4 7 7 7 7 5 5 5 6 6 6 7 7 7 SSO - The Realistic Case Like… • Domains have their own rules • For principles • To Sign On • To Transfer to eBay • To Check PayPal • Access Policy issues • Face Book based on Originator • How about eBay and PayPal? • Originator or what? • What about Your Bank? • Trust is doubtful! • The Originator or some 3rd Party Intermediary • Who decides? • Not you! Like You Thanks to Alan Karp et al

5. Trusted Partner SAML Policy Identity Policy Federated Identity Management • Managing Identities is hard • Access Control List synchronization • Federating Identities is worse • Every client adds to the cost of service • This negative feedback limits growth • How can a domain control access? • Look up policy by identity • Who is the real Identity? • Access is based on the policy • Access Control Lists set to match • If Access Policy is defined • Then use a Capability Pattern • Convey policy with the identity • Certify Access rights to a service • Chained to Some Method on an Object

6. IBAC Client change are Server problems! Services authorize IDs ALC set for roles/identities Know all users and rights Update as users change Many service partners Many more identities Third party mashups Scalability is THE problem ZBAC Client Changes are only Client problem! Service sells Access contracts Capabilities to service As access to a contract Clients manage them Distribute by roles A capabilities for a contract Include ways to revoke Scalability is possible Policy Management Options Authorization-Based Access Control for the Services Oriented Architecture Alan H. Karp, HP Laboratories Palo Alto

7. ~50% Management Overhead IBAC Example UC 1. Client sends a Signed Contract to corporate! 2. Manager sends a service-request to client. 3. Client approves user to corporate. 4. Corporate sends site-credentials to manager. 5. Manager sends Work-requests to work site. 6. Work site sends credentials to manager. 7. Manager sends service account to work site. 8. Manager sends credentials to corporate. 9. Manager sends staff-request to client. 10. Client approves identity at corporate. 11. Corporate returns credentials to staff. 12. Staff sends Work-request to work site. 13. work site returns work-credentials to staff. 14. Staff loads Work to the work site. 15. Staff loads work-credentials at corporate. 16. Staff sends Work request to service. 17. service requests Work at work site. 18. work site sends Work to the service. 19. service sends Job-result to staff.

8. Trade Off Questions • Questions of • Identity control and security policy administration • Authority controls and POLA “Least Authority” rules • These issues have been debated for decades • First as computers developed • Centralized governance (Mainframe time-share requirement) • Distribution and delegation (Fault tolerant design requirement) • Now as the Internet grows • Mainframe traditions (Like Cobal – will never die) • Internet browsing (The new open paradigm) • Eventually as working infrastructure • Proprietary solution (Ownership driven) • Open applications (beyond Open-source)

9. Using SAML as an Authority • Follows Capability Law • Trustworthy abstractions with Watermarks • Encapsulation, dynamic binding with access limits • This is Object Oriented POLA or O-Cap • Service owners “Mint” SAML certificates • “Watermarked” currency - the service assertion • Location + service name + owner’s public key • Authorization field or Deeded Value - the rights delegated • Made out to bearer – the “authority owner” • Authority Delegation • The “authority owner” Mints a delegate certificate with • A public key, the service assertion - some lesser deeded value • This new certificate has provable authority • A Service watermark and a Delegation watermark chain • The Delegation chain can be cut by any prior owner

10. SAML as a Capability Used when revoking • Note that the permissions can be removed for any methods of the service at any point in a delegation chain • READ • WRITE • PRINT • DELEGATE • REVOKE AssertionID="_9f225bc3-2506-4a2b-9ce3-…. “Issuer="BrochureServiceAuthority“ NotBefore="0001-01-01T00:00:00Z“ NotOnOrAfter="9999-12-31T23:59:59Z" Resource=http://www.xyz.com/services/BS.asmxDecision="Permit" saml:NameIdentifier Format="X509SubjectName">CN="Corporate O=XYZ" <saml:Action Namespace="http://www.xyz.com/services/BS.asmx">Print</saml:Action> <saml:Action Namespace="http://www.xyz.com/services/BS.asmx">Revoke</saml:Action> <saml:Attribute AttributeName="PrintLimit“ AttributeNamespace="urn:zebra:copy:brochure_service:Print"> <saml:AttributeValue>10000 Signature><SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#_9f225bc3-2506-4a2b-9ce3-292560062455"> <Transforms><TransformAlgorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <TransformAlgorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <DigestValue>cC36y6LC8S1L4yh8fIq8IaLyNi4= <SignatureValue>F9KnRXR19AvmA0uGinqYmQNli4uLy9m8xcm…</SignatureValue> <KeyInfo><X509Data> <X509Certificate>MIIBwjCCASsCBEYUK9QwDQYJKoZIhvcNAQEE… Deeded values The Watermark Thanks again to Alan Karp et al

11. ~20% Management Overhead ~25% less Total Work ZBAC Use Case 1. Service self-signed certificate to corporate! 2. Client sends signed contract to corporate. 3. Corporate returns contract certificate to client. 4. Client sends manager certificate to manager. 5. Manager gives role certificate to staff. 6. Manager sends Work request to content service. 7. Content service sends Work certificate to manager. 8. Manager delegates Work certificate to staff. 9. Staff requests Work certificate at content service. 10. Content service returns certificate to staff. 11. Staff sends Work certificate to Service. 12. Service request jobs at content service. 13. Content service returned work to the Service. 14. Service sends the results to the staff.

12. IBAC Multi-dimensional overheads Jobs changes impact all Administrations IBAC policy updates Updates to ACLs Individual overhead Certificate maintenance ID/PW and Key storage Alternative technologies Security Abdication Unclear dialog boxes No single ownership responsibility ZBAC Authority flow is easy Delegate to subordinates People are responsible No outside approval Informed decision through local knowledge Can revoke prior copies Usability Improves A few clear Pop up dialog boxes Ownership is clear Based on public keys No Bureaucracy needed SSO and Federated-Trust

13. IBAC Client changes are multi-service overheads Slow to synchronize Role Definition vary Explosion in roles Share credentials Users find ways to get their jobs done Easy passwords Impersonation Undermines “Policy Overhead limits scale Fails with Mashups ZBAC Voluntary Oblivious Compliance Rights amplification Two authorizations rule One for access another for decryption Avoid policy leaks Use a Proxy service Policy violations are rare Enforce at Policy Decision Point Escalating Changes in Roles

14. IBAC Seepage Servers learn about client Detailed organization issues More overhead to remove deputy access Jobs in process may be lost Revoking access may cross departments Others lose access and tasks ZBAC No Identities Only Certificates Instant synchronization Avoid delay in revoking access Simple mechanism Revoked rights are specific and limited No reflected impacts On other authorities Any prior authority-owners can revoke the delegation chain Information Mismanagement

15. IBAC Roles for certain services Delegating may be denied for policy to be enforced Delegation is impossible if it violates policy People get around this problem by sharing credentials ZBAC Delegation is easy Orthogonal to policy Provided with the authorization Identity and attribute information Information supports policy A service can still deny a request if the policy matters Policy Compliance

16. IBAC Consistency is hard Not easy to scale For deputies or temps who need access Someone sets up ACLs Locally and centrally through system admin So people share credentials Passwords and private keys are abused Reduced Security ZBAC Distributed policy management Quick and easy team work Manages tasks without bothering outsiders Outsiders know nothing about local need Easy D/R Local decision only Orthogonal to policy Based on Key Chain Watermarks can be checked at any time Delegation & Revocation

17. IBAC Global name space problem How to trace orders to Identities is not easy The service cannot tell When asked dumb request Overwrite wrong files Service cannot check Client invocation Such as Global arguments ZBAC Local Name Space Advantage Follows a Need to Know rules (POLA) Deputies cannot be confused Authorization and designation are seamless Authority is chained to exactly the intended service Defense in depth Policy and Control

18. IBAC Single Sign-On exacerbates problems Each session has even more authority All of a ‘principals’ authorities are exposed A process has all the rights of the Identity A virus can do anything the Identity can do Bigger attack surface Scale leads to an increased attack surface ZBAC Processes act through Ownership of a Capability There are no needed Identities A subset of some authority owner’s rights Only delegate the needed rights Limited by time Limited by actions Defense in depth Granularity leads to scale Ambient Authority

19. IBAC Identities are not Transitive SSO is not simple Ambient Authority grows What Identities to use? Distribution Across distributed domains Multiple authentications Inefficiency Unsynchronized updates lead to service failures outFilewrite(inFileread()) One identity with all rights Undermines “Security” ZBAC Authorities are Transitive Forwarding rights is simple Delegate the needed rights Third Party rights included Rights origin may vary Some from a Client Others from a Service outFilewrite(inFileread()) All necessary authorizations are delegated Distributed Identity Management

20. IBAC Complexity blocks evolution SAML 1.0 to 2.0… New Service Introduction Client setup Hard to Understand No one known who to deal with on problems Ballooning Bureaucracy Productivity falls Stagnation leads to failure ZBAC Simplicity encourages improvements Safe JavaScript Caja and Chrome Mashups made easy Open Application reuse Rapid business improvements Multi level solution SAML Authorization Language Constraints System Enforcement Hardware Typing System Evolution

21. ZBAC Summary • No Global name space, neither Names or Identities • Supports the Principle of Least Authority (POLA) • No Distributed Governance or Bureaucracy • Easy Localized Delegation with Watermark chain • Built in Revocation at any link in the chain • Directed Scalability to add Mashups quickly • Autonomous Upgrade no synchronization issues • No Ambient Authority but defense in-depth • Trust entities are simplified to one-on-one • Open Application adoption – beyond Open Source

22. Observations • Identification-Based Access Control • Ambient Authority problem • Out of control on the Internet • Synchronization across Federated Bureaucracies • Single Sign On is really hard work • “Interneting” is not like “computing” • Applications span administrative domains • More users with increased insecurity • Dynamic rate of change • No one party managing correctness • Authorization-Based Access Control • Made for distributed systems • Less fragile with deeper security • More functionality with increased protection • Well proven examples to build upon

23. Conclusions • Avoid Single Sign-On • Testing for “Who are you and what do you want?” • Use API’s protected by Watermarked Contracts • Check instead “Did I authorized this?” • Self-signed SAML-SOA Interfaces • Design Capability Protected Contracts • Build Trust Relationships based on Protected Contracts • Self-signed certificates • Move Policy controls to the Client! • Get more Functionality with better Security • Other Options • Capability Languages, Memory Safe Virtual Machines or Typed Hardware

24. References • Adapted from • OASIS, • “Security Assertion Markup Language (SAML) 2.0 Technical Overview, Working Draft 05”, 10 May 2005, • http://www.oasisopen.org/committees/download.php/12549/sstc-saml-tech-overview-2%5B1%5D.0-draft-05.pdf • Authorization-Based Access Control For the Services Oriented Architecture • Alan H. Karp, HP Laboratories Palo Alto • HPL-2006-3, January 3, 2006 • Zebra Copy • A Reference Implementation of Federated Access Management • Jun Li, Alan H Karp, AAL, Client Laboratories, • HPL-2007-105, June 28, 2007