Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License. The OWASP Foundation OWASP AppSec DC October Integrating Identity Services into Web Apps Gunnar Peterson CTO, Arctec Group

OWASP AppSec DC Identity is under attack  Identity risks  Anti-Phishing Working Group July report of 14,135 phishing reports excerpt  Number of brands hijacked by phishing campaigns in July: 71  Number of brands comprising the top 80% of phishing campaigns in July: 6  Country hosting the most phishing websites in July: United States  Contain some form of target name in URL: 46 %  No hostname just IP address: 41 %  Percentage of sites not using port 80: 9 %  Average time online for site: 5.9 days  Longest time online for site: 30 days  Key finding: study found 174 unique applications for password stealing, and 918 unique password stealing malicious URLs

OWASP AppSec DC Identity is under attack (cont.)  Identity risks (cont.)  Publicly reported data breaches since the Choicepoint incident (2/15/05)  Over 50 million personal information records stolen including (very abbreviated list) –Bank of America 1.2 million (lost backup tape) –San Jose Med. Group 185,000 (stolen computer) –Wachovia 676,000 (dishonest insider) –Dept of Justice 80,000 (stolen laptop) –Univ of Utah 100,000 (hacking) –Lucas County Children Services 900 (exposed by ) –Merlin Data Services 9,000 (Bogus account setup) –Lexis Nexis 280,000 (password compromised)  The world is flat: identity attacks target identity data wherever it is found - small companies, big companies, government, non-profit, educational institutions, home users.

OWASP AppSec DC Understanding Identity  Foundations of Identity  Subjects  Claims  Claims about subjects are evaluated to negotiate access

OWASP AppSec DC The Laws of Identity  Codified on Identityblog.com  Why do we need laws to deal with identity?

OWASP AppSec DC The Laws of Identity -- identityblog.com  1. User control and consent: Technical identity systems must only reveal information identifying a user with the user's consent  2. Minimal disclosure for a constrained use: The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution.  3. Justifiable parties: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship  4. Directed Identity: A universal identity system must support both "omni-directional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles

OWASP AppSec DC The Laws of Identity -- identityblog.com (cont.)  5. Pluralism of operators and technologies: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.  6. Human integration: The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks  7. Consistent experience across contexts: t he unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

OWASP AppSec DC Architecting Identity  Identity Lifecycle  Generation  Representation  Consumption Usage  Transformation  Identity architectural concerns  Access control  Regulatory and legal  Privacy  Personalization  Domain attributes  Provisioning  Audit and reporting  Identity mapping services  Concerns can conflict and cascade

OWASP AppSec DC Architecting Identity  Risk examples  Promiscuous identity - Identity information leakage across domains  Disclosure of personal information  Overall vulnerabilities in weak identity implementations: custom coded identity layers and functions, username and password, password recovery  Phishing  User knowledge  Offline combination of personal information - data mining  Lack of full lifecycle protection of identity information  Lack of consistent usage of identity in distributed systems - inherent tradeoffs in using proxies, impersonation, delegation, etc.  Weaknesses in identity cascade across system - developers are instructed not to write their own crypto algorithms, but home grown identity system “protect” the crypto functionality

OWASP AppSec DC Impersonation & Delegation Bob Web Server Charlie App Server DB Server Alice Thin Client Bob Web Server Charlie App Server DB Server Alice Thin Client Alice Bob Charlie Impersonation Delegation Alice Review “Security Design Patterns” by Blakley & Heath for a full treatment of options

OWASP AppSec DC Security Domain Federated Identity Security Domain Federation User Store Alice App Red Fed Server Green Fed Server App/ Resources Standards support and emerging toolsets and vendor support in Federation space: SAML, WS-Federation, Liberty

OWASP AppSec DC Alice in Identityland  Problems in distributed systems are that the identity silos do not reflect the security context of the transaction Silo Bob Web Server Charlie App Server DB Server Alice Thin Client Identity Silos are tightly coupled

OWASP AppSec DC Alice in Identityland  Use an Identity Abstraction Layer to facilitate interoperability, security, and loose coupling Silo Bob Web Server Charlie App Server DB Server Alice Thin Client Identity Abstraction Layer Support query, update, attribution Standards and vendor/tool support emerging: WS-Trust for security token exchange, creation, and validation for SAML, Kerberos, Username/pwd, X.509 SAML KerbX.509

OWASP AppSec DC Identity Abstraction Layer  Identity Runtime Services:  Abstract identity implementation details from interface  Authoritative source for identity data  Reporting services:  Audit, logging, reporting  Differentiate between runtime services and provisioning

OWASP AppSec DC Identity Abstraction Layer  Goals  Abstract back end systems, similar to how a data access layer works in n tier systems  Use strong identity standards for interoperability across domains  Service oriented focus: decouple identity from systems  Functions  Access control  Naming services  Checkpoint services  Common descriptor format  Consistent interface, api, and data exchange format for accessing and updating identity data

OWASP AppSec DC Guarding the Keys to the Kingdom  Hardening identity servers and services  Design for failure  Usability  Incident response  Assurance  Availability

OWASP AppSec DC Project Roles  Identity architect: identity system architecture and implementation  Application architect: responsible for application requirements  Developer: writes code (and unit tests) but should not be writing custom crypto, password recovery, and provisioning systems

OWASP AppSec DC Where to go from here  OWASP Guide  Build Security In DHS Portal  cert.gov/portal/article/bestpractices/assembly_integration_and_evolution/Identity_in_Assembly_and_Integration.xml cert.gov/portal/article/bestpractices/assembly_integration_and_evolution/Identity_in_Assembly_and_Integration.xml  Blogosphere  Identityblog identityblog.com  Id Corner idcorner.org  Open Group  Jericho Forum focused on deperimeterization   Security Design Patterns: 