Docstoc

BrainShare_mbj+dolds_21-Mar-07

Document Sample
BrainShare_mbj+dolds_21-Mar-07 Powered By Docstoc
					Who are you?
From Directories and Identity Silos to Ubiquitous User-Centric Identity
Mike Jones, Microsoft and Dale Olds, Novell

Who are you?
Question central to
enabling you to do things you're entitled to do, preventing you from doing things you’re not.

True in both
physical world, online world.

Who are you (online)?
Past, present, and future:
From directories, to identity silos, to ubiquitous, interoperable, user-centric digital identity.

The Bad Old Days
Username/password per application
But that’s preposterous and inconvenient!

The Bad Old Present
Username/password per web site
But that’s preposterous and inconvenient!

Enter Directory Services
Identity attributes for users in a central repository Allows multiple applications within a domain to share identities Attributes can be retrieved by applications Examples:
LDAP implementations Novell eDirectory Microsoft Active Directory

Directory Services Advantages
Applications within the domain can use the same identity attributes Allows enterprise single-sign-on within participating applications Some directory interoperation via LDAP, virtual directories, meta-directories And, recently shown at Monday's keynote, federation

Directory Services Disadvantages
Several incompatible protocols – silos Applications know which directory they use Identities only valid usable a single domain Disjoint and overlapping domains are inevitable as organizations evolve

Directory Services, Meta and Virtual Directories
Very useful systems which solve some of silo problems of overlapping identity domains Accessed as a central repository of identity data by many other services Services and revisions of services accumulate over time Control of repository schema and updates becomes political The central repository tends to become an immovable political mass

Identity Silos
In the Web and within the enterprise, disjoint identity domains are common Username/password per site X.509, Kerberos, SAML have not helped Each with its own protocol Each operates only within its own silo

Enter Federation
Enables use of identities at other sites Advantages
Extends login identities to other trust domains Standards-based interoperation

Disadvantages
Requires establishing explicit trust relationships No user choice of which identity to employ relative to each domain

Examples
SAML based federation WS-Federation based federation OpenID

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

The Laws of Identity
Established through Industry Dialog
1.

User control and consent

2.
3. 4. 5. 6.

Minimal disclosure for a defined use
Justifiable parties Directional identity Pluralism of operators and technologies Human integration

7.

Consistent experience across contexts

Join the discussion at www.identityblog.com

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 we’ve seen this in computing
Emergence of TCP/IP unified Ethernet, Token Ring, Frame Relay, X.25, even the not-yetinvented wireless protocols

Enter User-Centric Identity
Enables people to choose which of their identities to use at which sites
Analogously to how they choose which card to pull out of their wallet in different circumstances

Used through Information Card metaphor
Visual cards represent different identities

Benefits
People in control of their identity interactions Easy to use – no passwords to remember! Strong crypto – instead of shared secrets Phishing-resistant

Identity Roles
Identity Providers
Issue identities

Relying Parties
Require identities

Subjects
Individuals and other entities about whom claims are made

Information Cards
SELF - ISSUED MANAGED

Contains self-asserted claims about me Stored locally Effective replacement for username/password Eliminates shared secrets Easier than passwords

Provided by banks, stores, government, clubs, etc. Cards contain metadata only! Claims stored at Identity Provider and sent only when card submitted

CardSpace Experience

Information Card Properties
Cards are references to identity providers
Cards have:
Address of identity provider Names of claims Required credential

Not claim values

Information Card data not visible to applications
Stored in files encrypted under system key User interface runs on separate desktop

Self-issued information cards
Stores name, address, email, telephone, age, gender No high value information Effective replacement for username/password

Open Identity 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 WSSecurityPolicy

Technology specifically designed to satisfy requirements of an Identity Metasystem

Not just a Microsoft thing…
Based entirely on open protocols Identity requires cooperation – and you’re seeing it today! Interoperable software being built by
Novell, IBM, Sun, Ping, BMC, VeriSign, … For UNIX/Linux, MacOS, mobile devices, …

With browser support under way for
Firefox, Safari, …

Unprecedented things happening
Microsoft part of JavaOne opening keynote Microsoft sponsoring BrainShare

LINUX Journal Sep ’05 Cover
By Doc Searls Linux Journal Editor Author of the “cluetrain manifesto”
Introducing “The Identity Metasystem”

WIRED Magazine - Mar ’06
By Lawrence Lessig Influential Internet & Public Policy Lawyer Special Master in antitrust case against Microsoft
Quotation:

Microsoft Open Specification Promise (OSP)
Perpetual legal promise that Microsoft will never bring legal action against anyone for using the protocols listed
Includes all the protocols underlying CardSpace

Issued September 2006

http://www.microsoft.com/interop/osp/

For More Information
http://cardspace.netfx3.com/ http://www.bandit-project.org/
Mike Jones – mbj@microsoft.com Dale Olds – dolds@novell.com

(Backup Slides)

Protocol Drill Down
User
7 User approves release of token 4 User selects an IP

Client
1 Client wants to access a resource

Request security token

5

3

Which IPs can satisfy requirements? 2 RP provides identity requirements

6 Return security token based on RP’s requirements 8 Token released to RP

Identity Provider (IP)

Relying Party (RP)


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:12/18/2009
language:English
pages:27