Integrating Identity

Services into Web Apps

Gunnar Peterson
CTO, Arctec Group
gunnar@arctecgroup.net

OWASP
AppSec
DC
October 2005 Copyright © 2005 - 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

http://www.owasp.org/
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 2005 2

Identity is under attack (cont.)

 Identity risks (cont.)

 Publicly reported data breaches since the Choicepoint
incident (2/15/05)
http://www.privacyrights.org/ar/ChronDataBreaches.htm
 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 email)
– 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 2005 3

Understanding Identity

 Foundations of Identity
 Subjects
 Claims
 Claims about subjects are evaluated to negotiate access

OWASP AppSec DC 2005 4

The Laws of Identity

 Codified on Identityblog.com
 Why do we need laws to deal with identity?

OWASP AppSec DC 2005 5

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
OWASP AppSec DC 2005 6
handles
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: the unifying identity

metasystem must guarantee its users a simple, consistent
experience while enabling separation of contexts through
multiple operators and technologies.

OWASP AppSec DC 2005 7

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 2005 8
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 2005 9

Impersonation & Delegation

Alice Alice
Bob Charlie
Thin
Client Bob Charlie DB Impersonation
Web App Server
Server Server

Alice
Thin
Client Bob Charlie DB Delegation
Web App Server
Server Server
Alice
Alice Alice

Review “Security Design Patterns” by Blakley & Heath for a

full treatment of options OWASP AppSec DC 2005 10
Federated Identity

Security Domain Security Domain

App Federation
Alice Red Green App/ Resources
Fed Fed
User Server Server
Store

Standards support and emerging toolsets and vendor

support in Federation space: SAML, WS-Federation,
Liberty

OWASP AppSec DC 2005 11

Alice in Identityland

 Problems in distributed systems are that the identity silos

do not reflect the security context of the transaction
Alice
Thin
Client Bob Charlie DB
Web App Server
Server Server

Silo Silo Silo Identity Silos are

tightly coupled

OWASP AppSec DC 2005 12

Alice in Identityland

 Use an Identity Abstraction Layer to facilitate

interoperability, security, and loose coupling
Alice
Thin
Client Bob Charlie DB
Web App Server
Server Server
SAML Kerb X.509

Identity Abstraction Layer

Support query, update, attribution

Silo Silo Silo

Standards and vendor/tool support emerging: WS-Trust for security token

exchange, creation, and validation for SAML, Kerberos, Username/pwd,
X.509 OWASP AppSec DC 2005 13
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 2005 14

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 2005 15

Guarding the Keys to the Kingdom

Hardening identity servers and

services
Design for failure
Usability
Incident response
Assurance
Availability

OWASP AppSec DC 2005 16

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 2005 17

Where to go from here

 OWASP Guide
 Build Security In DHS Portal
 https://buildsecurityin.us-cert.gov/portal/article/bestpractices/assembly_integration_and_evolution/Iden

 Blogosphere
 Identityblog identityblog.com
 Id Corner idcorner.org
 Open Group
 Jericho Forum focused on deperimeterization
 http://www.opengroup.org/jerichoforum
 Security Design Patterns:
 http://www.opengroup.org/bookstore/catalog/g031.htm

OWASP AppSec DC 2005 18