Transcript Identity at CACR

Identity management:
Is a change coming?
John Weigelt
Chief Security Advisor / Privacy Compliance Officer
Microsoft Canada
Information Protection
Challenges
Situation
•
Organizations are creating and sharing more information digitally, which
increases the risk of misuse and leaks of sensitive information
• Perimeter security technologies and encrypted delivery control access, not
usage
• Accidental or intentional misuse of information can be costly resulting in
loss of revenue, competitive advantage and customer confidence
• End to end security of information and control of data state difficult
Customer Need
•
•
•
•
Better protection for sensitive information
Protection technology that is easy to use
Flexible, customizable technology that is easy to administer
Technology that augments existing perimeter-based security and encrypted
delivery
• Roaming and secure credential storage
Establishing Trust
• Trust is built through a number of mutually
supporting measures
Legislation
Policies
Procedures
Physical Controls
Application
Features
Inherent
System
Capabilities
Identity Management
Standards-Based
• Kerberos
User/Password
Multi-Factor
• X509
• LDAP Bind
• PEAP (network)
• 802.1x (network)
• RADIUS (network)
Active
Directory
• XrML
Integrated PKI
• Multi-Factor authentication
• Auto-enrollment/renewal
Wireless
Internet/Remote
Single Sign-on
• Kerberos Applications
• Windows Integrated Apps
Extending identification across
trust domains
• X.509 certificates are often used to extend
trust relationship across trust domains
• PKIs provide a strong linkage between
technology and policy in support of ID
management
• Cross certification used to extend trust across
policy boundaries and define:
• Levels of assurance, allocation of liability, service
levels etc.
Integrating Identity Today
Authorization
Challenges in ID Management?
• Certificate Dilemma
• Concerns about DN composition, use,
traceability
• Differing interpretation / use of extensions
• Cross Certification
• Policies don’t address the business
requirements very well
• Agreements difficult to forge
• Trust difficult to extend across policy
domains
• Traditional protocols fundamentally hard to
implement
Grassroots PKI Deployments
Application Driven
• Applications driving PKI
• Wireless network explosion
• Content protection needs
•The market has evolved
• No more “pure play” PKI
• Evolving into operating system and
identity management solution
components
• XrML and Digital Rights
Management
• New applications and protocol
development
SOAP and XML
Internet Transports
Management
Transactions
Security
Messaging
Policy
Discovery
Web
Services
Web Service Specifications
Security Tokens & Claims
Messages have security tokens
that assert claims
Claim – A statement that a client makes (e.g. name,
identity, key, group, privilege, capability, etc).
Unsigned
Username
…
Proof of
Possession
Signed
X.509
…
Kerberos
Password
XrML
SAML
Secret Key
Policies
Web services have policies that
describe required claims
• Policies can also
describe where to get
claims
Policy
?
Does the request have
the correct security tokens?
Security Token Service
A security token service
issues security tokens
Security
Token
Service
Policy
• It is just a web service
• A solution may require
multiple token services
Web
Service
Policy
Federated Identity:
Getting There
•
Key Architectural Principles
• Multiple “authorities” in a “trust network”
•
•
•
•
Each owns their customers and employees
Each owns their infrastructure
Each issues their own credentials
Each can decide whether to accept credentials from
other authorities
The Federation Model
Org #1
Org #2
Business Level Agreement
Defines a Common Namespace
• Terms, Keys, Limits
• Auditing requirements
• Etc.
Private
Namespace
Private
Namespace
Extending trust across domains
B2B Federated Single Sign-on
Security Token
(eg Kerberos Ticket)
Exchange
Web Service
Collaboration
Active
Directory
ADFS
Intranet
Applications
1.
2.
3.
4.
ADFS Creates XRML token
Signs it with company’s private key
Sends it back to the user
Access Supplier with the token
1.
2.
3.
4.
ADFS Creates SAML token
Signs it with company’s private key
Sends the token back to the user
Accesses Supplier B using the token
Supplier A
Supplier B
WS Security
Application
User Account/Credentials
Security Token
Requires XRML
WS Security
Application
Requires SAML
Addressing the challenges
• Certificate Dilemma localized
• Only share claims that are required by the
candidate service
• Security tokens can be used to limit information
that is shared
• Cross Certification de-emphasized
• Claims and policies engage the business
process owner
• Business oriented discussion vs tech discussion
• Aids interoperability by providing the
tailored security tokens
Technology Comparison
X.509 and XrML
X.509
XrML
Binds a public key to an identity;
mainly for the purpose of
authentication of an identity
Grants rights on resources; can be used to
specify trust & authorization policy as well
as authentication; can use public keys for
identifying and authenticating principals
Based on X.509 and IETF (PKIX
working group standards)
XrML 2.x is being standardized by MPEG
ASN.1 encoded certificates and objects
XML encoded licenses and policy
assertions
XrML is consumed by Rights Management
applications; currently used by Office 2003
and Rights Management Server
Application support includes SSL/TLS,
S/MIME, digital signatures, PKINIT
Limited policy enforcement such as
name constraints, application
constraints and organizational policy
definitions
Rich and extensible policy language for
defining principals, rights, resources, and
conditions over usage and content
Looking Ahead
Choosing the Right Technology
•
Both X.509 and XrML will coexist and be supported in
applications for the next 10
years (minimum)
• Existing application standards will
remain in place
• X.509 certificate mapped into XrML
structures
• X.509 identity combined with XrML
authorization policies
•
New application protocols will
likely adopt XrML over X.509
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.