Federated Security Patterns with SAML SSO vs' POLA

1
Federated Security Patterns with SAML (SSO vs.
POLA)

• A tale of two visions
• Identity Management dreams of Single Sign-On
  while
• Authority Management adopts the Principle of
  Least Privilege

FAU-Secure Systems Research Group Ken
Hamer-Hodges, ken_at_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 service 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 Clients SSO service
• Clients public key for service to verify SAML
  responses

http//code.google.com/apis/apps/sso/saml_referenc
e_implementation.html
4
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
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
Policy Management Options

• 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

Authorization-Based Access Control for the
Services Oriented Architecture Alan H. Karp, HP
Laboratories Palo Alto
7
IBAC Example UC
50 Management Overhead

• 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 owners 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
AssertionID"_9f225bc3-2506-4a2b-9ce3-.
Issuer"BrochureServiceAuthority
NotBefore"0001-01-01T000000Z
NotOnOrAfter"9999-12-31T235959Z" Resourcehttp
//www.xyz.com/services/BS.asmx Decision"Permit" s
amlNameIdentifier Format"X509SubjectName"gtCN"Co
rporate OXYZ" ltsamlAction Namespace"http//www.
xyz.com/services/BS.asmx "gtPrintlt/samlActiongt
ltsamlAction Namespace"http//www.xyz.com/servic
es/BS.asmx "gtRevokelt/samlActiongt ltsamlAttribute
AttributeName"PrintLimit AttributeNamespace"urn
zebracopybrochure_servicePrint"gt ltsamlAttribu
teValuegt10000 SignaturegtltSignedInfogt ltdsCanonical
izationMethod Algorithm"http//www.w3.org/2001/10
/xml-exc-c14n"/gt ltSignatureMethod
Algorithm"http//www.w3.org/2000/09/xmldsigrsa-s
ha1"/gt ltReference URI"_9f225bc3-2506-4a2b-9ce3-2
92560062455"gt ltTransformsgtltTransformAlgorithm"htt
p//www.w3.org/2000/09/xmldsigenveloped-signature
"/gt ltTransformAlgorithm"http//www.w3.org/2001/10
/xml-exc-c14n"gt ltDigestValuegtcC36y6LC8S1L4yh8fIq8
IaLyNi4 ltSignatureValuegtF9KnRXR19AvmA0uGinqYmQNli
4uLy9m8xcmlt/SignatureValuegt ltKeyInfogtltX509Datagt lt
X509CertificategtMIIBwjCCASsCBEYUK9QwDQYJKoZIhvcNAQ
EE

• 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

Deeded values
The Watermark
Thanks again to Alan Karp et al
11
ZBAC Use Case
20 Management Overhead 25 less
Total Work

• 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
SSO and Federated-Trust

• 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

13
Escalating Changes in Roles

• 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

14
Information Mismanagement

• 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

15
Policy Compliance

• 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

16
Delegation Revocation

• 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

17
Policy and Control

• 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

18
Ambient Authority

• 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 owners rights
• Only delegate the needed rights
• Limited by time
• Limited by actions
• Defense in depth
• Granularity leads to scale

19
Distributed Identity Management

• 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

20
System Evolution

• 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

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 APIs 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/1
  2549/sstc-saml-tech-overview-25B15D.0-draft-05.p
  df
• 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

25
A Capability Example

• UNIX Example two ways to Copy a file
• Using global names means any file is valid
• cp foo.txt bar.txt
• Using file descriptors limits access to 2 files
• One can be read only, the other write only
• cat lt foo.txt gt bar.txt
• Using file descriptors uses only local names
• Follows the Need to Know Rule
• No global names
• So knowledge of also means local access
• Bundle permission and alias together
• Creates a Capability

26
Capability Security

• Defense-in-depth
• User defined Locks and Keys in the abstract
• Natural and intuitive for implementing POLA
• Works in Networks for Distributed System
• Proven commercially Plessey Multiprocessor
• Capabilities are Authorized Access Rights
• Cannot be successfully guessed or picked
• Acquired by Reference
• From someone who willingly grants access
• The single act of Designation
• A mouse Click or Pass by Reference
• Convey the (needed) object(s)
• Grants the limited (considered necessary)
  authority
• Revocation is Dynamic (in Real Time)
• By changing the lock

27
O-Cap and POLA Today

• Polaris (Alan Karp et al)
• A Windows Desktop with POLA
• Polaris changes the way programs are launched
• E Language now Caja (Mark S. Miller et al)
• CapDesk, Darpa Browser next Chrome
• Capability based DeskTop Application Launching
• Rendering is capability confined
• Joe-E v0.21
• Adrian Mettler, David Wagner, Tyler Close
• Emily
• Marc Stiegler

28
Caja and Mashups

• Caja Goals
• A Concrete box
• Hosting page is in control
• Tamed JavaScript
• No redirects, phishing pages
• No malware
• Requests are proxied
• No XSS
• Sanitized DHTML
• Typed IO
• Mashups
• Open (Trusted) Applications
• Directed Scalability
• Fast service construction

29
Other Reading

• Early Capability Publications
• Jack B. Dennis, Earl C. Van Horn, Programming
  Semantics For Multiprogrammed Computations
  (1966) 
• Hamer-Hodges, "A Fault-Tolerant Multiprocessor
  Design for Real-time Control" Computer Design,
  Dec. 1973, pp. 75-81.
• Present Day O-Cap
• Robust CompositionTowards a Unied Approach to
  Access Control and Concurrency Control Mark
  Samuel Miller
• Stiegler, E in a Walnut, http//www.skyhunter.co
  m/marcs/ewalnut.html
• Mark Miller, Chip Morningstar, Bill Frantz,
  Capability-based Financial Instruments,
  Proceedings of Financial Cryptography 2000,
  http//www.erights.org/elib/capability/ode/index.h
  tml
• Jonathan Rees, "A Security Kernel Based on the
  Lambda-Calculus", (MIT, Cambridge, MA, 1996) MIT
  AI Memo No. 1564. http//mumble.net/jar/pubs/secur
  eos/.
• J. S. Shapiro, S. Weber Verifying the EROS
  Confinement Mechanism, 2000 IEEE Symposium on
  Security and Privacy. http//www.eros-os.org/paper
  s/oakland2000.ps
• Google-Caja - A source-to-source translator for
  securing Javascript-based web content