Welcome to this TechNet Event

1
Welcome to this TechNet Event

• Evaluations are now on-line see reminder
  e-mail for URL
• Pick your Own Collateral
• Special offers for TechNet Plus Subscribers
• Register for BETAs at www.microsoft.com/uk/beta
  central
• Beer and Pizza no more! ?
• No Planned Fire Drills
• Please turn your Mobile Phones off

2
Advances in DigitalIdentity

• Kim Cameron,
• Chief Architect of Identity
• Microsoft

3
Threats to Online Safety

• The Internet was built without a way to know who
  and what you are connecting to
• Internet services have one-off workarounds
• Inadvertently taught people to be phished
• Greater use and greater value attract
  professional international criminal fringe
• Exploit weaknesses in patchwork
• Phishing and pharming at 1000 CAGR
• Missing an Identity layer
• No simplistic solution is realistic

4
What is a Digital Identity?

• Set of claims one subject makes about another
• Many identities for many uses
• Required for transactions in real world and
  online
• Model on which all modern access technology is
  based

5
Lessons from Passport

• Passport designed to solve two problems
• Identity provider for MSN
• 300M users, 1 billion logons per day
• Identity provider for the Internet
• Unsuccessful
• Learning solution must be different than
  Passport

6
The Laws of Identity

• User control and consent
• Minimal disclosure for a defined use
• Justifiable parties
• Directional identity
• Pluralism of operators and technologies
• Human integration
• Consistent experience across contexts
• Join the discussion at www.identityblog.com

7
Identity Metasystem

• We need a unifying Identity metasystem
• Protect applications from identity complexities
• Allow digital identity to be loosely coupled
  multiple operators, technologies, and
  implementations
• Not first time weve seen this in computing
• Emergence of TCP/IP unified Ethernet, Token Ring,
  Frame Relay, X.25, even the not-yet-invented
  wireless protocols

8
Metasystem Players
Identity Providers Issue identities
Relying Parties Require identities
Subjects Individuals and other entities about
whom claims are made
9
Empowers the User
10
InfoCard UserExperience Preview
11
InfoCard Overview

• Simple user abstraction for digital identity
• For managing collections of claims
• For managing keys for sign-in and other uses
• Grounded in real-world metaphor of physical cards
• Government ID card, drivers license, credit
  card, membership card, etc
• Self-issued cards signed by user
• Managed cards signed by external authority
• Shipping in WinFX
• Runs on Windows Vista, XP, and Server 2003
• Implemented as protected subsystem

12
Implementation Properties

• Cards represent references to identity providers
• Cards have
• Address of identity provider
• Names of claims
• Required credential
• Not claim values
• InfoCard data not visible to applications
• Stored in files encrypted under system key
• User interface runs on separate desktop
• Simple self-issued identity provider
• Stores name, address, email, telephone, age,
  gender
• No high value information
• User must opt-in

13
Protected Subsystem

• Prevent disclosure of personal data and keys to
  malicious code on the client
• System service running at elevated privilege
• Encrypted storage accessible only by system
  service
• User session agent process on separate desktop
• System managed user secret displayed in UI
• User interaction required to release PII

14
An Identity Metasystem Architecture

• Microsoft worked with industry to develop
  protocols that enable an identity metasystem
  WS- Web Services
• Encapsulating protocol and claims transformation
  WS-Trust
• Negotiation WS-MetadataExchange and
  WS-SecurityPolicy
• Only technology we know of specifically designed
  to satisfy requirements of an identity metasystem

15
Basic Protocol Flow
Browser w/ InfoCard
Web Site
Web Site Front End
Relying Party
Security Token Server (STS)
Identity Provider (Managed or Self-Issued)
16
InfoCard UserExperience Preview
17
Browser IntegrationDesign Goals

• Minimal impact on web site front end
• Support from multiple browsers
• Fail gracefully if not supported no negative
  impact on user experience for browsers that do
  not support integration

18
Incremental Addition of InfoCard
Web Farm
User
19
OBJECT Tag
lthtmlgt ltheadgt lttitlegtWelcome to
Fabrikamlt/titlegt lt/headgt ltbodygt ltimg
src'fabrikam.jpg'/gt ltform name"ctl00"
id"ctl00" method"post"
action"https//www.fabrikam.com/InfoCard-Browser/
Main.aspx"gt ltcentergt ltimg
src'infocard.bmp' onClick'ctl00.submit()'/gt
ltinput type"submit" name"InfoCardSignin"
value"Log in" id"InfoCardSignin" /gt
lt/centergt ltOBJECT type"application/x-in
formationCard" name"xmlToken"gt ltPARAM
Name"tokenType" Value"urnoasisnamestcSAML1.
0assertion"gt ltPARAM Name"issuer"
Value "urnschemas-microsoft-comws2
00505identityissuerself"gt ltPARAM
Name"requiredClaims" Value
"http//schemas.microsoft.com/ws/2005/05/identity/
claims/emailaddress http//schemas.microsoft.
com/ws/2005/05/identity/claims/givenname
http//schemas.microsoft.com/ws/2005/05/identity/c
laims/surname"gt lt/OBJECTgt lt/formgt
lt/bodygt lt/htmlgt
20
Ubiquitous Implementation a Key Goal

• Fully interoperable via published protocols
• With other identity selector implementations
• With other relying party implementations
• With other identity provider implementations
• Detailed implementation guide available
• The industry has created an Open Source Identity
  Selector Consortium animated by Verisign, Red
  Hat, Novell, IBM, and others
• Microsoft provides technical assistance

21
Components Microsoft is Building

• InfoCard identity selector
• Component of WinFX, usable by any application
• Hardened against tampering, spoofing
• InfoCard simple self-issued identity provider
• Self-issued identity for individuals running on
  PCs
• Uses strong public key-based authentication
  user does not disclose passwords to relying
  parties
• Active Directory managed identity provider
• Plug Active Directory users into the metasystem
• Full set of policy controls to manage use of
  simple identities and Active Directory identities
• Windows Communication Foundation for building
  distributed applications and implementing relying
  party services

22
For More Information

• Whitepapers
• Microsofts Vision for an Identity Metasystem
• The Laws of Identity
• Documentation
• InfoCard implementers guides
• InfoCard browser integration guide
• Code and samples
• Federated Identity and Access Resource Kit
• WinFX runtime
• Links from
• http//www.identityblog.com
• http//msdn.microsoft.com/winfx/reference/infocar
  d/

23
(Backup Slides)
24
WS- Metasystem Architecture
ID Provider
ID Provider
Relying Party
Relying Party
Security TokenService
WS-SecurityPolicy
Security Token Service
WS-SecurityPolicy
Identity Selector
25
Flow with Relying Party STS
Browser w/ InfoCard
1
HTTP(S)/GET (Protected Page) ?
Web Site
? Redirect to Login Page
2
HTTPS/GET (Login Page) ?
? Login Page (HTML) w/ InfoCard Tags
7
HTTP(S)/POST Token to Target Page ?
Web Site Front End
? Cookie Browser Redirect
3
4
InfoCard lights up User selects card
Retrieve Policy ? via WS-MetadataExchange ?
6
5
Token ? via WS-Trust/RST
Get token viaWS-MetadataExchangeand WS-Trust
Token ? via WS-Trust/RSTR
Security Token Server (STS)
Security Token Server (STS)
Relying Party
Identity Provider (Managed or Self-Issued)